Compile on windows

[q-depot]

Hi,

I'm trying to compile the driver on windows and I have quite a few issues. First of all I don't understand why there are two different libraries included in the driver folder, j4cDAC and libetherdream, the latter seems to be specific for unix.

j4cDAC seems more windows friendly, however I had to make lots of changes to fix the errors, but then I stumbled upon some others that I can't resolve, an example is the gettimeofday function that doesn't exist on windows.

I'm trying to include the driver source code instead the dll mainly because the dll doesn't seem to be working properly, some functions are working and some others are not, for instance EtherDreamGetCardNum completely block the execution of my program and I can't debug the dll.

I think the easiest thing would be to include the libetherdream source in my app, or compile it as a library, is this possible?

thanks Andrea

[elliotwoods]

Hey Hey Andrea!

Also hitting similar issues.

I've been editing libetherdream to be Visual C++ compatible, but not fully successful yet (have to convert to winsock).

I downloaded Code::Blocks to build with MinGW to use as DLL, but that still doesn't work :) (still needs winsock). So how is etherdream.dll actually built?

My issue is I need to bring it into a 64bit VC++ project.

Any tips?

[elliotwoods]

to note. andrea send me his code but it didn't work for me out of the box so i went back to my own code.

here's how far i've got with my attempt: https://gist.github.com/elliotwoods/d550d6a8e0e9da7f20d74b091b40959d which works well enough to send single patterns but had troubles with continuous streaming it's designed to be cross-platform, but is C++11 reliant to keep things tidy

If I can't get this working perfectly, then I'm looking to implement the network signalling directly with new code (e.g. ASIO or other simple cross-platform network library).

[push-pop]

Hi there,

Elliot, I got your code working OK and using a repeat value of -1 I could sometimes get an image up for a second before the socket would close.

I started new code for this using ASIO. ~~Unfortunately following the same logic as the driver here, I seem to have the same issue. After I send begin command, the next bit of data I send gets a "An existing connection was forcibly closed by the remote host" from my TCP client. Seems like there is a problem with the host, as it is closing the socket on me.~~

Have you revisited this or have any ideas?

Edit: I just updated the firmware on my etherdream device and Elliot's code is working much better. Still can only stream for ~30 seconds max before I get NAK invalid command with the command 'd' and it gets stuck in a state where the prepare command won't ACK

[elliotwoods]

hi @push-pop. thanks for giving my code a try i tend to find my code highly unreliable, but i'm able to occasionally send a shape to the device which it'll keep looping through. i haven't tested again recently but would love to be kept updated if you found a way to get past this hurdle. did you try your own ASIO code after updating the firmware?

[push-pop]

@elliotwoods I did give my code a try, it has very similar issues. It seems that the server on the DAC does not guarantee returning ACKs so pending acks can get out of control, then when the client tries to send the prepare message again, it blocks forever waiting for acks that will never come. You can "improve" performance by unblocking that code, but then the laser flashes on an off, and I am still receiving some NAKs when streaming data.

I took a look at the DAC driver code, and I can't tell where these NAKs would even get sent from, since I didn't see a code path where the command 'd' returns a NAK.

Planning to try out the DLL driver that is provided, and may need to ask @j4cbo for some help on this, as it appears it may be a DAC Driver issue.

[elliotwoods]

Wow. Seriously? I can't understand how this is so bad :)

Always tempted to roll my own DAC using a 6 channel audio SPI DAC chip + line drivers if a big enough project comes in.

Anyway back on topic. Something must work. This hardware has been used by so many people for so many projects. Maybe only a really old version of the code actually works? Any thoughts?

[j4cbo]

Try this:

https://github.com/j4cbo/etherdream-driver

A much updated and improved version of the driver in this repo. It's still Windows-only, but compiles with modern MSVC, and I've been slowly working on removing the Windows-isms with an eye towards eventually swapping in asio and making it cross-platform.

[Vamoss]

I was able to make it work on windows \o/

These are the files updated: https://gist.github.com/Vamoss/a7f769845cd47c4c7ea076f68617ffb5

I had to move the headers from cpp to h.

And the watch_for_dacs() socket was not working because it was being called before WSAStartup(wVersionRequested, &wsaData).

We just have changed the order, and now it working fine.

Thank you for sharing @j4cbo and @elliotwoods.