|
« Return to Thread: Widely used low level API?
Re: Widely used low level API?
by Oliver Betz
::
Rate this Message:
Heinz-Juergen Oertel wrote:
[...]
> > > We ended up creating our own custom API, but really its almost as simple as
> > > Open, Close, Send, Receive. Users of the API are usually not too
> > > intimidated by such simple functionality, and there is not really much
> > > software out there (at least that I'm aware of) that uses a common driver
> > > API anyway.
> >
> > there are some more possibilities as setting versatile filters,
> > distributing incoming messages to the appropriate handlers...
>
> From our experience, maintaining the open source can4linux,
> and a lot of proprietary drivers for CANopen, DeviceNet, J1939,
> CAN error handling is very importand.
Ack.
> When we use manufacturer provided drivers, e.g. Windows CAN drivers,
> we see big differences there.
> Very importand is that the Error Passive State and Bus off are reported
> to the application.
> Error counters if available should be readable any time.
>
> More things come in mind.
e.g. power management.
> http://www.can-wiki.info/CanInterfaceAPI
> is the place to collect requirements.
Good idea. I try to add my conclusions (when there are any valuable).
> By the way, I agree that filtering should be handled by the driver.
...since it's usually done in hardware.
> But message distribution may be not. Could be a layer above if necessary.
As long as the message buffer retains the filter hit(s), that's o.k.
If the message buffer can hold only one filter hit (e.g. "object
number"), a message distribution to more than one consumer is
somewhat difficult. I have to admit that overlapping filters are a
rather unusual scenario.
> The driver API should be a simple as possible and as flexible as possible.
Ack.
After all, any new implementation should now (nine years past C99)
use the exact-width integer types defined in stdint.h. And of course,
it should not depend on endianness of the target system (e.g. by
using a union for the CAN data field).
Oliver
--
Oliver Betz, Muenchen
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-owner@...>
[...]
> > > We ended up creating our own custom API, but really its almost as simple as
> > > Open, Close, Send, Receive. Users of the API are usually not too
> > > intimidated by such simple functionality, and there is not really much
> > > software out there (at least that I'm aware of) that uses a common driver
> > > API anyway.
> >
> > there are some more possibilities as setting versatile filters,
> > distributing incoming messages to the appropriate handlers...
>
> From our experience, maintaining the open source can4linux,
> and a lot of proprietary drivers for CANopen, DeviceNet, J1939,
> CAN error handling is very importand.
Ack.
> When we use manufacturer provided drivers, e.g. Windows CAN drivers,
> we see big differences there.
> Very importand is that the Error Passive State and Bus off are reported
> to the application.
> Error counters if available should be readable any time.
>
> More things come in mind.
e.g. power management.
> http://www.can-wiki.info/CanInterfaceAPI
> is the place to collect requirements.
Good idea. I try to add my conclusions (when there are any valuable).
> By the way, I agree that filtering should be handled by the driver.
...since it's usually done in hardware.
> But message distribution may be not. Could be a layer above if necessary.
As long as the message buffer retains the filter hit(s), that's o.k.
If the message buffer can hold only one filter hit (e.g. "object
number"), a message distribution to more than one consumer is
somewhat difficult. I have to admit that overlapping filters are a
rather unusual scenario.
> The driver API should be a simple as possible and as flexible as possible.
Ack.
After all, any new implementation should now (nine years past C99)
use the exact-width integer types defined in stdint.h. And of course,
it should not depend on endianness of the target system (e.g. by
using a union for the CAN data field).
Oliver
--
Oliver Betz, Muenchen
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-owner@...>
« Return to Thread: Widely used low level API?
| Free embeddable forum powered by Nabble | Forum Help |
