Questions regarding SPI and I2C

rfb1

Hello everyone.· I'm new to this forum and am currently playing around with the parallax propeller demo board.· Right now, my project is trying to decode and simulate the serial signals of a power supply interface unit (PSIU)·that I'm working with using the propeller.· It uses a 4 pin phone jack to communicate with peripheral devices.· The problem is I am not able to get it to work by using the propeller as a middle man between the PSIU and the peripheral devices using the full duplex serial program.· All I had it do was relay messages from the PSIU to the peripheral devices as complete as possible, but the PSIU never was able to communicate with the peripherals.

Then, I began to wonder if I was using the wrong communication style.· I found it odd that one of the wires was not being used because I assume that the setup was

Ground· Transmit· Receive· Power

but the receive line was always low and never had a signal across it, though at times it should have.·

Then, I realized it used one wire to transmit and receive.· This bothered me and still does, but I am pretty sure now that it uses SPI or I2C.· Is there any way of knowing for certain? Also, is there a good batch of code that I can use to transmit and receive the signals in SPI or I2C?· Lastly, what is the difference between the two, it seems as if I2C simply does what SPI does but with the possibility of multiple masters.

Thanks!

Ken Peterson

rfb1: You can find a pretty good description of both SPI and I2C on Wikipedia (www.wikipedia.org). I2C uses the same line for transmit and receive and is half-duplex. SPI uses one line for transmit and another for receive and is full-duplex. SPI tends to allow higher transmission rates than I2C. Both have separate clock and data lines and are master-slave type networks.

I would expect for that application a UART interface would be used.· Perhaps it's inverted or baud or parity are incorrect.· Do you have a scope handy to view the signals on the interface?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

rfb1

So, here is essentially what I am working with.· There is a device by Trikinetics that is a fly counter.· It is an array of photointerrupts that count what passes through and then report back to the PSIU via a 4 pin telephone jack.· After analyzing a bit with the Oscilloscope, I realized that one was ground, one was transmission, one was 9v (power) and one had nothing across it, ever.· I assumed it was receiving, but I have never seen a signal across it, and the stuff works just fine without it.

My goal was to replace the PSIU with the propeller demo board after understanding how the two communicated, what they said, and so on. I originally used the full duplex serial file by parallax to read transmissions and so on. The thing is, I can not get the PSIU to communicate with the counter when the propeller demo board is the middle man and simply relaying information from the PSIU to the monitor.· I am sure the PSIU's signals are being transmitted because I checked with the oscilloscope and the signal was getting to the counter, but it never spoke back.· So, I am thinking that the mode of communication is incorrect (the PSIU is listed under UART by the device manager) or I am messing up by omitting information some how, yet I don't know how.· I simply use the rxcheck command and omit and FF bytes which are the no signal bytes.

Anyone have an idea as to what the possible problem may be or if it is even possible for the propeller board to replace the PSIU .·

*Sorry for being a little vague with certain details or unclear, I'm still learning the stuff.

rfb1

Oh, forgot to add. I was checking the signals when the PSIU was transmitting to nothing and there were the same as what was coming from the propeller pin to the counter, with regards to voltage sign. I couldn't tell if they were exactly the same since the signals are a lot of sharp peaks with small time frames.

The baud rate was the thing I was thinking would be the largest problem. I wonder if I could fix it by viewing the number of junk no signal bytes that are output to the TV and diving the current rate by that.

Ken Peterson

rfb1: You can figure out the buad rate by capturing a byte and scaling it on the scope. Most protocols are 8N1 which means 8 data bits, no parity bit, and one stop bit. UARTS also start each byte with a start bit. So a total of 10 bits per byte. If it's a TTL UART, they typically are idle high, with the start bit low. Some are the reverse and are idle low with a high start bit. The level of the start bit always represents 0, and the idle level (stop bit) represent 1.

Read up on RS232 and UART on Wikipedia for details of the UART transmission format.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

rfb1

Thanks!· I actually managed to get the close to the correct baud rate that way, but it was still slightly off.· So, what I ended up doing was changing my baud rate till I managed to only get around 64 bytes out on the screen because the thing has 32 channels reporting and I assumed that they used 2 bytes to report back since 1 byte would be too little·for counting purposes.