Dangerous Prototypes

Dangerous Prototypes => Bus Pirate Development => Topic started by: ian on July 08, 2010, 10:57:50 am

Title: Bus Pirate v4 hardware
Post by: ian on July 08, 2010, 10:57:50 am
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.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on July 08, 2010, 09:09:22 pm
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Ω
Title: Re: Bus Pirate v4 hardware
Post by: Darren on July 09, 2010, 12:05:34 am
You mention above about no bootloader or driver for this design, are you aware of libusb? http://www.libusb.org/ (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 (http://www.schmalzhaus.com/UBW/FW/Microchip/Usb/Documentation/Getting%20Started/Getting%20Started%20-%20Using%20the%20Device%20-%20USB%20Device%20-%20Bootloaders.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
Title: Re: Bus Pirate v4 hardware
Post by: udif on July 09, 2010, 12:14:25 am
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.
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 09, 2010, 09:32:14 am
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 (http://http://dangerousprototypes.com/forum/index.php?topic=503.0) 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 :)
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 09, 2010, 09:39:42 am
[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 ;)
Title: Re: Bus Pirate v4 hardware
Post by: tayken on July 09, 2010, 11:52:10 am
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. :)
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 09, 2010, 12:04:09 pm
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
Title: Re: Bus Pirate v4 hardware
Post by: robots on July 09, 2010, 12:06:31 pm
[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 ... )
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 09, 2010, 12:13:13 pm
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.
Title: Re: Bus Pirate v4 hardware
Post by: tayken on July 09, 2010, 12:24:40 pm
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.
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 09, 2010, 01:14:34 pm
Managed to fit the second EEPROM underneath, not the neatest fit, but it should work. No DRC errors. :)
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 09, 2010, 01:18:18 pm
Also, are the other two pads of the crystal supposed to be connected to ground?
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: Scorpia on July 09, 2010, 02:26:40 pm
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
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 09, 2010, 02:52:53 pm
[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).
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 09, 2010, 03:23:51 pm
Managed to squeeze the second EEPROM on top of the board by shifting the USB connector up and doing a bit of fiddling. A little neater, but still not great. No DRC errors. :)
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 09, 2010, 03:44:14 pm
Nice fit :) Your warning about the EEPROM makes me want to use a so-8 so we can have more space. If we do that, we can go SPI and it'll be faster and the pins will be easier to assign and more direct (PPS). Not a bad deal :) Then we can encourage user upgrades :) Sjaak is rumbling about storing modules externally, we might as well give him the space for it :)

This version's most important feature is centered header and USB jack. Together for the first time :) The board can be bigger if needed, but not uncentered :)

Does anyone have thoughts on a frequency prescaler? Is there a common, cheap chip that could extend the 40MHz probe to 100MHz or beyond? I've done a little searching but not a lot, I thought it might make a nice demo post.

*SPI EEPROM
*reorganize bus pins so only SDA and SCL need to cross
Title: Re: Bus Pirate v4 hardware
Post by: Scorpia on July 09, 2010, 03:59:59 pm
Interesting,

I personally would be in favor of keeping the USB chip and adding a second interface for testing purposes.

It would allow the use of the current firmware and allow further hacking/advancements. The cost savings to me would be hardly worth removing the chip.
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 09, 2010, 04:40:08 pm
If we go SPI, sticking something large like the 25LC512 should be fine. It will cost a little more than an I2C equivalent. Do we really need the speed?
As for prescalers, OnSemi MC12080 (100MHz to 1.1GHz) divide by 80/40/20/10 (5V) . Or one of the fixed divide ratio 0 to 1.5GHz (3V) ones here: http://www.rell.com/Pages/Product-End-C ... gory=10007 (http://www.rell.com/Pages/Product-End-Category.aspx?productCategory=10007)
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 09, 2010, 07:59:56 pm
the speed of i2c would be fine, since it will be only used when needed.

Though I prefer a 128Kbyte or bigger to work with (256Kbyte is ideally). This will be far more easy to implement and better for backwards compatibility (i2c also :))

[quote author="Scorpia"]
Interesting,

I personally would be in favor of keeping the USB chip and adding a second interface for testing purposes.

It would allow the use of the current firmware and allow further hacking/advancements. The cost savings to me would be hardly worth removing the chip.
[/quote]

We thought about this, but having a native usb sollution would trigger to us to make a usb stack and will be much faster in terms of speed (baudrate).
Title: Re: Bus Pirate v4 hardware
Post by: Scorpia on July 10, 2010, 01:25:37 am
[quote author="Sjaak"]
the speed of i2c would be fine, since it will be only used when needed.

Though I prefer a 128Kbyte or bigger to work with (256Kbyte is ideally). This will be far more easy to implement and better for backwards compatibility (i2c also :))

[quote author="Scorpia"]
Interesting,

I personally would be in favor of keeping the USB chip and adding a second interface for testing purposes.

It would allow the use of the current firmware and allow further hacking/advancements. The cost savings to me would be hardly worth removing the chip.
[/quote]

We thought about this, but having a native usb sollution would trigger to us to make a usb stack and will be much faster in terms of speed (baudrate).
[/quote]

Keeping the usb chip and added the native USB gives the best of both worlds. you can keep the current software and then upgrade to the native usb connection as required. so to me having both is a big advantage
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 13, 2010, 03:22:07 pm
[quote author="Scorpia"]
Keeping the usb chip and added the native USB gives the best of both worlds. you can keep the current software and then upgrade to the native usb connection as required. so to me having both is a big advantage
[/quote]

You can't have both. Well, not without making it bigger and having a mux or FET switches between the USB ports. This would also increase cost. The PIC24FJ256GB106 is a beauty and maturing the product into this path is a natural progression.
Ian, do you have a custom EAGLE library you work from similar to Sparkfun/Ladyada's? Also what are your grid/etc settings for board layout? I managed to figure out the wire and via sizes in mils, but some of the wires were a little wonky. I usually work in mm, at 0.1 or 0.01 with multiple of 5 or 10. Hooray for the metric system. :P
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: Scorpia on July 13, 2010, 03:34:36 pm
Why do we need to switch between USB ports when to the FDTI one is just a serial port as far as the PIC is concerned?

I never said anything about connecting both to the PC at once. As for increased cost well i think its worth it. One thing that this would allow for example would be developing the USB OTG part of the pic while still using the current terminal interface of the usb-serial chip.

but as i said, its just a personal preference. Im am in no way the designer. Just voiceing an opinion.
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 13, 2010, 05:09:57 pm
Can we discuss the EEPROM a little? I had intended to store a few bytes of settings (for instant-on, saved modes settings, saved commands, personalization, etc). Sjaak has talked about loading whole modules from EEPROM :)

How big should it be? I thought 4kbit (500 bytes) sot-23 would be fine. The biggest sot-23-5 is 64Kbit ( 8000 bytes) :
http://www.microchip.com/ParamChartSear ... d=&lang=en (http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=70008&mid=&lang=en)

The biggest microchip EEPROM is 1mbit (128Kbytes) and it's pretty pricey (and SO-8). IF 256K+ is needed, we should probably move to a 4mbit flash or something (also so-8).
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 13, 2010, 05:39:45 pm
Well, how many settings do we need to store currently? How big are all the modules? Ideally we can choose a device that uses about 2/3rds it's capacity with our current requirements, unless someone foresees a feature which requires a significantly large EEPROM. I would prefer only settings to be loaded from it as well.
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 13, 2010, 06:47:54 pm
Quote
Ian, do you have a custom EAGLE library you work from similar to Sparkfun/Ladyada's? Also what are your grid/etc settings for board layout? I managed to figure out the wire and via sizes in mils, but some of the wires were a little wonky.

Yup, it's in SVN, I made a wiki page too:
http://dangerousprototypes.com/docs/Dan ... ts_library (http://dangerousprototypes.com/docs/Dangerous_Prototypes_Cadsoft_Eagle_parts_library)

We don't have a fixed grid/etc, though we try to use 15/20/25/30 mil vias and 10-12-16-24 mil traces. If you make a wiki page with grid and other specs we'll adopt it from now on :)

Size:
The mode config struct is about 18 bytes, but I'm not sure what that little buffer is for:
http://code.google.com/p/the-bus-pirate ... base.h#117 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/base.h#117)

bpconfig is about 10 bytes:
http://code.google.com/p/the-bus-pirate ... eCore.h#19 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/busPirateCore.h#19)

Some bus modes also have a few byte struct for settings. For example SPI has a byte, but could use one more to hold the speed, etc:
http://code.google.com/p/the-bus-pirate ... e/SPI.c#56 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/SPI.c#56)

I imagine settings for each mode could take 2-3bytes per mode for another 30 bytes or so.

It might also be useful to store macros permanently. How many macros would be useful, and how long should they be? Should it just be a backup of the volatile macros in memory? That's 32*5=160bytes.

It would also be useful to have a place to store the STK500v2 hardware ID and version number, it's currently hard-coded intot he firmware. THe stk500v2 will be incorporated into the main firmware in v4 (due to the MS dip switches). That could be another 6 bytes.

What about a personal ID (name) or maybe a user defined VID/PID? Thats maybe 20bytes + 4bytes.

That's 248 bytes... You could increase every macro to 256 bytes (1500) and still fit in a 16 or 32Kbit chip.

But, if Sjaak wants to store giant easter egg modules, or we want to store PIC/AVR firmware for remote programming, then the 256Kbyte EEPROM (or a cheaper flash rom) is a better idea.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 13, 2010, 08:46:08 pm
Hee sorry about the big easter egg :P I did make it as small as I could.

On v4 only settings is needed, since the flash is four times the current bp (256K vs 64K). Don't forget the scripting engine, the current program memmory is 1024bytes.
Title: Re: Bus Pirate v4 hardware
Post by: Scorpia on July 13, 2010, 11:44:55 pm
With the eeprom in mind, Would any of the eeproms your talking about be quick enough to be used as a storage location for the Logic analyiser ? If it was quick enough to store reading them I could see more and more reasons to go the larger chip.

but my prefernce would be for the larger footprint, even if it only came with a smallish eeprom by default. at least it could be changed in the future.

Or as a seperate idea, is there any room to run both? have the current 5 pin chips by default with a footprint for the 8 pin on the board for module expansion/storage etc if the user requires it.
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 14, 2010, 07:58:51 am
I was joking about the easter egg :) I like it a lot. If only someone would find it I can stop littering every post with clues :)

Good point about the scripting. Another 1K, or really any larger amount, to store scripts is useful.

@scopria - Ideally we'll fit both. I think the SOT-23-5 will be populated with 16 or 32Kbit EEPROM. The extra footprint will be a SO-8 (wide) for the 'big' 1024mbit chips.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 14, 2010, 08:40:49 am
then you should (when using an i2c) have the adressslect userconfigurable. for example the 24a1025 needs a0 to be pulled up or the chip won't work.

Spi is a better choice? (don't know much about those, but afaik they don't have the adressing issues)
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 14, 2010, 11:33:13 am
[quote author="ian"]
I was joking about the easter egg :) I like it a lot. If only someone would find it I can stop littering every post with clues :)
[/quote]

The first person that send me 100U$ will receive the directions to the easteregg :P

:X
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 16, 2010, 02:01:17 pm
I noticed the two new AUX connection don't have (selectable) pullups. Will they have this in the final design or is this by design?

