Follow-up: My original screenshot looks sharper than it appears in the browser, but I found my browser's zoom was 110% (aging eyes). Back at 100%, my screenshot is crisp and yours is not so blurry, but is bolder, and still the apparent kerning issue. Note the difference in the font style too.
I certainly have Consolas installed and it does look like Consolas, so that seems to not be it.
The text rendering settings on my machine are non-default, so maybe that's it.... Annoyingly, the only obvious way to change them is some wizard thing that doesn't tell you what you're actually changing. You can see them in the registry under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAYx and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAYx ,where x is the monitor ID. Yes, it's spread over two keys like that.
I've got this on both my displays (actually, DISPLAY2 has gamma set to 2200....)
Also, I must express many thanks for the existence of PASM DEBUG. It just helped me fix a bug that would have taken forever to chase down without. Basically, it was jumping to a garbage address because the data block containing the pointer was garbage because the pointer it was read from was garbage because the table it was read from was read out-of-bounds because the index was garbage because the table it was read from was read out-of-bounds because the index was garbage because a memory copy function was copying in the wrong direction, so it was actually reading uninitialized data as the index. Makes your head spin, right?
Chip,
There is something wrong with the debug_baud command. It is happening on the P2-EVAL as well as my RamBlade2.
Update
It is the DEBUG_BAUD command. I think it may be calculating the baud incorrectly because setting it to 2_000_000 always seems to work, whereas anything else mostly (currently always) fails.
I get a blank debug window. I was using this program below and changing the debug_baud setting between 115_200 * 2 and 115_200 * 4 to see where/why the CP2102 was failing with my RamBlade2 boards. Most times I changed the baud multiplier from 2 to 4 and from 4 to 2 I was getting a blank debug window ie no text. Recompiling and it worked until I next changed and saved the source (using pnut).
I went back to P2_EVAL and the same thing happens.
CON
_clkfreq = 10_000_000
DEBUG_BAUD=115_200 '* 2
PUB go() | i
' waitms(100)
repeat i from 0 to 9
debug(udec(i))
In fact, I now have a hard failure if I use the debug_baud setting at all. So I am saying it has gone into a hard failure with commenting in/out the debug_baud statement in the program below. I repowered the P2-EVAL and re-launched pnut35i, and this is solid now. Works or doesn't depending on the debug_baud command being commented in/out.
CON
_clkfreq = 10_000_000
' DEBUG_BAUD = 115_200
PUB go() | i
repeat i from 0 to 9
debug(udec(i))
Just reconfirmed this again. I'll post this and then reboot my PC and see what happens.
Confirmed. Rebooting the PC makes no difference.
But it is worse as I can no longer get it to work using the DEBUG_BAUD = 115_200 or anything else. I have to comment this out for it to work at all, so must have been a fluke it worked before.
@Cluso99 said:
Chip,
There is something wrong with the debug_baud command. It is happening on the P2-EVAL as well as my RamBlade2.
FYI- just in case you're thinking of trying it... I haven't had time yet to support this feature in Propeller Tool, so I'm curious to see what the source of this problem is.
Confirmed. Rebooting the PC makes no difference.
But it is worse as I can no longer get it to work using the DEBUG_BAUD = 115_200 or anything else. I have to comment this out for it to work at all, so must have been a fluke it worked before.> @cgracey said:
Cluso, are you using the PropellerTool or PNut? Last I checked, it worked in PNut, but I haven't tried it in PropellerTool.
This is all pnut and P2-EVAL. There is something seriously wrong. Could be getting a pointer wrong?
@Cluso99 said:
Confirmed. Rebooting the PC makes no difference.
But it is worse as I can no longer get it to work using the DEBUG_BAUD = 115_200 or anything else. I have to comment this out for it to work at all, so must have been a fluke it worked before.> @cgracey said:
Cluso, are you using the PropellerTool or PNut? Last I checked, it worked in PNut, but I haven't tried it in PropellerTool.
This is all pnut and P2-EVAL. There is something seriously wrong. Could be getting a pointer wrong?
I will look into this in the morning. It was working last I tested it, so something must have gone wrong.
Chip,
You may have to try a few times before it fails solidly. I was putting in a waitms(500) before the repeat loop, and changing the debug_baud = 115_200 * 2 and * 4 and getting intermittent results before it failed solidly. Maybe something isn’t initialised properly?
@Cluso99 said:
Chip,
You may have to try a few times before it fails solidly. I was putting in a waitms(500) before the repeat loop, and changing the debug_baud = 115_200 * 2 and * 4 and getting intermittent results before it failed solidly. Maybe something isn’t initialised properly?
It is working fine for me in PNut.exe, but it doesn't work in PropTool. Jeff didn't know that the baud rate could change. I need to tell him about this.
Chip,
No! It’s definitely a problem in pnut35i.
You just have to try your simple debug_ demo, adding a few lines - I presume this moves the object code around, and then delete the extra stuff, and it fails hard. Comment in/out the single debug_baud setting and it the debug window is blank whenever the setting is active.
procedure OperateDebug;
var
i: integer;
begin
if P2.DebugBaud <> 2000000 then
begin
BuildCommDCB(PChar(IntToStr(P2.DebugBaud) + ',n,8,1'), CommDCB);
CommDCB.Flags := 0; // ADD THIS LINE - THIS SOLVES THE PROBLEM!!!
SetCommState(CommHandle, CommDCB);
end;
DebugActive := True;
DebugBuffHead := 0;
DebugBuffTail := 0;
if RxBuffStart <> RxBuffEnd then
begin
Move(RxBuff[RxBuffStart], DebugBuff[0], RxBuffEnd - RxBuffStart);
DebugBuffHead := RxBuffEnd - RxBuffStart;
end;
DebugForm.ResetDisplays;
while DebugActive do
begin
ReceiveDebugData;
for i := 1 to 100 do
if DebugBuffHead <> DebugBuffTail then
begin
DebugForm.ChrIn(DebugBuff[DebugBuffTail]);
DebugBuffTail := (DebugBuffTail + 1) and DebugBuffMask;
end
else Break;
Application.ProcessMessages;
//Sleep(50);
end;
CloseComm;
end;
@cgracey said:
Add the 8th line. This solves the problem.
How'd you figure that out!?
My code does indeed set the Flags to 0 (which I'd forgotten), but while looking up the flags, I found this statement from Microsoft which would make me think our code wouldn't work:
fBinary
If this member is TRUE, binary mode is enabled. Windows does not support nonbinary mode transfers, so this member must be TRUE.
However, obviously it does and has for years.
Here's another note: At some point in the evolution of Propeller Tool code, I chose not to BuildCommDCB() anymore, and instead, once the port is open, I GetCommState() and then only adjust what needs to be adjusted; in this case, the .BaudRate field would be appropriate... but in my Open routine, I see that I set the .Flags to 0.
FCommHandle := CreateFile(PChar('\\.\' + FComPort), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if FCommHandle = INVALID_HANDLE_VALUE then Error(ord(mtPortUnopened) + (strtoint(FComPort) shl 16)); {Failed to open port}
if not SetupComm(FCommHandle, RxBuffSize, TxBuffSize) then Error(ord(mtPortUnconfigured) + (strtoint(FComPort) shl 16));
FCommDCB.DCBlength := sizeof(TDCB);
if GetCommState(FCommHandle, FCommDCB) then
begin {Got serial port configuration data; adjust for our use}
FCommDCB.BaudRate := BaudRate[FPropModel];
FCommDCB.Parity := NOPARITY;
FCommDCB.ByteSize := 8;
FCommDCB.StopBits := ONESTOPBIT;
FCommDCB.Flags := 0;
end
else {Unable to get serial port configuration data}
Error(ord(mtPortUnusable) + (strtoint(FComPort) shl 16));
SetCommState(FCommHandle, FCommDCB);
@cgracey said:
Add the 8th line. This solves the problem.
How'd you figure that out!?
My code does indeed set the Flags to 0 (which I'd forgotten), but while looking up the flags, I found this statement from Microsoft which would make me think our code wouldn't work:
fBinary
If this member is TRUE, binary mode is enabled. Windows does not support nonbinary mode transfers, so this member must be TRUE.
However, obviously it does and has for years.
Here's another note: At some point in the evolution of Propeller Tool code, I chose not to BuildCommDCB() anymore, and instead, once the port is open, I GetCommState() and then only adjust what needs to be adjusted; in this case, the .BaudRate field would be appropriate... but in my Open routine, I see that I set the .Flags to 0.
FCommHandle := CreateFile(PChar('\\.\' + FComPort), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if FCommHandle = INVALID_HANDLE_VALUE then Error(ord(mtPortUnopened) + (strtoint(FComPort) shl 16)); {Failed to open port}
if not SetupComm(FCommHandle, RxBuffSize, TxBuffSize) then Error(ord(mtPortUnconfigured) + (strtoint(FComPort) shl 16));
FCommDCB.DCBlength := sizeof(TDCB);
if GetCommState(FCommHandle, FCommDCB) then
begin {Got serial port configuration data; adjust for our use}
FCommDCB.BaudRate := BaudRate[FPropModel];
FCommDCB.Parity := NOPARITY;
FCommDCB.ByteSize := 8;
FCommDCB.StopBits := ONESTOPBIT;
FCommDCB.Flags := 0;
end
else {Unable to get serial port configuration data}
Error(ord(mtPortUnusable) + (strtoint(FComPort) shl 16));
SetCommState(FCommHandle, FCommDCB);
I just saw that I was doing it in my OpenComm routine, but not in my baud change routine. I added it and it started working on the P2 Eval board. This is weird... The baud change was working on the PropPlug, but not on the P2 Eval board. The same chip, but different internal EEPROM configuration. This change made it work on both. Not sure why.
@"Jeff Martin" said:
BuildCommDCB() must be doing something different those times (or each time?)... don't know.
Still... may be best to just reuse your existing CommDCB from the Open() and just change the baud rate, then SetCommState() with it.
But there's something about the way we programmed the FT231XS on the P2 Eval vs the PropPlug that cause the PropPlug to work and the P2 Eval to fail on the baud rate change I was initially doing. Mysterious.
I posted a new v35j at the top of this thread which hopefully fixes the DEBUG_BAUD problems, where things go dead on some boards when using baud rates other than 2M:
@cgracey said:
I posted a new v35j at the top of this thread which hopefully fixes the DEBUG_BAUD problems, where things go dead on some boards when using baud rates other than 2M:
Thanks Chip.
Yes, it now works with P2-EVAL.
With the CP2102 & RamBlade2 I saw some inconsistencies early on in testing but seems to be OK now. It could be some mix of what I've found below.
CP2102
Using DEBUG_demo.spin2 that comes with pnut35j and adding the CON DEBUG_BAUD = xxx results are as follows
CON
_clkfreq = 10_000_000
' DEBUG_BAUD = 115_200 'CP2102 OK
' DEBUG_BAUD = 230_400 'CP2102 OK
' DEBUG_BAUD = 460_800 'CP2102 OK
DEBUG_BAUD = 921_600 'CP2102 OK
' DEBUG_BAUD = 1_000_000 'CP2102 drops chars
' DEBUG_BAUD = 1_152_000 ' 115_200 *10 'CP2102 data corruption
' DEBUG_BAUD = 1_200_000 'CP2102 data corruption
' DEBUG_BAUD = 1_500_000 'CP2102 data corruption
' DEBUG_BAUD = 1_843_200 ' 921_600 *2 'CP2102 data corruption
' DEBUG_BAUD = 2_000_000 'CP2102 blanks screen
PUB go() | i
repeat i from 0 to 9
debug(udec(i))
So, from this info, 921_600 is the max baud when using debug. I've said previously I do use loadp2 at 2_000_000 baud without problems (or so I have thought).
I am going to revert to using loadp2 at 921_600 baud.
Chip, you said on zoom today that you setup the serial debug initially at 2_000_000 baud. From what I found here, this could be a potential problem for anyone using a CP2102.
@Cluso99 said:
CP2102
Using DEBUG_demo.spin2 that comes with pnut35j and adding the CON DEBUG_BAUD = xxx results are as follows
```
CON
_clkfreq = 10_000_000
' DEBUG_BAUD = 115_200 'CP2102 OK
' DEBUG_BAUD = 230_400 'CP2102 OK
' DEBUG_BAUD = 460_800 'CP2102 OK
DEBUG_BAUD = 921_600 'CP2102 OK
' DEBUG_BAUD = 1_000_000 'CP2102 drops chars
' DEBUG_BAUD = 1_152_000 ' 115_200 *10 'CP2102 data corruption
' DEBUG_BAUD = 1_200_000 'CP2102 data corruption
' DEBUG_BAUD = 1_500_000 'CP2102 data corruption
' DEBUG_BAUD = 1_843_200 ' 921_600 *2 'CP2102 data corruption
' DEBUG_BAUD = 2_000_000 'CP2102 blanks screen
It may be that the 2-way traffic is more of a load on DEBUG, than it is on Download. Duplex or echo is certainly tougher on these parts than largely one way flows.
The newer CP2102N is certainly faster than CP2102
Do you have a CP2102N you can repeat the trial ? and maybe a P2D2, as the UB3 on that should be similar/faster? than CP2102N ?
There are new bridge parts coming out of Asia, like CH343, and PL2303Gx, that claim higher baud speeds, I'm trying to find some modules using those new parts.
@cgracey said:
I posted a new v35j at the top of this thread which hopefully fixes the DEBUG_BAUD problems, where things go dead on some boards when using baud rates other than 2M:
You could experiment with different STOP bit settings, at higher baud speeds ?
eg I know the EFM8UB3 on P2D2 needs 2 stop bits at 6Mbd and 8MBd settings, and those are pretty much half-duplex / burst capable, as the sustained average is in the 4MBd ballpark.
It would also be worth testing DEBUG with a FT232H or FT2232H serial link, up to 12MBd. The FT2232H is popular on many FPGA and CPLD boards.
@cgracey said:
Sounds like we need to be able to set the download baud, too.
Wait... are you saying that you can download at the 2 Mbaud speed, but DEBUG has all these baud-related issues?
Yes. I’m not sure what debug actually does regarding serial traffic. However, it seems like the CP2102 can handle data from the pc fine at 2Mbaud, but only 921_600 baud to the pc. At 1Mbaud it drops characters.
For what it's worth I ran a CP2102 through some tests today. Using a Win10 machine with usb 3.0 ports, an ocsiliscope , a dongle with an FTDI 232r (capable for 2M baud) and PST as the serial terminal, I maxed out the CP2102 at 921600 (one of PST's presets) on TX and RX speeds. TX'ing at speeds above that shows no change in the actual baud rate of 921600 on the output. RX'ing above 921600, it shows garbage on the terminal.
@mojorizing said:
For what it's worth I ran a CP2102 through some tests today. Using a Win10 machine with usb 3.0 ports, an ocsiliscope , a dongle with an FTDI 232r (capable for 2M baud) and PST as the serial terminal, I maxed out the CP2102 at 921600 (one of PST's presets) on TX and RX speeds. TX'ing at speeds above that shows no change in the actual baud rate of 921600 on the output. RX'ing above 921600, it shows garbage on the terminal.
Interesting.
The TX at speeds above 921600 test shows no change in actual speed doesn't make sense. When I do any comms and I set the rate to 2000000 baud, that is the speed we set the P2 UART to. This works for slow data because loadp2 can use the command line prompt from W10 and this definately works. I can enter data (as well as the download) just fine, and I can write out replies to the PC window/screen fine too. This makes me think that 2000000 works for small data packets, but not large data where overrun occurs and ultimate corruption.
When I tried the 921600 vs 1000000 it dropped some of the space characters. I wondered if this was a baud mismatch or an overrun at 1000000. Everything I tried above this causes corrupted characters (nothing recognisable).
However, downloading seems to work fine at 2000000. But it's possible the PC is slowing down the data due to software or OS (ie W10) overhead.
I have a real FT232RL in PropPlug format (and a number of real FT232RL chips and probably more pcbs if I could find them). For a back to back test a PC is needed in between, and that hides problems because the PC is not always responsive.
Chip,
FWIW the very first time I run the simple code (with DEBUG_Baud = 921_600 enabled) the debug screen is blank. Just a Ctl-F10 recompile/download works. SO the first time seems to fail.
If you read the previous post - I tried the debug with a waitms(50) in the repeat loop to try and slow the data down, but I still get corruption.
At 1_000_000 and outputting just a sole "a" with debug every 500ms results in line(s) of corrupted characters for each single "a". So you must be sending lots of extra overhead for this single character because I believe this is overruning the CP2102 buffer. Is there a simple way you can delay the overhead characters down to test this theory?
Comments
Follow-up: My original screenshot looks sharper than it appears in the browser, but I found my browser's zoom was 110% (aging eyes). Back at 100%, my screenshot is crisp and yours is not so blurry, but is bolder, and still the apparent kerning issue. Note the difference in the font style too.
I certainly have Consolas installed and it does look like Consolas, so that seems to not be it.
The text rendering settings on my machine are non-default, so maybe that's it.... Annoyingly, the only obvious way to change them is some wizard thing that doesn't tell you what you're actually changing. You can see them in the registry under
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAYxandHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Avalon.Graphics\DISPLAYx,where x is the monitor ID. Yes, it's spread over two keys like that.I've got this on both my displays (actually, DISPLAY2 has gamma set to 2200....)
Also, I must express many thanks for the existence of PASM DEBUG. It just helped me fix a bug that would have taken forever to chase down without. Basically, it was jumping to a garbage address because the data block containing the pointer was garbage because the pointer it was read from was garbage because the table it was read from was read out-of-bounds because the index was garbage because the table it was read from was read out-of-bounds because the index was garbage because a memory copy function was copying in the wrong direction, so it was actually reading uninitialized data as the index. Makes your head spin, right?
Indeed. Yes, I'm excited about PASM DEBUG but I haven't the luxury to use it for real yet. ;-P So, I "second" that thanks!
I see. Maybe that is it.
Is anyone else here seeing kerning issues in their Debug Terminal display?
Chip,
Your writeup and/or debug_demo.spin2 needs an example of using your Symbols to modify debug behaviour.
Chip,
There is something wrong with the debug_baud command. It is happening on the P2-EVAL as well as my RamBlade2.
Update
It is the DEBUG_BAUD command. I think it may be calculating the baud incorrectly because setting it to 2_000_000 always seems to work, whereas anything else mostly (currently always) fails.
I get a blank debug window. I was using this program below and changing the debug_baud setting between 115_200 * 2 and 115_200 * 4 to see where/why the CP2102 was failing with my RamBlade2 boards. Most times I changed the baud multiplier from 2 to 4 and from 4 to 2 I was getting a blank debug window ie no text. Recompiling and it worked until I next changed and saved the source (using pnut).
I went back to P2_EVAL and the same thing happens.
CON _clkfreq = 10_000_000 DEBUG_BAUD=115_200 '* 2 PUB go() | i ' waitms(100) repeat i from 0 to 9 debug(udec(i))In fact, I now have a hard failure if I use the debug_baud setting at all. So I am saying it has gone into a hard failure with commenting in/out the debug_baud statement in the program below. I repowered the P2-EVAL and re-launched pnut35i, and this is solid now. Works or doesn't depending on the debug_baud command being commented in/out.
CON _clkfreq = 10_000_000 ' DEBUG_BAUD = 115_200 PUB go() | i repeat i from 0 to 9 debug(udec(i))Just reconfirmed this again. I'll post this and then reboot my PC and see what happens.
Confirmed. Rebooting the PC makes no difference.
But it is worse as I can no longer get it to work using the DEBUG_BAUD = 115_200 or anything else. I have to comment this out for it to work at all, so must have been a fluke it worked before.
FYI- just in case you're thinking of trying it... I haven't had time yet to support this feature in Propeller Tool, so I'm curious to see what the source of this problem is.
Cluso, are you using the PropellerTool or PNut? Last I checked, it worked in PNut, but I haven't tried it in PropellerTool.
Confirmed. Rebooting the PC makes no difference.
But it is worse as I can no longer get it to work using the DEBUG_BAUD = 115_200 or anything else. I have to comment this out for it to work at all, so must have been a fluke it worked before.> @cgracey said:
This is all pnut and P2-EVAL. There is something seriously wrong. Could be getting a pointer wrong?
I will look into this in the morning. It was working last I tested it, so something must have gone wrong.
Chip,
You may have to try a few times before it fails solidly. I was putting in a waitms(500) before the repeat loop, and changing the debug_baud = 115_200 * 2 and * 4 and getting intermittent results before it failed solidly. Maybe something isn’t initialised properly?
It is working fine for me in PNut.exe, but it doesn't work in PropTool. Jeff didn't know that the baud rate could change. I need to tell him about this.
Chip,
No! It’s definitely a problem in pnut35i.
You just have to try your simple debug_ demo, adding a few lines - I presume this moves the object code around, and then delete the extra stuff, and it fails hard. Comment in/out the single debug_baud setting and it the debug window is blank whenever the setting is active.
I saw your changes for this but it was right before that day's release of the PT at the time and I needed to triage this change. It's on my list to do. https://github.com/parallaxinc/Propeller-Tool/issues/127
procedure OperateDebug; var i: integer; begin if P2.DebugBaud <> 2000000 then begin BuildCommDCB(PChar(IntToStr(P2.DebugBaud) + ',n,8,1'), CommDCB); CommDCB.Flags := 0; // ADD THIS LINE - THIS SOLVES THE PROBLEM!!! SetCommState(CommHandle, CommDCB); end; DebugActive := True; DebugBuffHead := 0; DebugBuffTail := 0; if RxBuffStart <> RxBuffEnd then begin Move(RxBuff[RxBuffStart], DebugBuff[0], RxBuffEnd - RxBuffStart); DebugBuffHead := RxBuffEnd - RxBuffStart; end; DebugForm.ResetDisplays; while DebugActive do begin ReceiveDebugData; for i := 1 to 100 do if DebugBuffHead <> DebugBuffTail then begin DebugForm.ChrIn(DebugBuff[DebugBuffTail]); DebugBuffTail := (DebugBuffTail + 1) and DebugBuffMask; end else Break; Application.ProcessMessages; //Sleep(50); end; CloseComm; end;Add the 8th line. This solves the problem.
How'd you figure that out!?
My code does indeed set the Flags to 0 (which I'd forgotten), but while looking up the flags, I found this statement from Microsoft which would make me think our code wouldn't work:
However, obviously it does and has for years.
Here's another note: At some point in the evolution of Propeller Tool code, I chose not to BuildCommDCB() anymore, and instead, once the port is open, I GetCommState() and then only adjust what needs to be adjusted; in this case, the .BaudRate field would be appropriate... but in my Open routine, I see that I set the .Flags to 0.
FCommHandle := CreateFile(PChar('\\.\' + FComPort), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); if FCommHandle = INVALID_HANDLE_VALUE then Error(ord(mtPortUnopened) + (strtoint(FComPort) shl 16)); {Failed to open port} if not SetupComm(FCommHandle, RxBuffSize, TxBuffSize) then Error(ord(mtPortUnconfigured) + (strtoint(FComPort) shl 16)); FCommDCB.DCBlength := sizeof(TDCB); if GetCommState(FCommHandle, FCommDCB) then begin {Got serial port configuration data; adjust for our use} FCommDCB.BaudRate := BaudRate[FPropModel]; FCommDCB.Parity := NOPARITY; FCommDCB.ByteSize := 8; FCommDCB.StopBits := ONESTOPBIT; FCommDCB.Flags := 0; end else {Unable to get serial port configuration data} Error(ord(mtPortUnusable) + (strtoint(FComPort) shl 16)); SetCommState(FCommHandle, FCommDCB);I just saw that I was doing it in my OpenComm routine, but not in my baud change routine. I added it and it started working on the P2 Eval board. This is weird... The baud change was working on the PropPlug, but not on the P2 Eval board. The same chip, but different internal EEPROM configuration. This change made it work on both. Not sure why.
BuildCommDCB() must be doing something different those times (or each time?)... don't know.
Still... may be best to just reuse your existing CommDCB from the Open() and just change the baud rate, then SetCommState() with it.
But there's something about the way we programmed the FT231XS on the P2 Eval vs the PropPlug that cause the PropPlug to work and the P2 Eval to fail on the baud rate change I was initially doing. Mysterious.
@VonSzarvas does the P2 Eval and the PropPlug use the same FTDI chip type? Were they programmed differently in Manufacturing?
I posted a new v35j at the top of this thread which hopefully fixes the DEBUG_BAUD problems, where things go dead on some boards when using baud rates other than 2M:
Thanks Chip.
Yes, it now works with P2-EVAL.
With the CP2102 & RamBlade2 I saw some inconsistencies early on in testing but seems to be OK now. It could be some mix of what I've found below.
CP2102
Using DEBUG_demo.spin2 that comes with pnut35j and adding the CON DEBUG_BAUD = xxx results are as follows
CON _clkfreq = 10_000_000 ' DEBUG_BAUD = 115_200 'CP2102 OK ' DEBUG_BAUD = 230_400 'CP2102 OK ' DEBUG_BAUD = 460_800 'CP2102 OK DEBUG_BAUD = 921_600 'CP2102 OK ' DEBUG_BAUD = 1_000_000 'CP2102 drops chars ' DEBUG_BAUD = 1_152_000 ' 115_200 *10 'CP2102 data corruption ' DEBUG_BAUD = 1_200_000 'CP2102 data corruption ' DEBUG_BAUD = 1_500_000 'CP2102 data corruption ' DEBUG_BAUD = 1_843_200 ' 921_600 *2 'CP2102 data corruption ' DEBUG_BAUD = 2_000_000 'CP2102 blanks screen PUB go() | i repeat i from 0 to 9 debug(udec(i))So, from this info, 921_600 is the max baud when using debug. I've said previously I do use loadp2 at 2_000_000 baud without problems (or so I have thought).
I am going to revert to using loadp2 at 921_600 baud.
Chip, you said on zoom today that you setup the serial debug initially at 2_000_000 baud. From what I found here, this could be a potential problem for anyone using a CP2102.
It may be that the 2-way traffic is more of a load on DEBUG, than it is on Download. Duplex or echo is certainly tougher on these parts than largely one way flows.
The newer CP2102N is certainly faster than CP2102
Do you have a CP2102N you can repeat the trial ? and maybe a P2D2, as the UB3 on that should be similar/faster? than CP2102N ?
There are new bridge parts coming out of Asia, like CH343, and PL2303Gx, that claim higher baud speeds, I'm trying to find some modules using those new parts.
You could experiment with different STOP bit settings, at higher baud speeds ?
eg I know the EFM8UB3 on P2D2 needs 2 stop bits at 6Mbd and 8MBd settings, and those are pretty much half-duplex / burst capable, as the sustained average is in the 4MBd ballpark.
It would also be worth testing DEBUG with a FT232H or FT2232H serial link, up to 12MBd. The FT2232H is popular on many FPGA and CPLD boards.
Sounds like we need to be able to set the download baud, too.
Wait... are you saying that you can download at the 2 Mbaud speed, but DEBUG has all these baud-related issues?
Yes. I’m not sure what debug actually does regarding serial traffic. However, it seems like the CP2102 can handle data from the pc fine at 2Mbaud, but only 921_600 baud to the pc. At 1Mbaud it drops characters.
For what it's worth I ran a CP2102 through some tests today. Using a Win10 machine with usb 3.0 ports, an ocsiliscope , a dongle with an FTDI 232r (capable for 2M baud) and PST as the serial terminal, I maxed out the CP2102 at 921600 (one of PST's presets) on TX and RX speeds. TX'ing at speeds above that shows no change in the actual baud rate of 921600 on the output. RX'ing above 921600, it shows garbage on the terminal.
Interesting.
The TX at speeds above 921600 test shows no change in actual speed doesn't make sense. When I do any comms and I set the rate to 2000000 baud, that is the speed we set the P2 UART to. This works for slow data because loadp2 can use the command line prompt from W10 and this definately works. I can enter data (as well as the download) just fine, and I can write out replies to the PC window/screen fine too. This makes me think that 2000000 works for small data packets, but not large data where overrun occurs and ultimate corruption.
When I tried the 921600 vs 1000000 it dropped some of the space characters. I wondered if this was a baud mismatch or an overrun at 1000000. Everything I tried above this causes corrupted characters (nothing recognisable).
However, downloading seems to work fine at 2000000. But it's possible the PC is slowing down the data due to software or OS (ie W10) overhead.
I have a real FT232RL in PropPlug format (and a number of real FT232RL chips and probably more pcbs if I could find them). For a back to back test a PC is needed in between, and that hides problems because the PC is not always responsive.
Chip,
FWIW the very first time I run the simple code (with DEBUG_Baud = 921_600 enabled) the debug screen is blank. Just a Ctl-F10 recompile/download works. SO the first time seems to fail.
If you read the previous post - I tried the debug with a waitms(50) in the repeat loop to try and slow the data down, but I still get corruption.
At 1_000_000 and outputting just a sole "a" with debug every 500ms results in line(s) of corrupted characters for each single "a". So you must be sending lots of extra overhead for this single character because I believe this is overruning the CP2102 buffer. Is there a simple way you can delay the overhead characters down to test this theory?