can serial port be disconnected and reconnected with spin still running?
realolman1
Posts: 55
I made a spin program that communicates with a VisualBasic.Net program. It also communicates with the Parallax Serial Terminal
If I close the port on the VB serial port, I can communicate with the PST, and vice versa.
What I wanted to do was have the propeller stand alone and then come back and get what I wanted from it. Here is the problem:
When I disconnect the serial cord from between the propeller and the computer, I lose communications. What can be done to prevent that... or how can I regain comms?
All it is doing at the moment is running a cog to communicate, and a cog to keep a timer going. If I send a "t" to the comms cog, I get the elapsed time back "from the timer cog". I see when I re connect the serial cord there is activity on the "propeller plug"
I would like to be able to disconnect the computer and come back later and reconnect. how can I do that? I suppose I could use an input pin to restart serial comms
the code is attached
thank you
If I close the port on the VB serial port, I can communicate with the PST, and vice versa.
What I wanted to do was have the propeller stand alone and then come back and get what I wanted from it. Here is the problem:
When I disconnect the serial cord from between the propeller and the computer, I lose communications. What can be done to prevent that... or how can I regain comms?
All it is doing at the moment is running a cog to communicate, and a cog to keep a timer going. If I send a "t" to the comms cog, I get the elapsed time back "from the timer cog". I see when I re connect the serial cord there is activity on the "propeller plug"
I would like to be able to disconnect the computer and come back later and reconnect. how can I do that? I suppose I could use an input pin to restart serial comms
the code is attached
thank you
Comments
Theoretically, you might be able to have it automatically detect that the serial port was connected and opened by manually wiring the appropriate RS-232 flow control line to a Propeller input (using appropriate level shifters, of course). I don't know enough about flow control lines to tell you if that is actually possible. However, I wouldn't bother with flow control lines - I would find it much easier to just manually tell the Propeller to start sending again.
Or, you can just have it always send data, and the data only actually goes anywhere if the computer is listening.
Opening and closing a serial Port on the PC will change the status of RTS/CTS and doing that will reset the Propeller.
Worse are Propeller Boards with USB. If nothing is connected to the USB sending out data from the Propeller will power up the USB chip thru parasitic voltage/current and - guess what - reset the Propeller also.
Rarely any Propeller Board is protected from that. The Spinneret had a jumper on the reset line to prevent this behavior, unplug jumper for use, plug in jumper for programming.
So to get serial communication running with or without being connected and able to hotplug, you need to cut the trace to the reset pin and put a jumper there.
Enjoy!
Mike
Mike
I made a LED blink during the program, and it did exactly as you said. It stopped when I plugged the USB back in
If you disconnect the RES from the USB it cant find the propeller for a download but you can disconnect and reconnect the serial cord and still communicate
Well, that stinks
Why would the propeller be reset by disconnecting and reconnecting the serial cord?
Edit:
Apparently it resets it before a download.
I might be able to live with that.
Combine the two, and voila...
And that is the correct way Propeller boards get reset while programming.
It is by design. But planned to do that, so intentional.
On the older boards without USB but using a prop-Plug you could avoid the problem easy by not connecting the reset pin, but since build-in USB you basically need to cut traces and put a jumper there.
@Electrodude is completely right that you can change the behavior on the PC end under Linux, sadly not under Windows.
The issue of Propeller-Boards resetting themselves by outputting to the USB with nothing connected is also by Design, but not planned or intentional. Sadly most of the boards do that.
There is a software solution to just enable the serial driver IF something is connected, but it is a harsh step to disable the driver at startup and not being able to use it later.
I think it was to check if rx is high and not floating, then USB is connected.
But it is a kludge.
Enjoy!
Mike
It's kinda important to me to be able to disconnect and reconnect the serial cord.
Certainly, if you have access to download source code, it would be possible to change CTS to allow use of a charge-pump type reset, which should be immune to windows-find effects.
I don't suppose there could be some sorta pull up / down resistor installed on the res line
Is the windows enumerating and toggling a genuine reset signal?
Basically, yes. Because the Prop has a very simple reset take-off, almost any pulse will reset it.
If you cannot tolerate a jumper, then some more effort (changes) will be needed to separate a Windows-connect from a Download-Reset.
Yes, an alternative is to tolerate any Windows reset effect, by design.
You may want your download to reset-first anyway, to get to a defined state, but you do want to avoid confusing the waiting bootloader, so need to wait for the EEPROM boot to complete
Some loader info is here
http://propellerpowered.com/forum/index.php?topic=272.0
PC: set 115200-8-N-1 DTR low wait at least 10ms DTR high wait 100ms (+-10% tolerance) send $F9 (%0100111111 timing calibration) .... CHIP: <reset> wait for up to 150ms @20MHz for $F9 + bitwise LFSR[250] if timeout or mismatch, EEBOOT ....I think that says 150ms is the nominal serial loader timeout, so you can either wait (say) 200ms from DTR=\_/=, or you could try the mismatch path, if 200ms is an issue.It won't reset the prop chip, no wires etc...
https://www.parallax.com/product/32420d
https://www.parallax.com/sites/default/files/downloads/32420-Parallax-Wi-Fi-Module-API-v1.0.pdf
Then there's a relatively easy solution. Make set of jumper wires to go between the Prop Plug and the board but don't attach the reset line.
When you want to program the Prop, reattach the reset line.
It is just unnerving to spend a bunch of time on something, and then have something unexpected come out of left field. Makes you wonder if there's something with no work around lurking in the future.
thank you
The Parallax WiFi module looks cool but I don't think you'll be able to load code to the Propeller using the module without some sort of loading routine already in the Propeller. I think it's likely it will eventually be possible to load code onto the Prop using the module but it's not a simple replacement for the Prop Plug. At least this is the impression I received from the product page and documentation.
There are lots of wireless connection options for the Propeller. I use $3 HC-06 Bluetooth modules in a bunch of my projects. These modules allow the Propeller to communicate wirelessly to both a PC and Android devices. I don't know if the HC-05 will work with iPhones.
The only wireless substitute for a Prop Plug I've found so far has been a pair of Wixels. While the Wixels can be used for both wireless communication and wireless programming, setting up the Wixels to work this way isn't trivial. Martin_H explains how to use Wixels to program a Propeller in this thread.
In light of that, I think for now, I would be better off just jumpering the RES until the time that I might develop something useful
thanks very much.
This is what I generally do.
There have been a couple interesting alternatives to using a jumper. I'll add link(s) when I find these alternatives.
Normally the propeller pulls its own reset line high. The prop plug reset output is open-collector,and it is driven through a capacitor on the rising edge of the DTR signal. Something special has to happen from the computer end to generate that DTR rising edge.
Exactly with a PropPlug you can easy avoid the problem.
But sadly Parallax decided to put USB on every board. And there you get in trouble. It will enumerate when plugged in and on Windows will change DTR/RTS causing a reset. You can avoid that on Linux but I could not figure out how to do that on windows.
And sadly on most Parallax Boards even reset when you USE the port for output without having anything connected to the USB on the Propeller. Just by sending serial data the USB chip gets partially fired up thru the serial pin and - bang - resets the Propeller.
This USB on all boards is a horrible decision.
Mike
Not really. USB is everywhere these days.
What it could have used was some finesse in making the USB - RST path, more tolerant of Windows actions.
eg I believe a charge pump solution could be done, with minimal BOM impact.
You might look for a place to keep the timer data that needs to be non-volatile, immune to resets. Real time chips often have a small amount of battery-backed RAM that is perfect for this sort of thing. But that does entail an extra chip and extra code.
I generally like the USB interface to be built in for the sake of convenience and for OEM LiPo charging. It does have its traps though and ways to step around them, call them what you will, workarounds or solutions.