Dangerous Prototypes

With the newterm update (v5+) the firmware size jumped pretty dramatically. In the latest nightly we had to remove the easteregg to get the firmware to fit in the PIC.

We don't think the optimization route is feasible. It would be a lot of work for a little payout. Using compiler optimizations would be great, but they break stuff and nobody wants to track down all the bugs. 

That leaves us with the uncomfortable options of removing stuff or splitting the firmware into multiple parts. We could also just move to maintenance development for v3. New features that take too much space will be saved for a future Bus Pirate with more flash.

We're open to your votes, suggestions, and offers of assistance.

Even though I just purchased a BP, and haven't had time to use it yet, I would prefer that rather than removing any features, that another BP with more flash come out and I would purchase it too.  Leave the current one at a stable version with only bug fixes from now on, and have new development on the new (bigger flash) one.  I would also recommend leaving even the unpopular modes (such as PC Keyboard) still being a feature in the new BP.  Unless absolutely necessary, I don't like to see any hardware/software platform have a degredation in featureset.

I would also like to see (if the solution is a new BP with more flash) a user swappable flash to "futureproof" it.  Whether it is a socket, or unsoldering/resoldering a through hole component, it doesn't matter to me.  I think keeping it one or the other (not surface mount) would let the largest population of the users be able to upgrade it themselves.

Thanks tempmj - The flash is actually internal to the PIC, an updated BP would have a PIC with 4 times more flash to help future proof it (256K), that's the maximum amount of flash available on a PIC at this time.

No chance for external flash?

I think we should do the quick optimizing steps (remove obvious dead code/texts) to make some room for bugfixes and freeze the whole thing (featurewise). Unfortunately we did already the most obvious ones.. :D

(Is there a way to vote more then once? like spliting and remove some features)

tempmj: this is a bit cumbersome, but having multiple firmwares to flash (on your pc) is almost the same. The new version have some external flash but not (directly) for storing 'programs'. We coudl consider it (but with 256k flash it is a bit overkill (for now))

Edit: voted for splitting (i.e. keep a maintenance release and a cutting edge release (with new things and removed some options)

How important is the Basic interpreter?  It seems to be a large chunk of code and for me personally, I would probably never use it.  I prefer to do macros in my terminal program or using Perl or Python.

Gee, I'm going to miss that Easter egg :->

Randy

[quote author="ian"]
 (256K), that's the maximum amount of flash available on a PIC at this time.
[/quote]

512Kb is the max on the 32 bit PICs.

512Kb is the max on the 32 bit PICs.

You're right, I was just referring to the PICs we had evaluated for the Bus Pirate v4. the PIC 32 are not candidates because they lack the Peripheral Pin Select feature that makes the Bus Pirate so easy to design.

[quote author="Randy"]
Gee, I'm going to miss that Easter egg :->
[/quote]

Yeah! You're the first ;)

[quote author="tempmj"]No chance for external flash?[/quote]No.

In order to communicate with external Flash at full speed, the added memory would need to be wired to the PIC24 Parallel Master Port. That uses 6 pins for control, 8 pins for data, and up to 11 pins for address.  You'd need the 44-pin version of the PIC24. The Bus Pirate has the smaller 28-pin version. Besides, even with the 44-pin chip, by the time you've allocated 25 pins for an optional external Flash there really are not many I/O pins left over for the main Bus Pirate features.

You can add serial Flash, but I don't think you can execute from serial memory, and even if you could, it would be 1/8 normal speed.

[quote author="rsdio"]
You can add serial Flash, but I don't think you can execute from serial memory, and even if you could, it would be 1/8 normal speed.
[/quote]

Not without reflashing the PIC, possible but that makes it a bit difficult for the average user. Reflashing an other firmware is easier, and the user has more storage on his harddisk then we could possibly attach to the Buspirate. :D

If someone could port java or mono to pic24 the story would be a lot different ;)

I'd recommend some kind of firmware builder. Like a wizard that allows you to select the features you need, then compiles the firmware that matches your needs. THen upgrade the flash size in the next revision.

[quote author="Sal_The_Tiller"]
I'd recommend some kind of firmware builder. Like a wizard that allows you to select the features you need, then compiles the firmware that matches your needs. THen upgrade the flash size in the next revision.
[/quote]

Some of the extra modules already have a define in base.h that toggles the inclusion, but it needs additional tweaking to make it work. Moving to a true module based system will need a major rework of the core of the buspirate.

I can live with this but joe average will find this too much cumbersome and not use it. It also restricts the use to the windows platform (AFAIK MPLAB only works on windows).

I'm trying to build the latest C30 compiler (3.23b) on Linux (found one tutorial but wine caused some problems) so after I'm finished, it might solve some problems with Linux users. My only problem is time currently as my major masters exam is closing in.

[quote author="Sjaak"]AFAIK MPLAB only works on windows[/quote]What about the open source sdcc?  I would not want to develop a new firmware with it, but it might be fine for firmware that has already been debugged.

