Cannot make FullDuplexSerial work with USB connection

cleo

Hello,


I am a newbie and as a first step, I want to make propeller
communicate with my PC. I used FullDuplexSerial and created
really simple communication program below. (also attached)

It (should) starts FullDuplexSerial object with pin 30(TX), 31(RX),
outputs "Hello, world", and outputs every input charactor.
But in reality, it just outputs "Hello, world", and does not take any input.

I am using hyperterminal for input/output interface and prop and pc
is connected via USB cable.

I thought about the possibility of crooked RX pin, and replaced
the propeller, but the same situation.

Am i missing something?

---

con
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

TXPIN = 30
RXPIN = 31

CR = 13
LF = 10

obj
serialio: "FullDuplexSerial"

pub main | receivedbyte

serialio.start(RXPIN,TXPIN,%0000, 9600)

serialio.str(string("Hello, World"))
repeat

waitcnt(clkfreq + cnt)
receivedbyte := serialio.rxcheck

if(receivedbyte <> -1)

serialio.tx(receivedbyte)
serialio.tx(CR)
serialio.tx(LF)

---

deSilva

Your program is fine. The delay however is unnecessary and a little bit confusing!

cleo

Thank you deSilva!

Sorry to confuse you. I should have eliminated that part.

Okay, so, the program itself is fine...

I will check with my friend's computer tomorrow and see how it works...

paul6502

I am trying to get this to run also. The prop tool won't load the program if hyperterm is open because of the com port conflict (it seems). If I start hyperterm after the program loads and runs I don't get any chars back when I send data. when I quit hyperterm it seems to reboot the prop. Is this not really a good setup? , Thanks

deSilva

You can use Aribas PropTerm, which is not as versatile as HyperTerminal but has a lot of additional options...
In fact I use PropTerm as I use PC_Interface for all of my debugging and most user interfaces.
Never thought of using Hypertermina for months...

paul6502

Where can I find these? I tried using realterm, got the same results as with hyperterm. The program running on the prop should keep running when proptool is shutdown, right?

deSilva

e.g. insonix.ch/propeller/prop_term.html
The download is near the end.

paul6502

That works! thanks so much! I wonder why the other terms don't...?

dfletch

Doh! How did I get anywhere with my VGA driver without this? It is something of a minor miracle. This should speed things up, being able to actually see the numbers!

Paul Baker

paul6502 said...
That works! thanks so much! I wonder why the other terms don't...?

They do work, you just need to know the correct way of setting things up and physically manage the com port, if you don't follow the correct procedure it won't work.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

paul6502

I set the baud rate and com port the same on the terminal apps. (com4 - 9600 n/8/1)
Not sure what you mean by "setting things up and physically manage the com port"

cleo

Thank you all, i made it work finally.

> Paul

thank you, it was indeed the settings. I specified no flow control in hyperterminal modem
configuration, and it worked just as I wanted. I did doubt my code itself, but forgot to
doubt my configuration.


> deSilva

thank you for information of Prop Terminal. we can do much more thing on this terminal.

I am very happy that I could get rid of my concern from last week [noparse]:)[/noparse]

Paul Baker

paul6502 said...
I set the baud rate and com port the same on the terminal apps. (com4 - 9600 n/8/1)
Not sure what you mean by "setting things up and physically manage the com port"

You also have to make sure flow control is off. What I mean by manage is if you are also doing development you have to make sure you disconnect the Terminal or you cant program the propeller. You have to physically "manage" the port.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

paul6502

Turning flow control off was the issue. Thanks. Shutting down the terminal program (any of them) will still reboot the prop. Not that big of a deal to me, but just curious if this is expected behavior.