Repository navigation
Kvaser single_handle mode issues? #70
Description
Activity
Original comment by Brian Thorne (Bitbucket: hardbyte, GitHub: hardbyte):
- I'm unsure about the need to explicitly go bus off in either case. As it looks I'd say that
shutdownshould go bus off on the read handle. I'll add that now.
2 was a fun trip in software archaeology - here is where it was set in 2012 - I think the event and condition were the correct design for the problem though. From memory the problem was trying to read as fast as the kvaser device would allow, except when trying to send a message which would then be given priority of the bus.
3 - what can happen?
I think 2 and 3 point out clearly that the threading "protection" is currently broken - want to put together a PR? I would't like to hack at it too much myself as I don't have access to a kvaser anymore. But more than happy to help with reviewing etc.
- I'm unsure about the need to explicitly go bus off in either case. As it looks I'd say that
Original comment by Christian Sandberg (Bitbucket: sandberg, GitHub: sandberg):
-
Looks good.
-
I see. Seems to be some more dead code left from that time. In my opinion whenever you want to send and receive using different threads, you should use two handles (as per Kvaser's instructions). However, if the interface is accessed only from one thread, one could use single_handle mode. Therefore I think using locks is not really necessary on this level. The developer could make that decision and if he wants to access the same handle using different threads, he should use appropriate locks on a higher level to prevent concurrent access.
-
Not sure what would happen but as Kvaser writes, you should not access the same handle simultaneously in different threads. Now one could send during a read operation (even if it is only 1 ms).
My suggestion is to clean out all threading related things here and instead update the documentation about using a single handle from different threads. Alternatively, acquire a lock in both recv() and send() so that they can never be accessed at the same time. What do you think? I'm happy to create a pull request.
-
Original comment by Brian Thorne (Bitbucket: hardbyte, GitHub: hardbyte):
Various fixes for Kvaser.
Explicitly convert channel to integer.
Remove threading related stuff.
Fix timestamps.
Fix flags not being calculated on transmission.
Add channel info.
Reduced timestamp resolution to 10 us to reduce risk of overflow.
Tweaked logging levels.
Closes #47.
Closes #70.
Originally reported by: Christian Sandberg (Bitbucket: sandberg, GitHub: sandberg)
I'm not sure if these are actual issues or if I just don't understand.