[En-Nut-Discussion] RFC: CAN Bus driver buffer handling

Ole Reinhardt ole.reinhardt at embedded-it.de
Wed Aug 5 12:25:39 CEST 2009


Hi Henrik

> This is a good idea and I second that approach. I am happy to modify and
> verify the ATCAN driver.

Great! Currently I don't have any hardware with SJA1000 available. Do
you have any possebility to test this driver too? (I'll modify it, but
it then needs a test).

> If the CAN API is reviewed anyway, there are a few things which need
> attention:
> - time-out support also for sending

Just included this!

> - unified API for setting masks and filters so this works across all
> supported CAN controllers

Second step :-) Unfortunately the controllers differ quite much...

> - Buffer size configurable either via configurator OR run-time

I just included setting buffer sizes in steps of power of two (so you
can use a simple & instead of the very expensive modulo operation for
the ringbuffer).

> - Buffer size configurable differently for RX and TX

Ok, so far I'll add two settings for both buffers. Currently the ATCAN
driver does not support buffering for tx at all, right? It is limited by
the MOB objects of the controller, right?

> - Support for multiple CAN controllers

Yes, the first step is done, I added buffering etc. into the CANINFO
struct, so you can create multiple can instances if you like.

> Just one comment, the ATCAN driver does not use a TX buffer and a TX thread.

Ok, that was my question above :)

> The reason back then was that the first AT90CAN128 chips had issues with the
> stack which limited the amount of threads available so I did not want to
> waste a precious thread for sending. In addition the controller offers 15
> message objects which can be used as a buffer.

That's the same with the SAM7. In deed I won't support transmit
buffering there too (beside of the MOBs). If anyone needs larger buffers
one could implement it in the application too, right?

In reality a sending thread should not be needed. This could easily be
done in the interrupt handler too. So I won't implement it in the SAM7
driver either.

-- 
 _____________________________________________________________
|                                                             |
| Embedded-IT                                                 |
|                                                             |
| Ole Reinhardt        Tel. / Fax:        +49 (0)271  7420433 |
| Luisenstraße 29      Mobil:             +49 (0)177  7420433 |
| 57076 Siegen         eMail:    ole.reinhardt at embedded-it.de |
| Germany              Web:         http://www.embedded-it.de |
|_____________________________________________________________|




More information about the En-Nut-Discussion mailing list