Dangerous Prototypes Open Source Hardware

firmware size - memory issue

December 25, 2009, 11:52:39 pm

Guys,

I think from what ian has said the current chip in the buspirate is getting pretty full.

is it worth looking at switching a v4 board to be one of the pic 33 series with alot more memory? I assume the pinouts are close enough to the current chip so those with the available equipment could swap the chip on the current boards.

Also maybe start to look at making modules in the code that can be included or not in the compile to suit the memory.

Re: firmware size - memory issue

Reply #1 – December 26, 2009, 08:34:06 am

It is getting pretty full. There are a few drop-in replacement chips with twice the memory, the 33fj128GP202, for example, and also the 33FJ128GP802 with a ECAN module.

For now, though, I plan to release big new features as separate firmwares (AVR STK500v2 clone, PIC programmer), and squeeze as many improvements into the current chip as possible.

Re: firmware size - memory issue

Reply #2 – December 28, 2009, 01:40:45 am

I concur, I can live without the PIC programming (Already have an ICD2) and I don't have any AVRs to program, either. I'd rather have more little goodies along the way than have to make room for PIC and AVR stuff

Re: firmware size - memory issue

Reply #3 – December 29, 2009, 04:44:29 am

Is this using a PIC that has a limited flash duty cycle that would limit the number of times you could flip between functions?

I'd personally like the AVR programmer code to be more "mainstream" as it'll have a big part in my usage (when it arrives) .  That said, AVRDUDE may be sufficient and that capability seems to be in the main code base along with the i2c/1wire that I'd also use.  For me, PIC programming is unnecessary, all my uC work at the moment is in the 8-bit AVR space, I don't have any other programmers/chips/skills in the Microchip family.

Re: firmware size - memory issue

Reply #4 – December 29, 2009, 06:34:23 am

100,000 cycles

modular firmware would be the best option I think

Re: firmware size - memory issue

Reply #5 – December 29, 2009, 08:36:08 am

The modular approach is currently required for the STK500v2 clone because I don't know how to get all the protocols to play together. Right now, twenty times 0x00 enter binary mode, but five times 0x00 followed by 0x02 enters SUMP logic mode, etc.

Fortunately, these chips can take a lot of flash cycles. You could program it 28 times a day for the next 10 years before the average life is reached. I find most will do more, the 18f in the #twatch is rated for 100 cycles, but I've done double that on one chip.

But yes, eventually it would be nice to have a larger chip, and a jumper or switch to select between modes.