I think they are 5V tolerant though.
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 16, 2010, 02:07:35 pm
This is by design. The existing AUX pin doesn't have a pullup either. If there was room we could add another 4066 for all 3 aux pins, but I'm not sure where to put it.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 16, 2010, 02:41:35 pm
I think when moving all the resistors (between the pic and header) and current 4066 a bit up, loose the reset switch (not needed in the final design??) you can fit it there (don't know if it is routable, but should be). Using resistor arrays will give also extra room. Reset button could move to the left of the icsp if you want to keep it.

I hope you already send the current board to the pcb fab house :X
Title: Re: Bus Pirate v4 hardware
Post by: vimark on July 16, 2010, 03:59:18 pm
Hi guys,

I'll try to add the 2nd 4066 on the board.
Title: Re: Bus Pirate v4 hardware
Post by: SineWave on July 21, 2010, 03:14:32 pm
Can Seeed do 0402 parts? We could save a lot of room, but at a cost of half the power capacity. : /
 - Adam
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on July 21, 2010, 03:32:37 pm
Actually a bigger board won't cost (very much) extra. I guess it is a male thing to let size matters ;)

I also like to have resistors and capacitors I like to see and can solder with a regular iron (remember that it is an enginering prototype!!) I hope I can solder the pic ;]
Title: Re: Bus Pirate v4 hardware
Post by: vimark on July 21, 2010, 08:27:11 pm
Hello,

here's the board I made.
a couple modification on the wiring though
-swapped ADC3 and ADC4
-swapped PUVSEL33 and PUVSEL50

sorry for the delay

/V
Title: Re: Bus Pirate v4 hardware
Post by: ian on July 21, 2010, 09:07:00 pm
Nice :) I sent the update to the board house already, but we can send this one next week if anyone would like to test it too.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 10, 2010, 11:23:38 am
Just one question:

Why stick with PIC24 series for Bus Pirate 4 ?

why not switch to dsPIC33 ?  they have more RAM and better peripherals (especially PWM for motor control). For the price, I think that now that  Bus Pirate has made its proofs, so I think that users will accept to pay 3 or 4 more $$ to have a dsPIC instead of a PIC24.

regards
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 10, 2010, 11:36:35 am
Developers were persuaded to consider an integrated USB solution, and there are no integrated USB dsPICs:
http://www.microchip.com/ParamChartSear ... &pageId=74 (http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=8011&mid=10&lang=en&pageId=74)
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 10, 2010, 12:09:34 pm
I think that integrated USB is a very bad choice!
think about timing and usb state machine. You need to poll usb in less than 10ms each time. Some developpers use an interrupt to do that, but this is not a solution.
BusPirate should evolve in a way that it can provide better signals timing possibilities. Having to support USB is a problem.
All firmware should be written arround USB state machine, this means more constraints for less profit. I think that we could even split the desing of BusPirate in two separate modules,
1- one module that will be BusPirate signals and protocols handling,
2- and one module for data transfert from/to PC.

This second module can be:
- either USB based (FTxxxx),
- or Ethernet based which is (for me) a better choice because any PC on the lan can control BP, and any PC can control any number of BP on the Lan (we ca also do distant logging on internet),
- or either simply an UART (without tranceiver) based ... this will make it possible to pilote  BusPirate using handheld devices or some small industrial PC-104 boards like the  mini2440 ARM based board
http://www.friendlyarm.net/sites/produc ... 2440_2.jpg (http://www.friendlyarm.net/sites/products/mini2440_2.jpg)
http://www.friendlyarm.net/sites/produc ... 440-35.jpg (http://www.friendlyarm.net/sites/products/mini2440-35.jpg)

Regards
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 10, 2010, 12:23:28 pm
I certainly understand. As I said, we were persuaded. I was dead set against porting the Bus Pirate to a giant state machine, and enumerated all these reasons myself (plus VID/PID, and lack of open source USB firmware). Could you elaborate on why an interrupt is not a solution?

If timing is a consideration for you, don't look at the Bus Pirate signals on a logic analyzer, it's already totally unreliable because it has to push stuff up a slow UART. Really sensitive stuff, like PWM or frequency measurement, is hardware based and won't generally be effected by the USB service routine.

The Bus Pirate with a UART connection does not provide enough speed for a lot of the apps that support it, the biggest complaint is always speed and never timing.
The v3 with FTDI chip will remain available when v4 is for sale, so you still have the option of a non-USB Bus Pirate.

Really, we don't even know if it's going to happen. Tons of people have pushed for an integrated USB Bus Pirate, but nobody has coughed up any code to support it or anything. We're going to make a batch of prototype hardware for anyone that wants to mess with it, but that's as far as we're committed now.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 10, 2010, 01:01:12 pm
[quote author="ian"]
Could you elaborate on why an interrupt is not a solution?
[/quote]

Cause if you use Software protocols implementation for example like  I2C (to be able to strech signals or avoid hardware bugs), you'll need to take into account the usb polling (in the interrupt) ...
Software timing will become really a night mare to handle in ALL protocols. (why FPGA developpers always use an external chip for USB instead of implementing it in the FPGA?)
Understand me, I dont say it's not feasible (as most usb programmers works this way) but the profit from using an USB chip is really not that important! Development effort will become more important for very little profit ... and all you'll win in price, you'll lose it paying for VID/PID licenses (considering the production volume you're doing).

[quote author="ian"]

The Bus Pirate with a UART connection does not provide enough speed for a lot of the apps that support it.
[/quote]
On PC104 boards you can got UARTs at up to 2MB .... enought for logging slow I2C data  ;) 
When you use a BusPirate to spy an I2C bus that have very low traffic (only few bytes each 10 min) you dont need too much band width.

[quote author="ian"]
We're going to make a batch of prototype hardware for anyone that wants to mess with it, but that's as far as we're committed now.
[/quote]
I personally used USB only with PIC18 series (and with STM32). If you think you will be going this direction in BP4, I can help. But right now, I used only Microchip USB stack. I never looked for a free usb stack for Microchip mcu. If you have already took decisions about anything related to that, let me know, I'll be glad to help on that.

Regards
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 10, 2010, 02:40:50 pm
Afaik there are more interrupts involved into USB communication then just a timer interrupt every 10ms. All USB transactions (the handling of endpoints) is done in hardware, and the hw automatically stalls if an endpoint is full.

This new PIC also has no issues with broken hardware, like I2C on some revs of the current used chip. So most of the protocols are handled in hardware now. Besides this most protocols aren't timesensitive and also synchron.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 10, 2010, 03:04:36 pm
Hi Sjaak,
Even on PIC18 most of work was done in interrupts. I was only talking about the fact that polling the USB bus is mandatory, and this one WAS DONE on PIC18 mostly using a timer interrupt!

As for the select PIC24 chip for BP4, I didn't checked the (errata) datasheet yet, I just saw quickly the description, and it seems to be a nice and quite capable chip (3xSPI, 3xI2C, ...) ...
and I still think that adding a  $2 (or even $5 for the quick FTDI2232) chip to handle all USB stuff (and avoid the VID/PID licensing pb) is worth it if we want to keep the design of the BP fimrware very clean and very simple. Think about the future of this tool!!! any maintenance work will involve a lot of competence from future developpers who may join the dev team later.

Regards
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 10, 2010, 03:30:06 pm
[quote author="octal"]... polling the USB bus is mandatory[/quote]That is only true with the older Microchip USB Stack. The new versions support both polling and interrupt-based USB firmware options. The hardware has always supported USB interrupts for those brave enough to write their own USB stack, but now Microchip makes it much easier.

Quote
and I still think that adding a  $2 (or even $5 for the quick FTDI2232) chip to handle all USB stuff (and avoid the VID/PID licensing pb) is worth it if we want to keep the design of the BP fimrware very clean and very simple. Think about the future of this tool!!! any maintenance work will involve a lot of competence from future developpers who may join the dev team later.
My impression is that the FTDI chip is too slow, and too simplistic compared to a PIC with USB firmware.  There's not really any point to making a new Bus Pirate platform unless it can break the serial bottleneck.

Personally, it seems to me that the simplifications of choosing the FTDI serial chip ends up making other aspects of the firmware and the communication protocol more complex than they would be with a Vendor Class USB Device protocol.  Even if you avoid USB entirely, future developers still have to deal with some other proprietary serial protocol which may be even worse in the long run because it is so esoteric.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 10, 2010, 03:49:42 pm
[quote author="rsdio"]
That is only true with the older Microchip USB Stack. The new versions support both polling and interrupt-based USB firmware options. The hardware has always supported USB interrupts for those brave enough to write their own USB stack, but now Microchip makes it much easier.
[/quote]

I didn't knew that. The only way we used to do it with 18Fx550 was to poll the bus in a timer interrupt.
 thx

[quote author="rsdio"]My impression is that the FTDI chip is too slow, and too simplistic compared to a PIC with USB firmware.  There's not really any point to making a new Bus Pirate platform unless it can break the serial bottleneck.
[/quote]

I'm talking about the [glow=red,2,300]2[/glow]232,  not the 232 chip. Do you think CDC on PIC will do better? not that sure.
HID reports are also limited, and HID support with LibUSB seems to be a bit problematic under OS/X (check Saleae problems with the dev of the cross-platform version of their Software that handles Logic analyzer).

Maybe Cypress EZ-FX2 can be an option  :(
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 10, 2010, 11:59:42 pm
[quote author="octal"]I'm talking about the [glow=red,2,300]2[/glow]232,  not the 232 chip. Do you think CDC on PIC will do better? not that sure.
HID reports are also limited, and HID support with LibUSB seems to be a bit problematic under OS/X (check Saleae problems with the dev of the cross-platform version of their Software that handles Logic analyzer).

Maybe Cypress EZ-FX2 can be an option  :(
[/quote]The PIC can do more than CDC, so it's not a direct comparison versus the FTDIx232.  HID is probably not the best choice either.  A Vendor-specific device could easily outperform the FTDI if the command set needs are complex enough.

The way I see it is this:  Either you spend your time writing USB firmware and get a very efficient bus transaction design for your application, or you save time on firmware and end up spending time with the limitations of a single serial bit stream (devices getting locked into an 8-bit comm mode requiring power cycle, or comm modes which are limited to 7-bit values and make the software more cumbersome on both ends).  There are obviously a lot of considerations involved with each choice, but that is the basic tradeoff to be made.

As for Saleae, it's a great product for the price, but the USB implementation leaves much to be desired.  It uses Bulk transfers when Isochronous would be much more reliable.  That's the whole reason you cannot always get high sample rates to work every time with logic.  Also, Saleae has no OSX experience, so their troubles there should not really guide anyone else's design decisions.  USB client software under OSX is much easier than Windows because you do not need a driver.  If there are problems with libUSB, then it must not be the right choice.  OSX has its own USB API which is fairly easy to use and very high performance.  Don't get me wrong: I like logic and it is a bargain for the price - I use one!  But we should not be evaluating USB and OSX based upon the lack of success from one very small company.

Still, despite the particular problems that Saleae has had, the Cypress EZ-FX2 might be a good choice if High Speed is needed.  I am not aware of any High Speed PIC, but I might be forgetting a model.  Beware that High Speed is more difficult than Full Speed, both in terms of device firmware and on the host...
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 11, 2010, 11:32:18 am
The postman brought these boards (pic), and some others. I'll get it partly stuffed today, I don't have the SMD header yet, any suggestions are welcome.

Sjaak - you need me to solder anything before I send one to you?
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 11, 2010, 11:47:36 am
At least the pic ;). I got most of the other stuff at home.

Could you email/pm me the partlist, then I get the remaining from the electro store this afternoon.

Thanks, man!
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 11, 2010, 01:02:01 pm
There isn't one yet, for now I'll just do it from memory :) you can export it from the eagle files, should be around here somewhere. some of the parts are unknown yet and might cause trouble, like the vpu fets. I'll choose some and get them soon, but they aren't critical to a power up test.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 11, 2010, 06:02:52 pm
Stuffed part of the PCB and tried to connect with a programmer. No go, the ENVREG pin is connected to ground, it should be connected to power, this is opposite how it was on the 24fj64ga002 on the Bus Pirate. I drilled out the ground plane around the pin, scraped off the mask, then soldered a wire to power. After that I could connect to the PIC with an ICD2. Seems like a pretty annoying bug in the first revision, but easy to fix and we can still use these boards while waiting for rev2 to arrive... That's why I'm building it out first before Seeed makes the first 10 experimental developer prototypes.

