go away spammer

Author Topic: wireless programming  (Read 14842 times)

0 Members and 1 Guest are viewing this topic.

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
wireless programming
« on: April 15, 2008, 10:16:39 AM »
I'm just thinking ahead here, but I am interested in getting the BlueSMiRF BT device from sparkfun.

I can't picture though how you would reprogram your robot on the go. I know with the bootloader on the ATmega8 that you have to manually power cycle it for it to get to the bootloader address on reset.

How would you do that while your robot is on the go?
« Last Edit: July 29, 2008, 12:06:14 PM by pomprocker »

Offline Ro-Bot-X

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,431
  • Helpful? 25
  • Store: RoBotXDesigns.ca
    • Ro-Bot-X Designs
Re: wireless reprogramming?
« Reply #1 on: April 15, 2008, 12:28:39 PM »
The new BlueSmirf modules from Sparkfun have 6 pins (instead of just 4): Vcc, GND, Tx, Rx, RTS, DTR. You may use the DTR pin to reset your atmega to enter the bootloader.
Check out the uBotino robot controller!

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #2 on: April 15, 2008, 01:29:39 PM »
ehhh I'm not really sure how to go about doing that. Do you know of a link to a good walkthrough article on setting that up. I need to be babied here in my newb status

Offline Trumpkin

  • Supreme Robot
  • *****
  • Posts: 1,176
  • Helpful? 5
Re: wireless reprogramming?
« Reply #3 on: April 15, 2008, 03:11:57 PM »
Robots are awesome!

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #4 on: April 15, 2008, 03:24:42 PM »
meh, didn't see anything about DTR

Offline Ro-Bot-X

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,431
  • Helpful? 25
  • Store: RoBotXDesigns.ca
    • Ro-Bot-X Designs
Re: wireless reprogramming?
« Reply #5 on: April 16, 2008, 12:44:58 AM »
Of ourse you didn't see anything about DTR on the Lynxmotion website. It shows only serial connection on Bluetooth. What you need is Bluetooth bootloading.

Some bootloaders wait a few seconds at microcontroller power on (or reset) to reprogram the chip, then the allready loaded program starts working.
Some bootloaders will need a pin to be low at start to reprogram the chip.
Some bootloaders will need the reset to be triggered to reprogram the chip.

The last 2 cases you can use with the DTR pin from the Bluetooth module. But the loader software has to know to use that pin. The last type is exactly what Arduino does for the USB and Bluetooth modules, and I believe they are using avrdude loader with stk500 serial programmer.

This is all I know so far. Check how Admin's bootloader works. Perhaps there is a serial (standard) command to pull low the DTR pin for a few milisecs, triggering a reset on the board so the bootloader kiks in and you will be able to upload a new program. Add that command before the avrdude command and you're set.
Check out the uBotino robot controller!

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #6 on: April 18, 2008, 11:07:33 AM »
I found a description of someone doing it on an arduino board with an atmega8.

Quote
they added a capacitor between the USB-serial chip’s DTR line (active-low) and the microcontroller’s reset line, so that the host computer can trigger DTR and pull down the reset for a moment, relieving you of pressing the button.

Quote
with just a 0.1uF (100 nano-farad) capacitor and a soldering iron.