SDCC is a retargettable, optimizing ANSI - C compiler that targets the Intel 8051, Maxim 80DS390, Zilog Z80 and the Motorola 68HC08 based MCUs. Work is in progress on supporting the Microchip PIC16 and PIC18 series. SDCC is Free Open Source Software, distributed under GNU General Public License (GPL).

As we are using a PIC24F series device, SDCC will not work IMO.

[quote author="tayken"]
I'm trying to build the latest C30 compiler (3.23b) on Linux (found one tutorial but wine caused some problems) so after I'm finished, it might solve some problems with Linux users. My only problem is time currently as my major masters exam is closing in.
[/quote]

that is good news. Too bad exams are more important ;) Better finish those first.

[quote author="rsdio"]
[quote author="Sjaak"]AFAIK MPLAB only works on windows[/quote]What about the open source sdcc?  I would not want to develop a new firmware with it, but it might be fine for firmware that has already been debugged.
[/quote]

I thought ssdc was more 8051 specific?

Edit: like tayken says?

[quote author="tayken"]
I'm trying to build the latest C30 compiler (3.23b) on Linux (found one tutorial but wine caused some problems) so after I'm finished, it might solve some problems with Linux users.
[/quote]
I've tried as well. The compiler builds, but I sure can't make it actually compile anything.


This just HAS to be made to work though -- it's the only way out of this windows-only mess you get when using PICs in the first place. Once there's a proper build environment on linux or similar, this sort of problem becomes simple -- lots of ways to select/deselect modules to make the firmware fit the target device.


For reference, I used the instructions and build script found here:


http://www.electricrock.co.nz/blog/microchip-c30/ (http://http://www.electricrock.co.nz/blog/microchip-c30/)


This is the error I get (tons of these):


[tt:]/home/bert/pic30/bin/../lib/gcc/../../share/pic30-nonfree/support/PIC24F/h/p24FJ64GA002.h:14: error: syntax error before ‘__attribute__’[/tt:]

That is the same tutorial I was talking about Bert. Now I'm using the same patches as in that blog but I'm using an older tutorial which creates .deb packages and installs them.

This just HAS to be made to work though -- it's the only way out of this windows-only mess you get when using PICs in the first place.

Well for libraries we still need a Windows machine but only for that. I think these guys should start supporting Linux.

OK, I haven't bought my own Bus Pirate, yet, but can't the code be swapped to external memory(I2C,SPI)? That probably causes trouble with a bootloader but it would be a quick fix.

[quote author="paul.tech"]can't the code be swapped to external memory(I2C,SPI)? That probably causes trouble with a bootloader but it would be a quick fix.[/quote]As I mentioned on the first page of this thread, the PIC cannot execute program code directly out of I2C or SPI memory. Thus, adding external serial memory would just allow an alternate source for programming a limited internal Flash. As Sjaak has already pointed out, there really is no advantage to storing alternate firmware in serial memory when your USB host computer has infinite disk storage. Any solution requires re-Flashing the internal memory, so it really does not improve the situation to have onboard storage when Flashing is required.

If the PIC could execute code from RAM (and if there were more RAM) then external serial memory might be an improvement because this would not require re-Flashing the internal code memory.

Hi, I just ordered my Bus Pirate couple minutes ago, came to this forum  saw this thread and I was thinking great... mine has not yet left the factory and it's already obsolete new with 256k will be here soon :( So my vote goes to multiple chunks... It's nothing new... Cisco for example had 44 versions of their firmware with different subset of features (though they now have "only" 8).  So i would definitely not mind to re-flash bus pirate if a  new device comes under it's test probes ;) 

[quote author="siklosi"]So i would definitely not mind to re-flash bus pirate if a  new device comes under it's test probes ;)[/quote]Also, since the Bus Pirate is rather cheap compared to most test equipment, you could potentially dedicate a different Bus Pirate to each kind of device that you might want to test.  You'd probably want to make a different case for each one, with dedicated markings and firmware.  The only glitch would be some way to distinguish the variations from the computer, but that may already have been solved (?).

We still haven't reached the point where anything has been dropped, but we are riding that line :) Sjaak has implemented a multiple chunk scheme. The main firmware is pretty much what we have now. The secondary firmware will have new features as they become available (none currently, maybe the JTAG user terminal mode in the future).

Unfortunately, the 256K one is just a dream at this point... The first prototype is already a bit messed up, and there's a ton of testing, improvement, and (mostly) firmware work (USB library) to do. The v3 is the only Bus Pirate at this point, and for the forseeable future, we won't hold anything back ;)

[quote author="siklosi"]
Hi, I just ordered my Bus Pirate couple minutes ago, came to this forum  saw this thread and I was thinking great... mine has not yet left the factory and it's already obsolete new with 256k will be here soon :( So my vote goes to multiple chunks... It's nothing new... Cisco for example had 44 versions of their firmware with different subset of features (though they now have "only" 8).  So i would definitely not mind to re-flash bus pirate if a  new device comes under it's test probes ;)
[/quote]

With IOS15 you'll only get one, with an enforced licensing model to get your features.

As Ian says the new buspirate will take some time (I optimistly guess 3-6 months) to finish.