Open GoogleCodeExporter opened 8 years ago
[deleted comment]
We hope we sell these soon, too!
Original comment by gru...@gmail.com
on 25 Aug 2011 at 5:55
I've started this in trunk/firmware bootloader.
Jryki pointed me to this ...
http://seili.net/weblog/2010/07/14/avr2boots-dual-bootloader-released/
Dual boot USB&MMC fits to normal bootloader 2k
But it turned out that the USB part is actually just a old fashioned USART
serial, using an external chip. We need to implement a USB stack.
This makes it very, very unlikely that we can fit USB and SD card boot loader
functions into the 4K boot block.
Meanwhile, Jim is doing a great job on a little daughter board of a USBasp USB
programmer, as used by the infamous SmartieParts.com pogo board.
So then, it makes sense to concentrate on MMC/SD card boot-loading for our
onboard system.
This leaves the USB port kind of hanging in the air without a use for now. But
I still have hopes of at least building in an HID mode USB joystick interface
(to the main application code) with all those extra switches we've always
wanted for flying RC flying simulators.
Original comment by gru...@gmail.com
on 8 Oct 2011 at 10:13
Original comment by gru...@gmail.com
on 3 Apr 2012 at 7:01
Not sure is this possible but I throw idea anyway.
Now MCU memory is divided to boot loader ja program memory areas.
Can that memory areas be divided to FAT driver and main program areas.
Bootloader then update only main program area. That way "big" FAT driver not
need to fit bootloader.
Main system could also use SD card (or microSD) for log, alarm sounds and so on.
Original comment by jyrki.jo...@gmail.com
on 9 Apr 2012 at 6:59
Something like that might be possible. Some chips have a kind of partitioning /
protection scheme, where more than just the special bootloader area can be
independently 'write-protected'. If this chip can do that too, then the only
remaining challenge is to figure out how to make the compile put the two blocks
of code in the right places and have the function calls actually work.
That said, the FAT code for this needs only be read-only. I believe there is a
version of fsFAT that will easily fit in the space available. The challenge
then actually become doing something similar to the above solution for building
a USB interface -- something for which there is no minimalistic version that
will fit, so far as I can find.
That all said, the bootloader has gone on the back-burner for the foreseeable
future -- unless someone else wants to have a go at it. I started it, but
simply do not have the time to get back to it, for now.
Original comment by gru...@gmail.com
on 10 Apr 2012 at 8:57
Original issue reported on code.google.com by
gru...@gmail.com
on 15 Aug 2011 at 2:40