Pictures of my test board and Sjaaks board attached:) Sjaak - do you need me to drill a copper island in the board so you can make the fly wire?
Title: Re: Bus Pirate v4 hardware
Post by: vimark on August 11, 2010, 08:14:06 pm
Hmm... bug noted for the next revision
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 11, 2010, 08:25:56 pm
@ian: Please do :D I'm stil busy soldering a qfn ;)

(haven't started yet, real live is kicking in atm) Think I'll start tomorrow.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 12, 2010, 01:43:59 am
[quote author="rsdio"]
[quote author="octal"]... polling the USB bus is mandatory[/quote]That is only true with the older Microchip USB Stack. The new versions support both polling and interrupt-based USB firmware options. The hardware has always supported USB interrupts for those brave enough to write their own USB stack, but now Microchip makes it much easier.

[/quote]

Hi rdsio,
I checked Microchip last USB stack and they effectively added two defines :  "USB_INTERRUPT"   and   "USB_POLLING"

As I said in previous posts, in case USB_POLLING is enabled, you need to call a function named USBDeviceTasks()  to poll connection and remain connected to host (PC) side.
When USB_INTERRUPT is enabled, they simply use a generic interrupt handler to call this function

Code: [Select]
//These are your actual interrupt handling routines.
#pragma interrupt YourHighPriorityISRCode
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
        #if defined(USB_INTERRUPT)
        USBDeviceTasks();
        #endif

} //This return will be a "retfie fast", since this is in a #pragma interrupt section

Nothing has changed since first versions of the USB stack!!!
In some rare cases, when users had problems with some hosts (intempestive disconnection), (most) developpers where using a timer (High priority) interrupt to call this routine as needed.

This does not change the original problem, using an USB enabled PIC introduce two majors problems (desing architectural points):
1- Interrupt handling to keep USB connection alive means that all firmware functions need to be written with that in mind (no blocking functions)
2- Hardware signals generators or managers (hardSPI/ HardI2C, ...) will not suffer from that, but software protocols may become non deterministic relatively to the timing routines!!!

I think if a $2~$4 chip avoids all that and makes the firmware completely independent of the communication channel with PC it's really worth it!!!
Title: Re: Bus Pirate v4 hardware
Post by: psyko on August 12, 2010, 06:43:38 am
Hi, just a question i looking around on the forum but i didnt find a firmware for the V4 hardware. im not a pro of your programmation language but im almost sure the firmware for the pic24fj64 is not compatible with the pic24fj256, not completely.

did i miss a part in this forum or i just looking on the wrong place for it ??
any demo firmware for V4 hardware i can use to for testing my board

thank and good job all
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 12, 2010, 07:50:35 am
the v4 prototype isn't even built :) so there isn't a firmware yet. the design isn't even final yet and has the possibility to be abondonned. This thread is to explore the new design.

If you aren't a programmer/adventurer please wait for the final design.

@octal: i haven't studied the microchip stack, but i've looked into the datasheet of usb hatdware. Afaik the hardware takes really care of stuff and puts less stress on the firmware. 10ms are a lot of instructioncycles and most protocols aren't that timecritical. As said before the current fw is very sloopy with timings (take a la and see it)
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 12, 2010, 08:35:48 am
You're really preaching to the choir, getting me to work on the prototype was like pulling teeth. v3, with USB chip, is still available and will continue to be available after any v4 hardware is launched, so you will still have the UART+USB chip option if you like.

The flip side of your passionate argument for a USB chip is all the folks who feel like integrated USB is better/faster/cheaper. See for example this thread (among dozens) where some says 'why don't you just drop in a USB chip', like it's no big thing, and I'm, like, no way eva':
http://dangerousprototypes.com/forum/in ... opic=503.0 (http://dangerousprototypes.com/forum/index.php?topic=503.0)

This is just a development prototype, we're not committed, we're just having fun. The boards are made, Sjaak and I (and anyone else daring enough) can try the first boards and help work out the initial bugs (like the VREG problem), then we'll have Seeed make 10 initial units for any developers who want to play with the hardware.

Quote
This does not change the original problem, using an USB enabled PIC introduce two majors problems (desing architectural points):
1- Interrupt handling to keep USB connection alive means that all firmware functions need to be written with that in mind (no blocking functions)
2- Hardware signals generators or managers (hardSPI/ HardI2C, ...) will not suffer from that, but software protocols may become non deterministic relatively to the timing routines!!!

I think if a $2~$4 chip avoids all that and makes the firmware completely independent of the communication channel with PC it's really worth it!!!

Point 1 I don't understand, because blocking calls would be interrupted. I understand that's a problem for blocking loops if you use the polling method (such as USB IR Toy, etc). It might throw off loop related delays if the interrupt takes a long time to service, but we could use timers instead to help control the overall impact.

For point 2 I would really recommend you check out the Bus Pirate v3 output on a logic analyzer before you say it's "completely independent of the communication channel with PC". It is a dirty, dirty, device. It stalls, sputters, and spits while it shovels data up the UART to the PC.

In fact, I would wager 5 cents that USB actually has less timing related delays than the current UART... The UART has to wait while each character of the user text is transmitted, USB is just a copy to memory and transaction setup, a little connection maintenance. For example if you -^^_^ the Bus Pirate will spit out a whole bunch of text between each pin state change(-_) and the clock ticks (^), each time it has to delay for the text to finish:

Code: [Select]
3WIRE> -^^_^
DATA OUTPUT, 1
CLOCK TICKS: 0x01
CLOCK TICKS: 0x01
DATA OUTPUT, 0
CLOCK TICKS: 0x01
3WIRE>

I get that the UART delay is more predictable, we choose when to send/receive and service it, but interbyte delays are wicked huge.

I certainly understand your point - I'm defending a USB test that I fought against myself for months. We're going to mess with it regardless, and can't be persuaded not to hack at it. Probably the best thing is to sit back and laugh at our folly when we encounter all these problems and revert to the FTDI232-based v4 designed previously.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 12, 2010, 09:45:13 am
Hello Ian,
Please, don't misunderstand me, I'm not defending the FTxxx chips !I know it's a real bottleneck and they bring with them their part of problems and induce some desing pollution!

I only meant that I see it better to have all logic on an independent chip, and all transport in a second chip. This second chip can be another USB (low cost) PIC, another USB/UART tranceiver, or a chip capable of  high speed  Bulk transport like the Cypress solutions ... This will introduce an overcost of few $$$ and keep desing clean.

Now for V4, you can (should) of course try direct implementation on same chip using actual proto of course (and I can help on devs, actually I'm reworking the Scripting Engine of V3).

Regards
Title: Re: Bus Pirate v4 hardware
Post by: psyko on August 14, 2010, 01:50:29 am
Sorry Sjaak,  i just ask if any firmware was post already, i got one board V4 by "Free PCB Sunday" same schematic page 1, Reply #9.
This design is maybe not finish yet but i see some good stuff. By extending the number of port, we can implement new stuff, new sensor maybe, create some "shield".
A board for Ethernet read and debug, maybe retry "Lcd", a portable Bus pirate tool, RF sensor, optocoupler board for high power circuit i dont know. For my part, i know i will use,try and experiment with my board, i will use the C30 compiler of MPLAB, i try to lern and use Perl, Python.

next, i think Octal post a good idee using a USB PIC, i see alot of project using the PIC18f2550 to create virtual Serial port, im sure other PIC can do same job or a Cypress chip.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 14, 2010, 09:51:31 am
[quote author="psyko"]
Sorry Sjaak,  i just ask if any firmware was post already, i got one board V4 by "Free PCB Sunday" same schematic page 1, Reply #9.
This design is maybe not finish yet but i see some good stuff. By extending the number of port, we can implement new stuff, new sensor maybe, create some "shield".
A board for Ethernet read and debug, maybe retry "Lcd", a portable Bus pirate tool, RF sensor, optocoupler board for high power circuit i dont know. For my part, i know i will use,try and experiment with my board, i will use the C30 compiler of MPLAB, i try to lern and use Perl, Python.

next, i think Octal post a good idee using a USB PIC, i see alot of project using the PIC18f2550 to create virtual Serial port, im sure other PIC can do same job or a Cypress chip.
[/quote]

I didn't know you have already a pcb (or that that pcb is the same as Ian is using now). I'm sorry if I offended you.

I'm waiting for my proto to arrive, but the first things will be recompiling/porting the current firmware to the v4 hardware, verify that is is working. I think then we need to redesign some stuff and perhaps remake the PCB. Problaby writing an USB stack while we wait for the new boards to arrive :D I dunno :)

There are some extension on it way and prolly will some new in the future. please feed us with your darkest disires (please keep it buspirate related!!)!

I'm still not convinced about a dedicated USB chip, but only time will tell. We still need to develop our own USB stack to take away the burden of the microchip stack.
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 15, 2010, 06:51:00 pm
Hi,
Microchip introduced a new USB chip, the PIC24FJ256GB206 that we may consider for a new Bus Pirate, it's a 64 pin chip with 256 KB of Flash and (more importantly) 96 KB of RAM
It has also a nice ammount of peripherals (3xSPI, 3xI2C, CCP .... and USB ;) )
http://www.microchip.com/wwwproducts/De ... e=en547864 (http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en547864)

Regards
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 16, 2010, 08:42:39 am
96K SRAM is an insane amount of memory. I thought 8K was huge! Thanks for pointing this out.
Title: Re: Bus Pirate v4 hardware
Post by: tayken on August 16, 2010, 09:51:35 am
Wow, sweet! And it also looks like it is pin compatible with the 24FJ256GB110 that I have on my proto board.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 16, 2010, 09:58:27 am
It's great to have an upgrade path too... With the 24FJ64GA002 we're totally stuck, there's no similar chip with more flash/ram. With the 64pin chips we could start with 128 or 196 and move to 256 later. Now we also have a RAM upgrade path, it's great.

I think 256K flash, depending on availability and cost, it probably the place to start with v4 though. That should give us plenty of room to add back the easter egg :)
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 16, 2010, 10:09:01 am
yes Ian, I agree.

I passed a long time this weekend checking datasheets and PIC24 series. 96KB is really a very good thing especially for the scripting engine, or for buffering captured data if USB is too slow to transfer data to PC.
I'm checking also to use this chip on (modified) WebPlatform!!!

