Society of Robots - Robot Forum
Software => Software => Topic started by: kl22 on April 14, 2011, 01:56:04 AM
-
UPDATE:
The programmer for the Axon has now been released. It is in beta so please feel free to contact me or leave a message here regarding any bugs or suggestions.
You can find it here http://www.yetasoft.com/products/mcuber/ (http://www.yetasoft.com/products/mcuber/).
It is called McUber.
So far I have only released the Windows version. And it has been tested on Windows 7 x64. But it also works for the x86 (32bit) versions.
------------------------------
Hi everyone!
Good news! I finally got around to finishing the development for a 64bit flasher for the Axon (not Axon exclusive, but anything that uses the same bootloader).
It's been done in Java, so cross-platform will not be an issue. I will be releasing Windows version first, then Linux and Mac. Currently works in x86 (32bit) and x64 (64bit) Windows OS (tested on Windows 7 and Vista). Seems a little slow, probably because of Java, and haven't optimized the code yet.
The application has been developed so that I can provide some interface so that other MCUs/bootloaders can be added to it without affecting the overall application. So we can have an "all-in-one" flasher. I'll set up an SVN somewhere to get this open-source community going.
Also, I wanted to know you want/would like to see included with this app. My original design included a terminal (with some extra user-definable hotkeys), and the programmer. This allowed for automatic switching to the terminal once the programming was complete. Would you guys like to have this included before I release the first version?
Anyways, let me know what else you would like to see.
-
Awesome! :D
This allowed for automatic switching to the terminal once the programming was complete. Would you guys like to have this included before I release the first version?
Find some volunteers to play with the beta you have, while you work on the terminal. I think the terminal idea is a really nice touch. You'll need an option to save terminal data to a .txt in order to compete with Hyperterminal, though :P
Keep me updated here.
-
Terminal it is then!
Good idea with saving to txt is a really good idea. Any format you guys want it in? Maybe a csv?
-
AT LAST. I've been waiting for this for a long time! Thank you very much.
The terminal thing is a very good idea because of the paine to switch on and off the terminal program every time we flash and because ppl the majority of people using x64 are using 7 and it doesn't have HT.
-
Good idea with saving to txt is a really good idea. Any format you guys want it in? Maybe a csv?
optional is best, but txt is fine for anything really so no big deal
(Hyperterminal lets me do it in whatever format I want)
Currently, how long does it take to upload a program with the bootloader?
-
Thanks for the support & enthusiasm Dothos!
I haven't timed it yet, but it takes approximately 1min. I should be able to bring it down to less than 10s.
-
One thing you may want to add to your terminal which Hyperterminal is not good at, but others are, is displaying values outside the familiar 0x20 to 0x7f range ie control chars like carriage return and line feed, or Ack and Nak
Other terminal progs use a special font to show these in a human readable form - or alternatively allow stuff to be shown in pure ascii (like Hyperterminal) or in hex (so a spave is 0x20) or both.
Makes life much easier when using devices that use binary data vs just string data.
Suggest you look at other progs like RealTerm and Tera Term for ideas.
ie record input to file, play file to output, and perhaps Xmodem type file transfers (but I've only needed that when doing things like flashing the Blackfin so low priority), but also terminal emulation (eg VT100 is easy).
The world is your oyster !
Having said that - I think it would be good to release the programmer first (since that's your key differentiator) and should be the top of your support list (IMHO) as you don't want to become too bogged down in creating a professional terminal prog!
-
Hey webbot,
Thanks for the great input. I agree with you about releasing the flashed first. I think I'll get that finalized first.
I'll get that out hopefully by late next week.
Btw great job on webbotlib!!!!
-
Something I'd love to see added to the terminal functionality is redirecting of the serial port. For example receiving data on one serial port, displaying the data, and redirecting it as output to another serial port or TCP/IP. Something like this:
http://www.serialporttool.com/CommTunnel.htm (http://www.serialporttool.com/CommTunnel.htm)
-
Hi Knossos,
Thanks for the input.
Just to get clarified on what it does: So if I have incoming data on a serial port it is pretty much relaying the data to another port so that something else can listen in?
This seems very doable, unless I have some software on the same PC wanting to listen to the port that gets relayed to. I think I would have to do some kind of code that doesn't restrict usage to the same port for other application. Something like a serial sniffer + relay the info.
I'll see what I can do, give me a day or two to do some research and I'll get back to you :D
-
ie record input to file, play file to output, and perhaps Xmodem type file transfers (but I've only needed that when doing things like flashing the Blackfin so low priority), but also terminal emulation (eg VT100 is easy).
Could you give me more information on terminal emulation?
What is it? What does it? How does it work? (don't need anything in great detail, just an outline so I know what to look for in my research)
-
ie record input to file, play file to output, and perhaps Xmodem type file transfers (but I've only needed that when doing things like flashing the Blackfin so low priority), but also terminal emulation (eg VT100 is easy).
Could you give me more information on terminal emulation?
What is it? What does it? How does it work? (don't need anything in great detail, just an outline so I know what to look for in my research)
See http://en.wikipedia.org/wiki/Terminal_emulator (http://en.wikipedia.org/wiki/Terminal_emulator)
It stems from the days when everything was text based and you could plug a serial terminal (screen) into a big computer. So the computer needs to be able to control the current cursor position on the screen so that, say, the current time is always printed at the top right of the screen.
These 'control' commands generally start with an 'Escape character' (Hex 0x1B). But also cover things like 'clear the screen'.
-
I haven't timed it yet, but it takes approximately 1min. I should be able to bring it down to less than 10s.
Yea, 1 min is definitely too long. SP3 causes the current bootloader to take ~40s on the Axon, and SP2 I think was ~5s if I remember right. A hardware programmer is like ~3s.
-
Thanks Webbot& Admin.
Webbot: I'll look into it asap, never used it before so might be a small hurdle. But as you mentioned I think I'll do something like that for v3 or so.
Admin: yea it is way too long. Looking to optimize the code now, and removing all the delays I intentionally introduced for testing and debugging.
I'll keep you posted on when I release the beta
-
Hey Admin!
Good news!!! Initially the flasher averaged ~61000ms, but now I got it to around to average around ~3500ms for a hex file of size 43,748bytes (system file size).
-
I was wondering if there is any other bootloader that anyone wants supported on release.
FYI, the flasher is set up so the code for flashing other bootloaders can be added. Currently I only have AxonII (does axonI use the same bootloader?)
Is there a specific name for the bootloader that AxonII uses?
-
When are you going to realease the flasher? I could really use it right now :p tired of using an old pc just for the flashing...
-
Projected date is April 19th! (Today!!) or latest April 20th (depending how soon I can get test on linux/mac).
I might release before I even test on linux/mac. Check back here tomorrow (April 19th) at 6pm.
EDIT: Releasing Beta April 20th, should be available sometime after 6-7PM EST.
-
The programmer for the Axon has now been released. It is in beta so please feel free to contact me or leave a message here regarding any bugs or suggestions.
You can find it here http://www.yetasoft.com/products/mcuber/ (http://www.yetasoft.com/products/mcuber/).
It is called McUber.
So far I have only released the Windows version. And it has been tested on Windows 7 x64. But it also works for the x86 (32bit) versions.
-
So anyone tried it yet? I'm stuck in connecting for a long time...
-
Hi,
Could you give a little bit more detail? Sets you took?
Btw, the programmer works the same way that the old one does, after it says connecting, you need to power cycle the Axon.
-
Ahh that may be my problem.....but how long does it take to finish it?
-
Oh 2 systems that I tested it, it takes approx 3-4s from after connecting.
You might have to Goto the task manager to close it. I just realized that I forgot to implement the code for the stop button :) (end process to java.exe/javaw.exe)
I will fix the stop button tonight.
-
I don't know what I'm dong wrong but I'm still stuck in connecting. I pick the com port, use 115k baud rate and pick my file. With power off I clicked program then cycle power to on then nothing happened.
-
Oh that is the problem. The Axon bootloader is set up so you can only flash on 57k.
-
Works good for me on Vista x32, haven't tried it on any of my other computers yet. Flashing takes about 3 seconds which is pretty good.
The com port detection is a little slow (about 7-8 seconds) but thats only when you open the program.
Any chance of getting it to save last configuration (com port, baud rate, path to .hex file) and skipping com port auto detection when using saved config?
Great job so far!!
-
Hi knossos,
Thanks for all the positive feedback.
I have already implemented saving of the last configuration in the post-data release. But good idea on skipping COM detection on loading saved config. Ill also implement a refresh button that you can use to manually reset The COM port list. Thanks for pointing that out. I have also included the functionality for the stop button.
The 7-8 second delay when retrieving the COM ports is most likely caused by the bluetooth stack (SPP). I will try to figure out a work around for the bluetooth stack problem.
-
The 7-8 second delay when retrieving the COM ports is most likely caused by the bluetooth stack (SPP). I will try to figure out a work around for the bluetooth stack problem.
Did you just say it can do wireless bootloading? :o
-
Yep,
You should be able to assuming you get the Bluetooth on before you do a power cycle (since power cycling when using the axon as a power source will disconnect the bluetooth from the pc)
-
Yep,
You should be able to assuming you get the Bluetooth on before you do a power cycle (since power cycling when using the axon as a power source will disconnect the bluetooth from the pc)
Thats ok, because on the Axon you can send a wireless command to activate the watchdog timer which will cause a reset. :P
-
Oh no way. Please instruct me on so I can implement it..:)
-
In the users program (outside the bootloader), you need to first have this somewhere:
//turns off watchdog timer after reset
uint8_t mcusr_mirror __attribute__ ((section (".noinit")));
void disable_watchdog(void) \
__attribute__((naked)) \
__attribute__((section(".init3")));
void disable_watchdog(void)
{
mcusr_mirror = MCUSR;
MCUSR = 0;
wdt_disable();
}
Then to actually activate the reset, you need this in your user program:
if(uartGetByte(wireless_UART)='r')//the character 'r' is received
wdt_enable(WDTO_250MS);//reset microcontroller
The trick however would be to get your bootloader software on the PC to send that 'r' command and run the bootloader right after with perfect timing.
-
Hey Admin,
Thanks admin! Thanks for the quick reply. Hard for me to do anything outside of the bootloader, but this might be a possible solution:
can we somehow standardize the code for bluetooth programming. So that we can do something like this:
User always implements a certain method (the one you mentioned)
public void checkBluetoothForProgramming() {
if(uartGetByte(wireless_UART)='Peta' + 0xff + 'bt')//the character 'r' is received
wdt_enable(WDTO_250MS);//reset microcontroller
printf('Peta' + 0xff + 'reply'); //not correct, but just put here to give you an idea
}
}
Maybe Webbot can implement this into his loop, in the future?
Also, instead of just 'r', something more non-generic similar to what the bootloader uses already 'Peta' + 0xff + 'bt', this way we can give users a specific code they need to check for when using bluetooth to program.Also, this method should also include some kind of special reply that would be something along the lines of 'Peta' + 0xff + 'replied', to notify my application that reset has been initiated. This would allow my app to switch to the programming mode. I'll dev something up and send it to Webbot for approval for implementation into his library.
(Note the check strings that can altered to any predefined strings)
This should be a temporary fix until the time comes when I decide to dev a new bootloader.
-
looks ok to me!
-
Any updates on this?