Help with moving over to Simple_Serial from DuplexSerial

DiablodeMorte

First off: Thanks to StefanL38 for helping me with my other problem, i just don't want to bump that thread saying thanks

Here's the situation:
I'm working on an object to let me interface with a MaxBotix MaxSonar sensor. I've gotten the code to work with the code attached(MaxBotix.spin) but I don't want to use a cog just to get sonar, so I'd like to move over from FullDuplexSerial to SimpleSerial. I tried simply changing Com : "FullDuplexSerial" to Com : "SimpleSerial" since Simple Serial is supposed to me a drop in replacement for FullDuplex. I changed the Baud to inverted(ie -9600 baud) like it's supposed to be and the code KINDA works. I get some Smile data(4 hex numbers) and then the "R" like there's supposed to be, then the 100's digit, then the 10's digit, and then the hex number $9A. it's always 9A but it's supposed to be the 1's digit. Remember, this works perfectly with FullDuplexSerial but it seems that with SimpleSerial it doesn't work. Any suggestions?

Regards,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Projects:
Robot Control Via Skype API - Dev Stage(50% Complete) - Total(25%)
Robot Localization Via Xbee's - Research Stage
IR Tracking with Propeller - Research Stage

StefanL38

Hello Harrison,

about your initial question why is the 1's-digit always $9A. I guess this has to to with the timing
FullDuplexSerial dedicates a cog to receive and send bytes in assembler which makes it possible to
send/receive data up to 115200 baud.

Simple_serial is written in SPIN which is quite slower. (it only manages 19200 baud)

The Sensor sends all four bytes straight forward with no extradelay between the bytes. Your samplecode MaxbotixSonar.spin sends several bytes on com2 before
you come back to receive the next byte from the sensor on com1 and in the meantime the other bytes are already through.
The FullDuplexSerial-object receives the bitstream and buffers the received bytes. In simple_serial there is no buffer.
And therfore bytes can get lost much easier than in fullduplexserial.

As the name says simple_serial is quite simple.

The Simple_Serial has no DEC-Method which is used by your MaxbotixSonar.spin-code.
But you can copy & paste the dec-method from the FullDuplexSerial-object

in general:
the Simple_Serial-object does not need another cog - but if the bytes came in at unpredictable times your program has to stay inside the rx-method until a byte comes in.
In the meantime your program can do NOTHING else. So this cog would be dedicated exclusive to serial receiving too.

If this sensor works this way:

you send out a byte as a command "hello sensor send me ONE actual value" and you could wait then for the answer of the sensor there might be a chance
to put this in a loop together with other parts of your program that should be executed periodically.

If your sensor sends bytes all the time you will loose bits and bytes. The simple_serial-objects waits for the Startbit to come in.

If the sensor sends values all the time the timepoint when you call the RX-Method of simple_serial will be at ANY time. So the sensor will be at ANY bit of ANY byte
when the RX-Method "thinks" this is the startbit and then it will mix-up the rest of the bits. It might be possible to manage this problem by analysing the bytes and through away bad bytes,
but i think it will be much easier to use FullDuplexSerial. With FullDuplexSerial all bytes will be received properly. If you don't read out the receivebuffer periodically the oldest bytes just get
overwritten by the newest bytes.

Serialdata receiving is quite timecritical. I think there are other things that are less timecritical which can be shared in one cog in one loop together.

So a question from me: what do you want to do in SUMMARY with the propeller ? Do you think you will ran out of cogs ?
Tell us what you want to do ALL in final.

So my recommendation is to use FullDuplexSerial

best regards

Stefan

Post Edited (StefanL38) : 5/25/2008 8:57:34 PM GMT

Mike Green

If you're running out of cogs and you don't need to listen to the Maxbotix Sonar all the time, you could effectively turn the serial port (Simple_Serial) on and off cyclically. In other words, you'd start a cog which would initialize Simple_Serial, get a reading from the sensor, then stop itself thus freeing up the cog for some other use. It takes a couple of hundred microseconds to start up a cog and get ready to do serial I/O. That's not bad if the Prop is controlling the sensor and you can wait a millisecond to get the next reading.

DiablodeMorte

I'll probably revisit this at another time. I've decided to use FullDuplexSerial and just deal w/ the slight delay of getting the data. To StefanL38: what I am trying to design is a flight control unit for a robotic blimp. I want to use the sonar sensor to measure height. I forsee the use of many cogs inorder to control all the sensors on the unit. What I wanted to do was to create a non-blocking way to read the sonar. If i used FullDuplexSerial this would require 2 cogs, 1 for FullDuplex and the other 1 the nonblocking read. If i used Simple Serial It would only take 1 cog. I've decided to use FullDuplexSerial and only use 1 cog and just deal with the small amount of time needed to get the data via the core program. If I start running out of cogs i'm sure i'm going to use your idea Mike and just shutdown what I don't need.

Thanks to everyone.

Regards

EDIT: Published @ Obex: obex.parallax.com/objects/325/ If anyone has a MaxSonar and some time please try it out and gimmie some feedback! Thanks

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Current Projects:
Robot Control Via Skype API - Dev Stage(50% Complete) - Total(25%)
Robot Localization Via Xbee's - Research Stage
IR Tracking with Propeller - Research Stage

Post Edited (DiablodeMorte) : 5/25/2008 11:49:59 PM GMT