Prop Plug/wireless programming
xanadu
Posts: 3,347
When you program a Prop via the Prop Plug, what happens with RESn? Is that low while programming or only afterwards for a reboot?
Comments
RESn is not low during programming. That would hold the Prop in reset. I think it only goes low after programming to start the new program.
Could it be done using just tx/rx then RESn bounce to reboot and load the new code?
I found a wifi transparent serial bridge and would like to use it to program the propeller over wifi.
I could use a GPIO to bounce RESn. It would be clunky but worth it.
To program the Propeller, the serial data must start 90..110 ms after RESn goes high. And the data must have the right format. Otherwise the code from EEPROM is loaded and started.
The programdata stream must alse be continuous without gaps, so it is unlikely that a wifi bridge works. And you need a way to generate a reset pulse from the bridge.
But with the right code in the EEPROM it is possible to reprogram the Propeller from many sources like Wifi, Bluetooth or SD-card with a two step process.
Andy
The RESn going low triggers the PNut Booter v0.2. I have reprogrammed the Propeller 1 via Wifi using a hacked WR703 with loading software compiled by Heater. As long as the pullup resisters are right, it works. The .spin file can actually be compiled to a binary on the WR703 and then loaded.
You might have more latency problems if you expect to send the binary over wifi while loading.
When RESn is released the Propeller boots up.
As the Prop boots up it listens for programming data. If there is none it loads code from EEPROM.
In this way a program on your PC can reset a Prop and program it via the Prop Plug.
There are no "official" documents describing this boot/programming procedure. Kind of shameful after all these years. But it can be gleaned from the loader in prop-gcc and other places as hinted above.
I now see that the actual ESP8266 appears to not have any USB. So it seems that the mention of PropPlug is a distraction. The Propeller Manual provides schematics of the simpler RS232 TTL interface that is typical and can be adapted in many ways (the MAX233 level shifter, RS-422 full-duplex, a PropPlug, or direct TTL asynchronous serial).
My Propeller Protoboard with the Tp-link WR-703 (or the MR-3020 which may be easier to acquire) actually uses the direct TTL levels via a hardware hack.
The MR-3020 has a USB port and can do the same with USB and a PropPlug, but one is merely adding more layers of hardware and cables. If the goal is a small DIY device, consider setting aside the USB.
Ah, I see the problem. You asked the wrong question here. This is nothing to do with the Prop Plug. Your question is "How to Program a Propeller over a TCP/IP to serial bridge". Specifically that ESP8266-transparent-bridge.
So what we have is:
Propeller -> serial Tx,Rx, Res -> ESP8266 -> WIFI -> PC.
On the PC that shows up as TCP/IP socket rather than a serial port.
In theory this is easy. Just get a Propeller loader program and modify it to read/write bytes from a network socket instead of a serial port.
As far as I can tell issuing a reset to the Propeller would be done via a GPIO pin on the ESP8266 and the AT command as shown on the git hub page for the bridge.
Somewhere here there is a Propeller loader in Python that could be easily modified to do all this. Or take the loader from prop-gcc and tweak that, bit harder in C though.
In theory, yes... but with the ESP8266 apparently having only two GPIO pins and they being needed for Rx and Tx, I don't see how the RESn will get propagated. I don't see enough GPIO pins. Is there a clever wiring solution that makes the Rx (or Tx) a dual use GPIO?
It seems I misread something. Tx, Rx, and two GPIO are available.
I fear that the ESP8266 is dedicated to Rx and Tx and its own Reset input is to reset the ESP8255.
Still, the WR-703 or MR-3020 remain a useful solution for wifi programing of a Propller. Both provide a lot more resources beyond wifi. And the additional of RAM and a file system on those allows the Propeller to migrate recorded data into files for ready transfer when wifi is available.
Thanks for the link, I will have to try that out with Tachyon as reprogramming is easily done at the higher level anyway. Might be useful.
For example the ESP8266 spec. sheet here: https://drive.google.com/file/d/0B_ctPy0pJuW6Y0FHcDlVY09Xdjg/view?pli=1
You may indeed be correct. What I apparently misread was an Arduino tutorial.
I have crossed out the portions of my above posting that were wrong.
The ESP8266 is a 3.3v device. It should work, but the RESn may desire a pull-up resistor.
Yes, we could move the whole programming thing to a higher level.
A minimal Propeller loader written in C will probably fit in the ESP8266. Just send it a Propeller binary and let it sort out the programming protocol itself.
Then there would be no worries about network delays during programming.
I think every Prop should come with an ESP8266. Any one out there working a little board like that?
I asked about the Prop Plug because I am more interested in how that works at the moment. I think I have the ESP side of things covered. If something starts to look feasible, I'd start another thread on the whole thing.
I am able to tx/rx data over the link, but not program, yet. I am using a PC running a virtual comm port, connected with a wireless link to one ESPv12.
I have no idea how virtual comm ports work under Windows. Perhaps there is a way to assert the serial line control signals via it. DTR, CTS etc. as used by the Prop Plug.
But so far I don't see how that gets to a GPIO pin at the ESP end.
Serial over WIFI should work fine. I was thinking a bit further out. What if my Prop is far away over the internet with all kind of latencies and drop outs along the way?
Here's the virtual port that will connect to the ESP's bridge firmware.
I'm not sure about over the internet programming. I'd be really happy with not having to connect a heavy USB cable to a tiny little SMT port.
Propeller "hello_world.spin" -> ESP -> wifi internet gateway -> remote wifi internet gateway -> Virtual Comm -> Propeller Debug terminal.
The virtual comm software will queue the data if the Prop debug terminal isn't open. That's pretty neat! When I open the terminal is streams the data to it. So if you wanted to transmit on a less than good link, you could wait to open the connection until it is fully buffered to the remote side. This would require a computer to run the software. Still kind of neat!
I am not sure where 'virtual comm ports' might lead us.
The ESP8266 should be equally able to support a com port in Linux, OSx or Android in order to allow all sorts of Parallax users to enjoy a wifi interface.
That's a bit big and expensive. So what about just having a EP8266 at both ends? Oe does serial to IP for the Propeller, one does serial to IP for the PC.
Agreed, I'm not presenting any solution here though. Just trying to understand the programming process. My hack job attempt didn't work, but I understand the process better.
The IDE will need to support the bridge. I can't hit DTR and then program anything, that doesn't work. Either the timing is off, or the IDE doesn't like the virtual comm port, or both.
It's Windows only software - http://www.hw-group.com/products/hw_vsp/index_en.html
I think you'd only need one ESP on the device. The computer can use the network to talk to it.
Unless we modify some Prop loader to use a network socket instead of a serial port.
I'm working on it.....
About the only difference is the arrangement of the GND, Tx, Rx, and RESn. There really isn't not much to reverse engineer in it. Any FTDI chip a third line available for RESn use will work.
A network device would just have to convert and buffer the network input to serial.
Most easily done via a Linux router with an available serial i/o. My hacked Tp-link MR-3020 was intended to do this via wifi, but it can work equally well via RJ-45 interface. Heater compiled the code and did work on that. I suspect it could be nicely extended.
but that requires a 64k eeprom.
OR you could use socat with RFC 2217 patch: http://www.dest-unreach.org/socat/contrib/socat-rfc2217.html
The hardest part of dealing with hacking it is opening the plastic case if you desire to save the case. The device can provide Tx, Rx, and RESn to a Propeller directly, or you can use the USB port to cable to a PropPlug. (There is a 4 pin header for Rx, Tx, Vcc, Gnd on the board -- look at the OPENwrt photos)
If you use the USB and a PropPlug, and provide 5VDC -- I think you don't have to open the case for anything.... just modify the flash image, and use Heater's code to load binaries or to compile SPIN files that have been downloaded to the MR-3020 file space.
========
Providing the Tx, Rx, and RESn is a bit of a microsurgery challenge. The Tx and Rx are easy, but you have to liberate a GPIO on the board for the RESn by removing a surface mounted resistor and attaching a small wire (I used wire wrap wiring) to one of its pads - then that wire has to go to a 10K pullup connected to 3.3VDC.
I removed R17 to wire up GPIO29 right next to the 7 in the R17.(see photos)
You also need to master all the wifi configuration in the OPEN-wrt scheme. So, it may be best to get the MR-3020, reload with the OPEN-wrt code, and explore what it does before you open it up and start modifications.
http://wiki.openwrt.org/toh/tp-link/tl-mr3020
Soldering that wire-wrap lead to the GPIO pinout is a serious challenge. Everything is tiny. And the wire should be glued to the board so it won't pull up the pad it is soldered to. I first used super-glue and that did not work. Then I used epoxy with a toothpick as an applicator. The soldering job is about the width of a human hair... really!
Take it slow, the MR3020 has only a few easy GPIO locations. If you ruin one, you don't have many extra. The WR703 may be an easier board, but you might have to go to EBay and buy from China.
++++++++
I deeply enjoyed modifying the MR-3020 and greatly appreciate Heater's compiles of useful code that make it work well with the Propeller 1.
But it is an adventure to flash a commercial device with OPENwrt code and then to hack into. You learn a lot along the way.
I actually have a second brand-new one here that sits unopened in the original box for future use.