Shop Learn
PNut/Spin2 Latest Version (v35n - PLOT Sprites and REPEAT-var post-fix) - Page 41 — Parallax Forums

PNut/Spin2 Latest Version (v35n - PLOT Sprites and REPEAT-var post-fix)

13839414344

Comments

  • Cluso99Cluso99 Posts: 17,761

    Chip,
    As confirmation, FT232RL works with my RamBlade2 board at 2_000_000 baud.
    I have a slight problem as I tested with a double transistor reset circuit as both my FT232 board and my RetroBlade2 both have the transistor circuit enabled so I have to repower before each test.
    It's proof the CP2102 cannot go to 2_000_000 baud consistently, though the FT232RL can.

  • cgraceycgracey Posts: 13,610

    @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.

    Thanks, Mojorising.

    Parallax never used this chip, as far as I know. We've used only FTDI.

    So, how is this CP2102 entering the picture here? And is it getting past the 2 Mbaud download?

    Does Cluso's board use a CP2102?

    Sorry if I'm behind here.

  • cgraceycgracey Posts: 13,610

    @Cluso99 said:
    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?

    Cluso, the DEBUG output that appears in the black window with green text is verbatim what is sent. There are no extra characters in the transmission. I have no explanation for what you are seeing.

  • jmgjmg Posts: 14,676
    edited 2021-03-18 05:28

    @cgracey said:
    Parallax never used this chip, as far as I know. We've used only FTDI.
    So, how is this CP2102 entering the picture here? And is it getting past the 2 Mbaud download?
    Does Cluso's board use a CP2102?
    Sorry if I'm behind here.

    CP2102 is popular on the cheap modules from Asia.
    To complicate things, there is a newer, faster, CP2102N, and SiLabs recently fiddled with their drivers to change what settings were possible.
    I asked them to increase the limits on VCP drivers, for EFM8UB3 and they seem to have done that.

    SiLabs driver : 10.1.8.2466 - limited baud to 1Mbd for other than CP2102N
    then
    Release notes for 10.1.10 (2021-01-13) actually 10.1.10.103
    Changes for VCP Driver
    MCUSW-651 | Support baud rate up to 2187500 for CP2102, CP2104, CP2109

    Ie they decreased, then increased again, looks like 2187500 is now the CP2102 SW driver imposed top in Q1 2021 driver (CP2102N is higher)

    So what is possible, depends on both the chip, and which exact version of SiLabs driver is installed.

    The web has this info for an older CP2102 + older driver (when baud settings of 3MBd were allowed on old parts, but you see the sustained averages were lower > 1.5MBd)
    _ ` 1495820 bits per second (49.9 % of 3000000 bps)
    149582 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    7010 milliseconds elapsed time

    1495610 bits per second (74.8 % of 2000000 bps)
    149561 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    7011 milliseconds elapsed time

    1495180 bits per second (99.7 % of 1500000 bps)
    149518 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    7013 milliseconds elapsed time

    918590 bits per second (91.9 % of 1000000 bps)
    91859 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    11415 milliseconds elapsed time

    918510 bits per second (122.5 % of 750000 bps)
    91851 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    11416 milliseconds elapsed time

    497450 bits per second (99.5 % of 500000 bps)
    49745 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    21079 milliseconds elapsed time

    248920 bits per second (99.6 % of 250000 bps)
    24892 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    42125 milliseconds elapsed time

    229880 bits per second (99.8 % of 230400 bps)
    22988 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    45613 milliseconds elapsed time

    114990 bits per second (99.8 % of 115200 bps)
    11499 bytes per second
    1048576 total written
    1048576 total read (100 %)
    0 total error bytes
    91187 milliseconds elapsed time`_

  • cgraceycgracey Posts: 13,610

    Thanks, Jmg.

    What kind of modules do these come on, from China? Things like PropPlugs?

  • jmgjmg Posts: 14,676

    @cgracey said:
    What kind of modules do these come on, from China? Things like PropPlugs?

    yes. small PCBs with a header and USB, often the older USB-A

  • Cluso99Cluso99 Posts: 17,761
    edited 2021-03-18 05:45

    Chip,
    Here is a pic of the CP2102 board.
    https://forums.parallax.com/discussion/172556/clusos-retroblade2-your-board-s-have-arrived-so-what-to-do-next/p1
    It is available on eBay for around US$1.50 shipped. There is a newer one with micro-USB but it is not pin compatible, tho it still uses the CP2102 and not the CP2102N part. There are other cheap USB-Serial modules too based on other chips like the CH340 etc. They don't all bring out DTR.
    So yes, it is effectively a PropPlug replacement, but without the transistor reset circuit, but with the bonus that it can supply 5V from the PC's USB port if that is sufficient for the prop board.
    There are FT232 based ones too, but you have to be careful of counterfeits so I don't recommend using them.

    I have been using these for many years with the P1 so it was an obvious choice for my P2 board. The pinout matches these so that they plug straight into my RetroBlade2 which also powers it from the USB too. That is why I have the transistor reset circuit on the RetroBlade2 (and my P1 boards) as a solder-linkable option.

    Unfortunately when I sent the RetroBlade2 boards to Ken and yourself I didn't have any spare CP2102 boards or I would have sent them too. I'll send you a couple but it will take a couple of weeks.

  • cgraceycgracey Posts: 13,610

    @Cluso99 said:
    Chip,
    Here is a pic of the CP2102 board.
    https://forums.parallax.com/discussion/172556/clusos-retroblade2-your-board-s-have-arrived-so-what-to-do-next/p1
    It is available on eBay for around US$1.50 shipped. There is a newer one with micro-USB but it is not pin compatible, tho it still uses the CP2102 and not the CP2102N part. There are other cheap USB-Serial modules too based on other chips like the CH340 etc. They don't all bring out DTR.
    So yes, it is effectively a PropPlug replacement, but without the transistor reset circuit, but with the bonus that it can supply 5V from the PC's USB port if that is sufficient for the prop board.
    There are FT232 based ones too, but you have to be careful of counterfeits so I don't recommend using them.

    I have been using these for many years with the P1 so it was an obvious choice for my P2 board. The pinout matches these so that they plug straight into my RetroBlade2 which also powers it from the USB too. That is why I have the transistor reset circuit on the RetroBlade2 (and my P1 boards) as a solder-linkable option.

    Unfortunately when I sent the RetroBlade2 boards to Ken and yourself I didn't have any spare CP2102 boards or I would have sent them too. I'll send you a couple but it will take a couple of weeks.

    No problem. If I look for a symbol called DOWNLOAD_BAUD, I can use that for downloading. Would that be helpful?

  • Cluso99Cluso99 Posts: 17,761
    edited 2021-03-18 07:07

    @cgracey said:

    @Cluso99 said:
    Chip,
    Here is a pic of the CP2102 board.
    https://forums.parallax.com/discussion/172556/clusos-retroblade2-your-board-s-have-arrived-so-what-to-do-next/p1
    It is available on eBay for around US$1.50 shipped. There is a newer one with micro-USB but it is not pin compatible, tho it still uses the CP2102 and not the CP2102N part. There are other cheap USB-Serial modules too based on other chips like the CH340 etc. They don't all bring out DTR.
    So yes, it is effectively a PropPlug replacement, but without the transistor reset circuit, but with the bonus that it can supply 5V from the PC's USB port if that is sufficient for the prop board.
    There are FT232 based ones too, but you have to be careful of counterfeits so I don't recommend using them.

    I have been using these for many years with the P1 so it was an obvious choice for my P2 board. The pinout matches these so that they plug straight into my RetroBlade2 which also powers it from the USB too. That is why I have the transistor reset circuit on the RetroBlade2 (and my P1 boards) as a solder-linkable option.

    Unfortunately when I sent the RetroBlade2 boards to Ken and yourself I didn't have any spare CP2102 boards or I would have sent them too. I'll send you a couple but it will take a couple of weeks.

    No problem. If I look for a symbol called DOWNLOAD_BAUD, I can use that for downloading. Would that be helpful?

    While I'm not having problems using the faster 2Mbaud for the initialisation, or even download, I think that option might prove beneficial. I'm going to rollback my download speed just to be safe.

    Did you see this...
    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.

    And while we're on this, pnut still fails if I have an SD card in the slot without the boot file. Note I'm using the transistor reset so I'm resetting when DTR goes inactive. I need to try this with the transistor circuit bypassed.

  • cgraceycgracey Posts: 13,610

    @Cluso99 said:

    @cgracey said:

    @Cluso99 said:
    Chip,
    Here is a pic of the CP2102 board.
    https://forums.parallax.com/discussion/172556/clusos-retroblade2-your-board-s-have-arrived-so-what-to-do-next/p1
    It is available on eBay for around US$1.50 shipped. There is a newer one with micro-USB but it is not pin compatible, tho it still uses the CP2102 and not the CP2102N part. There are other cheap USB-Serial modules too based on other chips like the CH340 etc. They don't all bring out DTR.
    So yes, it is effectively a PropPlug replacement, but without the transistor reset circuit, but with the bonus that it can supply 5V from the PC's USB port if that is sufficient for the prop board.
    There are FT232 based ones too, but you have to be careful of counterfeits so I don't recommend using them.

    I have been using these for many years with the P1 so it was an obvious choice for my P2 board. The pinout matches these so that they plug straight into my RetroBlade2 which also powers it from the USB too. That is why I have the transistor reset circuit on the RetroBlade2 (and my P1 boards) as a solder-linkable option.

    Unfortunately when I sent the RetroBlade2 boards to Ken and yourself I didn't have any spare CP2102 boards or I would have sent them too. I'll send you a couple but it will take a couple of weeks.

    No problem. If I look for a symbol called DOWNLOAD_BAUD, I can use that for downloading. Would that be helpful?

    While I'm not having problems using the faster 2Mbaud for the initialisation, or even download, I think that option might prove beneficial. I'm going to rollback my download speed just to be safe.

    Did you see this...
    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.

    Yes, there must be some initialization problem in my code when talking to a CP2102. I will order one of these cheap boards. I will need one to figure this out.

  • jmgjmg Posts: 14,676
    edited 2021-03-18 08:57

    @cgracey said:
    Yes, there must be some initialization problem in my code when talking to a CP2102. I will order one of these cheap boards. I will need one to figure this out.

    You might want to also grab a CP2102N-MINIEK from Digikey or Mouser, (~$8) and a 2264 adafruit (~$15) would get you a 12MBd UART test capability too.
    Also check you have latest driver : CP210x Universal Windows Driver v10.1.10 1/14/2021

  • cgraceycgracey Posts: 13,610

    @jmg said:

    @cgracey said:
    Yes, there must be some initialization problem in my code when talking to a CP2102. I will order one of these cheap boards. I will need one to figure this out.

    You might want to also grab a CP2102N-MINIEK from Digikey or Mouser, (~$8) and a 2264 adafruit (~$15) would get you a 12MBd UART test capability too.
    Also check you have latest driver : CP210x Universal Windows Driver v10.1.10 1/14/2021

    Will do. Thanks, Jmg.

  • Cluso99Cluso99 Posts: 17,761

    @cgracey said:

    @Cluso99 said:

    @cgracey said:

    @Cluso99 said:
    Chip,
    Here is a pic of the CP2102 board.
    https://forums.parallax.com/discussion/172556/clusos-retroblade2-your-board-s-have-arrived-so-what-to-do-next/p1
    It is available on eBay for around US$1.50 shipped. There is a newer one with micro-USB but it is not pin compatible, tho it still uses the CP2102 and not the CP2102N part. There are other cheap USB-Serial modules too based on other chips like the CH340 etc. They don't all bring out DTR.
    So yes, it is effectively a PropPlug replacement, but without the transistor reset circuit, but with the bonus that it can supply 5V from the PC's USB port if that is sufficient for the prop board.
    There are FT232 based ones too, but you have to be careful of counterfeits so I don't recommend using them.

    I have been using these for many years with the P1 so it was an obvious choice for my P2 board. The pinout matches these so that they plug straight into my RetroBlade2 which also powers it from the USB too. That is why I have the transistor reset circuit on the RetroBlade2 (and my P1 boards) as a solder-linkable option.

    Unfortunately when I sent the RetroBlade2 boards to Ken and yourself I didn't have any spare CP2102 boards or I would have sent them too. I'll send you a couple but it will take a couple of weeks.

    No problem. If I look for a symbol called DOWNLOAD_BAUD, I can use that for downloading. Would that be helpful?

    While I'm not having problems using the faster 2Mbaud for the initialisation, or even download, I think that option might prove beneficial. I'm going to rollback my download speed just to be safe.

    Did you see this...
    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.

    Yes, there must be some initialization problem in my code when talking to a CP2102. I will order one of these cheap boards. I will need one to figure this out.

    Chip, I will send you a couple.
    We can live with the current solution for now if you cannot see why it doesn’t work the first time the DEBUG_BAUD = 921600 is used. I will recheck tomorrow if it happens on P2_EVAL too.

  • Jeff MartinJeff Martin Posts: 686
    edited 2021-03-18 16:51

    @Cluso99

    I've been reading and rereading all the debug serial issues in this thread, trying to make sense of it all.

    I may have missed it somewhere, but have you captured both Tx and Rx (at the Propeller) with an oscilloscope? Have you checked the bit period of the analog signals in both directions (not relying on any digital logic translation/filter modes in the scope that would hide critical details from you... just pure analog)? Noticed any slew or capacitive ring (or incorrect bit timing)?

    I'll tell you my experience in doing this years ago with an old FTDI chip (I "think" it was an FT232R) and of course an older version of the driver. I think the CP2102 may also be exhibiting the same behavior that I discovered with that FTDI chip.

    I think I was attempting speeds of 921,600 Baud, 1 MBaud, 1.5 MBaud, 2 MBaud, 2.5 MBaud?, and 3 MBaud. In my testing at the higher speeds, I found that my Propeller code would often receive the right values from the PC-transmitted stream, but not always. Also, the same was true going the other direction. The problem would change if I sent larger packets of data vs. shorter packets, but shorter wasn't always better (it would sometimes fail on short packets).

    Ultimately, I 'scoped it very carefully (numerous times) and to my surprise, I found that at any fixed high-speed baud rate, sending the same short stream (for example) multiple times (with delays in-between) would result in each corresponding data burst arriving to the Propeller (from the FTDI chip's Tx pin) with slightly different timing each time; most of which wasn't perfect timing.

    The bit period (timing) would remain consistent within any given data burst, regardless of the length of that data, but the timing itself would vary from one burst to the next.

    At the higher baud rates, the bit period (timing) would vary from the ideal (for that particular baud rate) by close to or beyond 2.5%. This would easily cause misinterpretations of the transmitted data (by the receiving side; Propeller in this case) starting within the first few bytes or sometimes not until closer to the end of the data burst... however, retransmitting that same data again (same session, same baud rate) would result in complete success or a different amount of failure than before.

    Data coming from the Propeller (to the FTDI chip then to the PC) seemed to also follow the same pattern of interpreted success/failure, yet the data itself was always faithfully transmitted by the Propeller with perfect timing.

    I also found that certain baud rates would tend to exhibit closer-to-perfect bit timing more often than others.

    From this, I reasoned that the FTDI chip was really pushing its limits and was basing it's timing on a PLL that would sample just before each data burst; keeping the timing throughout the data burst, but changing it's timing for each successive data burst.

    I think (but can't be sure) I also found that requesting baud rates outside of the FTDI's capabilities would not result in an error (on the PC side), but would result in data transmitting at some baud rate that "it could" do.

    One more question: Are you sure (I mean oscilloscope-verified sure) that the CP2102 is transmitting the downloaded P2 application at 2 MB? I think you indicated that you verified this with P2 code set to 2 MB and that should be sufficient, but if you're just pointing out that you never have download failures, my theory is that this could be because the CP2102 is transmitting at some other effective baud rate (other than 2 MB) and the P2 is autobauding (able to receive the image just fine) but going the other way won't work because the P2 is transmitting at 2 MB for real and the CP2102 is receiving at some other effective baud rate.

    For kicks, I just checked at various DEBUG_BAUD rates to verify the Propeller was transmitting properly. I only did this with my Saleae LA, which can only do 10 MS/s analog and 100 MS/s digital) and verified the data was intact and the analog timing was good (as best I could see it with the limited sample rate).

    In the sample below the "RX..." channel is from the perspective of the PC; ie: it's measuring the Tx pin output of the Propeller. Below it is the analog version of that same pin.

    Here's a sample at 230,400 baud.

    Here's a sample at 1 MBaud.

  • jmgjmg Posts: 14,676

    @"Jeff Martin" said:
    One more question: Are you sure (I mean oscilloscope-verified sure) that the CP2102 is transmitting the downloaded P2 application at 2 MB? I think you indicated that you verified this with P2 code set to 2 MB and that should be sufficient, but if you're just pointing out that you never have download failures, my theory is that this could be because the CP2102 is transmitting at some other effective baud rate (other than 2 MB) and the P2 is autobauding (able to receive the image just fine) but going the other way won't work because the P2 is transmitting at 2 MB for real and the CP2102 is receiving at some other effective baud rate.

    That's a good point, as the drivers in most UARTS these days, accept any baud value within band, and snap to the nearest possible baud.
    In most parts that becomes 24MHz/N, but Silabs will also impose a SW ceiling in their drivers, which has bounced around over time.

    Just dug deep to find a dusty old CP2102, and checked this

    SiLabs driver : 10.1.8.2466 - limited baud to 1Mbd for other than CP2102N
    then
    Release notes for 10.1.10 (2021-01-13) actually 10.1.10.103
    Changes for VCP Driver
    MCUSW-651 | Support baud rate up to 2187500 for CP2102, CP2104, CP2109

    With 10.1.10.103, and older CP2102, values above 24M/11 = 2181818 give a setting error, 2181818 and below are valid.
    The sustained average data rate is lower. (I get numbers lower than #1204 above)

  • mojorizingmojorizing Posts: 247
    edited 2021-03-18 19:48

    The CP2102 on my usb to serial doogle is from at least 10 years ago that I used on a small run project. At the time, users of the device where having a hard time finding and installing the drive as I recall. The driver I'm using is today 10.1.10.103. On the acual chip has on it
    SILABS
    CP2102
    DCL07X
    1250+

    The doogle has 6 pins GND, RXD, TXD, 5V, RST, 3.3V. I tried to use it as a propplug, but what is labelled as RST is not RTS, not DTR. Actually I can't control that pin using the likes of RealTerm, etc. Further inspection I see that this RST pin is pulled high to VBUS via a resistor, no connection to the CP2102. Given that, I don't think I can use this as a proplug, right?

    I'm liking Jeff's theory on the CP2102 to P2 autobauding on download at something less that 2MB.

  • jmgjmg Posts: 14,676
    edited 2021-03-18 21:29

    @mojorizing said:
    I'm liking Jeff's theory on the CP2102 to P2 autobauding on download at something less that 2MB.

    Yes, it's been a while since I tried CP2102, as I usually use CP2102N, or EFM8UB3, and the older CP2012 is worse than I recall.

    It is more granular than 24M/N - not quite 24M/4*N ? - valid values I hit on old CP2102 are 921600, 1.2M, 1.5M whilst CP2012N follows 24M/N

    and whilst setting 2181818 is legal on both CP2102 & CP2012N with driver 10.1.10.103, the actual outcomes are quite different - here is a simple send of 'UUU'

    The older CP2102 part has inter-char gaps (extra stop bits), even on just 3 chars, whilst the newer CP2102N part has the faster MCU with UART FIFO.

  • Thanks @jmg and @mojorizing.

    @mojorizing - Right, if that RST is just pulled high and has no connection to the CP2102 (not connected to either DTR nor RTS), then you won't be able to use it as a PropPlug replacement. Makes me wonder what that RST pin was for - meant for a specific product that requires it's RST line high to program? Or high to communicate normally?

    @jmg - That's good info to know. Sounds like they were having issues supporting the speeds they spec'd.

  • @jmg said:
    It is more granular than 24M/N - not quite 24M/4*N ? - valid values I hit on old CP2102 are 921600, 1.2M, 1.5M whilst CP2012N follows 24M/N
    ...
    The older CP2102 part has inter-char gaps (extra stop bits), even on just 3 chars, whilst the newer CP2102N part has the faster MCU with UART FIFO.

    Thank you, @jmg - that test looks like it supports my theory of what's happening with the CP2102.

  • Jeff MartinJeff Martin Posts: 686
    edited 2021-03-18 21:37

    @jmg - can you try the same test but with 2000000 as the target baud rate?

    Oh! I see it from the numbers about the capture... CP2102 @ 2000000 results in the same baud rate as with 2181818.

  • jmgjmg Posts: 14,676

    @"Jeff Martin" said:
    @jmg - can you try the same test but with 2000000 as the target baud rate?

    Oh! I see it from the numbers about the capture... CP2102 @ 2000000 results in the same baud rate as with 2181818.

    Yes, and in both 2000000 & 2181818 cases, older CP2012 actually runs at 1.5Mbd, ie not what the user entered ;)

  • Cluso99Cluso99 Posts: 17,761

    Jeff,
    No, I haven’t confirmed serial speed with a scope. If necessary I can get it out of storage.

    Interesting idea that the P2 is autobaud inch and it’s not really 2Mbaud. However, pnut sends out the initial debug setup data at 2Mbaud and this part does work, and I’m sure Chip is setting the P2 to do this at 2Mb. Then we change this down to what the CP2102 seems to be able to consistently handle by setting DEBUG_BAUD = 921_600. This part wasn’t working (and still seems to fail on the very first time pnut is loaded if this option is set in the code - but just doing another Ctrl-F10 works, and does from then on) but Chip has fixed this now (except the first instance).

    Where this problem started was that DEBUG_BAUD wasn’t working, and ultimately that bug wasn’t a CP2102 problem at all, just that it revealed the bug.

    I’m happy to just live with 921_600 (or lower if need be). We’ve never pushed the CP2102 to it’s limits before, nor FT23x chips for that matter.

    To sum up, IMHO

    • Need to be able to configure downloading baud
    • Need to be able to configure debug baud (both initialisation and debugging)
      This could all be the one setting if desired.

    And, pnut still has a problem with the very first compile if DEBUG_BAUD is used.
    And, pnut still has a timing problem with my RetroBlade2 and CP2102 using the transistor reset circuit if there is an SD Card without the P2 boot file/sequence in the SD slot.

    As I said to Chip above, we can work around all these until I get him two CP2102 dongles. I know it’s so much easier to have the failing hardware yourself than trying to fix it remotely.

    I still need to try out the latest PropTool. I haven’t had time yet, and while I had/have pnut problems, there was little point.

  • cgraceycgracey Posts: 13,610

    Yes, the P2 autobauds on download. So, we tell the PC to use 2 Mbaud and it uses something else, like maybe ~1.5 Mbaud. The P2 adapts to that and everything goes well. Then, we start setting hard baud rates and the dissimilarity shows up.

  • Cluso99Cluso99 Posts: 17,761
    edited 2021-03-18 22:37

    @cgracey said:
    Yes, the P2 autobauds on download. So, we tell the PC to use 2 Mbaud and it uses something else, like maybe ~1.5 Mbaud. The P2 adapts to that and everything goes well. Then, we start setting hard baud rates and the dissimilarity shows up.

    So we could be being fooled by the CP2102 downloading.

    What about the debug initialisation back to the PC? I don’t think this part could be fooled by the CP2102 as the P2 is setting this speed???

    Doesn’t get past the point that CP2102 has at least an upper limit of 921600 for reliable comms. I can live with this, or else use a better chip.

  • cgraceycgracey Posts: 13,610

    For downloading, the P2 autobauds from the incoming serial. In DEBUG, the compiler hard-codes the baud value into the P2. In that case, the two baud rates must match.

  • It sounds like if we had a setting in the IDE (PNut or Propeller Tool) that allowed the selection of download baud rate, that setting could be passed to the compiler to become to "default" baud at which Debug performs for that particular compiled image... then, if DEBUG_BAUD wasn't specified by the source, it would naturally use the "download baud rate" specified by the software.

    And if DEBUG_BAUD were specified by the source, two different baud rates could be involved (if desired; just like it is now) except both download baud and debug baud are configurable by the user.

  • @Cluso99 said:
    ...pnut sends out the initial debug setup data at 2Mbaud and this part does work...

    Oh... do you mean PNut configures the application for the specified debug baud rate, but at runtime the Debug initialization strings (that are generated from application/cog launch) come back to the PC at 2 MB and only after that, the baud rate is changed for further runtime DEBUG() statements?

  • Cluso99Cluso99 Posts: 17,761

    @"Jeff Martin" said:

    @Cluso99 said:
    ...pnut sends out the initial debug setup data at 2Mbaud and this part does work...

    Oh... do you mean PNut configures the application for the specified debug baud rate, but at runtime the Debug initialization strings (that are generated from application/cog launch) come back to the PC at 2 MB and only after that, the baud rate is changed for further runtime DEBUG() statements?

    Yes, that is my understanding.

  • Cluso99Cluso99 Posts: 17,761

    @"Jeff Martin" said:
    It sounds like if we had a setting in the IDE (PNut or Propeller Tool) that allowed the selection of download baud rate, that setting could be passed to the compiler to become to "default" baud at which Debug performs for that particular compiled image... then, if DEBUG_BAUD wasn't specified by the source, it would naturally use the "download baud rate" specified by the software.

    And if DEBUG_BAUD were specified by the source, two different baud rates could be involved (if desired; just like it is now) except both download baud and debug baud are configurable by the user.

    Yes, this would make the most sense.

  • cgraceycgracey Posts: 13,610

    I made a new v35k at the top of this thread which adds DOWNLOAD_BAUD symbol sensitivity for setting the download baud. You can also set DEBUG_BAUD to establish a different baud for DEBUG data. It may be necessary to add a 'DEBUG_DELAY = 100' to make things work when you are going from a fast (2 Mbaud) download baud to a much slower DEBUG baud.

Sign In or Register to comment.