8 data bit Serial Issue with FullDuplexSerial
Greidinger
Posts: 2
I apologize if this issue has already been explained in the past - I did search beforehand and unfortunately I was unable to find anything.
This is tested with a simple serial terminal program with no parity, 8 data bits, 1 stop bit, and no hardware flow control. Baud is set to 9600.
Basically, bytes that are transmitted to the serial terminal appear to have their MSB set to 1 regardless of the input value. When I set my terminal to 7 data bit mode, it partially works (see below), but I do require 8 bit width.
Furthermore, if I don't bitwise-or the transmitted data with 0x80 MSB - 1 will be zero.
This happens with received data as well - in this case I bitwise-and with 0x7F in order to strip the faulty bit.
The code itself is trivial:
Clearly, I'm missing something important. Any help would be appreciated.
This is tested with a simple serial terminal program with no parity, 8 data bits, 1 stop bit, and no hardware flow control. Baud is set to 9600.
Basically, bytes that are transmitted to the serial terminal appear to have their MSB set to 1 regardless of the input value. When I set my terminal to 7 data bit mode, it partially works (see below), but I do require 8 bit width.
Furthermore, if I don't bitwise-or the transmitted data with 0x80 MSB - 1 will be zero.
This happens with received data as well - in this case I bitwise-and with 0x7F in order to strip the faulty bit.
The code itself is trivial:
OBJ
comms : "FullDuplexSerial"
CON
rxPin = 31
txPin = 30
var
byte input
PUB runTest
dira[noparse][[/noparse]19]~~
dira[noparse][[/noparse]22]~~
if comms.start(rxPin, txPin,0,9600)
outa[noparse][[/noparse]19] := true
waitcnt(30_000_000+cnt)
repeat
comms.tx("a" | 128)
'displays a repeatedly on the screen
waitcnt(50_000_000+cnt)
Clearly, I'm missing something important. Any help would be appreciated.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
"a" is normally ascii 0x61 (from memory).
"a" | 128 is ascii 0xe1.
I think Greidinger is doing it like this to demonstrate what he does to get the code to operate in his "7 bit mode".
It all makes me hugely suspicious of the bit times - hence clock rates etc.
·
*Peter*
I think you have a baudrate-problem. In your posted code, you don't have set the crystal frequency and pll-mode. In this case the Propeller runs from the internal 12 MHz oszillator, but this is not exact enough for serial communications.
In the CON section use this:
_clkmode = xtal1 + pll16x _xinfreq = 5_000_000and forget the 7 Bit mode and the setting/masking of the MSB.
Andy
-He has already had it 'quasi' running in·7 data bits mode ...
Not quite sure whats the issue here though..
I set the my logger to 9600,n,7,1 - and ran example on prop..
on test with no CLK settings the only difference is the repeat delay - it successfully sends·'a'·!
I don't get the overall question though - when the example just transmits 'a' ??
QuattroRS4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 7/24/2007 2:47:08 AM GMT
Con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 rxPin = 31 txPin = 30 OBJ comms : "FullDuplexSerial" var byte input PUB runTest dira[noparse][[/noparse]19]~~ dira[noparse][[/noparse]22]~~ if comms.start(rxPin, txPin,0,9600) outa[noparse][[/noparse]19] := true waitcnt(30_000_000+cnt) repeat comms.tx("a" | 128) 'displays a repeatedly on the screen waitcnt(50_000_000+cnt)Gives '?' repeatedly as output char on logger set to 9600,n,8,1 - obviously as databits set to 8 not 7 on the logger.
as with Peters question re: |128 .. so I dropped it to test..
Con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 rxPin = 31 txPin = 30 OBJ comms : "FullDuplexSerial" var byte input PUB runTest dira[noparse][[/noparse]19]~~ dira[noparse][[/noparse]22]~~ if comms.start(rxPin, txPin,0,9600) outa[noparse][[/noparse]19] := true waitcnt(30_000_000+cnt) repeat comms.tx("a") 'dropped the '|128' 'displays a repeatedly on the screen waitcnt(50_000_000+cnt)and output char is 'a' repeatedly on logger set to 9600,n,8,1 - again because |128 dropped so databits are 8.
The opposite is true when |128 is added and logger set to 9600,n,7,1
Which means all is well ...
That said I tried it without the CLK settings (as per Ariba) and dropped the |128 and I get odd results
with a 9600,n,8,1 but fine with the |128 and CLK not set..at 9600,n,7,1
so Overall question remains though - where is the issue ? Perhaps Ariba nailed it - funny though how it seemed to work with no CLK vals in CON and 9600,n,7,1 ..
Regards,
QuattroRs4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 7/24/2007 2:59:24 AM GMT
If the Serial communication on your Propeller works also with the internal 12MHz oscillator, then you can be lucky, you have a chip with really 12 MHz oscillator. But this is not always the case, the Datasheet says this internal osc can be 8...20MHz! I have 2 Propellers , one has also exact 12MHz the other not.
The problem is that the FullDuplexSerial uses a clkfreq of 12_000_000 to calculate the bittime for a given baudrate, also if the oscillator has not exact this frequency, and so the baudrate can be wrong.
I think the frequency of Greidingers osc. is slightly higher then 12 MHz, so instead of Bit7 the terminal receives already the 1. stopbit (wich gives always MSB set). If he uses only 7 Bits then it works "partially" because as Bit6 the terminal receives sometimes Bit 6, sometimes Bit7 of what the Propeller sends.
The FullDuplexSerial always uses 8 bit + 2 stopbits. With | 128 he sets the MSB (Bit7) to 1 what makes a third stopbit. So he gets 7 bit + 3 stopbits.
Andy
Aware of that .. but as you can see I had it working lucky maybe - but thats where (i think) the issue is .. if you see from the post - I had said you had nailed it - for this very reason he was getting a 'Quasi' working sample ...
You will note from the post I had added CLK settings and gave the results then at the end of the post I added the anomaly - I have a jpg of the samples without CLK settings to highlight this anomoly .. was going to append previous post but I will put it here instead..
I had highlighted this very issue a few months back on a thread
http://forums.parallax.com/showthread.php?p=626420
QuattroRS4
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
Post Edited (QuattroRS4) : 7/24/2007 3:48:07 AM GMT
It's odd, I suspected that the internal oscillator was to blame but I never got around to checking it - I ended up checking everything else though. One trivial fix and everything worked great.
One thing I noticed in my experiments earlier is that the results were sometimes inconsistent (even when they were wrong) and this disturbed me. Is it possible that the internal clock is not only running at a different frequency than advertised (12mhz) but also inaccurate timing-wise?
Thanks again for the extremely helpful responses, everyone.
edit: Just noticed that QuattroRS4 demonstrated the inconsistency issue in the post above.
Post Edited (Greidinger) : 7/24/2007 9:32:12 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In Quattros example the internal Clock is slightly higher then 12MHz and every bit is a little to short. At one point the sampling point is just at a bit border (Bit5-Bit6 here) and because the sampling point differs, one time Bit5, an other time Bit6 is taken:
%10000110 = $61 = 'a'
%10000100 = $21 = '!'
Andy
Post Edited (Ariba) : 7/24/2007 10:20:17 AM GMT