as for upgrade path, I think that we should also ask ourselves if we need to stick with Microchip parts. STM32 parts offers PPS, more peripherals, more protocols implemented in hardware (IRDA, ISO... ), more options on pins (PullUp, PullDown, Res completely disabled, Open Drain, ...) ... and ALL THE SERIE is compatible (all hardware and peripherals are at same adr), so you can upgrade without changing any line of code.

Should we think to switch to another serie of MCU ?
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 16, 2010, 10:20:33 am
Microchip does a great deal on keeping the pics pincompatible. I think the 24fj256gb106 (the one on the v4 proto) has 16K of RAM.

However RAM isn't much of an issue, since the 4096 bytes buffer (which takes +- half of the current RAM usage) is mostly not used and can be reused. Perhaps to speed up for programming other chips. It could be that i don't see the benifits of 96K ;)
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 16, 2010, 10:29:11 am
[quote author="Sjaak"]
 Perhaps to speed up for programming other chips. It could be that i don't see the benifits of 96K ;)
[/quote]

if you tried to enhance the Scripting engine (adding arrays support, to read/modify/write a serie of data directly) you could see it quickly ;)
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 16, 2010, 10:51:27 am
Though I think we finally found the right chip for the Zmachine text adventure emulator :)
Title: Re: Bus Pirate v4 hardware
Post by: octal on August 16, 2010, 11:01:24 am
I don't know the Zmachine Adv Emul, but if you dont need PPS, you may also check the latests PIC32. They have up to 128KB of ram and builtin Ethernet and USB :)
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 16, 2010, 11:15:11 am
[quote author="ian"]
Though I think we finally found the right chip for the Zmachine text adventure emulator :)
[/quote]

Haha, after this we must upgrade again (because of the eateregg ;) )
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 17, 2010, 03:39:33 pm
The pullup FET controls are not connected to 5volt tolerant pins, so only the 3.3volt switch will work on this prototype. The 5volt switch will put 5volt into the pin and ruin it.
*connect 5volt (and 3.3volt) FET controls to 5volt tolerant pins.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 19, 2010, 11:52:39 am
Here's another picture of the bpv4 under test. It has all the parts except the parts of the pullup resistor circuit (4066, PNP switches) and the buttons.

I will try to get the Microchip USB stack working on it tonight if I have time.

I re-did the VDIS fix by isolating the ground plane, scraping the mast away near the MCLR resistor (ICSP header area), and made a solder bridge. Presto, no silly wire to snap off all the time. That required moving all the parts from the old board to a new board, but still worth it.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 19, 2010, 12:00:41 pm
[quote author="ian"]Presto, no silly wire to snap off all the time.[/quote]I think I know what you're talking about here.  Whenever I make white-wire repairs to a board, they seem abnormally fragile, as if I made a cold solder joint, but I know that I'm better at soldering than that.  There must be something about tiny wires and tiny SOIC or smaller pins that means they won't last.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 19, 2010, 06:55:23 pm
I've been trying to get the USB to enumerate with my minimal firmware. Windows says 'unknown usb device', which is something, but no success yet. That's usually a timing problem. I'm using a 24mhz external crystal and I'm pretty sure the config settings are correct. I'm going to take a break and I'll be back to work on it later.

The test code is in svn:
http://code.google.com/p/the-bus-pirate ... /source-v4 (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/source-v4)

