Society of Robots - Robot Forum
Software => Software => Topic started by: pomprocker 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?
-
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.
-
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
-
Does this help? http://www.lynxmotion.com/images/html/build125.htm
-
meh, didn't see anything about DTR
-
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.
-
I found a description of someone doing it on an arduino board with an atmega8.
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.
with just a 0.1uF (100 nano-farad) capacitor and a soldering iron.
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.
-
I found a description of someone doing it on an arduino board with an atmega8.
... 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...
-
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.
-
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.
-
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?
-
Would this be anything?
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_softreset (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 (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?
-
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 . . .
-
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 (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.
-
whats opposite of rprintf so the ATmega8 can receive letters you type into hyperterminal?
-
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
-
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.
-
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.
-
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
//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
//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!!
-
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?
-
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
-
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?
-
It's been a long time since I've been able to come back to this . . .
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.
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?
-
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.
-
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
-
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.
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 . . .
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 . . .
-
I am thinking about going with an XBee setup for this since it can connect faster:
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.
-
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.
-
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.
-
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.
-
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 . . .
-
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
-
Someone has managed to wirelessly bootload the ATmega168 using Xbee.
tutorial:
http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=122
-
I've been featured in this month's Servo magazine on page 16...LOL :D
-
I've been featured in this month's Servo magazine on page 16...LOL :D
Darn! I just ran out of subscription...
-
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
-
I've been featured in this month's Servo magazine on page 16...LOL :D
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)
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)
-
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 ;D
-
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)
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!
-
do you have to be a member or something for them websites because i can't access them.
-
not that i know of
-
Ladyada's tutorial was just updated to handle larger programs than 1K:
http://www.ladyada.net/make/xbee/arduino.html
-
I've been featured in this month's Servo magazine on page 16...LOL :D
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)
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?
-
I plan on looking into doing it with bluetooth when i get the chance
-
I want to implement wireless access to my robot also.
What do you guys think is a better option between XBee and a BluesSMiRF
-
Well, it's been proven to work with Xbee, not yet proven with BlueSMiRF
-
pomprocker, a guy named iggie01 on avrfreaks (http://www.avrfreaks.net/index.php?name=PNphpBB2&file=profile&mode=viewprofile&u=189470) 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 (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...
-
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??
-
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 . . .
-
This worked for me - http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=122 (http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=122).
-
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 (http://pomprocker.blogspot.com/2009/02/robot-firmware-over-air.html)