Widely used low level API?

[Oliver Betz]

Hello All,

as I'm redesigning and extending parts of an application, I have to
change the API accessing the CAN hardware (init, filter, read,
write...).

I wonder whether there is a widely used/accepted API I should
consider to be compatible to.

Any suggestions?

TIA,

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@...>

[stunbmun]

I designed a CAN/USB device for my company and we sell it via the web.  In my experience, I have only ever heard of one common API that was requested by a potential customer - I can't remember what it was now and never heard of it again, so that may be a good sign that it was not widely used or adopted.  Of course I never really ever looked again, so I may be completely wrong.

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.  

I'm not familiar with Vector, but do they have an API that will allow supported hardware to work with their software?  Perhaps National Instruments has something that will let users seamlessly plug-in your CAN hardware.

Let me know what you find - I would be willing to make our hardware work with it as well.

[Oliver Betz]

stunbmun wrote:

> I designed a CAN/USB device for my company and we sell it via the web.  In my
> experience, I have only ever heard of one common API that was requested by a
> potential customer - I can't remember what it was now and never heard of it
> again, so that may be a good sign that it was not widely used or adopted.
> Of course I never really ever looked again, so I may be completely wrong.
>
> 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...

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@...>

[Bende Georg]

Hello,

Just to add my 2 Eurocents:
Further functions that are nice to have:
-Bus status notification
-Buffer handling

Common API:
Our company has a software for managing our motor controllers (Motion Manager) that uses more than one type of CAN adapter. Currently IXXAT and ESD are supported, but via Plug-In DLLs it's easy to add new ones. We have implemented a common communication layer for those adapters.
If you want to check it out, it can be downloaded from http://www.faulhaber-group.com/images/SetupFAULHABERMoMan4_1_en.exe free of charge. But without a supported card it has a rather limited capability.

Best wishes,
Georg

> -----Ursprüngliche Nachricht-----
> Von: canlist-owner@...
> [mailto:canlist-owner@...] Im
> Auftrag von Oliver Betz
> Gesendet: Donnerstag, 20. November 2008 09:17
> An: canlist@...
> Betreff: Re: [CANLIST] Widely used low level API?
>
>
> stunbmun wrote:
>
> > I designed a CAN/USB device for my company and we sell it
> via the web.  In my
> > experience, I have only ever heard of one common API that
> was requested by a
> > potential customer - I can't remember what it was now and
> never heard of it
> > again, so that may be a good sign that it was not widely
> used or adopted.
> > Of course I never really ever looked again, so I may be
> completely wrong.
> >
> > 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...
>
> 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@...>
>

--
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@...>

[Bertil Bäck-2]

Hi,
almost all CAN hardware manufacturers have their own CAN API's. Vector
and Kvaser lets you download the API from their web page and build own
software against their HW. The only bigger API that I know of is
socketCAN for Linux. This is still in development and the API is not in
stone yet, but they are close. I think there have been some attempts to
run the same on Windows wsing miniport network driver.

Articles:
CANopen Newsletter 3/2008 page 62
http://lwn.net/Articles/253425/

Links:
http://en.wikipedia.org/wiki/Socketcan
http://developer.berlios.de/projects/socketcan/

hope this can help

Br,

Bertil BÄCK R&D Manager Hardware
T [phone], M [phone], F [phone]
bertil.back@..., www.tke.fi



stunbmun wrote:

> I designed a CAN/USB device for my company and we sell it via the web.  In my
> experience, I have only ever heard of one common API that was requested by a
> potential customer - I can't remember what it was now and never heard of it
> again, so that may be a good sign that it was not widely used or adopted.
> Of course I never really ever looked again, so I may be completely wrong.
>
> 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.  
>
> I'm not familiar with Vector, but do they have an API that will allow
> supported hardware to work with their software?  Perhaps National
> Instruments has something that will let users seamlessly plug-in your CAN
> hardware.
>
> Let me know what you find - I would be willing to make our hardware work
> with it as well.
>
> -----
> - Jon
>
> http://www.cancapture.com CANCapture: Advanced CAN and J1939 Analysis
> Software
>  

> Hello All, as I'm redesigning and extending parts of an application, I
> have to change the API accessing the CAN hardware (init, filter, read,
> write...). I wonder whether there is a widely used/accepted API I
> should consider to be compatible to. Any suggestions? TIA, 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@...>

