Re: USB driver

From: Bernd Porr <bp1_at_cn.stir.ac.uk> · Date: Thu, 08 May 2003 00:50:34 +0100

Frank,

many thanks. You've been a great help.

/Bernd

Frank Mori Hess wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Wednesday 07 May 2003 08:21 am, Bernd Porr wrote:
>  
>
>>Dear David,
>>
>>I'm just writing a driver for a USB board which will be produced in the
>>near future. The driver works so far (channellist and ranges not
>>implemented yet).
>>
>>I have some questions regarding the usb-comedi interaction:
>>
>>1) The USB device driver has to have an array of private data
>>structures. Every entry in this array is associated with one data
>>aquisition board. The structure is already there and therefore I have
>>also associated to private structure of the comedi device with a entry
>>in this array. I'm aware that comedi does not like global structures but
>>this one has to be there. The problem arises when I call the detach
>>function of comedi. This routine frees the private structure. However,
>>this structure is static in memory and stays there until the module is
>>removed. From my point of view there are just now two solutions: I
>>_really_ allocate a private structure which is removed after detach.
>>This structure might then only contain one pointer to the usb-structure.
>>Or: comedi allows me to keep the private structure even after detach has
>>been called. I'm open for suggestions. Just now I _give_ comedi
>>something what I have allocated in order to free it. Have a look at the
>>code.
>>    
>>
>
>You could alternatively set dev->private to NULL in detach.  That would 
>prevent comedi from trying to free it.
>
>  
>
>>2) USB has an event handler and not an interrupt. What do you think is
>>the best way to cope with this? My solution you find in the code. I had
>>a look how comedi treats registering an handler and did the same in my
>>code. Howevre, I can not use the original code as it requests a physical
>>interrupt which is not there in the usb subsystem.
>>
>>    
>>
>
>I'm not sure what you are talking about here.  comedi_request_irq() exists 
>only for the sake of making interrupt handlers RT.  You can't make the usb 
>systems interrupts RT so it doesn't matter.
>
>  
>
>>3) I cannot use the macro COMEDI_INITCLEANUP. The reason is that I have
>>to register the usb subsystem and the comedi driver. Can you imagine a
>>macro which can call an additional init and cleanup function? It would
>>be nice having that.
>>    
>>
>
>You dont have to use COMEDI_INITCLEANUP, its just there for convenience.
>
>  
>
>>4) Regarding firmware: how can I upload firmware? Just now I have
>>registerd an additional device /dev/ez0 which I use for the up- and
>>download (which is in fact really a cypress chip which I use). Also not
>>very elegant. But it works.
>>    
>>
>
>A pointer and length are passed as part of the options array during attach.  
>See for example the daqboard2000 driver.  I'm noticing a problem though, the 
>options array needs to be changed to type long instead of int, since int's 
>aren't guaranteed to be large enough to hold pointers.
>
>- -- 
>Frank
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.6 (GNU/Linux)
>Comment: For info see http://www.gnupg.org
>
>iD8DBQE+uSW+5vihyNWuA4URApvzAKCSVgxr2a2xVmOjVhiYu6+yq4iVLwCdGD6C
>Qd2jWeQkRS2PrXcZCdhVubQ=
>=bKMB
>-----END PGP SIGNATURE-----
>
>
>_______________________________________________
>comedi mailing list
>comedi_at_comedi.org
>https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi
>  
>

-- 
http://www.cn.stir.ac.uk/~bp1/
mailto:bp1_at_cn.stir.ac.uk