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

Matt Jadud matt at jadud.com
Thu Jan 6 17:50:20 GMT 2011


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




More information about the developers mailing list