Get the SoR Robotics Android App on Android Market for FREE. See this forum post for details.
0 Members and 1 Guest are viewing this topic.
I've been featured in this month's Servo magazine on page 16...LOL
Quote from: pomprocker on January 30, 2009, 11:38:02 PMI've been featured in this month's Servo magazine on page 16...LOL 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 OMGi'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
Here ya go:http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1
Quote from: Ro-Bot-X on January 31, 2009, 07:02:32 AMQuote from: pomprocker on January 30, 2009, 11:38:02 PMI'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=CLLzr9AWKK9a1http://servo.texterity.com/servo/200902/?pg=16&pm=2&u1=friend&sub_id=CLLzr9AWKK9a1
Hi Mr. RobotI 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=1927I'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:QuoteI 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:QuoteAs 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...
I never got the wireless bootloader working unfortunately . . .
As for the timing, using SP3, the timer isn't wrong (by much at least). It really does take much longer to program!