At EFX-TEK we use open-baudmode serial communications and Parallax's AppMod protocol to communicate with multiple, addressable devices on a single-wire buss (our AP-8, DC-16, and RC-4 all use the SX and are programmed in SX/B). Since SERIN and SEROUT are in place, and it's easy to add ISR-driven UART code, that might be your cleanest solution. If you want to make your slave SXes I2C compatible, you can find code on sxtechlist.com for doing that -- but it's all in assembly.
That PAUSE 500 in the demo code you cite (that I wrote), is simply there to slow the program so the user can watch it; the EEPROM usually needs about 10 ms to write, I believe, and that's easy to deal with. Here's a routine I use:
' Use: PUT_EE address, byteVal
' -- writes 'byteVal' to 24LC512 at location 'address'
' -- 'address' may be a byte (0 to 255) or word (0 to 65535)
PUT_EE:
IF __PARAMCNT = 2 THEN ' byte address
tmpW1 = __PARAM1
tmpB1 = __PARAM2
ELSE ' word address
tmpW1 = __WPARAM12
tmpB1 = __PARAM3
ENDIF
I2C_START
I2C_OUT SlaveWr ' send slave ID
I2C_OUT tmpW1_MSB ' send address, high byte
I2C_OUT tmpW1_LSB ' send address, low byte
I2C_OUT tmpB1 ' send data byte
I2C_STOP ' finish
DO ' let write cycle finish
I2C_START
I2C_OUT SlaveWr
LOOP UNTIL ackNak = Ack
RETURN
The end of the routine waits for the write-cycle to complete before returning to the calling point of the program. I've attached the program that uses that routine as it demonstrates the comments I made about encapsulating I2C instructions into subroutines to minimize code spaced used by a program.
"Parallax's AppMod protocol" is that the same as the example program for the Serial·SX LCD controller and BS2 code and in the Nuts n' Volts artical #116?
Yes, the AppMod protocol is described in article #116 in N&V. I don't know of any serial LCD that conforms to the protocol -- most LCDs use the SEETRON standard or act as terminals.
I know about that project -- in fact, I created it. That project uses an "extended" SEETRON protocol to get bi-directional comms to/from the LCD. The physical connection is open-true serial (as with the AppMod devices), but the protocol differs.
Comments
That PAUSE 500 in the demo code you cite (that I wrote), is simply there to slow the program so the user can watch it; the EEPROM usually needs about 10 ms to write, I believe, and that's easy to deal with. Here's a routine I use:
The end of the routine waits for the write-cycle to complete before returning to the calling point of the program. I've attached the program that uses that routine as it demonstrates the comments I made about encapsulating I2C instructions into subroutines to minimize code spaced used by a program.
Post Edited (JonnyMac) : 2/20/2007 5:45:03 PM GMT