you'll need to get the USB framework on your own and drag this in. You also need to use the usb descriptor file one of the Microchip CDC demos. Code is also attached.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 19, 2010, 09:14:06 pm
I spent a while trying to get this going. I went back to a fresh copy of the Microchip USB stack demo and tried with the closest matching chip (24fj256GB106 (I'm testing with the 128)). Still no connection.

Quote
    _CONFIG1( JTAGEN_OFF & GCP_OFF & GWRP_OFF & COE_OFF & FWDTEN_OFF & ICS_PGx2)
    _CONFIG2( 0xF7FF & IESO_OFF & FCKSM_CSDCMD & OSCIOFNC_ON & POSCMOD_HS & FNOSC_PRIPLL & PLLDIV_DIV6 & IOL1WAY_ON)

I'm pretty sure these are the correct config words. I'm using a 24mhz external HS/PLL crystal /6 for a 4mhz reference. I don;t know why 0xf7ff, but Microchip saw fit to do it, so I did it too.

I double checked the hardware, it runs under debug, but it never makes a connection.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 19, 2010, 09:28:54 pm
Is it really a 24Mhz I did send? And is it working properly?

That message is displayed even when the resistor is in place to distinguish between low and hispeed.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 19, 2010, 09:41:45 pm
I don't know. It's marked Y24 and :48. It doesn't work with the /6 or /12 PLL, though /12 is out of spec for the PIC. The PIC does run, it runs and runs under debug. It's hard to see where the USB is having a problem because stepping the code messes up the timing too.

Maybe I'll just have to wait for my mouser order :(
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 19, 2010, 10:38:25 pm
I tried to look over the oscilator docu. But it looks ok the things you did.

why did they make the oscillator this difficult :S Can you measure the freq on the oscillator?
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 20, 2010, 08:16:40 am
I don't have an oscope, but it the swing is enough I can measure with the OLS or the Bus Pirate frequency probe.
Title: Re: Bus Pirate v4 hardware
Post by: tayken on August 20, 2010, 08:27:24 am
[quote author="ian"]
I don't have an oscope, but it the swing is enough I can measure with the OLS or the Bus Pirate frequency probe.
[/quote]

Seems like we all need an oscilloscope for development.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 20, 2010, 11:18:08 am
[quote author="ian"]I don't have an oscope, but it the swing is enough I can measure with the OLS or the Bus Pirate frequency probe.[/quote]Do you have the Saleae logic?  For some reason I thought you did.  You could possibly measure frequency with that, even though 48 MHz is technically too high.  Due to aliasing math, you could still confirm the frequency by sampling at different available rates and calculating the sum and difference.  This all assumes that the voltage swing is enough, in which case you could just use the BP.  The OLS certainly has a high enough sampling rate.  I just wanted to mention the trick for subsampling, since I've used it once to double-check a frequency.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 23, 2010, 12:59:03 pm
With the new crystal (12MHz) it works on the first try :) Time to whip together a test firmware.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on August 23, 2010, 01:08:03 pm
I guess there was a problem with that crystal I send you.

Sorry ;)
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 23, 2010, 01:36:35 pm
Better to have something to try than just wait for the postman.
Title: Re: Bus Pirate v4 hardware
Post by: fenugrec on August 26, 2010, 09:07:52 pm
Would it still be time to add (after component selection) something like this
(http://http://img832.imageshack.us/img832/6420/servoreg2.gif)

in addition to / instead of the 3.3 / 5 selectable regulators ?
I haven't gone through all of the source code, but if I'm reading the PIC's datasheet
correctly it should be possible to use one PWM output on a spare pin, start it on device
initialization, and leave it running constantly while allowing the ratio to be selected
on demand. For low currents a small SOT23 transistor would be able to supply 100mA
at 3.3V and ~50mA down to 0 volts. Or use the next bigger size (SOT223-5) and enjoy
probably 1/2 to 1 W max power dissipation.

I know the schem I've shown restricts the max output voltage to about 4 - 4.3V, but
I figure someone needing 5V will just connect directly to +VUSB !! Full 0-5V range
would be possible but would require an additional drive transistor and a bunch of resistors.
Not a high cost, but it increases required PCB area...
Title: Re: Bus Pirate v4 hardware
Post by: fenugrec on August 27, 2010, 05:09:01 am
Great, I just lost the post I was typing, just because I tried to attach the wrong kind of file !!
Luckily, a memory dump allowed me to retrieve the precious text, in essence:


Here, I've gone forth and included my proposed software regulator in the PCB. I fit it instead of the secondary 3.3V regulator. However I only managed to fit in a SOT23 transistor. A SOT223-5 or SOT89 would possibly fit slightly lower and to the right of the current placement, I haven't tried.
Keep in mind this is very basic draft, and some testing would be required to make sure the circuit is stable and reliable. This kind of circuit can fall into oscillation if not designed properly - which currently is the case.

On a related note, I'd like to know what these are used for :
*VREGEN signal - that's just to turn on / off the regulators and save a few uA, right ?
*PUVSEL33 / PUVSEL50  signals - this is the selector to use either 3.3 or 5V ?
*VR3. This is the 5V regulator. What is its justification?

The USB bus should be an OK source of about 5V, give or take a little. Since VUSB is monitored on ADC5, I really don't see why one would need an additional 5V regulator. Especially considering this :
 + If VUSB is only slightly below 5.0+[dropout voltage], the regulator is totally useless as its pass element will be fully saturated in trying to maintain the impossible 5.
 + If the user needs a precise 5V source, relying on the USB power source to be >5V is not a great idea, and one would probably be better served with a precision reference mounted off-board.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 27, 2010, 06:05:51 am
[quote author="fenugrec"]
On a related note, I'd like to know what these are used for :
*VREGEN signal - that's just to turn on / off the regulators and save a few uA, right ?[/quote]
Low quiescent current regulators only use a few µA when nothing is connected to their output.  If something is connected, then they could draw well over 100 mA.  The USB specification requires that a device not draw more than 100 mA until after it has reported to the host that it needs more and the host gives permission by selecting a configuration which lists a higher current.  Thus, it's a good idea for the PIC to have control over the non-critical supplies (these regulators) to keep current under control until the device is fully operational.  Otherwise, your computer's USB might burn out when you attach something (it still might, if you don't get everything right).

Quote
*PUVSEL33 / PUVSEL50  signals - this is the selector to use either 3.3 or 5V ?
Yes, this is for the pull-ups, which can be programmed for either voltage.

Quote
*VR3. This is the 5V regulator. What is its justification?

The USB bus should be an OK source of about 5V, give or take a little. Since VUSB is monitored on ADC5, I really don't see why one would need an additional 5V regulator. Especially considering this :
 + If VUSB is only slightly below 5.0+[dropout voltage], the regulator is totally useless as its pass element will be fully saturated in trying to maintain the impossible 5.
 + If the user needs a precise 5V source, relying on the USB power source to be >5V is not a great idea, and one would probably be better served with a precision reference mounted off-board.
Excellent questions/observations.

First of all, the MIC5205-5.0 will not work under all valid conditions.  According to the USB specification, it is perfectly legal for an unpowered hub to deliver as little as 4.01 V to a USB device.  That's a worst-case transient value, but the average is only a little higher, at 4.35 V.  But the MIC5205 requires that its Vin be greater than the desired Vout by at least 10 mV to 350 mV.  In other words, this part of the circuit would fail USB validation testing!

Second of all, an off-board source is not needed.  Boost regulators, such as the Maxim MAX1595 (http://http://www.maxim-ic.com/datasheet/index.mvp/id/3061), MAX682 (http://http://www.maxim-ic.com/datasheet/index.mvp/id/1837) or MAX1797 (http://http://www.maxim-ic.com/datasheet/index.mvp/id/2377), can produce a rather accurate 5.0 V source from relatively small voltages, and quite easily with 4 V.  All they require is a tiny SMD capacitor or inductor to achieve the boost.  The only caveat is that no part is 100% efficient, so some of the meager 0.5 W maximum that USB offers would be wasted.  i.e. Don't depend upon getting 500 mA at 5 V.  The MAX1595 is only rated at 125 mA output current, but it could take over 200 mA from the USB to achieve that.

P.S.  A precision (voltage) reference is not the same thing as a voltage regulator.  A reference cannot deliver significant current by any stretch.  A regulator is not very precise, and would not make a very good reference, e.g., for A/D.  You could combine the two such that the regulator provides the current and the reference keeps the regulator adjusted precisely.  Some regulators have a built-in reference, but a very high precision one could still be added via an op-amp feedback loop.
Title: Re: Bus Pirate v4 hardware
Post by: fenugrec on August 27, 2010, 07:03:13 am
Hi,

[quote author="rsdio"]
Low quiescent current regulators only use a few µA when nothing is connected to their output.  If something is connected, then they could draw well over 100 mA.  The USB specification requires that a device not draw more than 100 mA until after it has reported to the host that it needs more and the host gives permission by selecting a configuration which lists a higher current.  Thus, it's a good idea for the PIC to have control over the non-critical supplies (these regulators) to keep current under control until the device is fully operational.  Otherwise, your computer's USB might burn out when you attach something (it still might, if you don't get everything right).
[/quote]

You have a good point about the USB current draw. I was just accounting for the quiescent current; I don't have the MIC datasheet handy but it probably is <5mA.

....
Quote
First of all, the MIC5205-5.0 will not work under all valid conditions.  According to the USB specification, it is perfectly legal for an unpowered hub to deliver as little as 4.01 V to a USB device.  That's a worst-case transient value, but the average is only a little higher, at 4.35 V.  But the MIC5205 requires that its Vin be greater than the desired Vout by at least 10 mV to 350 mV.  In other words, this part of the circuit would fail USB validation testing!

That's my point - I was evaluating the necessity of having a 5V regulator on a board powered by... 5V !
The only times it would regulate would be when the USB bus is supplying appreciably more than 5V. In most cases I've dealt with though, the ~5V supplied by the USB port is quite good enough to act as a generic, low(ish) power supply for microcontrollers, small projects, etc.
So my question would rather be : who would need the onboard 5V regulator, and in which context ?
I'm thinking it possibly isn't needed by a vast majority of users ?

Or, if by design, BP is required to provide a stable 5V source, then as you mentioned a buck-boost converter would be needed to cater to the wide range of VUSB.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 27, 2010, 07:27:05 am
[quote author="fenugrec"]You have a good point about the USB current draw. I was just accounting for the quiescent current; I don't have the MIC datasheet handy but it probably is <5mA.[/quote]To phrase my point more concisely, the Enable input is not designed to get rid of the quiescent current, it's designed to stop the attached load from drawing any current.  It basically acts as a soft power switch.

The Bus Pirate has the feature of allowing other devices to be attached and potentially take their power from the Bus Pirate, and thus you can never guarantee how much current will flow.

Quote
That's my point - I was evaluating the necessity of having a 5V regulator on a board powered by... 5V !
The only times it would regulate would be when the USB bus is supplying appreciably more than 5V. In most cases I've dealt with though, the ~5V supplied by the USB port is quite good enough to act as a generic, low(ish) power supply for microcontrollers, small projects, etc.
So my question would rather be : who would need the onboard 5V regulator, and in which context ?
I'm thinking it possibly isn't needed by a vast majority of users ?
The problem is that you really need to pay careful attention to the requirements of the chips you're working with.  The vast majority of 5 V chips are only specified to work with 5 V +/-5%, meaning 4.75 V to 5.25 V, but USB will not deliver this in all situations.  Why take the risk of spending money on a design when it might not work when you need to add an unpowered USB hub in order to expand your ports?

Thanks for bringing up this topic.  I had not reviewed the Bus Pirate schematic in detail before now, or I would have pointed out the problem with the 5 V regulator.  Basically, the Bus Pirate needs to be redesigned with a 5 V boost regulator instead of a standard regulator.  Otherwise, as you point out, there is not much use in having a feature which could so easily fail to work properly, given the USB environment.
Title: Re: Bus Pirate v4 hardware
Post by: fenugrec on August 27, 2010, 07:42:06 am
[quote author="rsdio"]To phrase my point more concisely, the Enable input is not designed to get rid of the quiescent current, it's designed to stop the attached load from drawing any current.  It basically acts as a soft power switch.

The Bus Pirate has the feature of allowing other devices to be attached and potentially take their power from the Bus Pirate, and thus you can never guarantee how much current will flow.

[...]
The problem is that you really need to pay careful attention to the requirements of the chips you're working with.  The vast majority of 5 V chips are only specified to work with 5 V +/-5%, meaning 4.75 V to 5.25 V, but USB will not deliver this in all situations.  Why take the risk of spending money on a design when it might not work when you need to add an unpowered USB hub in order to expand your ports?

Thanks for bringing up this topic.  I had not reviewed the Bus Pirate schematic in detail before now, or I would have pointed out the problem with the 5 V regulator.  Basically, the Bus Pirate needs to be redesigned with a 5 V boost regulator instead of a standard regulator.  Otherwise, as you point out, there is not much use in having a feature which could so easily fail to work properly, given the USB environment.
[/quote]

Well answered, thanks. I think it's a good idea considering the wide, unpredictable variety of "gimmicks" which are likely to be connected to BP...
Oh, it's going to be fun fitting an SMPS on that already "comfortably crowded" PCB ! Don't forget generous ground planes !
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 27, 2010, 08:06:13 am
[quote author="fenugrec"]Oh, it's going to be fun fitting an SMPS on that already "comfortably crowded" PCB ! Don't forget generous ground planes ![/quote]I think you may be the only one wanting to add an SMPS.  There is a separate DP project to create a PS, but that's not a BP.  I think it was you who suggested a PWM-controlled supply, but maybe that was someone else.

In any case, the MAX1595 only needs three small SMD caps, and it smaller than an 8-pin SOIC, so it can fit in almost the same space as the questionable 5V regulator.
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 27, 2010, 08:17:38 am
Thanks for your feedback, I read all your comments with great interest. There's always room for new stuff in the next hardware update.

Quote
*VREGEN signal - that's just to turn on / off the regulators and save a few uA, right ?

It's not to save power, it's to switch the regulators off so everything is in a safe high-impedance state when the Bus Pirate starts up. The idea is that the BUs Pirate doesn't interact with a test circuit until specifically commanded to.

Quote
*PUVSEL33 / PUVSEL50  signals - this is the selector to use either 3.3 or 5V ?

This is a new feature that's in development for v4. The v3 hardware fed the on-board pullup resistors from an external pin on the IO header. This confuses tons of people, so we added a high-side switches so a 3.3 or 5volt pullup can be selected from software. More about the on-board pullups:
http://dangerousprototypes.com/docs/Pra ... _resistors (http://dangerousprototypes.com/docs/Practical_guide_to_Bus_Pirate_pull-up_resistors)

Quote
*VR3. This is the 5V regulator. What is its justification?
1. Enable-able ~5votl supply, 2. regulate USB over 5.0volts, 3. in practice its a cheap part that seems to work ok in this capacity. It should also (depending on part and SPECs) provide over-current, short-circuit, and over-heat protection.

The MAX1595 looks really interesting, and I'd be willing to try something like that. The MAX1595 is (according to shifty Maxim) $1.43 @ 1000. I could only find the msop8 version at Digikey for $4.05 (http://http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&WT.z_homepage_link=hp_go_button&KeyWords=MAX1595&x=0&y=0). Even at the 1000 price (remember, we only make 100s of Bus Pirates), it's 10x more expensive than the 5volt regulator.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 27, 2010, 11:30:21 am
[quote author="ian"]The MAX1595 looks really interesting, and I'd be willing to try something like that. The MAX1595 is (according to shifty Maxim) $1.43 @ 1000. I could only find the msop8 version at Digikey for $4.05 (http://http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&WT.z_homepage_link=hp_go_button&KeyWords=MAX1595&x=0&y=0). Even at the 1000 price (remember, we only make 100s of Bus Pirates), it's 10x more expensive than the 5volt regulator.[/quote]Point taken.  I have also suffered from the difficulty in obtaining Maxim parts, such as an RS-485 receiver that I ended up getting 9 free samples to meet my total needs.  But despite how cheap the Micrel part may be, it just won't work in all USB setups.

You might want to look into Linear, or maybe Texas Instruments.  I'm sure lots of companies make boost regulators for the USB world.  I recall considering Linear for my commercial design which used the MAX1595.  I looked at the LT1268 and LTC1157, but forget the prices.  It seems like Texas Instruments should have something to offer, but I do not recall any part numbers.  There has to be something that will work, even if you roll your own with the PWM on the PIC.
Title: Re: Bus Pirate v4 hardware
Post by: fenugrec on August 27, 2010, 05:46:09 pm
[quote author="rsdio"]
I think you may be the only one wanting to add an SMPS.
[/quote]

Not specifically, I just wanted to remove the linear 5V reg - but you and Ian justified its presence, so I rest my case !
I indeed suggested the PWM driven supply to replace the secondary 3.3 regulator and provide more functionality. (That's also what lead me to the 5V questions)
Incidentally, it would also act as a switchable power supply : just set the PWM to 0% and the load is effectively off, the only current draw being the op-amp's quiescent current and the transistor leakage

Does any of you have an idea whether there's room in the software to add the PWM reg I've been rambling
on about ? I figure it would be pretty simple, but I'm not familiar with PICs > 18F .... Give me a 10F200 however and
I'll get it working in no time !
Title: Re: Bus Pirate v4 hardware
Post by: ian on August 27, 2010, 06:00:26 pm
There's a couple pin-assignable hardware PWMs in the pic24s :) The problem is going to be the extra pins though, but there's plenty of them on the V4.
Title: Re: Bus Pirate v4 hardware
Post by: honken on August 29, 2010, 02:36:19 pm
I just had a thought.
The usb connector on the board actually has a footprint of mini-A/B.
Couldn't we then route the ID pin of the connector to the unused RP16/USBID pin of the PIC?
All other facilities i.e Vbus sensor/detector is already in place except for supply.
The supply could be taken care of by a "hacked" usb-otg cable.
Then there would be a future possibility of USB-OTG.
That could be used for rrreeeaaallllllyyy long BASIC scripts via external hard drive :-)
Or connect a hub, keyboard and the usb lcd backpack developed in another thread and then we have a handheld field testing device.
Firmware wanting of course.

But I would think it'll make the v4 hardware even more future proof.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on August 30, 2010, 05:11:30 am
[quote author="honken"]The usb connector on the board actually has a footprint of mini-A/B.
Couldn't we then route the ID pin of the connector to the unused RP16/USBID pin of the PIC?[/quote]I would buy the Bus Pirate v4 just for such an OTG feature, because that would make it a cheaper PIC OTG evaluation board than anything Microchip offers.  Anyone interested in getting started with OTG programming but who doesn't want to design the initial hardware could use the BPv4 as a platform for early firmware development and testing.

Quote
All other facilities i.e Vbus sensor/detector is already in place except for supply.
The supply could be taken care of by a "hacked" usb-otg cable.
I think it might be better to add a header pin to the BPv4 board so that external power can be applied directly, and then the OTG function could operate without a hacked cable.  OTG only needs to provide 100 mA, so it shouldn't be much of an issue.  This might be more complicated than I think, though.

Quote
Then there would be a future possibility of USB-OTG.
That could be used for rrreeeaaallllllyyy long BASIC scripts via external hard drive :-)
Or connect a hub, keyboard and the usb lcd backpack developed in another thread and then we have a handheld field testing device.
Firmware wanting of course.
Yes, the PIC OTG host will only support the protocols that you program into the firmware.  There is no automatic hosting for OTG just because the hardware is there.  But having a cheap platform like the BPv4 would make it easier for the open community to start writing this sort of firmware.

Quote
But I would think it'll make the v4 hardware even more future proof.
At the very least, the unused pin should be connected so that brave firmware developers can get started.  In other words, I think you have a great idea thought here, and a worthwhile suggestion.
Title: Re: Bus Pirate v4 hardware
Post by: ian on September 01, 2010, 10:49:50 am
Completed board, except Q1 which is incorrectly designed. Will be testing this with Honken's USB stack ASAP :)
Title: Re: Bus Pirate v4 hardware
Post by: tayken on September 01, 2010, 12:18:36 pm
Cool! Looking forward for the results!
Title: Re: Bus Pirate v4 hardware
Post by: ian on September 01, 2010, 04:51:49 pm
Honken's USB stack is working on the IR Toy. I started to port it to 24F but there are unresolved issues. You can read about the stack and the 24F port here:
http://dangerousprototypes.com/forum/in ... 31#msg9331 (http://dangerousprototypes.com/forum/index.php?topic=937.msg9331#msg9331)
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on September 09, 2010, 10:38:50 am
By the way, the POV topic suggested using the resistor array from the BPv4 design, and that made me realize that I haven't seen the Eagle files for this yet, or even the BoM.  Have I just missed it somewhere?  (Hope this isn't the wrong topic to be asking - i.e. hope I'm not hijacking)
Title: Re: Bus Pirate v4 hardware
Post by: ian on September 09, 2010, 10:44:33 am
The eagle files are back there somewhere. I have updated files though, that aren't quite done, I'll post them today probably.
Title: Re: Bus Pirate v4 hardware
Post by: ian on September 09, 2010, 07:00:37 pm
Here's the latest board and eagle files.

Props if you can figure out a routing that lets us use a resistor array with the four resistors by the PNP transistors.

-Moved the LEDs closer to the board edge.
-Swapped MOSI and MISO text in the reference layer outside the board, I already swapped this last time (can't recall), maybe we used the old copy of the buspirate when we start to revise it.
-Change the resistor arrays with a much bigger landing pads. Added it also to dp_devices named RNETWORK.
-IO header chaged to shrouded PTH type
-USB ID pin (pin33) is now connected to USB mini-b. USB mini-b device on our dp_devices is also updated since the USB ID pin was not included in the symbol.
-AUX1 is now in included in port D. All AUX pins is now on port D
-external power header is included, I also added a diode in series
-3 10k Resistor array replaced some pull-ups exluding the MOSI and 8 voltage divider resistors on 5V and 3.3V sensors. I used the 0603-concave on 'resistor-dil' lbr.
-flipped the crystal to fit in 1 trace
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on September 09, 2010, 09:08:20 pm
[quote author="ian"]Props if you can figure out a routing that lets us use a resistor array with the four resistors by the PNP transistors.[/quote]Those resistors are half 10 kΩ and half 1 kΩ - seems like you'd need to redesign the circuit so that all resistors have the same value if you want an array.

Could you replace the PNP with FET?  Not sure whether the gate voltage could be met, but perhaps.  FET would allow deleting the bias resistor, leaving just two resistors.
Title: Re: Bus Pirate v4 hardware
Post by: ian on September 09, 2010, 09:21:22 pm
Good point. The base R can be 10K if needed.
Title: Re: Bus Pirate v4 hardware
Post by: fenugrec on September 26, 2010, 03:55:56 am
Any hope of replacing the 3.3V reg with the software-driven regulator I mentioned earlier ?
Title: Re: Bus Pirate v4 hardware
Post by: ian on September 26, 2010, 10:22:11 am
Hi fen - this version is pretty wrapped up and ready for an initial 10 or so developer units. There is definitely a place for a software driven variable power supply in future revision though. It would be great to have a step-up too so any programming voltages for PICs and AVRs could be generated on-board.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on September 26, 2010, 12:54:20 pm
There are also two extra AUX pins, which can be used to drive a transistor and coil to step up the voltage using pwm.
Title: Re: Bus Pirate v4 hardware
Post by: ian on October 22, 2010, 11:31:36 am
The latest PCB arrived. I sent Sjaak the old one yesterday :) I'll solder two today, but I don't have the resistor arrays yet.
Title: Re: Bus Pirate v4 hardware
Post by: rsdio on October 22, 2010, 11:40:15 am
Did you ever figure out a resistor array for the PNP transistor biasing?  ... or would that have to wait for a future PCB rev?  (not that it looks terribly crowded)
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on October 22, 2010, 11:45:16 am
/me cries!!

But thank you :P
Title: Re: Bus Pirate v4 hardware
Post by: ian on October 22, 2010, 11:53:43 am
Someone pointed out that we had 1K and 10K mixed, though that was just a result of the copy&paste job on the resistor (they could have been 10K too). We can reduce it in a future revision.
Title: Re: Bus Pirate v4 hardware
Post by: ian on October 22, 2010, 04:47:49 pm
I made a new one for you too :) I'm just sad because I waited all week and then sent it anyways, I could have hot-aired the parts from the old to the new, that is so much faster than making a new one (and recycling).

Whatever, as soon as the R arrays arrive I'll solder it up and send it your way.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on October 22, 2010, 04:53:32 pm
Thanks!
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on October 23, 2010, 08:58:41 pm
Came around to play a bit with the prototype. It looks very promising!

I had some trouble of getting it to compile with the microchip stack (matter of copying the right stuff to the right place), but eventually it did work. Nice to see that the memory gauge is at 55% :)
Title: Re: Bus Pirate v4 hardware
Post by: ian on October 23, 2010, 09:03:36 pm
Just wait, the 24FJ256GB106 is at 26% ;)
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on October 23, 2010, 09:10:09 pm
Har Har ;)
Title: Re: Bus Pirate v4 hardware
Post by: ian on October 23, 2010, 09:16:49 pm
The sample program is good for these chips, 6 max instead of the usual 3. I have a big box of them :) IP's resistor networks came today, I'll solder the next BPv4 up and send it off tomorrow or monday.
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on October 23, 2010, 09:26:10 pm
Thanks!

