Simple Serial Between two Propellers
Jkane
Posts: 113
Hello,
I'm have some trouble with the serial communication
as far as hardware
two propeller boards with two wires between them (total of two wires)
Prop1 TX P24 => Prop2 RX P2 (wire 1)
Prop1 RX P26 => Prop2 TX P1 (wire 2)
The only message I ever get from both sides is:
Message not received from remote side
or
Message not recieved from host side
Host side code
Remote Side code
If anyone has any ideas it sure would be helpful
regards
Jeff
I'm have some trouble with the serial communication
as far as hardware
two propeller boards with two wires between them (total of two wires)
Prop1 TX P24 => Prop2 RX P2 (wire 1)
Prop1 RX P26 => Prop2 TX P1 (wire 2)
The only message I ever get from both sides is:
Message not received from remote side
or
Message not recieved from host side
Host side code
{{
Computer Side (host)
}}
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
' SER_DOUT_PIN = 1
' SER_DIN_PIN = 2
SER_DOUT_PIN = 24
SER_DIN_PIN = 26
SER_MODE = %0000
SER_BAUD = 9_600
LED_PIN = 20
TX_PIN24 = 24
RX_PIN26 = 26
obj
SER : "FullDuplexSerial" 'comms to SER.
PST : "Parallax Serial Terminal"
var
long recv
pub go
SER.start(SER_DOUT_PIN, SER_DIN_PIN, SER_MODE, SER_BAUD) 'start comms to SER
PST.Start(9600)
PST.Clear
PST.str(string("Starting Host Side",13) )
'main loop
repeat
SER.tx("H") 'prompt the host for validation
recv := SER.rxtime(250) 'receive our response byte, wait 1/4 second max for response
if recv == "R" 'if we receive a valid response, then execute the following...
PST.str(string("message received on Host side",13) )
else 'else, if something else was received
PST.str(string("message not received on Host side",13) )
waitcnt(cnt + (3*clkfreq)) 'wait 3 seconds
Remote Side code
{{
(remote client)
}}
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
SER_DOUT_PIN = 1
SER_DIN_PIN = 2
SER_MODE = %0000
SER_BAUD = 9_600
obj
SER : "FullDuplexSerial" 'comms to SER.
PST : "Parallax Serial Terminal"
var
long recv
pub go
SER.start(SER_DOUT_PIN, SER_DIN_PIN, SER_MODE, SER_BAUD) 'start comms to SER
PST.Start(9600)
PST.Clear
PST.str(string("Starting Remote Side",13) )
'main loop
repeat
SER.tx("R") 'prompt the host for validation
recv := SER.rxtime(250) 'receive our response byte, wait 1/4 second max for response
if recv == "H" 'if we receive a valid response, then execute the following...
PST.str(string("message received on remote side",13) )
else 'else, if something else was received
PST.str(string("message not received on remote side",13) )
waitcnt(cnt + (3*clkfreq)) 'wait 3 seconds
If anyone has any ideas it sure would be helpful
regards
Jeff
Comments
Yes, sorry forgot, , there is a ground connection between the two propellers.
what is interesting is "back in the days of the dinosaurs", TX went to RX and RX went to TX, but I'm not sure this works this way. I am beginning to suspect it is RX=> RX and TX=>TX, which makes no sense to me.
my other thought is that it would be byte for the recv rather than long.
regards
Jeff
Tx <-> Rx is still valid.
remote side
{{ (remote client) }} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 SER_DOUT_PIN = 1 SER_DIN_PIN = 2 SER_MODE = %0000 SER_BAUD = 9_600 ' SER_BAUD = 115_200 NL = 13 ''NL: New Line obj 'SER : "FullDuplexSerial" 'comms to SER. SER : "Parallax Serial Terminal" 'comms to SER. PST : "Parallax Serial Terminal" var 'long recv byte recv byte message1[255] byte Lengthis pub go 'SER.start(SER_DOUT_PIN, SER_DIN_PIN, SER_MODE, SER_BAUD) 'start comms to SER SER.StartRxTx(SER_DOUT_PIN, SER_DIN_PIN, SER_MODE, SER_BAUD) 'start comms to SER PST.Start(9600) PST.Clear PST.str(string("Starting Remote Side 2",13) ) waitcnt(cnt + (3*clkfreq)) 'wait 3 seconds 'SetString( @message1, String("Hello how are you doing") ) repeat ' SER.tx("H") 'prompt the host for validation ' recv := SER.rxtime(250) 'receive our response byte, wait 1/4 second max for response SER.StrIn(@message1) 'PST.dec(recv) PST.str(@message1) PST.str(string(" ",13)) Lengthis := StrSize(@message1) Pst.dec(lengthis) PST.str(string(" ",13)) if lengthis > 0 'if we receive a valid response, then execute the following... PST.str(string("message received on Remote side: ",13) ) else 'else, if something else was received PST.str(string("No messages received on remote side",13) ) SER.str(string("A message from the remote site",13) ) waitcnt(cnt + (3*clkfreq)) 'wait 3 secondshost side
{{ Computer Side (host) }} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' SER_DOUT_PIN = 1 ' SER_DIN_PIN = 2 SER_DOUT_PIN = 24 SER_DIN_PIN = 26 SER_MODE = %0000 SER_BAUD = 9_600 'SER_BAUD = 115_200 LED_PIN = 20 TX_PIN24 = 24 RX_PIN26 = 26 NL = 13 ''NL: New Line obj 'SER : "FullDuplexSerial" 'comms to SER. SER : "Parallax Serial Terminal" 'comms to SER. PST : "Parallax Serial Terminal" var 'long recv byte recv byte count byte Lengthis byte message2[255] pub go 'SER.start(SER_DOUT_PIN, SER_DIN_PIN, SER_MODE, SER_BAUD) 'start comms to SER SER.StartRxTx(SER_DOUT_PIN, SER_DIN_PIN, SER_MODE, SER_BAUD) PST.Start(9600) PST.Clear PST.str(string("Starting Host Side",13) ) 'main loop repeat ' SER.StrIn(@message2) waitcnt(cnt + (1*clkfreq)) 'wait 3 seconds PST.str(@message2) PST.str(string(" ",13)) Lengthis := StrSize(@message2) Pst.dec(lengthis) PST.str(string(" ",13)) if lengthis > 0 'if we receive a valid response, then execute the following... PST.str(string("message received on Host side: ",13) ) else 'else, if something else was received PST.str(string("No messages received ",13) ) SER.str(string("A message from the host site",13) ) waitcnt(cnt + (3*clkfreq)) 'wait 3 secondsI tried it on two different cards, (4 in total) same results
sometimes it works fine, others it is just a mess, I also changed out the wires
I think the transmission needs some hardware stablization.
regards
Jeff
Post a picture of the "mess" ?
sure, there are some other strange things, one thing I noticed was that when I connect the two pins (pin 1 and pin 2) to the other board, it gets power, ie the green power led turns on the board with no other power source connected on the board. I checked the two pins, pin1 and pin 2 and there is 3.3 volts on both. but I did not connect a ground to the other board, so I have no idea why this should happen, unless you can power another propeller board thru any io pin.
I'm thinking that there can only be one power supply for both boards, and use vin for powering both boards, tomorrow I will take a sample of the mess vs normal. I also will trace it on a scope to see hat is going on.
regards
Jeff
Actually, some parasitic power does get through. This has been a long time point of confusion.
Just because you see a little green, doesn't mean it has good power, and weird things can happen.
If you made your own boards (or breadboarded with DIP chips) it's very important to follow good power and ground practices with the propeller chip. All VDD and VSS should be connected (3.3V and GND respectively), and some local filtering should be used like 0.1uF capacitors and a bulk 100uF or so polar electrolytic or tantalum capacitor all rated 10V or more. Make sure there is a common ground between boards of course.
This is a fundamental property of all CMOS chips - the input/output protection diodes mean power can come
from any signal pin at all.
However doing this is really bad news indeed, the protection diodes are good for 500uA only, so if you
do this you burn out the diodes. Worse still you risk triggering CMOS latch-up which cooks entire chips,
and the driving pin is overloaded and can burn out.
Connecting separate boards which may not both be powered up has to be done carefully because of this -
typically some 10k series resistors might be added to the serial connections (although this reduces bandwidth),
or extra schottky diodes are added to take the current safely to the rails coupled with a few hundred ohms
of current-limiting resistor.
The simplest way to connect boards safely is using open-drain signals with pull-up on the receiving board.
Either board can be powered down and nothing bad happens - the supply voltages can even be different
(to a limited extent). You can even test for the other board being powered!
I have been running connected all day with no issues, but as noted, making sure the power is correct and stable seems to be a key point. all day i have been running two power sources and monitoring them with a Logic Analyzer, the power is to each board, with the three pins, TX,RX and Ground between them, and things are fine.
but when i was looking at it this morning, i just reset both units and then watched the scope to see what was going on, most of the time things are great (communication is good, transmission every second, but if you connect anything else, such as a usb cable to either board while transmitting, things go down hill and the scope shows constant transmission on both signals, I'm not sure why connecting a usb cable makes such a difference but is seems to mismatch the power and the signals go crazy.
if you have a recommendation on what resistors or caps should be added, it would be helpful and i can test it fairly soon, I would like to only add the components to the RX and TX lines. and then I can retest.
I'm not sure what is required for this suggestion below, since I'm not an ee or even close.
"The simplest way to connect boards safely is using open-drain signals with pull-up on the receiving board.
Either board can be powered down and nothing bad happens - the supply voltages can even be different
(to a limited extent). You can even test for the other board being powered! "
regards
Jeff
You could plug in anything like a web-cam or whatever and FTDI chip boards will reset.
Solution? Don't do that.
the boards are the activity board and the project board, I understand the reset, but what happens after is more interesting, once the usb is connected, the transmission never recovers, only way to recover is to disconnect the usb, but I should point out some details.
I have two boards
1 activity board and one project board, both boards use the standard 7 volt parallax power supply, and both power supplies are on, if I am connected to the activity board with usb, all is well, I can reboot both boards and watch the scope, there is normal transmission and messages, what I never could get to work is if I connect to the usb on the project board, and monitor it thru the terminal and scope, whenever I connect to the project boards thru usb, after the board resets (both boards), I never can get back to normal communication. if I then disconnect the usb on the project board and connect it back to the activity boards, (after the boards reset) all is well, communication resumes and I see normal communication on the scope.
anyway, I would like to protect the tx and rx pins from voltage issues, do you have any hardware recommendations?
It was mentioned that an open drain would help, I was wondering if anyone has experience with NC7WZ07?
regard
Jeff
74LVC2G17
LVC Data says [" This device is fully specified for partial power-down applications using IOFF.
The IOFF circuitry disables the output, preventing the damaging backflow current through
the device when it is powered down."]
so there is no phantom power path that can prevent proper resets, but when powered they can work faster.
A simple series R on both boards can give more ESD / slip protection, choose a value that gives a time constant well above the BAUD speed.
The 2G17 is a dual, non inverting schmitt, so you can use 1/2 TX and 1/2 RX
Tracy Allen tried to teach me the difference between a NUL character and a framing error but it wasn't until Tracy started fixing the code himself that this problem was fixed. The problem was with the four port object (would you would likely find useful) but I think the framing error issue also applied to FDS.
I found adding a pull-up resistor to each line really helped keep the noise down. I don't think I need to use the pull-up resistors when using Tracy's version.
I'm not sure what "voltage issues" you mean?
If you have a programming error where one Propeller set an I/O pin high and the other Prop sets it low, then there's a chance of damaging the Propeller. A 100 ohm series resistor would keep the current to a safe level if this is a concern.
How long are your wires between the Propeller boards? There are other alternatives besides just using 3.3V logic if the wires are long. RS-232 and RS-485 are popular protocols which should work over a longer distance than 3.3V logic.
the distance between boards is about 12-14 inches,
my setting on both boards are
SER_MODE = %0000
SER_BAUD = 9_600
I am much more interested in reliability than speed
"The 2G17 is a dual, non inverting schmitt, so you can use 1/2 TX and 1/2 RX"
sorry my dumb question, what do you mean by 1/2 TX and 1/2 RX (wattage?, volts?)
on my oscilloscope shows the mean voltage at 3.44 for RX and 3.28 for tx.
rise time is about 40us,
thanks and regards
Jeff
The 74LVC2G17 is a two input-two output device. I believe he meant to use 1/2 of the device for RX and the other half for TX.
thanks
regards
Jeff
#18 is correct - you wire one buffer facing each way, one on TX one on RX.
That gives you the over-voltage tolerance on both pins, and also isolates the Prop from the coal face a little.
Something like 470R in each line on each board, gives more esd/slip protection too.
Start testing with a common supply sequence, and also confirm you have graceful recovery from disturbance on each side. (and also a reset-recovery on one side only)
Then do split power sequence, and check Vcc on the non-powered board, to confirm you have removed phantom power effects. Partially powered boards can fail to properly reset.
Adding a proper Voltage reset part (APX803 etc) can also help here - that also ensures the part is not released from RESET until Vcc is valid.
(Some regulators have a PGOOD signal, use that if you have one )
9600 baud is quite slow, if reliability matters, you can increase that and add redundancy/checksums/framing to make sure only valid packets are used.
thank you for the data,
a few questions, i am getting the ic SN74LVC1G17DBVR from digikey, and will add it to the circuit, I also will add the 470ohm (ic package) on each serial trace line.
I have a question on the APX803, there are various versions,
min typ max (volts)
APX803-23 2.21 2.25 2.30
APX803-26 2.59 2.63 2.66
APX803-29 2.89 2.93 2.96
APX803-31 3.04 3.08 3.13
APX803-40 3.94 4.00 4.06
APX803-44 4.31 4.38 4.45
APX803-46 4.56 4.63 4.70
I think i should get apx803-31 or 40, not sure which, this is for a propeller.
where should this go, the way i have it set up, each the proto propeller boards are unmodified (there will be 5 boards) , I use a 40 pin connector and cable to go to the pcb board (about 6 inches), the pcb board gets vin, and then the propeller voltage regulators send 3.3 volts back on vdd. which supplies the pcb board with 3.3 volt power, ( ihave this in pcb (expresspcb layout) if you would like to see it, I think this would be placed before i receive the 3.3 power back to the pcb board from the propeller.
the package for this is sot23, which is pads of 0.65 mm to tiny, so i will try to find a slightly larger package.
the ic SN74LVC1G17DBVR will go on the serial interface board, I have the serial interface board in PCB layout (expresspcb) format if you want it.
thanks and regards
Jeff
Strangely it always works perfectly for communication with the PC, for PST.
I've switched to using this FullDuplexSerial2K.spin object for all of my projects and all of my problems evaperated. It runs cleanly all the way up to 115200.
FullDuplexSerial_2k.spin
the pcb board is being built, when i get it back I'll test with your spin module and report back.
regards
Jeff