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
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.
Vehicle Spy 3 does this, it's a long-standing firmware idiosyncrasy.
Due to the way the device handles packets, this didn't cause a loss of
communication, only a "host to device byte" app error under certain
circumstances.
If an external project links to the icsneocpp target and pcap has
been installed in a non-standard location, the build will fail to find
pcap.h because PCAP_INCLUDE_DIR is not associated with the
target.
Closes#58
If an external project links to the icsneocpp target and libusb has
been installed in a non-standard location, the build will fail to find
libusb.h because LIBUSB_INCLUDE_DIR is not associated with the
target.
Closes#57
Paul Hollinsky
Kyle Johannes
Kyle Schwarz