FullDusplexSerial Hints

lairdt

Any good hints on using FDserial?· New to this·library - I've been following the various conversations about stop bits and such, but nothing seems to help with the issues I'm running into.

Working with a Multilabs ezDisplay, I had a library that could send just fine, but not recieve - I'd like to recieve data from the touchpad now. So - I decided to convert over to FDserial. I'm having issues with sending data now that I didn't before, almost like there is a number of bits that need to be transmitted before it will start to work correctly. This doesn't appear to be an 8bit vs 7bit kind of thing, more like the amount of info transmitted before things start to work consistently.

I'm running fdserial.start(26,25,0,9600), then sending data to format the display... which appears to get dropped for a bit before it works... kinda.

Ideas?

Mike Green

You're going to have to provide much more information. FDSerial works well in other applications. It would be very unusual for it to be the source of the problem you're experiencing, particularly since you seem to be doing very straightforward things. It would help for you to post a diagram of your system and to attach a complete source of your program and maybe a more thorough description of what seems to be going wrong and when does it appear.

lairdt

Thanks for the quick reply Mike - you really do live here!

I'd hoped that there were some kind of gotcha's list for FDserial, but if that's not the case then it's faster for me to go back to the old library that works and add what I need to recieve data.

Diagram I don't have, but it's a very simple minimal setup: prop DIP40, 5mhz xtal, 32k eeprom, propclip attachments, ttl display on p1 for debugging, LEDs on p16-23, ezDisplay tx/rx on p25/26. Defined _clkmode = xtal1 + pll16x and _xinfreq = 5_000_000...

Code - I'll save all of that for something much more involved and puzzling. Since the old lib worked it just seemed too simple not to change over, but I'd rather debug new code than deal with FDserial nuances right now.

mirror

FullDuplexSerial does not check the stop bit. I added that and a couple of other things into SerialMirror.

http://forums.parallax.com/showthread.php?p=649541

tekochip

As long as we're talking about FullDuplex, does anybody know the speed limit?· I got it up to 115K, but that seems to be the limit.

TomS

I'm using it at 230400, which is the fastest I can set my Xport-AR. It's only over an inch long path though.

Tom

mirror

The issue at this speed 230400 will not be path length. The limit is in the code, and how long it takes to go round the Rx/Tx loop. Having said this, I've not tried to measure the limit. Serial port access could be made faster by splitting the transmitter and receiver into two cogs.

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

TomS

That depends. Yes, the code speed is the ultimate limit, but if you're using a cable between xmtr & rcxr, the capacitance will limit the length of cable you can use.

mirror

TomS said...
That depends. Yes, the code speed is the ultimate limit, but if you're using a cable between xmtr & rcxr, the capacitance will limit the length of cable you can use.

Yeh, but you'd have to be intentionally hanging capacitors off the wire to have a problem over 1 inch! I'm·not having a problem at 10,000,000 baud (SPI) over a distance of 3 inches using the Propeller.

TomS

[noparse][[/noparse]Yeh, but you'd have to be intentionally hanging capacitors off the wire to have a problem over 1 inch!]

I wasn't referring to my one inch but the possibility that tekochip was using a cable and that was limiting his speed. I've looked at the serial stream on an oscilloscope and don't see any reason you couldn't bump the speed up one more notch to 500K. I think the timing would be adequate. Now to find some means to test it at 500K!

Tom

tekochip

I have a 2" board trace. It seems that it becames less duplex at higher speeds; I can transmit, I can receive, I can't do both.