wireless programming

[Admin]

I found this today:
http://www.gnu.org/savannah-checkouts/non-gnu/avr-libc/user-manual/FAQ.html#faq_softreset

I also got another idea . . . what if you used *two* UARTs to do this?

For example, have UART0 for bootloader, and UART1 to receive the 'mcu reset' command. That way you can have the bootloader / spinning and still have a separate free channel to send the reset command.

Of course the ATmega8 series only has one UART, but the Axon has four and some of the newer ATmega's now have ~two.

The only disadvantage is that now you need two transceivers that work on different frequencies. Easy to do with bluetooth, but will cost more . . .

[pomprocker]

I had already been using the software reset with the wdt. With the XBee, you can solder a jumper between a GPIO and reset, and you can set the the receiver to mirror the reset. Using the FTDI cable http://www.ftdichip.com/Products/EvaluationKits/TTL-232R.htm  you can select an option in window 'set RTS on close' which will send a reset.

I follow the tutorial here:
http://www.ladyada.net/make/xbee/arduino.html


Unfortunately it seems this works for an LED blink type program, but anything big and it fails. You also have to either leave the serial monitor in the Arduino IDE open, or physically disconnect the xbee from the board to get it to run.

heres a pic of it with my Roboduino

[Admin]

Someone has managed to wirelessly bootload the ATmega168 using Xbee.

tutorial:
http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=122

[pomprocker]

I've been featured in this month's Servo magazine on page 16...LOL 

[Ro-Bot-X]

I've been featured in this month's Servo magazine on page 16...LOL 

Darn! I just ran out of subscription...

[pomprocker]

The sparkfun tutorial worked!! it uploaded my full hex of 32KB with only two retries, the amazing this is if it drops out, its able to pick up right where it left off and finish....it took 2 retrys and got the whole code on there.....all i have to say is OMG

i've been working on this for tooo long...

next step is to streamline this so everyone can do it, i would like to still see if this can be ported to bluetooth

[pomprocker]

I've been featured in this month's Servo magazine on page 16...LOL 

Darn! I just ran out of subscription...

Here ya go:
http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1
http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1

[yerbie]

The sparkfun tutorial worked!! it uploaded my full hex of 32KB with only two retries, the amazing this is if it drops out, its able to pick up right where it left off and finish....it took 2 retrys and got the whole code on there.....all i have to say is OMG

i've been working on this for tooo long...

next step is to streamline this so everyone can do it, i would like to still see if this can be ported to bluetooth

nice work pomprocker!  Were you able to get it to work on the Axon?  How about using bluetooth?  If so, maybe a tutorial would be greatly appreciated

[Ro-Bot-X]

Here ya go:
http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1
http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1

Thanks!

[frodo]

do you have to be a member or something for them websites because i can't access them.

[pomprocker]

not that i know of

[pomprocker]

Ladyada's tutorial was just updated to handle larger programs than 1K:

http://www.ladyada.net/make/xbee/arduino.html

[Admin]

I've been featured in this month's Servo magazine on page 16...LOL 

Darn! I just ran out of subscription...

Here ya go:
http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1
http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1

I get this error:
Use Limit Exceeded.
   This is a protected site. You have exceeded your accepted usage for this magazine.
     If you have any questions or concerns, please send mail to Digital Support.


Also, anyone know how I can do this wireless reprogramming with Bluetooth on the Axon?

[pomprocker]

I plan on looking into doing it with bluetooth when i get the chance

[Pototo]

I want to implement wireless access to my robot also.

What do you guys think is a better option between XBee and a BluesSMiRF

[pomprocker]

Well, it's been proven to work with Xbee, not yet proven with BlueSMiRF

[Admin]

pomprocker, a guy named iggie01 on avrfreaks contacted me with a bootloader he believes can be used wirelessly. Its a rewritten version for the same bootloader I use on the Axon.

below is what he says:

Hi Mr. Robot
I saw your post about danni's bootloader, and wanted to let you know I fixed up the linux uploader so that it works now (with OS X too).

http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_type=project&item_id=1927

I'm curious how your wireless modem interacts with the PC. My linux code checks for the modem to be ready to receive input rather than just blasting it out and hoping for the best. I don't know if the DOS program does this or not. The original linux port posted as a link by danni in that thread didn't check for modem status when writing. If the wireless modem does the right things with the COM pins when its busy, the new version should "just work". I'd be curious to know if it does or not. This bootloader doesn't transmit anything back to the PC other than a handful of bytes, so you shouldn't need the fancy pin fiddling on the AVR side. If you give my uploader a try, let me know if it works.

While fixing/porting the uploader, I noticed that is uses clock() to report the time. In ANSI C, clock() is supposed to report the CPU time (not the wall-clock time), but the standard says the implementation should "try" to do this instead of just doing it. Windows and DOS doesn't try very hard and just reports the wall-clock time, though maybe depending on the version it tries more or less hard. Maybe that's responsible for your weird timings b/w SP2 and SP3? Are these confirmed with a stopwatch?

The linux version uses gettimeofday(), which reports the wall-clock time to microseconds, which should always be the same (and probably closer to what is expected for flash timing results).

societyofrobots wrote:

I never got the wireless bootloader working unfortunately . . .

Even with the linux code? That's too bad...
Its really doing all the right things in software, but the modem has to tell it when its busy. Its not up to the AVR either (since its not busy), its really the modem that has to signal that its full/transmitting.

societyofrobots wrote:

As for the timing, using SP3, the timer isn't wrong (by much at least). It really does take much longer to program!

Well, there's no accounting for what the SPs do with COM ports, I guess. It made a huge difference in linux (100x) when I enabled the hardware/OS COM buffers and not forced it to flush each byte as it was written to the port. Can't guess as to how the DOS code does it - complete mystery to me.

There's usually (always?) a hardware buffer in the COM port - usually much smaller than the one in your radio (16 or 32 bytes?). In software, you keep checking the result of write() until it says that it didn't write the byte you sent it. Then you go for a little nap and try again with the same byte. Your radio should act as an extension of this hardware buffer, communicating its status to the COM port with the CTS pin. When its transmitting, the COM writes will fail for a while, causing a bunch of little naps until the radio is ready again.
There's also a buffer-drain command, which results in the hardware COM buffer being drained into the AVR (i.e. buffer drain == transmit everything in the buffer). This has to be done before the AVR sends back an "acknowledge". I don't know how the radio would know that you just drained the hardware COM buffer, signaling it to drain its own buffer. This could be a problem.

The only way around this may be for the radio to not use a buffer at all, and instead of putting together bytes into a "packet", use single-byte packets. That's the packet size RS232 is designed around, but it may not be practical to do it this way in a radio...

[pomprocker]

Hey all, I've been busy with college and life and all that so I had put down robotics for a while. I'll be graduating with a BS in comp sci this year and hope to pick back up on robotics after that!

Anyway, whats the latest on this topic??

[Admin]

I haven't reattempted it myself, but others have still expressed interest.

But I've been thinking about it a lot, and I really think the watchdog timer is key. A wireless command can enable it, it'll cause a restart, and in that window we can use the bootloader wirelessly. The new code will have to disable the watchdog timer on startup, I believe. All theory, of course . . .

[Pratheek]

This worked for me - http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=122.

[pomprocker]

Oh, I never told you guys I got it working with sparkfun's tutorial??

http://pomprocker.blogspot.com/2009/02/robot-firmware-over-air.html