Gopal Gorur wrote:
> Hi Armin,
>
> After some research in the mean time, I have concluded that, to have a "QNX compatible CAN driver" it means to have 
the following supported for the CAN controller:
> read()
> write()
>   

These calls are not appropriate to the needs of CAN communication.
We use CanSend and CanReceive as optimized read/write calls based on 
devctrl calls.

> ioctl()
>   
devctrl ...

> poll()
>   
non blocking CanRead ..

> select()
>   

receive blocking on a driver pulse ... select() is too slow.

> open()
> close()
>   
OK

> Also to somehow use the following prototypes:
> InterruptAttachEvent()
> InterruptAttach()
>   

InterruptAttach is the way to go ... at least if you have to handle 
shared PCI interrupts.

> Anyways, this is only my assumption.
>   

There are lot of other call necessary ... setting of filters, 
configuration actions, reading of status informations, e.g. for the 
Intel chip sending remote frames, different controller registers a.s.o.

 But these calls are depending on the controller type.

> I agree that there is no standard CAN controller (thank god!) but most of them adhere to Bosch CAN 2.0B specs.

If a controller isn't compliant to the CAN 2.0B ISO standard ... it 
would'nt be CAN controller.

>  But I think with the above APIs supported, such a CAN driver can be ported onto any system that has QNX running on it
, some apps, and has a CAN controller that needs a driver.
>   
The driver  dependeds on the CAN controller and the hardware interfaces 
... the API depends on the functionality of the CAN controller.
With your API "definition" you would loose a lot of the functionallity 
of the individual CAN controllers ...

Regards

--Armin