Quote
The retrofitting process consists on soldering a 0.1uF disc capacitor between the DTR pin and the Reset signal. The reset signal is available in several points of the PCB, but the most accesible one is in the ICSP header (pin #5).

So I guess you would



get a 22awg hookup wire and put one of those molex c-grid .100 housing connectors on one end
plug that into the DTR header on your breakout board
solder the capacitor to the end of the hookup wire
solder more hookup wire to the other end of the capacitor
heat shrink that area
then put another molex connector on the end of it
and plug it into the reset pin on your programmer headers on the $50 robot board.


but now how do you bring that reset pin low?

Can we recompile the fast tiny & mega bootloader to do this for us?

this is just me thinking this out. I haven't done any of this yet.
« Last Edit: April 18, 2008, 11:08:47 AM by pomprocker »

Offline Ro-Bot-X

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,431
  • Helpful? 25
  • Store: RoBotXDesigns.ca
    • Ro-Bot-X Designs
Re: wireless reprogramming?
« Reply #7 on: April 18, 2008, 01:16:45 PM »
I found a description of someone doing it on an arduino board with an atmega8.

Quote
... so that the host computer can trigger DTR and pull down the reset for a moment, relieving you of pressing the button.

but now how do you bring that reset pin low?

Can we recompile the fast tiny & mega bootloader to do this for us?

As you can see in the above quote, the answer to your question is allready there. The loader does the reset. The loader being AVRDUDE, PONYPROG...

I dodn't look closely to the fast tiny &mega bootloader, but if it waits for a even a fraction of a second to enter bootloading after a reset, it will work. If it waits for a different pin to be pulled low, then you need to tie the capacitor to that pin.

For instance, I have a small (128 words) bootloader that works with a different loader and enters bootloading mode by holding low PinC.1. I have changed it to work with PinC.6 (reset pin) but I had to change the fuse to make the reset pin a regular I/O pin. But this renders the mega8 unprogrammable by a regular programmer. Only a High Voltage programmer will be able to reprogram the chip to erase the bootloader. Usually this would not be a problem, since the use of the bootloader was necesary and there would be no need for a regular programmer, but I had the darn bad luck to corrupt the bootloader. And now the chip is useless. How did it happen? Well, I was using the bootloader to reprogram the chip and I accidentaly touched the power wire and the power LED flickered (that means the power was interrupted for a fraction of a second...). So beware, NEVER change the function of the Reset pin! Right now a new ATmega8 is cheaper than buying a High Voltage programmer, but after a few burnt chips I will consider buying one...
Check out the uBotino robot controller!

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #8 on: April 18, 2008, 02:19:27 PM »
WinAVR, PonyProg, AVRdude, and Hyperterminal can't send a file directly to the fast tiny & mega bootloader. It is done through the cmd prompt using fboot.exe.

Offline Ro-Bot-X

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,431
  • Helpful? 25
  • Store: RoBotXDesigns.ca
    • Ro-Bot-X Designs
Re: wireless reprogramming?
« Reply #9 on: April 18, 2008, 05:36:28 PM »
Indeed. I have looked at the Bootloader tutorial and it seems that once loaded into the chip, the bootloader enters bootloading mode for a little time at reset or power on (maybe it is giving out a signal on the serial connection). The fboot.exe is monitoriseing the serial port and when proper data is received it starts to download the new code to the chip. The fboot.exe may not send a active low DTR signal to reset the chip to be able to enter bootloading mode. It has to be determined through tests.

However, I get the impression that this bootloader is the same 1024 words size like the one Arduino uses. And Arduino's bootloader IS compatible with DTR resetting (through AVRdude). So the easiest way to determine it it is really working is to do it yourself. I have rendered my 2 atmegas worthless so I will not be able to do it myself soon.
Check out the uBotino robot controller!

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #10 on: April 22, 2008, 04:18:29 PM »
The new BlueSmirf modules from Sparkfun have 6 pins (instead of just 4): Vcc, GND, Tx, Rx, RTS, DTR. You may use the DTR pin to reset your atmega to enter the bootloader.

The 6 pin BlueSMiRF module has CTS-I, PWR, GND, TX-O, RX-I, and RTS-O

No DTR  ???

Would this same technique work through the RTS out?

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #11 on: April 23, 2008, 12:46:03 PM »
Would this be anything?

http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_softreset


Here is another good link.

http://support.atmel.no/bin/customer?custSessionKey=&customerLang=en&action=viewKbEntry&id=21

But again...There needs to be a function to disable the WDT. and This does not answer my question: does the software reset go into the bootloader address?
« Last Edit: April 28, 2008, 12:44:29 PM by pomprocker »

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
Re: wireless reprogramming?
« Reply #12 on: April 26, 2008, 06:12:00 PM »
Yeap, turning on the WDT would reset it in software. You'd have to send a command through serial to your ATmega to turn it on, then do your bootloader asap. Hmmmm might have a comport conflict . . .

Let me know your progress, I need this to work for my ERP, but don't have time to look into it . . .

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #13 on: April 27, 2008, 12:50:21 PM »
Here is a detailed description of someone doing it with XBee, an Atmega8, a transistor, and some code.


http://itp.nyu.edu/~raf275/meshnetworking/XBee/XBee_program_Arduino_wireless.html



Again, I just don't get electronics sometimes. Could someone tell me if I should use a 2N2222A transistor for the $50 robot board? Radio Shack only has 2N2222 transistors, whats the difference between that and A?

ugh, I wish electronics would just click into place in my mind already.
« Last Edit: April 27, 2008, 02:25:03 PM by pomprocker »

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #14 on: April 27, 2008, 06:44:15 PM »
whats opposite of rprintf so the ATmega8 can receive letters you type into hyperterminal?

paulstreats

  • Guest
Re: wireless reprogramming?
« Reply #15 on: April 28, 2008, 02:55:55 AM »
the getC() function usually does it. So:

char mychar = getC();

usually you have this inside of an interrupt on uart receive function so the microcontroller breaks out of its normal program when a char is sent to it otherwise it wouldnt know when there is a character available in the buffer

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #16 on: April 28, 2008, 09:51:51 AM »
Can you explain a little more?


I want the letter 'r' or some keyword to go into this function that enables the watchdog timer which resets the mcu after a delay of about 5 seconds or so.


If you look in the uart.h that Admin provides with his $50 robot code, you will see there is a function for receiving. I am just not sure how to implement it correctly.

« Last Edit: April 28, 2008, 10:56:11 AM by pomprocker »

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #17 on: April 28, 2008, 11:02:54 AM »
Yeap, turning on the WDT would reset it in software. You'd have to send a command through serial to your ATmega to turn it on, then do your bootloader asap. Hmmmm might have a comport conflict . . .

Let me know your progress, I need this to work for my ERP, but don't have time to look into it . . .


Since there are apparantly four ways to get an MCU to reset. I am going to try the one that does not require any extra hardware first.

The WDT reset:

I have done it to where i've gotten the mcu to reset over and over again with the WDT. I haven't quite figured out how to make it only reset once. But turning on the robot and then kicking off fboot.exe doesn't do it. The soft reset does not signal fboot.exe. So I don't think a soft boot is getting it to go to the bootloader address.


The other two ways I can think of is wiring a transistor/mosfet between the reset pin, ground, and some other output pin on the mcu. the second way is some kinda of wire with a small cap coming off of the bluetooth/zigbee/easy radio module DTR/RTS line going to the reset pin to pull it low.
« Last Edit: April 28, 2008, 11:06:14 AM by pomprocker »

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #18 on: May 03, 2008, 02:43:46 AM »
Finally, some results. I got it working with ATmega8, fast tiny & mega bootloader, sparkfun Breakout Board for CP2103 USB to Serial w/ GPIOs, and hyperterminal, and the watchdog timer!

first upload this code with your traditional uart bootload procedure



What you do is you get the command ready to hit enter in the command prompt:
fboot.exe -b57600 -c3 -puart_fun.hex -vuart_fun.hex

then go into hyperterminal and connect.
hold down the 'r' key for about two seconds on the hyperterminal clock
then you have approx. 3-4 seconds to disconnect from hyperterminal, go over to the command prompt and hit enter.


50_robot_sharpIR.c
Code: [Select]
//SoR Include
#include "SoR_Utils.h" //includes all the technical stuff


//global variables
char myReceivedByte;
int sharp_IR_reading=0;
int sensor_left=0;
int sensor_right=0;
int photo_thresh=8;

int scan_thresh=0;//threshold value of scanning sensor

int scan_angle=240;//position of scanner, in units of servo command -> 30 * 8
int max_scan_angle=448;//maximum position scanner can rotate to (57) -> 56 * 8


//this function causes scanning servo to center on edge of object
void scan(void)
{
//lower (-) goes right
//higher (+) goes left
//30 far right, 50 straight, 56 far left (until it jams)

/*psuedocode
object is detected
scan right object detected
object not detected
scan left until object detected*/

sharp_IR_reading=a2dConvert8bit(3);
    sensor_left=a2dConvert8bit(5);
sensor_right=a2dConvert8bit(4);
    rprintf( "Scanner: %d, \tAngle: %d, \tL Photo: %d, \tR Photo: %d\r\n",
          sharp_IR_reading, scan_angle, sensor_left, sensor_right );
   

if (sharp_IR_reading > scan_thresh)//object detected
{
if (scan_angle>328) //overflow protection -> 41 * 8
scan_angle-=16;//scan right -> 2 * 8?
}
else //object not detected
{
if (scan_angle<=max_scan_angle) //maximum servo angle
scan_angle+=16; //scan left -> 2* 8?
else //if scanned all the way, this forces it to start over
scan_angle=240;    // 30 * 8
}

//servo scan code
servo_scan(scan_angle);
}


//automatically calculates threshold value before run
void autocalibrate(void)
{
scan_thresh=a2dConvert8bit(3);//sensor reading
}

int main(void)
{
//LED_on();

initialize();

delay_cycles(336000);//two second wait delay -> 42000 * 8

/*********ADD YOUR CODE BELOW THIS LINE **********/

//find thresholds
autocalibrate();

//LED_off();


while(1)
{




scan();

        //Object Avoider
    if (sharp_IR_reading > scan_thresh)

robot_turn_right();


//object is centered
else
robot_go_straight();
         
        /*

    object chaser
//object on left
if(scan_angle > 456)     // 57 * 8
robot_turn_left();

//object on right
else if(scan_angle < 328)    // 41 * 8
robot_turn_right();

//object is centered
else
robot_go_straight();

         */



if (uartReceiveByte(&myReceivedByte))
{
    // if there are bytes waiting on the serial port
    char inByte = uartGetByte(); // read a byte
    if (inByte == 'r')
    {
    //if that byte is the desired character
        //int len = 5; // expected string is 6 bytes long
        //char inString[len]; // declare string variable
        //for (int i = 0; i < len; i++)
        //{
        //    inString[i] = uartGetByte();
        //}
        //if ( strstr(inString, "reset") != -1 ) // check to see if the respose is "reset"
              resetChip(5000); // reset the chip after waiting for the specified # of milliseconds
    } // end if
}  // end if
 



delay_cycles(3200);//a small delay to prevent crazy oscillations -> 400 * 8
}  // end while loop
/*********ADD YOUR CODE ABOVE THIS LINE **********/

return 0;
}   // end main


SoR_Utils.h
Code: [Select]
//AVR includes
#include <avr/io.h>     // include I/O definitions (port names, pin names, etc)
#include <avr/interrupt.h> // include interrupt support
#include <avr/wdt.h>        // include watchdog timer

//AVRlib includes
#include "global.h" // include global settings
#include "buffer.h" // include buffer function library
#include "uart.h" // include uart function library
#include "rprintf.h" // include printf function library
//#include "timer.h" // include timer function library (timing, PWM, etc)
#include "a2d.h" // include A/D converter function library


// For newer AVRs such as ATmega1281
// Function Pototype
int MCUSR;
void wdt_init(void) __attribute__((naked)) __attribute__((section(".init3")));

// Function Implementation
void wdt_init(void)
{
    MCUSR = 0;
    wdt_disable();

    return;
}




//define port functions; example: PORT_ON( PORTD, 6);
#define PORT_ON( port_letter, number ) port_letter |= (1<<number)
#define PORT_OFF( port_letter, number ) port_letter &= ~(1<<number)
#define PORT_ALL_ON( port_letter, number ) port_letter |= (number)
#define PORT_ALL_OFF( port_letter, number ) port_letter &= ~(number)
#define FLIP_PORT( port_letter, number ) port_letter ^= (1<<number)
#define PORT_IS_ON( port_letter, number ) ( port_letter & (1<<number) )
#define PORT_IS_OFF( port_letter, number ) !( port_letter & (1<<number) )
#define soft_reset()        \
do                          \
{                           \
    wdt_enable(WDTO_15MS);  \
    for(;;)                 \
    {                       \
    }                       \
} while(0)








//************CONFIGURE PORTS************
//configure ports for input or output - specific to ATmega8
void configure_ports(void)
{
DDRC = 0x00;  //configure all C ports for input
PORTC = 0x00; //make sure pull-up resistors are turned off
DDRD = 0xFF;  //configure all D ports for output
rprintf( "\n\n\t\t\tPorts Configured.\n\n" );
}
//***************************************

//************DELAY FUNCTIONS************
//wait for X amount of cycles (23 cycles is about .992 milliseconds)
//to calculate: 23/.992*(time in milliseconds) = number of cycles
//or (number of cycles)*.992/23 = time in milliseconds
void delay_cycles(unsigned long int cycles)
{
while(cycles > 0)
cycles--;
}
//***************************************

//*********SIMPLIFIED FUNCTIONS**********
//functions to make coding easier for a beginner
//but could cause port mixup confusion for intermediate users
void LED_on(void)
{
PORT_OFF(PORTD, 4);//turn LED on
}
void LED_off(void)
{
PORT_ON(PORTD, 4);//turn LED off
}
void servo_left(signed long int speed)
{
PORT_ON(PORTD, 2);
delay_cycles(speed);
PORT_OFF(PORTD, 2);//keep off
delay_cycles(1600); // 200 * 8
}
void servo_right(signed long int speed)
{
PORT_ON(PORTD, 3);
delay_cycles(speed);
PORT_OFF(PORTD, 3);//keep off
delay_cycles(1600); // 200 * 8
}
void servo_scan(signed long int speed)
{
PORT_ON(PORTD, 4);
delay_cycles(speed);
PORT_OFF(PORTD, 4);//keep off
delay_cycles(1600); // 200 * 8
}
void robot_turn_left(void)
{
servo_left(200); // 25 * 8
servo_right(200); // 25 * 8
}
void robot_turn_right(void)
{
servo_left(352); // 44 * 8
servo_right(352); // 44 * 8
}
void robot_go_straight(void)
{
servo_left(200); // 25 * 8
servo_right(352); // 44 * 8
}
void hold_position(void)//37
{
servo_left(312);//39 * 8
servo_right(280);//35 * 8
}
//***************************************

//*************INITIALIZATIONS***********
void initialize(void)
{
//other stuff Im experimenting with for SoR
uartInit();  // initialize the UART (serial port)
uartSetBaudRate(57600);// set the baud rate of the UART for our debug/reporting output
rprintfInit(uartSendByte);// initialize rprintf system


//timerInit(); // initialize the timer system

configure_ports(); // configure which ports are analog, digital, etc.
a2dInit(); // initialize analog to digital converter (ADC)
a2dSetPrescaler(ADC_PRESCALE_DIV32); // configure ADC scaling
a2dSetReference(ADC_REFERENCE_AVCC); // configure ADC reference voltage

rprintf("\t\t\tInitialization Complete\n\n");
}
//****************************************


void resetChip(int delayTime) {
   /* if the project does not typically receive data, and accidental chip resets are tolerable,
   * this is a simple method that should work just fine. Otherwise it is recommended that the
   * reset request string be part of a call-response sequence, be transmitted with a
   * reserved byte or byte string, or be transmitted in some way out of band, so that it is not
   * accidentally received.
   */
   
   rprintf("\nMCU will reset in ");
   rprintf("%d milliseconds...\n\r", (int)((delayTime *.992)/184));
   delay_cycles(delayTime); // wait for the specified amount of time, doing nothing
   rprintf("\nResetting NOW.\n\r");
   soft_reset(); // reset macro
}



next move is to get the BlueSMiRF and try this truly wireless!!






Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless reprogramming?
« Reply #19 on: June 05, 2008, 04:31:43 PM »
Now trying this with the blueSMiRF, my bluetooth connection is lost in between disconnecting hyperterminal and connecting with the FTM uart bootloader. anyone have any ideas on maintaining the bluetooth connection?

also does anyone know why the BlueSMiRF has two com ports? (incoming, outgoing), and how that can be utilized?

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #20 on: July 29, 2008, 12:08:09 PM »
So on the fast tiny & mega bootloader, the bootloader needs to receive the 'keyword' within 0.3 seconds or it starts the application.

I need to speed up the connection process of the BlueSMiRF, so I created a jumper cable for RTS/CTS last night, I will try that, I will also try lengthening the countdown for the watch dog timer that will give me more time to switch over to fboot.exe


Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #21 on: December 01, 2008, 07:01:48 PM »
Would there be a way to transmit the hex file to some sort of non-volatile memory onboard the robot, and then once the hex file is stored, have the robot reboot the MCU and read the new hex from the memory?

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
Re: wireless programming
« Reply #22 on: December 04, 2008, 12:31:22 AM »
It's been a long time since I've been able to come back to this . . .

Quote
So on the fast tiny & mega bootloader, the bootloader needs to receive the 'keyword' within 0.3 seconds or it starts the application.
You can change that timer amount to anything you want easily in the bootloader code. I can even do it for you if you want.

Quote
Would there be a way to transmit the hex file to some sort of non-volatile memory onboard the robot, and then once the hex file is stored, have the robot reboot the MCU and read the new hex from the memory?
Hmmmm I don't quite understand your question . . . you mean use the bootloader in the bootloader section to upload a program into EEPROM to be later uploaded into Flash?

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #23 on: December 04, 2008, 01:01:21 AM »
It seems like once the MCU is reset, theres not enough time to re-establish an RF connection in able to push the the new hex file to the bootloader. If there was a way to transmit the new hex to the robot prior to a reset and store it on an eeprom. Then you can reset the MCU remotely and tell the bootloader to expect the hex from the eeprom? therefore there is no delay.

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #24 on: December 04, 2008, 01:03:38 AM »
I don't have an O-scope, but would that be like your x-ray glasses to be able to see whats going on during this process to find out why the bootloader isnt gettting the data stream

Offline Admin

  • Administrator
  • Supreme Robot
  • *****
  • Posts: 11,703
  • Helpful? 173
    • Society of Robots
Re: wireless programming
« Reply #25 on: December 04, 2008, 04:15:27 AM »
Quote
It seems like once the MCU is reset, theres not enough time to re-establish an RF connection in able to push the the new hex file to the bootloader.
Are you also resetting the bluetooth connection? Keep it on a separate power bus with only ground being shared. In theory, once its connected, it wouldn't matter if the mcu is reset or not.

Quote
I don't have an O-scope, but would that be like your x-ray glasses to be able to see whats going on during this process to find out why the bootloader isnt gettting the data stream
I think what you need is a hardware debugger, like JTAG . . . they are a bit expensive though . . .

Quote
If there was a way to transmit the new hex to the robot prior to a reset and store it on an eeprom.
The latest Axon bootloader v2.1 can load into EEPROM, although I haven't tried it myself. The author didn't say how, just that it can . . .

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #26 on: December 18, 2008, 07:02:20 PM »
I am thinking about going with an XBee setup for this since it can connect faster:

Quote
ZigBee is broadly categorized as a low rate WPAN, and its closest technology is Bluetooth.  A good bit of energy has been spent in analyzing whether ZigBee and Bluetooth are complementary or competing technologies, but after a quick look at the two, it can be seen that they fall a lot farther down the complementary side of the spectrum.  They are two different technologies with very different areas of application and different means of designing for those applications.  While ZigBee is focused on control and automation, Bluetooth is focused on connectivity between laptops, PDA’s, and the like, as well as more general cable replacement.  ZigBee uses low data rate, low power consumption, and works with small packet devices; Bluetooth uses a higher data rate, higher power consumption, and works with large packet devices.  ZigBee networks can support a larger number of devices and a longer range between devices than Bluetooth.  Because of these differences, the technologies are not only geared toward different applications, they don't have the capability to extend out to other applications.  As an example, for its applications, Bluetooth must rely on fairly frequent battery recharging, while the whole goal of ZigBee is for a user to be able to put a couple of batteries in the devices and forget about them for months to years.  In timing critical applications, ZigBee is designed to respond quickly, while Bluetooth takes much longer and could be detrimental to the application.  Thus, a user could easily use both technologies as a wireless solution in a PAN to suit all types of applications within that network. 

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #27 on: December 22, 2008, 03:57:34 AM »
I've ordered 2 - Xbee modules (chip antenna ACI-001) from Mouser, and 2 - Xbee adapters from ladyada (Adafruit Industries)

I'm going to try it out with my new Roboduino.

Offline pomprockerTopic starter

  • Supreme Robot
  • *****
  • Posts: 1,431
  • Helpful? 16
  • Sorry miss, I was giving myself an oil-job.
    • Nerdcore - Programming, Electronics, Mechanics
Re: wireless programming
« Reply #28 on: December 31, 2008, 04:43:59 AM »
You know I got the Xbees and tried it, but after reading more, people can't seem to wirelessly program more than a blinky LED program, any more than that and it doesnt work.

This got me thinking about buffers, and then realizing this sort of thing happens all the time with mobile phones, Its called FOTA or Firmware Over the Air. In reading more about FOTA, there is a huge infrastructure behind it, and to make it more efficient, the current version and previous version of the firmware are "diffed" and only the diff code is transmitted, and somehow the target is able to add the new code in order to make its older version current.

This would handle the problem of transmitting too large of files, but I really don't know how to do this. This wireless programming thing is a whole ball game in itself. It would take an expert in wireless communications to help figure this out.

Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: wireless programming
« Reply #29 on: December 31, 2008, 01:47:47 PM »
so any wireless transceiver only has a set buffer size before it must pause while the radios send information the other way.
there's no easy way round this. you'll just have to modify a bootloader to take into account the buffer size on the transceiver you are using.
it should not be too hard though. do the XBee's have a DTR pin (Data Terminal Ready) or anything like that? if they do just pause the bootloader when the the DTR pin is clear.


dunk.

 


Get Your Ad Here

data_list