I'm experimenting with some modules that connect via serial and can act as a transparent transmission medium between a tcp port I.e like Telnet and the serial output of the device.
It also has one GPIO line.
So I'd like to try to upload new firmware over wifi, by I connecting the GPIO line to the reset of the arduino and then sending the binary via serial, however I can't track down the documentation of quite how this process works.
Can anyone give me some idea of where to find this information ?
If you're going to program it via the serial interface, you'd need to have a bootloader installed and your device would need to trigger a board reset and then go through the STK protocol sequence to upload the sketch. If you want to program it via the ICSP interface your device would need to trigger a board reset and then act as an In System Programmer to upload the image. It would probably make sense to use a serial-to-TCP application (such as Realterm or PuTTY) at the PC end so that you can use the standard AVRDude utility to do this for you - this would mean you could program it from the IDE. The part you'd need to provide for this to work is resetting the target board when the serial port is opened. In the conventional direct solution, this would be triggered by the serial port control lines; maybe you can do something similar.
The board (probably an Arduino mini) has the bootloader installed.
I was intending to connect the Wifi module (which has Rx and Tx) to the Tx and Rx of the Arduino, and then connect the GPIO line from the wifi module to the reset pin.
The wifi module always runs a Telnet server on port 23, and its possible to control the GPIO by logging in via Telnet.
So the plan was to log in via Telnet, toggle the reset. Then send the binary via RS232 to the wifi module (probably on port 80), which would then be streamed straight to the serial port of the module and into the serial of the mini Arduino.
However, I'm not sure what the
STK protocol sequence
is?
Is there some 2 way comms needed between the uploader and the Arduino, or is it just send of the serial?
I sound like from what you said, the best bet would be to modify an existing uploader e.g. AVRDude etc, so that it sends and receives via a TCP port.
I think the best option would be to use a serial-port-to-TCP bridge at the PC side which will cooperate with your TCP-to-serial device at the Arduino side to provide an end-to-end serial connection. From the point of view of the AVRDude utility that does the uploading, it would look just the same as if it was using a direct serial connection. For this to work you just need to arrange for the target Arduino to get reset when AVRDude opens the serial port at the PC side. I don't know how easy it would be to achieve that using the standard existing TCP<->serial bridges but it ought to be possible, and you can always provide your own bridge if necessary.
Serial to PCB bridge sounds an excellent idea, especially if someone else has already written one
umm. Perhaps this one would do the trick, I'll need to download and take a look.
I guess the tricky bit will be resetting the Arduino via the GPIO and then firing up the AVRDUde via the TCP bridge quick enough that things get going before the Arduino boots.
In the longer term if this looks like it would work, I may take a look at modifying AVRDude, as i think the source code is available.
I don't think you need to modify AVRDude - the problem is just to arrange that when the serial port is opened on the PC, the Arduino gets reset. The reset is actually triggered by AVRDude toggling the serial signal lines, so if your serial/TCP bridge carries the signal lines with it, all you need to do is have your firmware pull down the reset pin when it sees that signal. If it doesn't carry the signal lines through you would need to come up with other way to recognise that the port has been opened. You have access to the software at both ends (there are open source serial/TCP bridge implementations available) so there shouldn't be any problem doing that. I wouldn't propose hacking AVRDude though - leave that alone if you can, since it has significant logic and you don't want to be left trying to maintain your own variant of that.
I can toggle the reset via a different port on the Wifi module.
It has 2 TCP ports open by default. One port is effectively a command port (on 23), which can be used to control all sorts of stuff, but also allows the GPIO line to be set to high or Low
And it has a "transparent" tcp port that goes to its RS232 connections
So I'd need to write something that telnetted in on 23 and toggled the GPIO pin,then run AVR dude to the devices transparent tcp port (currently set to port 80)
I'm not sure if Telnet.exe on the PC is scriptable e.g. just to push commands, but I'll need to take a look.
Then write a something in windows scripting host etc that toggles the GPIO via telnet, and then runs avrdude
Actually I guess I could probably get the Arduino to reset its self via some command on port 80. i.e I've written a simple web server on port 80, so I could send a secret command to the web server and it could cause the Arduino to reset its self.
(I'm not sure if you can do this in code, I have a feeling there is a hack to do this)
rogerClark:
So I'd need to write something that telnetted in on 23 and toggled the GPIO pin,then run AVR dude to the devices transparent tcp port (currently set to port 80)
I'm not sure if Telnet.exe on the PC is scriptable e.g. just to push commands, but I'll need to take a look.
I'd do it entirely within the serial port if I were you - then from the outside world (AVRDude, Arduino IDE etc) it will all work transparently and you won't need to do any Rube-Goldberging to make it work. The requirement to send a specific message on some other TCP socket when the serial port opens is something you're unlikely to find on any of the standard freeware COM port redirectors, so I suggest you look at the COM port redirector implementation on sourceforge (find it via the com0com project) and look to modify that to send this command in response to the control signals that AVRDude sends when it opens the port (it toggles DTR iirc).
Realterm certainly is scriptable and it just might be possible to implement this as a script around the Realterm COM interface (i.e. using the Realterm COM API to detect when the serial port has been opened and send the reset command over the control port) if you prefer to tackle it that way.