How do I detect a propeller plug?

LarsE

I am working on an instrument project with a propeller chip and a propeller plug in it.
My part in this to get the reports out of the instruments via the plug and USB-cable to a Visual Basic app in the PC.
I have noticed that Propeller Tool reports different COM-ports upon almost every reconnection of the USB-cable.

How does the Propeller Tool identify the plug?
Is there some reference material on the plug interface?

Spork Frog

The plug is simply an FTDI USB-to-Serial converter. Both the demo board and the Hydra use this same chip onboard for programming. As for detecting, I believe the prop tool simply sends out a message down the serial line at its boot time. If a prop replies, there's one there.

hippy

Different COM ports indicates that your OS or the device driver is allocating a different port number whenever you plug the PropPlug into your PC. Nothing to do with the Propeller Tool.

As Spork Frog notes, and you've observed, the Propeller Tool scans all ports it can find looking for a Propeller Chip to answer back when it sends out a reset and an "are you there ?" message.

( See other forum posts regarding comments about how this scanning can cause problems with some Bluetooth devices and how that behaviour is undesirable for some users )

deSilva

@Sporc Frog: More or less... It checks the unattached COM-ports only (of course), "Resets" a propeller, if any, and sends a specific signal sequence that enables the boot loader to compute the bit-rate to be established.

Only after that can the Prop anwser intelligently.

This protocol is described here somewhere, and it is used in many "download helpers"...

Post Edited (deSilva) : 10/18/2007 12:36:34 PM GMT

Ken Peterson

@LarsE: I imagine you don't want to put the propeller into a boot mode when trying to communicate with it. The question is...does the port search algorithm used by the Prop Tool cause a reset on the propeller? You may want to come up with your own protocol and disable the reset line with a switch.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

LarsE

Thanks for the input.
Without it I still would have been fumbling in the dark.
Using the propellers built in protocol just to detect the instrument suddenly seemed like a bad idea.

Came up with a possible solution however:
We have come to the conclusion that its best to leave the interface "as is" and make use of the fact that connecting the USB cable triggers a reset.
When booting/resetting a splash screen shows on the instrument which will stay until a button is pressed. While showing the splash screen
the instrument is beaconing its presence to the PC which can set up itself to use the correct COM-port.
If one wants the PC connection leave the button be until a connection is established otherwise press button and start using it standalone.

hippy

I added an extra 4-pin Molex header to my board ( leaving reset unconnected ) and using P31/P30 through that for run-time serial via the PropPlug works just fine.

In my application I monitor the Rx line, and when a 'break' is seen it sends a message back to the PC. A VB program runs through the serial ports it can open, asserts the 'break' and waits to see if it gets the message it's looking for. When it does you've found your Propeller COM Port, otherwise timeout, close the port and try the next one. Similar to how the PropTool works but without using reset.

LarsE

More than a year has gone by with stable operation of the instruments and I thought I woud share
my experiences...

Here's the solution we finally came up with.
We abandoned thought of using virtual COM-ports, used the native FTDI API set instead and finally we cut the reset line, leaving a couple of soldering pads to enable programming by simply jumpering them temporarily.
Using the FTDI API set made everything way more powerful and stable than any comm port app I ever wrote before.