HP Forums

Full Version: DIYx flash bootloader
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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.

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.

Thank you for sharing your experiences!

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

Have you tried uClibc for the standard library -- it is designed small & can be customised fairly well.


- Pauli

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.

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

If I only had 128KB of flash to work with, I'd avoid them too!

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.

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.

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.

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.