Using onboard programming USB port for serial communication to PC

[SirHC]

Hi

I know that the propeller is usually programmed using the USB/Serial via P30/P31. The manual states that these pins can be used for normal I/O after it starts.

However, I tried using the SimpleDebug module to send and receive, but it does not appear to work. Below is an extract from it, that gave me this idea:

PUB start(baud) : okay
'' Starts uart object (at baud specified) in a cog
'' -- uses Propeller programming connection
'' -- returns false if no cog available
· okay := uart.start(31, 30, 0, baud)

It suggests that I only need to set the baud rate, and can use the rest of the functions.

On the PC, I used HyperTerm matching the speed setting in my spin code, with a simple echo loop, sending back what the prop receives.·I can tell the USB is receiving my typed characters, as the onboard RX LED flashes as expected. However, the TX LED is continuously on, and the HyperTerm receives nothing.

What am I missing/doing wrong?

Thanks for the help,
Chris

[Mike Green]

There's nothing wrong with the uart.start call you posted. SimpleDebug does work and it all does work with HyperTerm. There must be a problem with the code that you haven't shown.

[SirHC]

Hi Mike,

Thanks for the reply.

As I said it's quite simple echo loop, code below:

------------------------
Obj
Debug : "SimpleDebug"

Pub Main | ch

Debug.start(9600)

dira[0]~~ 'enable P0 for output to toggle LED on each char received

repeat
ch := Debug.getc
!outa[0]
Debug.putc(ch)

------------------------------

I thought it might be HyperTerm signalling DTR, which in turn resets the prop chip. I tried turning off hardware flow on HyperTerm.

Thanks,
Chris

[SirHC]

Hi Mike,

I made some progress. The DTR is causing the prop to be reset, and I was testing to RAM, so the previous EEPROM code was running!

The loop is working, but getting garbage chars back, which indicates speed mismatches. Will try to slow down the speed.

_Chris

[Mike Green]

You don't seem to have the constant definitions for _CLKMODE and _XINFREQ. For serial I/O, you really need to run the Propeller from a crystal since the internal default clock (RCFAST) isn't accurate enough for use for serial communications. The download protocol uses a special self-clocking protocol even though the PC side uses a standard serial port. You didn't say what kind of Propeller board you're using. Most of them use _XINFREQ = 5_000_000 and _CLKMODE = XTAL1 + PLL16X. Read the manual for details on these.

[SirHC]

Ok, that makes sense, I will add that.

However, also setting HyperTerm to 7 bits worked without doing that, but I except 300 baud to be slow enough for it to work.

Thanks for your help,
_Chris