[Torsten Krahl]

Hello
> Let me know what you find - I would be willing to make our hardware work
> with it as well.
>  
as Bertil already mentioned there are some Linux API approaches ... but
there is also CANpie. So maybe you can check out

http://sourceforge.net/projects/canpie

Mit freundlichen Gruessen
With best regards

Torsten M. Krahl


--------------------------------
http://www.MicroControl.net
mailto:krahl@...

Fon: +49 (0)2241 / 256 59 - 0
Fax: [phone] / 256 59 - 11

MicroControl GmbH & Co. KG
Lindlaustr. 2 c
53842 Troisdorf, Germany

Persönlich haftend:
MicroControl Systemhaus für Automatisierung Beteiligungsgesellschaft mbH, Troisdorf

HRB 4952 Siegburg (GmbH)  HRA 3110 Siegburg (KG)

Geschäftsführer:
Dipl.-Ing. Uwe Koppe
Dipl.-Ing. (FH) Torsten Krahl
Dipl.-Ing. (FH) Frank Wielpütz

Ust-IdNr. DE 812191199
--------------------------------

--
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@...>

[YAP-2]

On Fri, Nov 14, 2008 at 1:14 PM, Oliver Betz <list_ob@...> wrote:

> Hello All,
>
> as I'm redesigning and extending parts of an application, I have to
> change the API accessing the CAN hardware (init, filter, read,
> write...).
>
> I wonder whether there is a widely used/accepted API I should
> consider to be compatible to.
>
> Any suggestions?
>

Not commonly used maybe but there is CANAL (CAN abstraction layer), It
is documented here
http://www.vscp.org/wiki/doku.php/canal_specification and there is
drivers for many common adapters and equipment (some listed here
http://www.vscp.org/wiki/doku.php/canal_vscp_drivers).

There is a lot of code around CANAL in the VSCP project. One API can
be used to talk directly to a device or through a device connected to
a server over the Internet or similar.  Very easy to do simulated
systems on a machine or over TCP/IP. I use to support raw CAN in a
client application before but no one was interested in that so at the
moment I only do VSCP but will probably add raw CAN support to VSCP
Works in the future.

You also have canPie https://sourceforge.net/projects/canpie

On linux you have socketCAN http://en.wikipedia.org/wiki/Socketcan
CANAL will support Socket CAN as soon as I get time to add a driver.

Cheers
/Ake

Cheers
/Ake




--
 ---
Ake Hedman
D of Scandinavia, http://www.dofscandinavia.com
--
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@...>

[Heinz-Juergen Oertel]

Am Donnerstag 20 November 2008 schrieb Oliver Betz:

> stunbmun wrote:
>
> > I designed a CAN/USB device for my company and we sell it via the web.  In my
> > experience, I have only ever heard of one common API that was requested by a
> > potential customer - I can't remember what it was now and never heard of it
> > again, so that may be a good sign that it was not widely used or adopted.
> > Of course I never really ever looked again, so I may be completely wrong.
> >
> > 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...
>
> Oliver

From our experience, maintaining the open source can4linux,
and a lot of proprietary drivers for CANopen, DeviceNet, J1939,
CAN error handling is very importand.
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.

http://www.can-wiki.info/CanInterfaceAPI
is the place to collect requirements.

By the way, I agree that filtering should be handled by the driver.
But message distribution may be not. Could be a layer above if necessary.
The driver API should be a simple as possible and as flexible as possible.

Regards
  Heinz
  port GmbH

[Oliver Betz]

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@...>

[stunbmun]

My original post seemed to be thrashed pretty badly, let me revise:

[quote]
but really its almost as simple as Open, Close, Send, Receive
[/quote]

Revised:
[quote]
but really its not much more complicated then opening (including support for hardware filters), closing, sending (11-bit/29bit), and receiving (11-bit/29-bit/error frames).  You should add support for error frames and such (including error passive, bus off, etc), and make sure to support hardware filtering, as well as callbacks/notifications and such.  
[/quote]

I was just trying to simplify - relative to other busses, its still pretty simple to write your own driver.  Adding message distribution should be left to higher layers.  Power management is a given, but most of the considerations for that probably lies in the embedded code.