Re: socket can receive order

[Daniel Squires <dan@engineeredarts.co.uk>]

On 10/09/15 03:29, Tom Evans wrote:
> On 08/09/15 21:46, Wolfgang Grandegger wrote:
>>
>> Am 08.09.2015 um 13:13 schrieb Marc Kleine-Budde:
>>> On 09/08/2015 12:41 PM, Daniel Squires wrote:
>>>> On my laptop and Desktop PC I have not seen it happen.
>>> I mean what kind of CAN adapter...
>>
>> "https://github.com/fabiobaltieri/open-usb-can" seems to use a MCP2515
>> controller.
>
> http://fabiobaltieri.com/2013/07/23/hacking-into-a-vehicle-can-bus-toyothack-and-socketcan/#more-1419 
>
>
> "my own open hardware USB AVR + MCP2515 interface", "the performances 
> are not that good above 250kbps", "It’s tempting to use an SPI 
> controller (the MCP2515 is very common), but that has terrible 
> performances on highly loaded fast busses, and you will end up with 
> problem such as RX buffer underruns and out-of-order frames."
>
> He means "overruns". The MCP2515 doesn't have a FIFO. Messages have to 
> be read out over a slow SPI bus one bit at a time within one message 
> time or it overruns. Or two if the BUKT bit is set, but that risks 
> reading messages in the wrong order.
>
> The design uses an ATMEGA32U2 and an MCP2515. I can't see why it 
> shouldn't be able to buffer messages from the MCP2515 at relatively 
> high data rates, if the code is well written. From my experience 
> though, code for the MCP2515 is seldom "well written". It is too easy 
> to fall into a trap and get the message arrival order wrong.
>
> This is unlikely to be related to the OP's problem, but just something 
> to be aware of.

Yes, I had read that whole article and didn't use the hardware / 
firmware there for those reasons. I needed 1Mbit also. I am using the 
STM32F4 Discovery boards with a CAN phy attached. I didn't know where to 
start with t kernel module which is why i am suing the one from there at 
present, it would be nice to get a "standardised" usb class kernel 
module, but i guess that would require input form the USB implementers 
group.
>
> For anybody still coding and debugging MCP2515 stuff:
>
> http://www.microchip.com/forums/m620741.aspx
>
> > otherwise its prone to loosing TX packets when loaded.
>
> Do you know about having to do something like the following to stop 
> CAN Transmit Drops? The networking stack defaults to DROPPING CAN 
> transmit frames before blocking the socket if you don't.
>
>     /bin/echo 256 > /sys/class/net/can0/tx_queue_len
>     ...
>     int sndbuf = (250 + 8) * 256;
>     socklen_t socklen = sizeof(sndbuf);
>     /* Minimum socket buffer to try and get it blocking */
>     rc = setsockopt(pSkt->skt, SOL_SOCKET, SO_SNDBUF,
>                     &sndbuf, sizeof(sndbuf));
>
I hadn't noticed it could be done in that way, had been using ip 
utility, but was aware of the 10 frames default queue size and that it 
could be changed. In my very basic OOO test app i'm actually sending 
packets with incrementing values until there is no space (send returns 
ENOBUF), then doing the receives and checking the values until there is 
nothing to receive, before continuing to send from the previous failed 
value.
>
> http://socket-can.996257.n3.nabble.com/Solving-ENOBUFS-returned-by-write-td2886.html 
>
>
> Tom
>
>
>

-- 
Dan Squires

Engineered Arts Ltd.