I'm fiddling a bit with the firmware to make the user interface more consistant and try to implement the new features of the hardware.
Title: Re: Bus Pirate v4 hardware
Post by: jkissl on November 10, 2010, 04:56:37 pm
How about a Serial terminal (ST) header? Just a thought. 
Title: Re: Bus Pirate v4 hardware
Post by: ian on November 10, 2010, 05:10:24 pm
The programming header pins are RPx pins, so they can be used as a serial terminal header :) Also, it has an external power supply header too :)
Title: Re: Bus Pirate v4 hardware
Post by: tayken on November 10, 2010, 06:14:20 pm
Hi Ian,

I just realized AUX pins are connected to I2C pins. Will there be an implementation with hardware I2C or will it be software as in v2go&v3? If hardware will be implemented, I can help with the code when I get out of this overloaded time interval (read: after Make Meeting: Tokyo)
Title: Re: Bus Pirate v4 hardware
Post by: ian on November 10, 2010, 07:05:39 pm
I just checked the current final schematic (going up on the wiki in a minute). We moved some pins around, and the AUX are no longer I2C. They're clustered with teh other pins so they can be included in the logic analyzer without twiddling bits around.

The main IO pins (MOSI/CLK) DO have hardware I2C in BPv4. There is also an onboard EEPROM on a third I2C channel (that you can use a macro to switch to and play with from I2C mode, so every BP has a demo from the start!).

Most of the work now is in USB, bootloader, code architecture, cleanup, and (of course) new features. The pic24 is awesome and all the old stuff is (pretty much) working on the new hardware already. Any help is greatly appreciated.

As with the programming adapter, Seeed is preparing an initial 20 units now (should be done soon), and they will be available as beta hardware to developers, case makers, etc. Reserve yours now :)
Title: Re: Bus Pirate v4 hardware
Post by: tayken on November 10, 2010, 08:19:06 pm
Hmm, possible, I looked at the latest schematic that I could find. Now I looked at the latest one and it shows that they do have hardware I2C (and 2 pins connected to the same net). One is for the EEPROM and the other one is connected to the voltage regulators as a digital output.

After the meetup, I'll try to look at the code but working on it would be better when I get the beta hardware. :) I might also produce a case for it with the laser cutter at my university but first I have to design cases for the ones I have in hand, but have to get the parts first. :)
Title: Re: Bus Pirate v4 hardware
Post by: arhi on November 10, 2010, 11:01:40 pm
[quote author="ian"]
As with the programming adapter, Seeed is preparing an initial 20 units now (should be done soon), and they will be available as beta hardware to developers, case makers, etc. Reserve yours now :)
[/quote]

they are preparing 20 units of programming adapter or 20 units of bpv4.0beta ? if they are preparing bpv4.0b - where do i reserve it (nothing on seeed yet)?
Title: Re: Bus Pirate v4 hardware
Post by: ian on November 10, 2010, 11:11:34 pm
Both. Just let me know via PM.
Title: Re: Bus Pirate v4 hardware
Post by: hardcore on November 14, 2010, 01:31:17 pm
Whilst we are on the subject of the BP V4.
can we make the holes that take the header pins larger,  so that the header can be safely removed and a right angle header used if needed.
I recently had a hell of a job getting the connector off the BP v3b board, even managed to  pull out some of the PTH holes, the pins were that tight. (even with solder wick and a desolder station!!)

Or even make the opposite corners standard holes, then the rest a size larger, I suspect the pcb manufacturer may not have good control over the PTH thickness that is being laid down.
Title: Re: Bus Pirate v4 hardware
Post by: doegox on November 26, 2010, 01:04:57 am
Just an idea now that we have "plenty" of additional I/O:
Why not having a second group of same I/O to be able to be e.g. man-in-the-middle on a bus and relay or change on the fly the data?
So we could not only "sniff" or "speak" but also "alter" bus communication.
Fits as "pirate" spirit isn't it? ;-)
Title: Re: Bus Pirate v4 hardware
Post by: quickshadow_2 on January 01, 2011, 03:08:19 pm
Hi there i'm a layman, but very interested in getting a bus pirate v4

so how long more before it is in production ?
Title: Re: Bus Pirate v4 hardware
Post by: ian on January 01, 2011, 03:14:06 pm
Could be a few months or more still.
Title: Re: Bus Pirate v4 hardware
Post by: schazamp on January 19, 2011, 04:38:32 pm
Were there compelling reasons behind the rearrangement of the pins on the 2x6 header?  It sure would be nice if the 2 of the AUX pins were down at one end together, so I could still use my 10-wire bus pirate 3 cable (with appropriate hardware hack to make it fit in the shrouded header).
Title: Re: Bus Pirate v4 hardware
Post by: Sjaak on January 19, 2011, 04:57:51 pm
[quote author="schazamp"]
Were there compelling reasons behind the rearrangement of the pins on the 2x6 header?  It sure would be nice if the 2 of the AUX pins were down at one end together, so I could still use my 10-wire bus pirate 3 cable (with appropriate hardware hack to make it fit in the shrouded header).
[/quote]

