Shop OBEX P1 Docs P2 Docs Learn Events
Serial output from FlexCC — Parallax Forums

Serial output from FlexCC

David BetzDavid Betz Posts: 14,511
edited 2022-07-11 17:28 in Propeller 1

I wrote a trivial program to test another module I'm working on and am seeing some rather odd behavior. The program successfully writes text to the USB serial interface on the Quickstart but between each line of output I seem to get a bunch of garbage, mostly null bytes or framing errors. Is there a reason the line wouldn't be quiet between calls to printf? Is this because the Flex CC library lets the output pin float between calls to printf? How can I get it to leave the pin as an output?

#include <stdio.h>
#include <propeller.h>

int main(void)
{
    int state = 0;
    _setbaud(230400);
    while (1) {
        if (state == 0)
            printf("Hello, world!\n");
        setpin(22, state);
        setpin(23, !state);
        state = !state;
        _waitms(500);
    }
    return 0;
}

Comments

  • Just comment out the dira[_txpin] := 0 in the function _txraw in sys/p1_code.spin and then rebuild the compiler.
    I'm not sure why that line is there; on some boards do we need to let the pin float high?

  • Oh, I think I know why it's there... it's to allow multiple COGs to print. If we don't have it then as soon as another COG calls printf then they all fail.

  • That worked perfectly. Thanks!!

    Will I have to do that each time I get a new version of flexcc or will you make that change to the official library for future releases?

  • @ersmith said:
    Oh, I think I know why it's there... it's to allow multiple COGs to print. If we don't have it then as soon as another COG calls printf then they all fail.

    But that doesn't really work anyway does it? There is no guarantee that two COGs won't be trying to print at the exact same time.

  • @"David Betz" said:

    @ersmith said:
    Oh, I think I know why it's there... it's to allow multiple COGs to print. If we don't have it then as soon as another COG calls printf then they all fail.

    But that doesn't really work anyway does it? There is no guarantee that two COGs won't be trying to print at the exact same time.

    It does work, printf is protected by locks. It's only a problem on the QuickStart board, unfortunately.

  • Is this because there is no pull-up resistor on the TX pin on the Quickstart Rev A board? Do you know if they fixed that with Rev B? Unfortunately, almost all of my Quickstart boards are Rev A. I think I may have one Rev B kicking around.

  • @"David Betz" said:
    Is this because there is no pull-up resistor on the TX pin on the Quickstart Rev A board? Do you know if they fixed that with Rev B? Unfortunately, almost all of my Quickstart boards are Rev A. I think I may have one Rev B kicking around.

    I think it was something like that. I remember the Quickstart board was a real pain for the GCC libraries too.

    If you're not too speed limited you could try using the bytecode output (-1bc). That uses a separate COG for I/O, which can leave the pin as an output all the time.

  • @ersmith said:

    @"David Betz" said:
    Is this because there is no pull-up resistor on the TX pin on the Quickstart Rev A board? Do you know if they fixed that with Rev B? Unfortunately, almost all of my Quickstart boards are Rev A. I think I may have one Rev B kicking around.

    I think it was something like that. I remember the Quickstart board was a real pain for the GCC libraries too.

    If you're not too speed limited you could try using the bytecode output (-1bc). That uses a separate COG for I/O, which can leave the pin as an output all the time.

    No, your "fix" is good enough. This is just a simple test program to send serial data to a CH559 module. I'm using Matt Matz's module to provide USB Host support to another device and it didn't support an FTDI device so I'm adding that support and using the Quickstart for testing. In spite of having lots of other processors around, the easiest one to get going was the P1!

Sign In or Register to comment.