Nathan, good to know somebody is as crazy as we are :) Our main intention was (is) to program Microchip to behave (act) "exactly" as a one wire device (slave), so the master (OWFS) can't find any difference and will detect and treat microchip exactly as the real one 1-wire device. DS2431 (1024-Bit 1-Wire EEPROM) is coming to mind as a good candidate.
IMHO it can be possible to write commands (sense of rotation of the motor, speed, number of steps, acceleration, etc...) to the Microchip memory (acting as DS2431 EEPROM) through 1-wire network. Microchip (according to the received information) will control motor and will write feedback information (the real position of the motor for example) to an other part of the EEPROM so it will be possible to read this information from the 1-wire network. I will appreciate your comments. Petr NH> A friend of mine built a humidity/temperature sensor based on a NH> Sensirion SHT75. The part basically has a serial interface, which NH> we tied back to a PIC16F628 that then looks like a 1-wire part. NH> Mark's been meaning to clean it up because he wrote it in a bit of NH> a hurry (and it's written in Intel-esque pseudo-assembly, made to NH> be assembled by Tech Tools' cvasm16). Also, he fixed some NH> linearization bug since the last time I got source, so this NH> version isn't the final (nor perfect) one. However, this little NH> jewel is currently running my evap cooler, furnace, and air NH> conditioner with the assistance of my workshop computer, so it's NH> plenty reliable over a reasonably large 1-wire network (a few hundred feet of cable). NH> When I saw this discussion on the list today, I asked if he'd NH> mind if I posted it in its current state. So, the latest version I have: NH> http://www.drgw.net/~maverick/electronics/tidbits/sht75v10.src NH> I'll see if I can get the updated version from him tomorrow at work. NH> This brings us to an item about OWFS... As I remember it, NH> Dallas/Maxim reserves 0xFF as the device address class for things NH> that don't have an assigned number (or third-party type devices). NH> However, since OWFS assumes that 0xFF-class devices are that LCD NH> module, we had to map ours in as 0xFE (and set up the OWFS module NH> appropriately). This is a bit of a pain since his device may NH> eventually conflict with a Maxim part and we can (probably) never NH> merge the code with the main OWFS trunk. What about using a NH> couple more bytes of address on 0xFF devices to differentiate between subclasses? Thoughts? NH> Nathan ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