It would bend the 2 extra AUX pins. If you shave the connector at one side it would fall apart.
Title: Re: Bus Pirate v4 hardware
Post by: ian on January 19, 2011, 05:15:16 pm
The idea is to make a nice memorable progression from 1wire (MOSI) to I2C (MOSI, CLK) to SPI (first 4 wires), etc.

This is how the original Bus Pirate prototypes were, but I messed up the pin order when I made the first version with a 2x5 header. v4 'corrects' that mistake. Now pins should progress from most-common to least-common.
Title: Re: Bus Pirate v4 hardware
Post by: schazamp on January 19, 2011, 05:20:54 pm
[quote author="Sjaak"]
It would bend the 2 extra AUX pins. If you shave the connector at one side it would fall apart.
[/quote]

Ah, of course, I hadn't thought of that.

[quote author="ian"]
The idea is to make a nice memorable progression from 1wire (MOSI) to I2C (MOSI, CLK) to SPI (first 4 wires), etc.

This is how the original Bus Pirate prototypes were, but I messed up the pin order when I made the first version with a 2x5 header. v4 'corrects' that mistake. Now pins should progress from most-common to least-common.
[/quote]

That's a sensible arrangement, but I guess I'm a little surprised that the 5V and GND are at the bottom of the list.  What sort of things are the AUX pins used for?
Title: Re: Bus Pirate v4 hardware
Post by: ian on January 19, 2011, 05:34:46 pm
The order should be like this:

mosi
clk
miso
cs
aux1
aux2
adc
3v3
5v0
gnd

