This fixes GH-46 and a regression caused by 82954d9 where the project
would fail to build until configured a second time on Unix-y platforms.
LibFTDI adds libusb, so we need to make sure that's included first.
Windows does not use libusb so it does not need the include directory.
This fixes GH-46 and a regression caused by 82954d9 where the project
would fail to build until configured a second time on Unix-y platforms.
LibFTDI adds libusb, so we need to make sure that's included first.
Windows does not use libusb so it does not need the include directory.
Communication does this in waitForMessageSync if a filter
is not passed in.
This fixes a crash in icsneoWaitForRxMessagesWithTimeOut
for the legacy API.
For good measure, creation with an empty std::function will
immediately throw an std::bad_function_call back at the
caller, rather than letting that happen on the callback thread.
I'm also making the members const here so they are provably
always non-null (and not empty, for the function).
This way they will come out as NULL frames, which is likely
more appropriate for a default.
This only takes effect if you set a key slot, but then don't
configure a message buffer for it.
If you had a chain of packets being sent all at once, the latter
section of packets could be delayed, theoretically infinitely.
If queue1 was filled and enqueued for transmit, then queue2
had packets enqueued in it while queue1 was still transmitting,
we'd try to fill queue2 further rather than waiting for queue1's
transmit to finish.
However, in that case, we wouldn't check if we could transmit
queue2 again until the next packet. If the user application
was waiting for the response from something in queue2
before pushing more packets, it could hang indefinitely.
This also fixes a subtle bug where hitting the "not safe to try
to fit any more packets in this queue" limit would cause a
packet to drop, as it would be dequeued and then tossed.
Closes GH-42
If you had a chain of packets being sent all at once, the latter
section of packets could be delayed, theoretically infinitely.
If queue1 was filled and enqueued for transmit, then queue2
had packets enqueued in it while queue1 was still transmitting,
we'd try to fill queue2 further rather than waiting for queue1's
transmit to finish.
However, in that case, we wouldn't check if we could transmit
queue2 again until the next packet. If the user application
was waiting for the response from something in queue2
before pushing more packets, it could hang indefinitely.
This also fixes a subtle bug where hitting the "not safe to try
to fit any more packets in this queue" limit would cause a
packet to drop, as it would be dequeued and then tossed.
Closes GH-42
The following fixups were added during the squash/merge:
Fix formatting in EthPhyMessage and EthPhyRegPacket
Device: Use std::make_shared when creating the EthPHYControl filter
Network: Create NetID String for EthPHYControl
EthPhyRegPacket: Constants in PascalCase
We need at least C++11.
If we're statically compiling into an application, we want to be using the same
CXX_STANDARD as it for ABI compatibility (particularly with icsneo::optional),
hence having the check around it.
Paul Hollinsky
Kyle Johannes