Author Topic: 64bit / 32 bit Axon II bootloader (flasher) NOW AVAILABLE (Read 4734 times)

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/.

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.

Admin · « **Reply #1 on:** April 14, 2011, 09:58:49 AM »

Awesome!

Quote

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

Keep me updated here.

kl22 · « **Reply #2 on:** April 14, 2011, 11:14:58 AM »

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?

Dothos · « **Reply #3 on:** April 14, 2011, 11:27:49 AM »

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.

Admin · « **Reply #4 on:** April 14, 2011, 01:23:40 PM »

Quote from: kl22 on April 14, 2011, 11:14:58 AM

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?

kl22 · « **Reply #5 on:** April 14, 2011, 03:14:09 PM »

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.

Webbot · « **Reply #6 on:** April 14, 2011, 04:06:56 PM »

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!

kl22 · « **Reply #7 on:** April 14, 2011, 05:14:15 PM »

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!!!!

knossos · « **Reply #8 on:** April 14, 2011, 06:00:24 PM »

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

kl22 · « **Reply #9 on:** April 14, 2011, 08:04:50 PM »

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

kl22 · « **Reply #10 on:** April 14, 2011, 08:17:06 PM »

Quote from: Webbot on April 14, 2011, 04:06:56 PM

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)

Webbot · « **Reply #11 on:** April 15, 2011, 12:27:26 PM »

Quote from: kl22 on April 14, 2011, 08:17:06 PM

Quote from: Webbot on April 14, 2011, 04:06:56 PM
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

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'.

Admin · « **Reply #12 on:** April 15, 2011, 01:52:15 PM »

Quote from: kl22 on April 14, 2011, 03:14:09 PM

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.

kl22 · « **Reply #13 on:** April 15, 2011, 05:40:16 PM »

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

kl22 · « **Reply #14 on:** April 16, 2011, 03:19:29 AM »

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).

kl22 · « **Reply #15 on:** April 17, 2011, 08:37:35 PM »

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?

Dothos · « **Reply #16 on:** April 18, 2011, 05:30:39 PM »

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...

kl22 · « **Reply #17 on:** April 18, 2011, 11:59:37 PM »

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.

kl22 · « **Reply #18 on:** April 21, 2011, 01:55:40 AM »

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/.

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.

overdrv373 · « **Reply #19 on:** April 21, 2011, 09:29:14 AM »

So anyone tried it yet? I'm stuck in connecting for a long time...

kl22 · « **Reply #20 on:** April 21, 2011, 10:12:40 AM »

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.

overdrv373 · « **Reply #21 on:** April 21, 2011, 10:27:06 AM »

Ahh that may be my problem.....but how long does it take to finish it?

kl22 · « **Reply #22 on:** April 21, 2011, 10:29:20 AM »

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.

overdrv373 · « **Reply #23 on:** April 21, 2011, 10:45:25 AM »

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.

kl22 · « **Reply #24 on:** April 21, 2011, 10:46:57 AM »

Oh that is the problem. The Axon bootloader is set up so you can only flash on 57k.

knossos · « **Reply #25 on:** April 21, 2011, 07:23:15 PM »

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!!

kl22 · « **Reply #26 on:** April 21, 2011, 07:45:54 PM »

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.

Admin · « **Reply #27 on:** April 23, 2011, 06:12:39 PM »

Quote from: kl22 on April 21, 2011, 07:45:54 PM

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?

kl22 · « **Reply #28 on:** April 23, 2011, 06:15:28 PM »

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)

Admin · « **Reply #29 on:** April 23, 2011, 06:23:09 PM »

Quote from: kl22 on April 23, 2011, 06:15:28 PM

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.

News:

Author Topic: 64bit / 32 bit Axon II bootloader (flasher) NOW AVAILABLE (Read 4734 times)

Related Topics