Prop to Prop serial connection with C?
johnproko
Posts: 121
I have two propellers and want to put them to work in a single project.
I have tried a simple morse code with 3 pins yet all i can do is just inform the other that something
has happend, not get values.
Has someone done something similar with 3 wire. I have read the learn page with the eeprom yet i must say that
it seems complicated. I have done similar connection with the arduino. And hope that learning C will have a co-operation
between the simple arduinos and the more diverse props.
I have tried a simple morse code with 3 pins yet all i can do is just inform the other that something
has happend, not get values.
Has someone done something similar with 3 wire. I have read the learn page with the eeprom yet i must say that
it seems complicated. I have done similar connection with the arduino. And hope that learning C will have a co-operation
between the simple arduinos and the more diverse props.
Comments
But asynchronous serial (commonly referred to at RS232) with direct ttl connections and in a full duplex mode will allow a lot more flexibility. Both Propellers can be independently be listening to each other, none are dominant. This may be what fdserial will provide. (I think the fd means full-duplex.)
Half-duplex asynchronous serial seems to require one Propeller to again be dominant. While it may not be a formal master/slave relationship, it has similar constraints. To avoid collisions and missed messages one device has to initiate all communications.
Actually the Propeller can provide full-duplex and the other device provide the less adequate half-duplex. It will work, but the half-duplex device just can't listen and send at the same time.
Half-duplex is what you would normally want if there is some kind of master/slave relationship where the slave only speaks when spoken to. Half-duplex means much higher speeds and only a single I/O is required in which a small series resistor can be added in case of inadvertent contention which shouldn't happen at all if software is running correctly. Full-duplex is often wasted as other than terminal operations you will find that applications normally only speak when spoken to.
I may be wrong, but I always considerd it half-duplex even though it has both a Tx and a Rx wire which use two i/o. I've never tried to make it work on one i/o.
The original poster's reference to 'serial' didn't really say which serial was desired. I wasn't really recommending SPI as the best. It is just easier than I2C. To be complete, I covered both the synchronous and asychronous in my intro. Yes, there are issues with how many i/o pins are required for each alternative, and there are tricks to reduce the number of i/o.
I did not know that the Propeller lacks good SPI slave code. But I am sure a good full duplex asynchronous is likely to be the easiest to first explore, and supported in C.
As Loopy and Peter have mentioned, your life will probably much easier if you switch to asynchronous communication, commonly referred to as just "serial" or more specifically, UART. There are lots of different ways to accomplish this on the Propeller in C or C++.
The implementations I know of are:
* PropWare's UART & Printer classes [C++]
* Simple's simpletext.h functions [C] (like print and printi)
* Simple's FdSerial [C]
* libpropeller's FullDuplexSerial [C++] (similar driver code as Simple and the original Spin, but with a C++ interface)
* libpropeller's Serial class [C++]
I've left off the following because they are surely the wrong solutions for your problem: tinyio, tinystream, standard functions in libc
One just has to be aware that information in half-duplex can't travel in both directions at the same time. So care must be taken by the Propeller to listen to see if there is incoming serial data, before transmitting. Traditionally, the Half Duplex device sends a 'prompt' character when after it goes into listening mode. Having that can simplify monitoring the Propeller in Full-Duplex as it is assured that the other device is finished and silence isn't due to a failure or a delay in communication.
Asynchronous can have software flow control, but it has a reputation of not always working. Hardware flow control would mean more wires between the two devices. I think it becomes obvious that Full Duplex to Full Duplex is the prefered configuration.