HP Forum Archive 21

[ Return to Index | Top of Index ]

DIYx flash bootloader Message #1 Posted by Eric Smith on 17 Sept 2012, 7:44 p.m. I've now got programming the flash from USB working, in addition to the SD card. It takes less than 7 seconds to update with 256KB of calculator firmware. I'm using a command-line program on Linux to do the update, but it shouldn't be too hard to put together a cross-platform GUI program. The size of the bootloader is now 73K. It looks like over 40K of that is from the C standard library. Some of that will still be needed, but some of it should shrink considerably if I use a lightweight printf() replacement. I think that will drop it to under 64K, but not under my original 32K target. The linker seems to have problems linking the main calculator firmware to start at an address that isn't a multiple of 32K. 0, 32, 64, 96, or 128K all work fine, but I tried 80K and it failed. There doesn't seem to be anything in the linker script that deals with 32K boundaries, so I think this may actually be a linker bug. I haven't yet had time to investigate it thoroughly.

Re: DIYx flash bootloader Message #2 Posted by Eric Smith on 18 Sept 2012, 3:02 a.m., in response to message #1 by Eric Smith My replacement printf() compiles to less than 1.5KB, vs. around 30KB for the one from Newlib. The huge difference is partially because mine doesn't have floating point support, or some of the other less commonly used features of printf. That's brought the size of the bootloader to around 45KB, which leaves plenty of room for improvement if I reserve 64KB for it. The linker map shows that other stuff from Newlib is using about 11KB of flash. That still seems like an absurdly high amount, but even if I could completely eliminate it, it wouldn't let me get the boot loader to under 32KB with any room to spare.

Re: DIYx flash bootloader Message #3 Posted by Andrés C. Rodríguez (Argentina) on 18 Sept 2012, 9:18 a.m., in response to message #2 by Eric Smith Thank you for sharing your experiences!

Re: DIYx flash bootloader Message #4 Posted by Tim Wessman on 18 Sept 2012, 1:09 p.m., in response to message #2 by Eric Smith Yeah, when interviewing people I generally talk about printf to see if they understand what is meant when I say, "Why wouldn't we want to use the provided printf in this calculator?" :-) TW

Re: DIYx flash bootloader Message #5 Posted by Paul Dale on 18 Sept 2012, 4:50 p.m., in response to message #2 by Eric Smith Have you tried uClibc for the standard library -- it is designed small & can be customised fairly well. - Pauli

Re: DIYx flash bootloader Message #6 Posted by Eric Smith on 18 Sept 2012, 4:54 p.m., in response to message #5 by Paul Dale I looked at uClibc a little bit. It appeared much better suited for Linux or uCLinux than for bare metal, and it looked fairly heavy weight compared to my needs.

Re: DIYx flash bootloader Message #7 Posted by Paul Dale on 18 Sept 2012, 5:12 p.m., in response to message #6 by Eric Smith Yeah, it is aimed at full systems but can be configured leaner -- a lot leaner. There are other lean libc's although their names elude me at the moment. The 34S avoided all standard libraries. - Pauli

Re: DIYx flash bootloader Message #8 Posted by Eric Smith on 18 Sept 2012, 5:17 p.m., in response to message #7 by Paul Dale If I only had 128KB of flash to work with, I'd avoid them too!

Re: DIYx flash bootloader Message #9 Posted by uhmgawa on 19 Sept 2012, 1:33 a.m., in response to message #7 by Paul Dale Quote: The 34S avoided all standard libraries. KEMU avoided use of std libs as frankly there wasn't any advantage to linking against them, and bloat was more than enough reason to sidestep their usage entirely. Many library implementations will drag in i/o buffer space which for synchronous i/o (non-interrupt driven) is of no performance benefit, unnecessarily consumes r/w mem, and places a limit on the line length before either dropping characters or reverting to synchronous behaviour. For years I've been lugging around a compact footprint printf which supports most formats sans fp. In addition for NUT emulation I'd extended it to support CPU register 14 digit structure data both packed in memory and in-CPU working formats. I just checked a binary built for an ARM M3 which weighs in under 750 bytes of r/o text. For such embedded apps I find avoiding std libs completely also helps maintain size portability vs. whatever will be yanked out of a toolchain build environment.

Re: DIYx flash bootloader Message #10 Posted by Eric Smith on 19 Sept 2012, 3:32 a.m., in response to message #9 by uhmgawa The essence of engineering is to make appropriate tradeoffs. Faster, better, cheaper: pick two. While I'm not getting a great deal of value out of Newlib on the DIY4X, and have already replaced the printf() family of functions, freeing up the remaining 11KB of code would take more time than it is worth. If I was still using a microcontroller with only 128KB of flash, it would be a different story, but with 1MB of flash available, the priority of eliminating that 11KB is much lower. The only reason I have Newlib in there at all is that it is used in the sample projects from the microcontroller vendor and the toolchain vendor. A five minute experiment to eliminate it was not successful, but obviously with a little more effort I could find out what it is doing that I actually need, and replace it. I may eventually do that, but for now I have far more pressing bugs to fix and features to add. I know that this is a slippery slope kind of argument, and that if one is not careful this can easily lead to bloatware, so I don't make such decisions lightly.

Re: DIYx flash bootloader Message #11 Posted by uhmgawa on 19 Sept 2012, 9:15 a.m., in response to message #10 by Eric Smith Quote: The essence of engineering.. My comments weren't directed to your particular scenario -- I was actually responding to Pauli's post. Moreover I wouldn't typically expect aggressive footprint reduction to be a priority early in the development cycle.

Re: DIYx flash bootloader Message #12 Posted by Eric Smith on 19 Sept 2012, 7:01 p.m., in response to message #11 by uhmgawa Don't worry, I didn't think anyone was criticizing. I just felt like further elaborating on why I'm doing things the way I am.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall