Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compile on windows #18

Open
q-depot opened this issue Mar 5, 2014 · 10 comments
Open

Compile on windows #18

q-depot opened this issue Mar 5, 2014 · 10 comments

Comments

@q-depot
Copy link

q-depot commented Mar 5, 2014

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
Copy link

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
Copy link

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
Copy link

push-pop commented Jan 26, 2017

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
Copy link

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
Copy link

@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
Copy link

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
Copy link
Owner

j4cbo commented Apr 2, 2017

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
Copy link

Vamoss commented Sep 24, 2023

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.

@ObscuraDK
Copy link

I have tried to compile and use this 'driver' in visual studio. It compiles but throws an exception in line 723.
std::unique_lockstd::mutex lock(d->mutex); d->loop_cond.wait(lock);

@ObscuraDK
Copy link

Solved.

I commented out the mutex lock, as std::unique_lockstd::mutex lock(d->mutex); does this automatic.

Here is the code.

int etherdream_wait_for_ready(struct etherdream* d) {
//d->mutex.lock();
while (d->frame_buffer_fullness == BUFFER_NFRAMES && d->state != ST_SHUTDOWN) {
std::unique_lockstd::mutex lock(d->mutex);
d->loop_cond.wait(lock);
}
int is_shutdown = (d->state == ST_SHUTDOWN);
//d->mutex.unlock();

if (is_shutdown) {
	return -1;
}
else {
	return 0;
}

}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants