Getting two props to talk
Enrique
Posts: 90
I’m trying to have two Propellers talk to each other using FullDuplexSerial. In both cases I have set pin 17 for receiving the data and pin 16 for transmitting it. I connect directly with a wire pin 16 from one Propeller to pin 17 of the other.
·
The receiving propeller is behaving as if it is receiving data when none is being transmitted. I checked with a logic probe and I see no signals on the line. Do I need some kind of pull-up or pull-down resistors?
·
·
Enrique
·
The receiving propeller is behaving as if it is receiving data when none is being transmitted. I checked with a logic probe and I see no signals on the line. Do I need some kind of pull-up or pull-down resistors?
·
·
Enrique
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH
The FullDuplexSerial Object sets the algorithm for clocking in and out data, but it doesn't set the protocol for the data.· A protocol would described a data packet of how information is sent.· Having a data packet format may help transmission because you could setup a start byte of $FF.· The receiving Propeller would watch the line for $FF and when it sees $FF then the Propeller would clock in the next number of bytes.· Implementing a state machine or similar architecture for receiving data is on top of the serial object.· Make sense?
I also second that you need to tie the grounds together of two different boards if you are in fact using two different boards.· Further to this idea, how far apart of the processors?· If they are a couple feet away then you·may need to do some converting of signals from CMOS (3.3V) level to another means like RS232/422/485 or other.· Distance can bite you here if you are not careful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC, eProto fo SunSPOT, BitScope
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I suspect that your problem may be in the initialisation of the serial object, here is how I started serial mirror object.
It would help if you posted your code and we may just be able to help you further.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
·
I am running all the tests using a breadboard; the two microcontrollers share a power supply so I am sure there is a common ground.
·
I am using a logic probe to trace the program execution. I am sampling the transmit and receive signals as well as pins 18 and 19 which I use for tracing purposes.
·
I see on the probe pin 18 pulsing constantly. Before the data is transmitted pin 19 pulses every now and then. While the data is being transmitted pin 19 pulses once, after it is transmitted it pulses again and the it doesn’t pulse any more until I reset the transmitting Propeller.
·
Transmitter code
·
{{File TwoPropsCommTrans.spin Transmiter side }} con _xinfreq=5_000_000 _clkmode=xtal1+pll16x transPin=16 'transmision pin recPin=17 'receiving pin baudRate=300 '300 bauds mode=0 'comm mode obj comm:"FullDuplexSerial" 'The comm object pub main dira[noparse][[/noparse]0]~~ '********************************************************** outa[noparse][[/noparse]0]~ '********************************************************** outa[noparse][[/noparse]0]~~ '********************************************************** outa[noparse][[/noparse]0]~ '********************************************************** outa[noparse][[/noparse]0]~~ '********************************************************** comm.Start(recPin, transPin, mode, baudRate) comm.tx($02)Receiving code
{{File: TwoPropsRec.spin }} con transPin=16 'transmision pin recPin=17 'receiving pin baudRate=300 '300 bauds mode=0 'comm mode _xinfreq=5_000_000 _clkmode=xtal1+pll16x motorPin=0 'first motor pin obj comm:"FullDuplexSerial" 'The comm object motor:"StepperDriver" 'Motor driver pub main | byteReceived dira[noparse][[/noparse]18]~~ '************************************************************ dira[noparse][[/noparse]19]~~ '************************************************************ outa[noparse][[/noparse]18]~ '************************************************************ outa[noparse][[/noparse]19]~ '************************************************************ motor.start(0) comm.Start(recPin, transPin, mode, baudRate) comm.rxflush repeat byteReceived:=comm.rxcheck outa[noparse][[/noparse]18]~~ '************************************************************* outa[noparse][[/noparse]18]~ '************************************************************* if byteReceived <> -1 outa[noparse][[/noparse]19]~~ '************************************************************* outa[noparse][[/noparse]19]~ '************************************************* case byteReceived $01: motor.Halt $02: motor.GoUp $03: motor.GoDown·
I can't remember exactly and I don't have my rig set up to test it but I'm sure I had the same problem at low speeds.
I solved it by putting a pullup resistor on the comms lines.
Regards,
Coley
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite
Data Direction Register?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Enrique
·
First, no need for pull-up or pull-down resistors.
·
I had to change the code on the transmitting prop, this is the final code.
{{File TwoPropsCommTrans.spin Transmiter side }} con _xinfreq=5_000_000 _clkmode=xtal1+pll16x transPin=16 'transmision pin recPin=17 'receiving pin baudRate=9600 '9600 bauds mode=0 'comm mode obj comm:"FullDuplexSerial" 'The comm object pub main comm.Start(recPin, transPin, mode, baudRate) waitcnt(clkfreq+cnt) 'wait for comm cog to initalize repeat comm.tx($02) 'have the motor go up waitcnt(clkfreq*3+cnt) 'wait 3 secs comm.tx($03) 'reverse direction waitcnt(clkfreq*3+cnt) 'wait again·
You will notice that I added a 1 sec wait (it could also be 100msec) after the comm.Start sentence; this gives the communications cog time to start up. Most probably when I sent the comm.tx command the other cog was not ready yet.
·
·
Thanks for those answers,
·
Enrique
Glad to see that you were successful!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