-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Matthew Percival Sent: Tuesday, July 12, 2005 11:11 PM To: owfs-developers@lists.sourceforge.net Subject: Re: [Owfs-developers] Adding another means of accessing devices(ie not serial, USB, etc)...
G'Day, > And the search algorithm: > http://www.maxim-ix.com/appnots.cfm/appnote_number/187 Thanks to this document, I was able to eventually sort out the problem. There were lots of small differences here and there between the way the serial device works, and the way the OMAP bus works; these were the cause of much of the trouble. I also had to make my driver more intelligent, as it needs to work differently when an Search ROM command has been issued compared to normal. There also seemed to be aspects of the DS9097 driver that differed from the algorithm somewhat, but that was probably because of the way the adaptor works. I now have the basics working, but have not been able to test all the functions yet. There are also a few functions I am still not sure of the use of, and as such they may need to be rewritten a little. All-in-all, it is almost complete: I would just like to say what I have so far, so as to verify that I am doing what is expected. OMAP_detect: almost identical to the serial device, it does a little setting up, then resets the bus. ---- Sounds good. If the adapter presence can be tested, or there is some firmware information, this is where it would be tested. ---- OMAP_setroutines: simply assigns the functions that would be called by external routines; no overdrive functions provided. ---- Correct. This allows the rest of OWFS to access the low-level functions of your adapter. ---- OMAP_write: one I am not sure of. It splits the write buffer up into bits, and calls OMAP_send_and_get(). Do they really have to be sent as individual bits, or can I just leave them as bytes and send it all together? ---- The 1-wire bus transfers data 1 bit at a time. Some adapters have hardware support for transporting bytes or longer data segments. The main advantage is that the CPU does not have to wait for each bit, which can be very inefficient. ---- OMAP_read: effectively the same as OMAP_write(), only reading. Again, should I really be expecting bits, or can I assume byte returns? ---- This sends "1" bits and reads the bus to see if a device is driving it low. ---- OMAP_reset: sends a reset pulse, and verifies there are devices present. OMAP_next_both: the Search ROM routine. Sends a Search ROM command, reads two bits, writes a bit, and continues until either an error or it is complete. Checks the serial at the end. ---- Correct. The algorithm listed has a bit of loop unrolling to send/read three bits at a time. Some devices, (the LINK and the USB adapter) do this entirely in hardware. ---- OMAP_level: does not seem to do much of anything; more or less copied from the serial adaptor. ---- Right. The DS2480B has a complicated state machine that cares about "level". This is effectively bypassed for all the other adapters. ---- OMAP_PowerByte: sounds fancy, but I cannot work out the purpose of it. Calls OMAP_send_data(), switches level, waits, then calls OMAP_level(). ---- Again, some adapters have a specific software sequence to send a bit and leave the bus in the high state. For the passive adapter, this is the natural process. ---- OMAP_ProgramPulse: does not do anything right now; neither the DS9097 nor DS9490 seem to support it. ---- Correct. It needs to switch to 12V. ---- OMAP_sendback_data: seems to be OMAP_write() and OMAP_read() combined; as with the other two, is it really necessary to do this in bits, or can I assume bytes? ---- This is a higher level command. Some adapters can use this level, others have to bit-bang the interface. ---- OMAP_select: seems to be a Match ROM command; currently taken almost directly from the DS9097. If if is Match ROM, I may need to make a few, small, changes. I guess pn->sn is the serial number, and pn->dev has something to do with devices, but am not positive. ---- pn->sn is the serial number pn->dev is a pointer to the device type (DS2401 or whatever). ---- OMAP_send_data(): fairly similar to BUS_send_data(). It calls OMAP_sendback_data, and checks that it received back the same data it sent. I am guessing there is some kind of device that requires this. ---- Right. Most writing to the bus will use this. The check is to confirm the bus is not noisy. ---- OMAP_readin_data(): replacement for BUS_readin_data(), it is basically a front to OMAP_sendback_data, but does a memset() in the first argument rather than a variable; not sure of the purpose yet. OMAP_send_and_get(): replaces BUS_send_and_get(), and seems to work fine. If there's anything to send, it does; if there's anything to read, it does. If there is anything there I am wrong about, of if anyone can answer any of the questions, I would really appreciate it. ---- No, you got it all correct. There are a set of bit-level commands, and then some higher level composite commands (byte or more). -- Matthew ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
