[CCC DEV] Need... more... flash...

cljacobsen at gmail.com cljacobsen at gmail.com
Fri Jan 7 13:25:12 GMT 2011


We should perhaps see about using some linker script magic to decide
the firmware location.

 C

On 6 January 2011 18:50, Matt Jadud <matt at jadud.com> wrote:
> Hi all,
>
> The problem I've been trying to solve is one of flash space. I'm out.
> There's a question at the end, with some background if you're keen to
> read it.
>
> BACKGROUND
> ---
> At the very end of last term, a colleague asked if I could put
> together a sensor that did the following:
>
> 1. Collected and stored ambient light and temperature.
> 2. Collect data on a fixed schedule.
> 3. Collect data when motion is detected.
> 4. The data should be timestamped, and be reasonably accurate.
> 5. The sensor does not need to be powered by battery (it can be plugged in).
>
> I found a nice logarithmic light sensor, a simple temperature sensor
> (three pins, 5V, no calibration needed, accurate enough for gm'mnt
> work),  grabbed a Chronodot RTC (based on a Maxim part, with two
> alarms available), and the OpenLog from Sparkfun. (I started with an
> EEPROM, but the use-case for grabbing the data really dictates being
> able to grab an SD card, slam it into a PC, and read the data file
> into Excel.)
>
> All of this is fine. Miraculously, my TWI library from the summer
> works, although it is slow. I can live with that. So, I can talk to
> the clock, handle the interrupts, and drive a nice little process
> network for collecting the data and storing it over serial to the
> OpenLog. All good.
>
> Until I ran out of flash.
>
> Now, I could probably mangle some things so that they're more
> sequential... I suspect I can get the code into the space available.
> Or, I could design the board around a 644p, and have the kids solder a
> few more components (crystal, caps, etc. -- we did this last year with
> a 328p, so this isn't a big deal.) I think I just committed the code
> that would make this work -- at least, I'm running a TVM on a 644p,
> doing serial, and blinking some pins... its enough of a test to tell
> me that the constants were good and portability claims that we make
> are reasonable.
>
> But. That's tedious, and more work for me, and involves trying to
> figure out why my Mac won't enumerate my USBTinyISP. A solution there
> might be to just grab a Linux machine.
>
> QUESTION
> ----
> What am I trying to say? I need more flash space. Currently, we're
> really sloppy about bytecode placement -- I suspect that the few bytes
> we'd regain by being less sloppy would save my bacon. So, let me ask a
> dummy question, because I'm in a hurry:
>
> 1. When I upload our firmware, I get the following:
>
>
> reynoldsm at ubuntu:~/git/paper-es-sensor$ plumb arduino /dev/ttyUSB0 firmware
> Uploading firmware version [tvm-avr-atmega328p-16000000.hex].
> ... blah blah blah ...
> avrdude: 20040 bytes of flash written
>
> Is this the number of binary bytes written, or the location of the
> last byte written by avrdude? That is, can I put the bytecode at
> memory address 0x4E4A (two bytes after 0x4E48) and not worry about
> death-by-overwrite?
>
> I'll try this. It can't hurt. And, it would get me 438 bytes, which I
> need right now.
>
> Any other ideas, or corrections to my Magic Math(tm) would be welcome.
> Obviously, I'm 1. under a time pressure and 2. doing dumb things
> besides (like porting to new processors). Someone with more brain than
> me with an idea or two would be welcome.
>
> ...or, I could extend the VM memory model to use an external EEPROM
> for code storage...
>
> Cheers,
> Matt
>
> _______________________________________________
> developers mailing list
> developers at concurrency.cc
> http://unhosting.org/mailman/listinfo/developers
>



More information about the developers mailing list