Serial output from FlexCC

David Betz

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;
}

ersmith

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?

ersmith

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.

David Betz

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?

David Betz

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

ersmith

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

David Betz

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.

ersmith

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

David Betz

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