Forgot. Good news - I only need one extra stop bit.
CON
_rx = 91
_tx = 90
DAT
orgh $380
start org
clkset #$FF 'set 80MHz
'setsera ser_parms, bit_time
clrp #_tx ' Enable _tx pin
mov dirb,leds
mov outb,#1 ' if we don't get to another outb, we jumped to never-never land
jmp #hubexec
ser_parms long %10 << 16 + _rx << 9 + %10 << 7 + _tx
bit_time long 80_000_000 / 115200
ch long 0
leds long $FFF
y long 0
x long 0
w long 0
count long 0
'----------------------------------------------------------------
orgh
hubexec locptra #hello_world ' orgh, F10 download works $38A
mov outb,##hubexec ' $38B/C
' mov outb,##hello_world
' getptra outb
' nop
loop rdbyte ch, ptra++ wz ' $38D
mov x,ch
if_nz call #tx ' $38E
' if_nz serouta ch ' $38E
if_nz jmp #loop ' $38F
jmp @hubexec ' $390
hello_world byte "Hello World!",13,10,0 ' $391
bub serouta #64
jmp #bub
tx shl x,#1 ' insert start bit
setb x,#9 ' set stop bit
mov count,#10
getcnt w ' get initial time
:loop add w,bit_time ' add bit period to time
shr x,#1 wc
setpc #_tx ' write c to tx pin
'passcnt w
waitcnt w,#0 ' loop until bit period elapsed
jnz x,@:loop ' loop until 10 bits done
add w,bit_time ' add bit period to time
waitcnt w,#0 ' loop until bit period elapsed
ret
Bill
What I found weird was my initial test of your code worked every time(repeated F11's ~ 20 times).
Then I went back to the previous FPGA release and it failed.
When I restored the DE2 back to the latest FPGA release it then failed.
I must have been lucky with the PropPlug the first time round.
Its all good now, except for my LOCLONG issue.
Brian
Sorry, I'm a little late to this party. I've been out of town all week. Thanks Chip for the new FPGA image! I just loaded it into my DE2-115 board and am getting the monitor prompt so I guess all is well. Now I have no excuse not to dive into porting gas to the new instruction set!
Yep, the non-deterministic nature of the issue was driving me nuts.
When the bit-banged code, several versions, had the same issue is when I realized the problem might be due to back-to-back bytes without a sufficient gap for some (ftdi) chips.
Looks like the serial ports need 1/1.5/2/3 stop bit configurability...
You are fashionably late. I just ordered my DE2-115 and add-on board this morning.
I'm hoping you guys will post all the code you don't think is worth posting.
I'm particularly interested in simple hub exec models. Stripped down versions of do nothing code:)
Thanks but I'm afraid I won't be back for long. I travel every week from Tuesday-Friday and am away from my DE2-115 board. I suppose I should buy a second for my alternate location. Maybe I'll save my pennies! :-)
I'm missing something. I was running SERA on the Nano under the 2014_02_06 emulation with a PropPlug consistently at around 1Mbps before I started seeing issues. You're seeing issues at 115,200, now?
Yes, with my PropPlug - I am guessing it is a different rev of the FTDI chip.
Bit-banging with two stop bits resolved the issue, I'll try 1.5 stop bits now
Edit: 1.5 stop bits also works - gives enough breating room to my PropPlug!
We can do experiments with different plugs & bit rates to characterize the issue, but I thin the best solution is to ask Chip to allow a choice of 1/2/3/4 or 1/1.5/2/3 stop bits.
I'm missing something. I was running SERA on the Nano under the 2014_02_06 emulation with a PropPlug consistently at around 1Mbps before I started seeing issues. You're seeing issues at 115,200, now?
Yes, with my PropPlug - I am guessing it is a different rev of the FTDI chip.
Bit-banging with two stop bits resolved the issue, I'll try 1.5 stop bits now
We can do experiments with different plugs & bit rates to characterize the issue, but I thin the best solution is to ask Chip to allow a choice of 1/2/3/4 or 1/1.5/2/3 stop bits.
OK, I understand. It is such a wonderful feature (SERA/SERB) and space saver the added flexibility of configurable stop bits would make even that much better.
We can do experiments with different plugs & bit rates to characterize the issue, but I thin the best solution is to ask Chip to allow a choice of 1/2/3/4 or 1/1.5/2/3 stop bits.
If the requested full length control is implemented, this comes as part of that.
- want 4 stop bits ? ask for an 11 bit Async Field, and send the last 3 bits always = Stop Value
Also, with granular baud settings, you can adjust the Baud rate deliberately to give what becomes fractional stop bits.
Yes, with my PropPlug - I am guessing it is a different rev of the FTDI chip.
Bit-banging with two stop bits resolved the issue, I'll try 1.5 stop bits now
Edit: 1.5 stop bits also works - gives enough breating room to my PropPlug!
What baud rates and data-grouping are you using to see stop bit issues ?
Expanding stop bits can make systems more tolerant of Baud skew, and baud skew can be more subtle than the usual 8-bit-sampling maths.
I recently had a Ceramic resonator fail on a Serial link, when it was well within the classic baud char tolerance.
Turns out the problem was not per-byte, but with sending larger packets with no pauses.
If you do that, a 1% baud skew can give an additional char over 100, and 0.5% baud skew can give an additional char over 200
Even with a FIFO on receive, the slower pacing on echo was not able to 'keep up'.
Try your system with 1 Stop bit, but fractions of +-1% as baud-skews.
I just tried 1%, 0.5%, 0.25% and 0.125% stretched bit cells, which should effectively have made the stop bit longer.
No joy.
There is no point in trying going the other way (shrinking the bit cells) as then the FTDI chip would be even more likely to miss the stop/start bit transition.
I just tried 1%, 0.5%, 0.25% and 0.125% stretched bit cells, which should effectively have made the stop bit longer.
No joy.
There is no point in trying going the other way (shrinking the bit cells) as then the FTDI chip would be even more likely to miss the stop/start bit transition.
How many streamed bytes does it take for this to appear ?
Can you give some more details on Baud rates / test setup ?
Did you scope things to confirm exact baud value, and edge alignments ?
Yes, with my PropPlug - I am guessing it is a different rev of the FTDI chip.
Bit-banging with two stop bits resolved the issue, I'll try 1.5 stop bits now
Edit: 1.5 stop bits also works - gives enough breating room to my PropPlug!
We can do experiments with different plugs & bit rates to characterize the issue, but I thin the best solution is to ask Chip to allow a choice of 1/2/3/4 or 1/1.5/2/3 stop bits.
The problem seems to be if serial data is already being streamed when the PropPlug is enabled(opened) it has difficulty locking onto the start bit.
If a delay is allowed to open PST for example before transmission starts all works Ok. This I have tested to 1M baud.
I think you have hit it on the head, and based on your findings, I now think that the precise nature of the problem is the uart within the FTDI chip not being able to lock on to the start bit when the data stream is back to back, with no inter-character gap.
It would lock on to the first low bit it gets, thinking that it is a start bit, get eight bits, then not find a stop bit, rinse and repeat. Eventually it would get an offset bit stream that "looks" ok to it, and return garbage characters.
Using the bit-banged output, I was able to determine that adding half a stop bit is enough for the FTDI uart to synchronize properly. I'll probably try 1/4 bit time today, even though 1.25 stop bits is not standard.
The good news is that the problem was NOT with the P2!
And the investigation verified a number of instructions.
The problem seems to be if serial data is already being streamed when the PropPlug is enabled(opened) it has difficulty locking onto the start bit.
If a delay is allowed to open PST for example before transmission starts all works Ok. This I have tested to 1M baud.
Bill,
It seems that in the end the FTDI chip can handle "back to back" data as long as you give it
some "breathing space" before you start things going.
At least we know what it is npw
Cheers
Brian
Bill,
It seems that in the end the FTDI chip can handle "back to back" data as long as you give it
some "breathing space" before you start things going.
At least we know what it is npw
Cheers
Brian
Wouldn't this be true of any UART? If it starts sampling in the middle of a continuous stream how would if find a byte boundary? There is no bit stuffing in the serial protocol so there is no guarantee of finding a start bit among all of the data and stop bits is there?
- don't start blasting data at an FTDI chip mid-stream (wait a bit, like you found)
- make stop bits be 1.5 bit periods if you want an FTDI chip to read fire-hosed data
This also suggests that if I wait to receive a byte before hosing data (with just one stop bit) it should work. Will try that.
I am also beginning to suspect that pretty much any uart would have trouble being connected to back to back one stop bit stream data stream ... mid stream ... without 1.5 stop bits.
What a pain. New fpga image, new PNut, I did not think to look at the PropPlug for why I was getting garbage... until I eliminated everything else. The LED's helped a lot
I think I'll expand my P2 test rig by permanently mounting one of my logic analyzers on it. I think there is even enough room on the current styrene board for it!
I like that idea! I could use it to watch the trace output!
Bill,
It seems that in the end the FTDI chip can handle "back to back" data as long as you give it
some "breathing space" before you start things going.
At least we know what it is npw
Cheers
Brian
Wouldn't this be true of any UART? If it starts sampling in the middle of a continuous stream how would if find a byte boundary? There is no bit stuffing in the serial protocol so there is no guarantee of finding a start bit among all of the data and stop bits is there?
And you posted that while I was typing my long winded reply, where I also realized that.
Sadly, due to the image being new, and new PNut version, I was looking in the wrong place for the issue.
I'm glad it didn't end up being a hardware problem. Now you can go ahead with playing with the new P2 features! I'm starting to look over the new instruction encodings with an eye to updating GAS. It's going to be a slow process though since I can only work on it on the weekends between boring chores! :-)
I was afraid of it being a hardware issue. Well, at least it strongly suggests that it would be good to support 1/1.5/2/3 stop bits for serout.
I'll move on to playing with the other features in "spare" time too. Wifey was upset at yesterday for playing with the DE2 instead of more RoboPi docs/demos...
I'm glad it didn't end up being a hardware problem. Now you can go ahead with playing with the new P2 features! I'm starting to look over the new instruction encodings with an eye to updating GAS. It's going to be a slow process though since I can only work on it on the weekends between boring chores! :-)
Wouldn't this be true of any UART? If it starts sampling in the middle of a continuous stream how would if find a byte boundary?
I agree with David . Also, wouldn't you have to at least clear or flush before you try communicating with the buffer, device etc ?
Well, at least it strongly suggests that it would be good to support 1/1.5/2/3 stop bits for serout
Are 1/1.5/2/3 stop bits for serout" industry standards? If so, couldn't none conforming industry standards end up causing additional problems and confusion?
Are 1/1.5/2/3 stop bits for serout" industry standards? If so, couldn't none conforming industry standards end up causing additional problems and confusion?
Comments
I don't see it attached.
Forgot. Good news - I only need one extra stop bit.
CON _rx = 91 _tx = 90 DAT orgh $380 start org clkset #$FF 'set 80MHz 'setsera ser_parms, bit_time clrp #_tx ' Enable _tx pin mov dirb,leds mov outb,#1 ' if we don't get to another outb, we jumped to never-never land jmp #hubexec ser_parms long %10 << 16 + _rx << 9 + %10 << 7 + _tx bit_time long 80_000_000 / 115200 ch long 0 leds long $FFF y long 0 x long 0 w long 0 count long 0 '---------------------------------------------------------------- orgh hubexec locptra #hello_world ' orgh, F10 download works $38A mov outb,##hubexec ' $38B/C ' mov outb,##hello_world ' getptra outb ' nop loop rdbyte ch, ptra++ wz ' $38D mov x,ch if_nz call #tx ' $38E ' if_nz serouta ch ' $38E if_nz jmp #loop ' $38F jmp @hubexec ' $390 hello_world byte "Hello World!",13,10,0 ' $391 bub serouta #64 jmp #bub tx shl x,#1 ' insert start bit setb x,#9 ' set stop bit mov count,#10 getcnt w ' get initial time :loop add w,bit_time ' add bit period to time shr x,#1 wc setpc #_tx ' write c to tx pin 'passcnt w waitcnt w,#0 ' loop until bit period elapsed jnz x,@:loop ' loop until 10 bits done add w,bit_time ' add bit period to time waitcnt w,#0 ' loop until bit period elapsed retWhat I found weird was my initial test of your code worked every time(repeated F11's ~ 20 times).
Then I went back to the previous FPGA release and it failed.
When I restored the DE2 back to the latest FPGA release it then failed.
I must have been lucky with the PropPlug the first time round.
Its all good now, except for my LOCLONG issue.
Brian
Ok, thanks!, I just wanted to see if I could follow what you are doing,
So far so good. LOL
Yep, the non-deterministic nature of the issue was driving me nuts.
When the bit-banged code, several versions, had the same issue is when I realized the problem might be due to back-to-back bytes without a sufficient gap for some (ftdi) chips.
Looks like the serial ports need 1/1.5/2/3 stop bit configurability...
David,
Welcome back!
Bob,
It seemed like an appropriate first test
You are fashionably late. I just ordered my DE2-115 and add-on board this morning.
I'm hoping you guys will post all the code you don't think is worth posting.
I'm particularly interested in simple hub exec models. Stripped down versions of do nothing code:)
Rich
Bit-banging with two stop bits resolved the issue, I'll try 1.5 stop bits now
Edit: 1.5 stop bits also works - gives enough breating room to my PropPlug!
We can do experiments with different plugs & bit rates to characterize the issue, but I thin the best solution is to ask Chip to allow a choice of 1/2/3/4 or 1/1.5/2/3 stop bits.
OK, I understand. It is such a wonderful feature (SERA/SERB) and space saver the added flexibility of configurable stop bits would make even that much better.
If the requested full length control is implemented, this comes as part of that.
- want 4 stop bits ? ask for an 11 bit Async Field, and send the last 3 bits always = Stop Value
Also, with granular baud settings, you can adjust the Baud rate deliberately to give what becomes fractional stop bits.
What baud rates and data-grouping are you using to see stop bit issues ?
Expanding stop bits can make systems more tolerant of Baud skew, and baud skew can be more subtle than the usual 8-bit-sampling maths.
I recently had a Ceramic resonator fail on a Serial link, when it was well within the classic baud char tolerance.
Turns out the problem was not per-byte, but with sending larger packets with no pauses.
If you do that, a 1% baud skew can give an additional char over 100, and 0.5% baud skew can give an additional char over 200
Even with a FIFO on receive, the slower pacing on echo was not able to 'keep up'.
Try your system with 1 Stop bit, but fractions of +-1% as baud-skews.
I just tried 1%, 0.5%, 0.25% and 0.125% stretched bit cells, which should effectively have made the stop bit longer.
No joy.
There is no point in trying going the other way (shrinking the bit cells) as then the FTDI chip would be even more likely to miss the stop/start bit transition.
How many streamed bytes does it take for this to appear ?
Can you give some more details on Baud rates / test setup ?
Did you scope things to confirm exact baud value, and edge alignments ?
Can You test
Nextchar:
SEROUTA x
WAIT x ---- (2 - 9) will give extra stop time between Char's
JMP nextchar
If a delay is allowed to open PST for example before transmission starts all works Ok. This I have tested to 1M baud.
Don't know, I was streaming full blast. Frankly, I am not interested in how many bytes it takes, the FTDI chip should be able to take it full blast.
I posted the test code earlier in this thread, the earliest version exhibited the problem the most.
Not yet, for the weekend I moved my DE2-115 to the living room, it is going back to the lab Monday morning - then I can scope it.
FYI,
Brian's note about the delay makes perfect sense... more below in my response to him.
I am not sure that will work, as I understand it, serouta starts transmitting as soon as it gets the byte, so it would overlap with the WAITx
I think you have hit it on the head, and based on your findings, I now think that the precise nature of the problem is the uart within the FTDI chip not being able to lock on to the start bit when the data stream is back to back, with no inter-character gap.
It would lock on to the first low bit it gets, thinking that it is a start bit, get eight bits, then not find a stop bit, rinse and repeat. Eventually it would get an offset bit stream that "looks" ok to it, and return garbage characters.
Using the bit-banged output, I was able to determine that adding half a stop bit is enough for the FTDI uart to synchronize properly. I'll probably try 1/4 bit time today, even though 1.25 stop bits is not standard.
The good news is that the problem was NOT with the P2!
And the investigation verified a number of instructions.
It seems that in the end the FTDI chip can handle "back to back" data as long as you give it
some "breathing space" before you start things going.
At least we know what it is npw
Cheers
Brian
And we have two solutions:
- don't start blasting data at an FTDI chip mid-stream (wait a bit, like you found)
- make stop bits be 1.5 bit periods if you want an FTDI chip to read fire-hosed data
This also suggests that if I wait to receive a byte before hosing data (with just one stop bit) it should work. Will try that.
I am also beginning to suspect that pretty much any uart would have trouble being connected to back to back one stop bit stream data stream ... mid stream ... without 1.5 stop bits.
What a pain. New fpga image, new PNut, I did not think to look at the PropPlug for why I was getting garbage... until I eliminated everything else. The LED's helped a lot
I think I'll expand my P2 test rig by permanently mounting one of my logic analyzers on it. I think there is even enough room on the current styrene board for it!
I like that idea! I could use it to watch the trace output!
And you posted that while I was typing my long winded reply, where I also realized that.
Sadly, due to the image being new, and new PNut version, I was looking in the wrong place for the issue.
I was afraid of it being a hardware issue. Well, at least it strongly suggests that it would be good to support 1/1.5/2/3 stop bits for serout.
I'll move on to playing with the other features in "spare" time too. Wifey was upset at yesterday for playing with the DE2 instead of more RoboPi docs/demos...
0.25 stop bits is enough for the "fire hose" test
0.125 stop bits is NOT enough, and we get unsynchronized reception by the FTDI again.
Perhaps the configurable stop bits for serout should be 1/1.25/1.5/2 ?
I agree with David . Also, wouldn't you have to at least clear or flush before you try communicating with the buffer, device etc ?
Are 1/1.5/2/3 stop bits for serout" industry standards? If so, couldn't none conforming industry standards end up causing additional problems and confusion?
Values in bold are standard.