serial RX problems...

Jack Buffington

I have encountered a strange issue when using fullDuplexSerial, the propeller professional development board using the programming cable as my serial connection to the computer, and the Parallax serial terminal. I'm not sure what the problem is.

I am working to emulate a program that I once wrote for the PIC processor. I have a PC-side program that queries the processor with four bytes of data and then receives about a hundred bytes in response. The very simple propeller tester that just fakes its return data wasn't responding to the queries from the computer so I have done some testing today and have found that it is incorrectly receiving bytes with a value greater than 126 (it would be easier to understand if it were greater than 127...) I query the processor with (255)(data1)(data2)(data3). It is missing the 255 for some reason.

Here is a list of values

I send --- Propeller sees
127 --- 166
128 --- 199
129 --- 252
130 --- 233
131 --- 226
132 --- 228
133 --- 224

Here is the test code that I have used to determine these values:

SERIAL.Start(31,30,0,115200)

repeat
temp := SERIAL.rx
serial.tx(temp) ' send the same value right back

hundreds := temp / 100
temp := temp - (hundreds * 100)

tens := temp / 10
temp := temp - (tens * 10)

oness := temp


serial.tx(hundreds + 48) ' + 48 to turn the numeric value into an ASCII character for that value
serial.tx(tens + 48)
serial.tx(oness + 48)

Maybe the issue is my command of spin? I have spent most of my time working in propeller assembly. I can't see any rhyme or reason for the changes in the bit pattern for the improperly received bytes.

Mike Green

I would start testing with a Baud of 9600, not 115200. Your program seems ok, assuming that the indenting is ok. Make sure of that. I can't tell from what you posted. 115200 Baud is ok and should work, but if anything is off like the PC's or Propeller's Baud timing, 115200 Baud is pushing things.

Rayman

What object are you using? Is it the standard "fullduplexserial" ?
Never mind I see it now...

I've not heard of problems at 115200 baud, but I'm sure Mike knows better...

What are you using for a crystal? What is your PLL setting?

Maybe you don't have a high enough clock frequency?

JonnyMac

Does the crystal on the board match the setting in the code? I go back and forth between 5 and 6.25 MHz crystals and sometimes forget to make the appropriate code change.

Jack Buffington

I'm using the standard 5MHz crystal that came with the board with 16xPLL. It doesn't seem to be the speed of the connection that is the issue. I tested things just for fun and it looks like I can reliably go up to 1 Megabaud without errors. My program only needs 115200 so I am definitely safe with the baud rate. I'll try to run the code on a different board tomorrow. I think that I have something laying around that should work.

Jack Buffington

I just tried running things at 9600 baud but still received the same error. I'll have to check the actual signals out on my oscilloscope. I just figured that this must be something stupid that I was doing with software rather than a possible hardware problem. I have another USB to serial cable lying around in a drawer. I'll give that a try as well.

Rayman

Try posting your entire program here and perhaps someone will spot the problem....

StefanL38

program works as expected on my PPDB

see attachment

Jack Buffington

Today I tried a different serial adapter using the MAX232 chip on the PPDB instead of the FTDI chip. Same result.
I tried a different computer with Windows 7 instead of Vista. Same result.
I tried running the code that Stefan posted. Same result...

I haven't had a chance to take a look at things on my oscilloscope. Maybe that will help sort things out.

How did you send your bytes to the PPDB Stefan? I am holding down Alt and then typing the ASCII code on the numeric key pad to generate my bytes. The Propeller Serial Terminal is showing the correct characters (according to asciitable.com) so I am assuming that the proper characters are being sent.

StefanL38

Hi Jack,

catched it.
I just typed the characters themselves on the keyboard.
I tried your method and get the same results as you
example Alt-130 prop echoes back 233.

So simply try typing the letters directly

anyway thank you very much for posting this question. It shows perfectly that every dammed detail is important.

Some general advice:
for narrowing down a problem divide the whole thing into small parts
one part: what does PST.EXE send?

This question can be answered through making a loop-back connection. Means connect Tx and Rx directly together that each byte gets echoed back to PST.EXE

With doing this you would have found the same result Alt-130 = 233 but now knowing the problem is caused by PST.EXE, because nothing else than PST.EXE was involved using the direct loop-back.

This was standard-checking for me when setting up a new PC for industrial controls.

From your own tests you can conclude. It's not the PC it's not the OS, it's not the RS232-Chip
it's not the USB-serial adapater as you changed all these. So what could it be then?

The PC-software itself or the propeller-code. Propeller-code can be excluded as my code worked
on my PPDB. What stays left? PST.EXE when creating the characters through ALT-#

best regards

Stefan

kwinn

Make sure the PC is set the same as the FDS program for start, stop, parity, and data bits.

Jack Buffington

So I have a definite answer to this issue now. It is all in how Windows is translating my key presses. I downloaded Realterm which has a function to send numbers as a single character. When I used that feature everything worked. That's unfortunate. In the past, holding the alt key and typing a character code would work for ALL 256 character codes but now it seems that it only works for the first 127 of them.

schill

Something to try (I'm not in a position to check right now):

Instead of ALT 130, try ALT 0130 and see what happens (i.e., add a leading zero). If the result isn't any different, then I expect that Windows is doing some sort of additional interpretation of what you're typing.

Rayman

Ok, I see what's going on here now...

schill is right, you need to put a zero first...

Jack Buffington

Thanks guys!