Stripping the bus pirate for personal uses

March 04, 2011, 06:22:56 pm

Something that I have wanted to do ever since I heard about the bus pirate is to steal all of the code that I can use and put it in my own projects. The great thing about the open source community is that often you can get the people that put their blood, sweat and tears into the code give you all the hints and help you strip it down.

What I am thinking of doing is adding some #if defined(BP_USE_TERMINAL) lines of code which will block out all of the sections that use the terminal, leaving only the bit bang modes and the functions used by the bit bang modes.

In addition, I will write functions which will correspond with most of my functions in pyBusPirateLite_v1.

End Goals:
- Allow someone to have a microcontroller embeded in a project and be able to take it over with normal bit bang commands (however, I will probably extend the library somewhat to allow more control of any pin), and make it so that revisions to the bus pirate keep these sections blocked out.
- Once they have something working through pyBusPirateLite, they can easily (or semi-easily) port the code to the microcontroller using functions already written.
- Make it simple for someone to make a bigger, better bus pirate (albeit with only bit bang mode available) in a relatively quick manner. For instance, the pic24 family is very similar, they could make one with more outputs, or which was directly integrated in a new and exciting system.

To - Do List:
- Strip code of terminal messages and their associated functions. There is no need for most of the character filtering, the buffers to store user input, or anything else (although the buffers might be kept for the uart communication)
- I've worked with microcontrollers, but I've never done the extent of memory mapping that you guys are doing, and those hard coded messages (BPMSG...) are just plane insane in my opinion (no offense, I know you guys have done it out of necessity to save space). These would be gotten rid of.
- small tutorial to help guide the newbie down the path of coding microcontrollers.

So ya, the goal would be to make coding a pic24 easier for the average person, and with a strong base.

I have some questions right away:
- will I need a new linker file? I've never written one of these, so I would probably need help if I did.
- Looking at the memory mapping (I do not understand it at all...) it looks as if room for the messages is hard coded into it. If the messages and uart buffer were gone, could I use the microchip provided linker and memory mapping file? Can you foresee any difficulties?
- Any further comments would be appreciated.

Re: Stripping the bus pirate for personal uses

Reply #1 – March 04, 2011, 08:40:25 pm

The linkerscript does protect the bootloader. Since the BL is located at the end of the programmemmory, you are failry safe (after stripping code) to use the microchip default. If you would keep the bootloader is still necessary.

I agree the BPMSG's are an ugly hack, but it did save 33% storage of the string messages (which we indeed needed badly :))

Re: Stripping the bus pirate for personal uses

Reply #2 – March 09, 2011, 08:33:08 pm

Thanks, this is exactly what I wanted to know :D

One more question: Does any of the major developers have any interest in this being a hard coded feature, so that future revisions allow for easier implementation of the code in other projects? Or should I just grab the latest release and change it? Does not very much change in the hardware regardless?

And one more question, why are we using bit-bang protocol for I2C (as opposed to the hardware implemented I2C)?

Re: Stripping the bus pirate for personal uses

Reply #3 – March 12, 2011, 08:57:04 am

Quote

Does any of the major developers have any interest in this being a hard coded feature, so that future revisions allow for easier implementation of the code in other projects? Or should I just grab the latest release and change it? Does not very much change in the hardware regardless?

We can distribute your alternate firmware if you like. I'm not sure about the hardware changes you mention,.

Quote

And one more question, why are we using bit-bang protocol for I2C (as opposed to the hardware implemented I2C)?

On many revisions of the 24FJ64GA002 the hardware I2C does not work, so we use software only.