G'Day,
> > > 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.
The way it is currently written, my kernel driver would not support
something like that --- indeed, it would not even give you a chance to
try it. That may be something worth considering in future, though in
this case I am not sure there would be a significant change in
performance. When I have been testing things out, I have had an
oscilloscope connected to the bus, and it already seems to be going
about as fast as the bus allows.
> > > 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.
That is more or less done when the open() command is called in
ow_opt.c::OW_ArgOMAP(). Firstly, if you do not have the device file or
the driver, this will obviously fail. Secondly, if the bus is not there
(ie not an OMAP board), the driver should pick up on this when you try
to load it --- before owfs is even run.
> > > 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.
All the OMAP boards I know of come with on-board support for 1-Wire,
however it is poorly advertised: some pages will have at best one line
mentioning it, but most skip over the feature. That has been one of my
biggest problems here: there was absolutely nothing available for me.
That is why I have written the driver and the documentation, and now
begun adding it to owlib. It firstly gives me what I need, but it also
means that others wanting to do similar things will have a base to begin
from.
-- 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