The original AUX pin is a user pin with frequency measurement/generation, servo driver, and general IO. The second new AUX is mostly unused at the moment, but will probably find use in JTAG debuggin and other binary modes that need an extra pin.
Title: Re: Bus Pirate v4 hardware
Post by: AdShea on May 26, 2011, 11:33:05 pm
Are the crystal loading capacitors (C7, C8) really 100nF?  That seems awfully high.
Title: Re: Re: Bus Pirate v4 hardware
Post by: rsdio on May 27, 2011, 07:46:16 am
I have not seen a BoM in a while, but you're right.  The data sheet says the maximum is 15 pF.
Title: Re: Re: Bus Pirate v4 hardware
Post by: ian on May 27, 2011, 08:21:40 am
Yup, the eagle files are wrong, we copy&pasted the caps from somewhere else and forgot to update the values. I think we used 15pf.
Title: Re: Re: Bus Pirate v4 hardware
Post by: KamalS on July 31, 2011, 12:30:06 am
[quote author="rsdio"]
Second of all, an off-board source is not needed.  Boost regulators, such as the Maxim MAX1595 (http://http://www.maxim-ic.com/datasheet/index.mvp/id/3061), MAX682 (http://http://www.maxim-ic.com/datasheet/index.mvp/id/1837) or MAX1797 (http://http://www.maxim-ic.com/datasheet/index.mvp/id/2377), can produce a rather accurate 5.0 V source from relatively small voltages, and quite easily with 4 V.  All they require is a tiny SMD capacitor or inductor to achieve the boost.  The only caveat is that no part is 100% efficient, so some of the meager 0.5 W maximum that USB offers would be wasted.  i.e. Don't depend upon getting 500 mA at 5 V.  The MAX1595 is only rated at 125 mA output current, but it could take over 200 mA from the USB to achieve that.[/quote]

I would like to use either the MAX1595 or the MAX1759 to get 5v and 3v3 off VUSB in my own version of the BP.

How noisy would the Charge Pumps make the output supply (input is VUSB, output is 5v and 3v3 that powers the BP)?

Would it be comparable to that of a LM78xx or the LM340?

Would it be more noisy than the current MIC5205?

I was wondering if adding the Charge Pumps would add too much noise to power an external ADC off it?
Title: Re: Re: Bus Pirate v4 hardware
Post by: ian on July 31, 2011, 11:06:54 am
I'm sure it would be noisier than the MIC5205s. For prototyping this is no big deal, but I would be careful powering an ADC if you care about the quality of the readings.
Title: Re: Re: Bus Pirate v4 hardware
Post by: KamalS on July 31, 2011, 08:03:33 pm
[quote author="ian"]I'm sure it would be noisier than the MIC5205s. For prototyping this is no big deal, but I would be careful powering an ADC if you care about the quality of the readings.[/quote]

ian, I am not really worried about noise affecting digital operations, but my idea about Charge Pumps being very noisy is mainly theoretical with some idea after looking at the output of the MAX232 family.

Are there any documents that compare the noise floors across linear, switching and Charge Pumps?
Title: Re: Re: Bus Pirate v4 hardware
Post by: rsdio on August 01, 2011, 09:43:42 am
[quote author="KamalS"]I would like to use either the MAX1595 or the MAX1759 to get 5v and 3v3 off VUSB in my own version of the BP.

How noisy would the Charge Pumps make the output supply (input is VUSB, output is 5v and 3v3 that powers the BP)?

Would it be comparable to that of a LM78xx or the LM340?

Would it be more noisy than the current MIC5205?

I was wondering if adding the Charge Pumps would add too much noise to power an external ADC off it?[/quote]
First of all, for 3v3 you would almost always want to use an LDO regulator. Since the minimum USB voltage is 4.01 V, that's more than enough to power any half way decent 3v3 LDO, especially one designed for USB. The MIC5205 is one of many 3v3 LDO regulators that you could choose, but I see no reason to use anything different.

Second of all, it's only the 5v power rail where you need the MAX1595 or MAX1795. That's because you need to boost the potential 4.01 V up to 5 V. Also, note that these chips only provide 5v or 3v3, not both. I realize that the chip description makes it seem like it might output both voltages at the same time, but they don't. There is a part number suffix which describes whether it's internally preset to 3v3 or 5v. Some variations of the chips are programmable by a pin, not preset, but those still only produce one output voltage at a time.

The MAX1795 is inductor based, and will provide more power, but I have a suspicion that it will produce more EM noise. The MAX1595 is capacitor based, and provides plenty of power for most circuits, but you might need more. I can't really say whether it's less noisy, but the Maxim data sheets should have graphs and full information on the voltage noise (I don't know if they can characterize the EM noise without the PCB layout).

I have designed shipping products with the MAX1595 and it works fine. However, those products use the internal PIC A/D at 3v3, so I can't say how noisy the MAX1595 is. On that board, I actually designed two 3v3 regulators and one 5v boost regulator. The second 3v3 regulator was dedicated to the analog circuitry and feeds the PIC A/D reference input pins along with the isolated analog ground. I can say that the MAX1595 produces a very accurate 5.0 V output.

I do have one product in the works which uses the MAX1595 for the 5 V analog power, and I get very low noise 12-bit A/D with this. However, note that there is plenty of filtering at the MAX1595, before the SPI connector, and then at the far end of the SPI. In this particular design, I have the A/D on a separate board, so I imagine that the 3 or 4 capacitive filters between the MAX1595 and the A/D chip probably smooth out the 5 V supply a little more than might be possible on a single, small PCB. Also note that I'm using Texas Instruments A/D chips with very accurate Reference Voltage inputs, and the overall design may reject some power supply noise. I have not shipped this product yet, so I have not done complete testing.

I recommend that you leave the evisting 3v3 supply in the BP, but use the MAX1595 for a guaranteed 5.0 V supply for your A/D. Use the output filter capacitor as recommended near the MAX1595, then make sure that the power pins for your A/D also have supply bypass filter capacitors. You might even want parallel capacitors of different values to catch low and high noise. You could even plan your PCB layout for an RC filter near the A/D section, but so far I have not needed to go to that extreme.

I assume that you are considering a 5 V only A/D, and that's why you're asking about noise. If your A/D can run on 3v3 then that would be the better choice for low noise. But if you need 5 V then just give it a try and see whether you need more supply filtering. If you plan your PCB well, you can have unpopulated capacitor sites and/or plan on a series resistor for the optional RC filter but use a 0 Ω jumper to start with (assuming that the RC would be overkill). With such multisite design, you can make one PCB and then alter the circuit filtering without going back to the fab house. If you're breadboarding or deadbugging then you can try it all out before ordering a PCB.
Title: Re: Re: Bus Pirate v4 hardware
Post by: KamalS on August 02, 2011, 02:19:59 am
First of all, THANK YOU for taking out your time and noting these points down, it helpes me clarify a lot of incomplete thoughts I had.

[quote author="rsdio"]
First of all, for 3v3 you would almost always want to use an LDO regulator. Since the minimum USB voltage is 4.01 V, that's more than enough to power any half way decent 3v3 LDO, especially one designed for USB. The MIC5205 is one of many 3v3 LDO regulators that you could choose, but I see no reason to use anything different.
[/quote]

Linear regulators traditionally have lower noise than charge pumps or switching designs.

However, I have no data to show if a LDO has significantly lower noise than a charge pump.

[quote author="rsdio"]
Second of all, it's only the 5v power rail where you need the MAX1595 or MAX1795. That's because you need to boost the potential 4.01 V up to 5 V. Also, note that these chips only provide 5v or 3v3, not both. I realize that the chip description makes it seem like it might output both voltages at the same time, but they don't. There is a part number suffix which describes whether it's internally preset to 3v3 or 5v. Some variations of the chips are programmable by a pin, not preset, but those still only produce one output voltage at a time.[/quote]

I should have not spoken before doing more reading.

The parts that I have chosen are:

MAX1595EUA50+
MAX1676EUB+

The MAX1795 requires extremely good PCB design for good regulation and I just don't have that good knowledge or experience in designing good switchers.

MAX1676 attracted me as they have a preset, pin-selectable output for 5V or 3.3V. The outputs can also be adjusted to other voltages using two external resistors.

The MAX1795 has fixed output at 5v, and has less appeal.

[quote author="rsdio"]
I do have one product in the works which uses the MAX1595 for the 5 V analog power, and I get very low noise 12-bit A/D with this. However, note that there is plenty of filtering at the MAX1595, before the SPI connector, and then at the far end of the SPI. In this particular design, I have the A/D on a separate board, so I imagine that the 3 or 4 capacitive filters between the MAX1595 and the A/D chip probably smooth out the 5 V supply a little more than might be possible on a single, small PCB. Also note that I'm using Texas Instruments A/D chips with very accurate Reference Voltage inputs, and the overall design may reject some power supply noise. I have not shipped this product yet, so I have not done complete testing.
[/quote]

Does your filter use a RLC or a RC lowpass?

I would be interested in the type of caps you find useful.

[quote author="rsdio"]
I recommend that you leave the evisting 3v3 supply in the BP, but use the MAX1595 for a guaranteed 5.0 V supply for your A/D. Use the output filter capacitor as recommended near the MAX1595, then make sure that the power pins for your A/D also have supply bypass filter capacitors. You might even want parallel capacitors of different values to catch low and high noise. You could even plan your PCB layout for an RC filter near the A/D section, but so far I have not needed to go to that extreme.
[/quote]

The MAX1676 attracts me more as having a single part that can source multiple voltages is easy for BOM and ordering. I had Maxim hit me with a 8 week leadtime and then extend it yet even more; a single part is less risky.

I guess DP would also, if they consider these, like to have some certainty.

Why didn't you use the MAX1676 instead of the MAX1595?

[quote author="rsdio"]
I assume that you are considering a 5 V only A/D, and that's why you're asking about noise. If your A/D can run on 3v3 then that would be the better choice for low noise. But if you need 5 V then just give it a try and see whether you need more supply filtering. If you plan your PCB well, you can have unpopulated capacitor sites and/or plan on a series resistor for the optional RC filter but use a 0 Ω jumper to start with (assuming that the RC would be overkill). With such multisite design, you can make one PCB and then alter the circuit filtering without going back to the fab house. If you're breadboarding or deadbugging then you can try it all out before ordering a PCB.[/quote]

I don't understand analog well, but I am assuming you are happier with running the ADC off 3v3 using internal ref. or an LDO instead of something like the MAX1676?
Title: Re: Re: Bus Pirate v4 hardware
Post by: rsdio on August 02, 2011, 10:22:59 am
[quote author="KamalS"]I have no data to show if a LDO has significantly lower noise than a charge pump.[/quote]
A charge pump does generate a frequency via an internal oscillator, so there always seems to be the risk of that waveform appearing elsewhere in your circuit as noise. There's even the possibility of EM radiation that would cause interference in another piece of electronics nearby.

I believe that an LDO is just a linear regulator based on a diode with a lower forward voltage drop. I don't think that they have any kind of internal oscillator. I have not really studied the topic, though. You can grab the spec sheets for the Microchip LDO and Maxim boost regulators and then compare the specifications for noise. If you look at enough LDO data sheets, or perhaps find an Application Note from a prominent company that makes LDO parts, then you might find more detailed information that approaches the topic from a higher level, i.e., whether LDO has more or less noise than a linear regulator.

Quote
[quote author="rsdio"]
I do have one product in the works which uses the MAX1595 for the 5 V analog power, and I get very low noise 12-bit A/D with this. However, note that there is plenty of filtering at the MAX1595, before the SPI connector, and then at the far end of the SPI. In this particular design, I have the A/D on a separate board, so I imagine that the 3 or 4 capacitive filters between the MAX1595 and the A/D chip probably smooth out the 5 V supply a little more than might be possible on a single, small PCB. Also note that I'm using Texas Instruments A/D chips with very accurate Reference Voltage inputs, and the overall design may reject some power supply noise. I have not shipped this product yet, so I have not done complete testing.

Does your filter use a RLC or a RC lowpass?[/quote]
I actually used several pure C bypass filters, with the R provided by traces and cables. The circuit is roughly:

boost, cap, trace, cap, connector, flat flexible cable, connector, cap, trace, cap, A/D.

Capacitors are placed near the chips and near the connectors, so that the long runs of traces or cables are less of an issue. Some A/D data sheets recommend parallel capacitors with large and small values for better filtering. But I have not yet needed an RC filter anywhere that it wasn't recommended by the chip manufacturer.

Quote
I would be interested in the type of caps you find useful.
I use the caps recommended in the chip data sheets. Some chips have specific part numbers, others have general qualifications, and the rest really don't give any guidance beyond the capacitance. I basically study all Application Notes and Data Sheets until I have all the requirements, then search on Mouser for the cheapest parts that meet the requirements. There are a few tricks like overrating the voltage of ceramic caps in order to get more accurate values, but that is usually moot since many regulators seem to allow a wide range of capacitance, so it doesn't seem to matter whether it's accurate. I prefer data sheets that go so far as to tell you the ESR needed on the bypass cap. While its handy to have a specific part number, I sometimes don't like those data sheets because the part they pick invariably turns out to be way more expensive than a part that sounds the same. So long as they explain how they chose that particular part number, I'm happy to substitute and save some money.

Quote
The MAX1676 attracts me more as having a single part that can source multiple voltages is easy for BOM and ordering.

Why didn't you use the MAX1676 instead of the MAX1595?
The MAX1676 is an inductor-based boost regulator. Inductors are generally more expensive than capacitors, you have to calculate the peak current capacity needed, and I believe that inductors will generate more EM interference unless they're internally shielded (some are).

The MAX1595 is a capacitor-based boost regulator, so you can get by with a much cheaper part that is more easily substituted. I also assume that there is less EM generated.

Quote
I don't understand analog well, but I am assuming you are happier with running the ADC off 3v3 using internal ref. or an LDO instead of something like the MAX1676?
My point is that if your A/D will work with 3v3, then you have the option of designing with no charge pump at all. Just an LDO. That should produce less noise.

However, some of the most interesting A/D chips require 4.75 V to 5.25 V of supply, no less, no more. Those force you to use some kind of boost regulator if USB is your sole power source.

I usually have the decision forced upon me by the application, which dictates the A/D chip and therefore also dictates whether I need boost or LDO.
Title: Re: Re: Bus Pirate v4 hardware
Post by: rsdio on August 02, 2011, 10:33:33 am
By the way, at first I thought you specifically needed 5 V. Now you're talking about being able to switch between 3.3 V and 5 V. My question is why you can't just design two fixed voltage supplies and then connect your parts to the needed voltage. Why, exactly, do you need a boost regulator that can do either 3.3 V or 5 V when you already need a 3.3 V LDO for the PIC? I'm not being critical here, because there are many different possible design needs - I'm just wondering why you don't like the fixed 5 V output of the MAX1795.
Title: Re: Re: Bus Pirate v4 hardware
Post by: KamalS on August 03, 2011, 08:00:19 pm
[quote author="rsdio"]By the way, at first I thought you specifically needed 5 V. Now you're talking about being able to switch between 3.3 V and 5 V. My question is why you can't just design two fixed voltage supplies and then connect your parts to the needed voltage. Why, exactly, do you need a boost regulator that can do either 3.3 V or 5 V when you already need a 3.3 V LDO for the PIC? I'm not being critical here, because there are many different possible design needs - I'm just wondering why you don't like the fixed 5 V output of the MAX1795.[/quote]

The simple answer was that I did not write down my thoughts exactly and also confused with a wrong part number.

My point was to derive 5v and 3v3 off VUSB, and for that I wanted to use two of the same part - one to gen the 5v and the other 3v3.

While you have good experience with the MAX1595, it's a fixed voltage regulator. This means I need to buy two different parts and cannot swap one part out for another.

The MAX1759 (not the MAX1676EUB+ that I confused you with earlier) is adjustable, and this means I can a lot of them and can swap any of them out with another one.

However, it would be cheaper to use a MAX1759 or MAX1595 to source 5v from VUSB and obtain 3v3 through an LDO, and that's what I am going to do, unless you recommend otherwise.
Title: Re: Re: Bus Pirate v4 hardware
Post by: rsdio on August 04, 2011, 01:46:11 am
[quote author="KamalS"]However, it would be cheaper to use a MAX1759 or MAX1595 to source 5v from VUSB and obtain 3v3 through an LDO, and that's what I am going to do, unless you recommend otherwise.[/quote]
Agreed: You should use two different parts. Use a typical 3v3 LDO and then pick a 5v boost regulator.

While it's generally a good idea to reuse the same part whenever possible, you still want to avoid using the same part for different tasks when there are tradeoffs and compromises.

To rephrase this in terms of your project, you need to produce two voltages, one that is lower than Vusb and one that is potentially higher. That's actually two different problems. It's not a good fit to use the same part to solve two different problems (unless it's something really simple like a resistor or discrete transistor). Regulating down to 3v3 is much better with a simple LDO because you avoid the problems of boost regulators. But an LDO will not work under typical USB conditions for 5v, and thus you need a boost regulator there.

By the way, the capacitive boost regulator works by doubling the voltage and then regulating down from there. Where your standard 3v3 LDO will only have to drop from between 4v and 5v down to 3v3, the boost regulator will have to drop from between 8v and 10v! That's a lot more heat and wasted efficiency. With only 0.5W to 2.5W available over USB, you cannot afford to generate excess heat. With some boost regulators, the system is more efficient when the input voltage is low, but significantly less efficient when the input voltage is at full levels. Unfortunately, it seems that the inductive boost regulators are more efficient, but they might produce EMI. The capacitive boost regulators seem like a reasonable compromise.
Title: Re: Re: Bus Pirate v4 hardware
Post by: KamalS on August 04, 2011, 08:19:35 am
Putting that VSB to 5v pump looks good to me.

This would be one change in my BP.

Also, what do you guys think about swapping the 4066 with 4 garden variety 2N3904 or the like NPNs?
Title: Re: Re: Bus Pirate v4 hardware
Post by: rsdio on August 05, 2011, 07:20:07 am
[quote author="KamalS"]what do you guys think about swapping the 4066 with 4 garden variety 2N3904 or the like NPNs?[/quote]
In general, for replacing a 4066 (CMOS) in an arbitrary circuit, you should really use FET instead of bipolar (NPN). A bipolar can only pass current in one direction, where an FET acts like a voltage-controlled resistor. MOSFET really is just like a digital-controlled switch. However, the 4066 is pretty cheap already: At about $0.20 for the chip, you'd need $0.05 transistors or cheaper to beat the total price.

In the specific example of the BPv4, though, the 4066 is most certainly not the most efficient design. The current only ever flows in one direction, so bipolar transistors just might work. You would have to design around any diode voltage drops, otherwise the pull-ups would not reach full voltage. I can't remember how to calculate the Collector-to-Emitter voltage drop for a transistor, and I suppose it depends upon the exact transistor, but that's probably where you need to be careful.

I suggest that you start a new topic under Bus Pirate Development, where we can discuss replacing the 4066 pullup switches with something a little more streamlined. It might even be possible to do this with a single transistor, I'm not sure.
Title: Re: 4066 replacement
Post by: fenugrec on August 15, 2013, 09:31:03 pm
Regarding eliminating the huge 4066: I don't think it's big enough an issue to start a whole thread.
Of course the simplest that comes to mind, like rsdio mentioned, is just bunching all the pull-up resistors to a common, selectable V_PU like the first drawing. Very cheap : replaces the 4066 with an extra PNP+diode for enabling V_EXT.

Problem : now, if the all pullups are disabled (Q1-3 not conducting), the data/clock lines are all connected together through various resistors. If you're running a TX/RX UART with strong drivers at both ends; probably no big deal. But if RX is driving +5V while TX is driving 0V, then the other lines are at 2.5V ! That may be a problem either for the PIC pins or other circuits connected to the unused lines, I'm really not sure of the implications.

Solution: we can add diodes in series with each pull-up resistor. That's a few extra parts (2x BAT54A this time, common-anode diodes in one SOT23) but solves the inter-connection problem. The additionnal "diode drop" shouldn't be a problem : if a 2k pull-up resistor is sourcing 1mA (unlikely), it already drops 2V so the additional ~0.3V of a schottky is small.

Is it worth it ?
extra parts = 1xPNP, 1x resistor,  2x bat54; but removed 1x4066.
Pros: smaller footprint, nearly the same cost, cheaper to repair (but how would it break ?), expandable for >4 bus
cons: extra diode drop (small con !), PCB change required, more parts

Tough call ! For my own stuff I would go with the discrete solution because I don't like, and don't stock 4066 ICs. For a production board... I think it would be cheaper to go with the IC.
[EDIT : I just remembered another problem with the discrete solution : if VEXT can be larger than 5V, it's necessary to drive its transistor with an open-collector output from the PIC, but only if the PIC pins aren't protected by diodes to VCC. If so, it needs an NPN transistor as well !! So unfortunately another point in favor of the 4066]