Skip to main content
Topic: Bus Pirate v4 hardware  (Read 71978 times) previous topic - next topic

Bus Pirate v4 hardware

Here's a major update of the Bus Pirate design. There's no guarantee this will ever see the light of day, no estimated release date. The problem is there's no bootloader or USB driver for this design, so don't count on anything happening soon. We will probably have 5 or 10 made under the DP red label for developers, get your reservations in early :)

Changes:
* 256K flash (vs 64K on v3)
* EEPROM for settings storage
* measures USB voltage
* working hardware I2C
* shrouded, SMD header
* header and USB centered
* Integrated USB PIC
* 2 additional AUX pins
* mode select pins to startup as AVR STK2, self test, extra IO
*reset button
*FETs to feed on-board power supply into pullups, software selectable vpullup
*maybe a secondary EEPROM footprint if we can fit it
* mounting holes

Your comments on the hardware are appreciated, draft boards will go out pretty soon.

The Bus Pirate will always be open source, these PCBs are just marked -NC because it's intermediate work product.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #1
There are 10) 10K, 4) 2K, and 4) 1.1K resistors. To make more room for the EEPROM, these should be resistor arrays.  According to the schematic, these should be isolated, since there isn't a common pull-up.
Suggested parts carried by Mouser would be:
742C163103JP 10KΩ 5% 50V
742C083222JP 2.2KΩ
742C083182JP 1.8KΩ
742C083122JP 1.2KΩ
742C083102JP 1.0KΩ

Re: Bus Pirate v4 hardware

Reply #2
You mention above about no bootloader or driver for this design, are you aware of libusb? http://www.libusb.org/ if this was used then no custom driver would be needed and would work across many platforms, once a device is found, packets can be sent/received directly, only a generic client/console app would need to be created to display information and transmit options, like a terminal currently does

Don't know if you was aware of this regarding a usb bootloader

http://www.schmalzhaus.com/UBW/FW/Micro ... aders.html

Hope its ok to pitch in an idea, if I got this correct, your planning on a High voltage programming addon for the bus pirate ? What about having a programmable high voltage pin in this design ? say max 15v or 24v, fully controllable from firmware, then it could be used to program various chips or to be used to power other external devices that maybe connected to the bus pirate

Re: Bus Pirate v4 hardware

Reply #3
I see many I/O's from the CPU as N.C.

Please, please, trace any spare CPU I/O you can to a 100mil grid footprint for an optional connector.
This should not increase the cost (if you fit it without increasing board size) and would enable future projects that requires extra I/O pins.

Re: Bus Pirate v4 hardware

Reply #4
Thanks everyone!

Will check out the resistor networks to see if the routing is still reasonable. When the design is ready to go to the board house we'll bring as many of the remaining pins to a header as possible.

Quote
You mention above about no bootloader or driver for this design, are you aware of libusb?

The driver is only for the PIC side. To be consistent with the existing Bus Pirate stuff the new design will enumerate as a virtual serial port, which doesn't need a driver on a modern OS.

I'm aware of the Microchip USB stuff, and have used it in other DP designs. We'll probably use the MC USB stack in initial testing and development, but the goal is to create an open source replacement before this design is available to the public. I feel that the non-distributable Microchip code is philosophically incompatible with the Bus Pirate. The Bus Pirate is public domain so you can prototype with it, then use the source and hardware design any way you want in a new project, no strings attached. Once we use the MC USB stuff, then we can't keep code in SVN and can't distribute it (even if we fix one of Microchip's bugs). It creates a dependence on Microchip stuff, and a hamster wheel of updating code to match their latest version (they make changes and remove old versions from their site - grrr!). Just getting me to design a USB-based version was like pulling teeth ;)

The SMPS is a great idea, and we also considered it for this design. I don't think it will make this version with the major USB hurdle already driving everyone nuts though :)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #5
[quote author="udif"]
I see many I/O's from the CPU as N.C.

Please, please, trace any spare CPU I/O you can to a 100mil grid footprint for an optional connector.
This should not increase the cost (if you fit it without increasing board size) and would enable future projects that requires extra I/O pins.
[/quote]

The busprate isn't an arduino ;)

Re: Bus Pirate v4 hardware

Reply #6
How about changing mode select pins to DIP switches? SMD versions are present, and save people from working with jumpers. I usually carry my BP to school and back to home in a rugged hard-disk case with OLS and having jumpers inside that case is not that good of an idea.

About SMPS: Although it is a good idea for PIC programming, I think it is useless for other stuff as we cannot draw much current. But maybe we can implement it by just adding a few components, and using two pins of the PIC (one for ADC feedback, the other for driving the FET). I might be able to help with this part if needed. :)

Re: Bus Pirate v4 hardware

Reply #7
Looks great, Ian! :)
I have a few PIC24FJ256GB106-I/PT's at work, so I can test the hardware side of things if those developer reservations haven't been filled yet. I'm gonna give it a go in Eagle and see if I can't squeeze some space in there.
For the SOT23-5 EEPROM, I'd recommend not using the 24AA16/24LC16 as each of it's pages are a different I2C address. Found that out the hard way. Just a bothersome quirk it has. How big do we need it to be?
Where does Seeed mostly order their parts from, Mouser, Digikey, ..?
 - Adam

Re: Bus Pirate v4 hardware

Reply #8
[quote author="ian"]
*FETs to feed on-board power supply into pullups, software selectable vpullup
[/quote]

Be sure to use fets without internal diode. They will most likely misbehave. (pushing Vext to 5v/3v3 rail, etc ... )

Re: Bus Pirate v4 hardware

Reply #9
Seeed sources locally in China whenever possible. The get some stuff for our projects from Microchip direct, and digikey when needed.

*DIP MS switches
*resistor arrays
*Check FETs
*Check EEPROM

Here's the previous v4. These went out to the Flash Destroyer guessers.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #10
I have a PIC24FJ256GB110 demo board with me, which I used during my microprocessor course and assistantship. I may also help with some stuff, probably software.

If it is not possible to find a suitable FET without internal diode (as usually they have body diode as far as I know), a diode may be connected to disable the internal diode.

Re: Bus Pirate v4 hardware

Reply #11
Managed to fit the second EEPROM underneath, not the neatest fit, but it should work. No DRC errors. :)
 - Adam

Re: Bus Pirate v4 hardware

Reply #12
Also, are the other two pads of the crystal supposed to be connected to ground?
 - Adam

Re: Bus Pirate v4 hardware

Reply #13
Great to see this moving forward.

I really hope that since yu are using the GB version of the chip that the USB pins ont he pic get routed to a USB plug of some sort, i really think its a great idea going forward. giving direct USB access via the PIC.

Also i am not suggesting any software be written to support USB, but just the ability to add it lateras the hardware is ready is all i would be asking for at this stage.

As allways great work ian

Re: Bus Pirate v4 hardware

Reply #14
[quote author="Scorpia"]
I really hope that since yu are using the GB version of the chip that the USB pins ont he pic get routed to a USB plug of some sort, i really think its a great idea going forward. giving direct USB access via the PIC.
[/quote]

The USB pins are routed to the usb plug. In fact there isn't a FTDI chip (on the 1st pcb proposed).