On Sunday 17 July 2005 08:45 pm, Matthew Percival wrote: > G'Day, > > > Nice work. I've been going through your code. > > Thanks: I appreciate it! > > > One basic question: What exactly is this "adapter" and which architecture > > supports it? > > It is not a true adaptor: Texas Instruments' OMAP development boards > have hardware support for 1-Wire. I recently wrote a kernel driver for > this, and needed to add support for my driver to owfs. I am just > finishing off some documentation on the hardware support and my driver, > if you are interested --- though I would not imagine it would be > particularly interesting to anyone not using OMAP boards. > I would like to include support with the mainline code, once you finished your testing. We would probably make in a compile-time option, since it won't be sued that often.
> > Specific comments: > > 1. in ow_omap.c : OMAP_reset, are we missing something? I see a loop, > > with fsync, but no body. > > That would be a typo I had not noticed: it should have a semi-colon at > the end. fsync() could return -EBUSY if the bus were currently in use, > which meant you needed to wait a moment before you could use it (at the > time I felt that was a cleaner solution than blocking). Due to a > hardware bug, if you try to do anything while another operation is > completing, you risk corrupting data (`anything' includes even reading > status registers!). That will not be relevant soon, however, as my next > version of the driver will be blocking when performing operations, and > as such there is no -EBUSY signal. > > > 2. How big a send/recieve buffer does the adapter have? > > At the moment, I am buffering everything in kernel, and sending it one > byte (or bit, if performing Search ROM) at a time. I am considering > changing that in future, but at the moment there is no hard limit. > I notice that you "write" then "read", but the string can be of uncertain length. The DS9097U buffers one byte in hardware, and the kernel allows something like 100 bytes of buffer (the combuffer string is sized for this). The existing code will break long communication into write/reads of this length or less. There is a balance between buffer length and the cost of read/write setup. Unfortunately, the search algorithm uses a very short read/write string (3 bits at best) so tends to be slow. We had a major speedup of the DS9097 code when we did some loop regrouping to join the 1 bit direction selection with the next two bit query. > > 3. Is there a characteristic major/minot device number to test for in > > OMAP_detect > > ow_ds9097.c had no such thing, so I did not realise I needed to test > anything like that. Because there is no device assigned to this (and, > really, there probably never will be), this may need to change, but > currently /dev/owire is set to 232/0. > You don't. I'm just trying to find ways to reduce errors and misconfigurations. It would be nice to have a positive test that the OMAP adapter is actually there. > > 4. It's a matter of style. Your ow_omap.h has only static function > > prototypes. I've been putting them at the start of the source module and > > using the *.h files for externally visible definitions. > > That is simple enough to change --- I mainly do it like that for my own > reference early on anyway. Once I get to a certain point, it works just > as well for me either way. > > > 5. Do you have a picture of the adapter for the web site? > > Since it is not really an real adaptor, there are no pictures of the > relevant aspect, however if you want a picture of an OMAP development > board there is one of the board I am using here: > http://omap.spectrumdigital.com/osk5912/ > Looks interesting. I don't see a 1-wire port, however. > -- Matthew > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
