Dangerous Prototypes

An experimental Bus Pirate v4 (http://http://dangerousprototypes.com/docs/Bus_Pirate_v4) prototype is now available for $50 at Seeed Studio:
http://www.seeedstudio.com/depot/bus-pi ... ?cPath=174 (http://www.seeedstudio.com/depot/bus-pirate-v4-for-developers-p-740.html?cPath=174)

This batch of Bus Pirate v4 is intended only for developers and accessory designers. It comes on a green PCB to signify that it's not ready for general use.

The sales page and the blog post both say it ships without a firmware. That's not quite true. It ships with the v6 firmware posted in the other thread. It doesn't have a bootloader though, so USB upgrades are impossible. I don't want anyone who is unable to update it to buy it, so I thought it would help to advertise it as 'without firmware' to drive the point home.

The initial price is set very high to discourage non-developers. Active developers will receive a 50%-100% refund from Dangerous Prototypes.

Seeed is listing half of the developer boards. If they run out and you need one, we'll dip into the reserve boards. The reserve boards will also be used to mail the freebies.

If no major flaws are discovered in the v4 design, it can go into mass production when we have a working bootloader for USB firmware upgrades. Unfortunately this hasn't even been started, but we hope to make some progress next week.

Read about the Bus Pirate v4 design on the wiki:
http://dangerousprototypes.com/docs/Bus_Pirate_v4 (http://dangerousprototypes.com/docs/Bus_Pirate_v4)

---

such a sexy looking piece of hardware!

I will order after my finals are over. Then I will be free! (kinda :S)

What kind of help do you need?  I might have some time so if I can do something to help I will grab one.

Currently the biggest priority if getting the USB stack working and then integrating it into the Bus Pirate code and a bootloader.

Really though, any contribution is appreciated. I'll refund at least 50% (and probably 100%) of the cost of the developer BPv4s for any contributors.

Hello ian,

what version of microchipusb stack and compiler are using? I installed mplabc30 v3.25 and Microchip Application Libraries v2010-10-19 copy the usb_descriptors.c from USB demo simple, compiled fine
the PC recognize the USB device but can't communicate, debugged and seems to wait forewer at UART1RXRdy()

can you send me your usb stack and usb_descriptors.c?
Thanks.

Tested the bpv4-usbtest and same,no data receiving and the terminal can't send the data!(wait forewer)

Hi joco,

Not sure about my stack and compiler versions, they are pretty recent (last 60 days).

I'm sorry, Microchip's license doesn't allow us to redistribute the USB stack, you can only get it from them.

What version of the v4 firmware are you using? I'll try to give it a test tomorrow to check that the latest version is working correctly. I think we're all devoting efforts to get the open source USB stack going, then development on the main BPv4 firmware will resume.

You can't post for me even on private?
At least the usb_descriptors.c?

I'm using the latest svn.

Thanks.

I'm sorry, I know it's silly, but it would be an infringement of Microchip's copyright and we (as a business) have to be 100% clean about that. That's why we prefer open source :)

Ok, then
the i2c shiffer have a bug with V4 hardware because of replacement of uart to usb, please correct it
and compile with your usb stack.
I need it and i want to help you by fixing this, but if you dont't help me...

I'm sorry about your frustration, I totally share it. We are working hard here to replace the stack:
viewforum.php?f=39 (http://dangerousprototypes.com/forum/viewforum.php?f=39)

I really appreciate your offer of help, but I cannot do something illegal in exchange.

Tested the bpv4-usbtest and same,no data receiving and the terminal can't send the data!(wait forewer)...
the i2c shiffer have a bug with V4 hardware because of replacement of uart to usb, please correct it
and compile with your usb stack.

So it is specifically with the I2C sniffer? Other features work OK? The I2C sniffer uses a special ring buffer that has not been ported to USB as far as I know. I only ported the basic terminal interface so far. It sounds like you are already setup to fix this issue yourself - I can confirm that this is an issue with the BUs Pirate code and not the USB stack or compiler.

Currently, I don't plan to do any fixes with the Microchip USB stack. We're kind of holding until there is an open stack we can distribute freely, for exactly the reasons that we're having this conversation. I you need these features now, I highly recommend a Bus Pirate v3. If you got the v4 instead by mistake, please let me know, I will swap it with a v3 for you.

Ok, i found it the problem was inside usb_descriptors.c  after copy from cdc demo you must change the _EP02_OUT to _EP03_OUT;  _EP02_IN to _EP03_IN and _EP01_IN to _EP02_IN or change at usb_config.h to 2 1 2, that's all.

and here a fast hack for i2c sniffer if somebody want, not really fast, but enough for me for now, maybe
later i will optimize the code.

diff -uN b/I2C.c a/I2C.c
--- b/I2C.c	2011-02-07 14:34:15.000000000 +0200
+++ a/I2C.c	2011-02-07 14:34:01.000000000 +0200
@@ -717,14 +717,22 @@
 	{
 		if(!IFS1bits.CNIF){//check change notice interrupt
 			//user IO service
+#if !defined (BUSPIRATEV4)
 			if(U1STAbits.UTXBF == 0){//check first, don;t waste time jumping to function
+#endif
 				UARTbufService();
+#if defined (BUSPIRATEV4)
+				if( UART1RXRdy() >=1 ){
+#else
 				if(U1STAbits.URXDA == 1){//any key pressed, exit
 					dat=U1RXREG;
+#endif
 					break;
 				}		
 				continue; 
+#if !defined (BUSPIRATEV4)
 			}
+#endif
 		}
 
 		IFS1bits.CNIF=0;//clear interrupt flag
diff -uN b/baseIO.c a/baseIO.c
--- b/baseIO.c	2011-02-07 14:34:11.000000000 +0200
+++ a/baseIO.c	2011-02-07 14:34:00.000000000 +0200
@@ -469,10 +469,17 @@
 	i=readpointer+1;
 	if(i==TERMINAL_BUFFER) i=0; //check for wrap
 	if(i==writepointer) return; //buffer empty, 
-
+#if !defined (BUSPIRATEV4)
 	if(U1STAbits.UTXBF == 0){//free slot, move a byte to UART
+#else
+	if(USBUSARTIsTxTrfReady()){	
+#endif
 		readpointer=i;
+#if !defined (BUSPIRATEV4)
 		U1TXREG=bpConfig.terminalInput[readpointer];
+#else
+		UART1TX(bpConfig.terminalInput[readpointer]);
+#endif
 	}
 }
 
@@ -483,10 +490,17 @@
 		i=readpointer+1;
 		if(i==TERMINAL_BUFFER) i=0; //check for wrap
 		if(i==writepointer) return; //buffer empty, 
-	
+#if defined (BUSPIRATEV4)	
+		if(USBUSARTIsTxTrfReady()){	
+#else
 		if(U1STAbits.UTXBF == 0){//free slot, move a byte to UART
+#endif
 			readpointer=i;
+#if !defined (BUSPIRATEV4)
 			U1TXREG=bpConfig.terminalInput[readpointer];
+#else
+			UART1TX(bpConfig.terminalInput[readpointer]);
+#endif
 		}
 	}
 }

I you need these features now, I highly recommend a Bus Pirate v3. If you got the v4 instead by mistake, please let me know, I will swap it with a v3 for you.

Thanks but i know what i buying, i don't need any old hardware, at worst case i can write my own software, but make the hardware it's a little bit harder.

[quote author="ian"]I'm sorry, I know it's silly, but it would be an infringement of Microchip's copyright and we (as a business) have to be 100% clean about that. That's why we prefer open source :)[/quote]
I certainly support you being 100% clean about the Microchip license. However, I think that there is a way to build firmware based on the Microchip stack which doesn't completely suck. :-) If you write usb_descriptors.c from scratch - perhaps even assigning the file a different name - then you should be able to redistribute it without violating Microchip's license. You just need to provide an MPLAB project that references only the needed files from the USB Stack in a common installation location while referencing your own custom files locally (e.g. your USB Descriptors).

Granted, I had planned on writing this reply and suggestion a long time ago, but decided not to because there are other reasons besides the Microchip license not to distribute open source USB Descriptors. Namely, the VID and PID within the USB Descriptors are protected and should not be spread around to newbies who don't really understand the ramifications of violating the VID/PID licensing (which pisses off the USB organization, not just that tiny little Microchip company). In other words, even though there probably is a way to base an open source project around the Microchip USB Stack without distributing their usb_descriptors.c, I think it would be wise not to do it anyway.

Note: You're probably going to have to deal with the latter issue anyway once your own open source USB library is released into the wild. It seems like there's a risk that hardware cloning operations will steal the convenient VID/PID when compiling the open source, and I really worry about what that will do to Dangerous Prototypes license of that specific VID/PID. Then again, I suppose you can alter the VID/PID to 0x0000/0x0000 in the public sources to discourage absent-minded (or intentional) violations.

[quote author="rsdio"]Note: You're probably going to have to deal with the latter issue anyway once your own open source USB library is released into the wild. It seems like there's a risk that hardware cloning operations will steal the convenient VID/PID when compiling the open source, and I really worry about what that will do to Dangerous Prototypes license of that specific VID/PID. Then again, I suppose you can alter the VID/PID to 0x0000/0x0000 in the public sources to discourage absent-minded (or intentional) violations.[/quote]

i agree, allowing someone to use a DP VID/PID in an unaltered reproduction of our hardware may be ok. but if it is modified hardware/software intended for resale they should be responsible for their own VID/PID.

You're right, the descriptor has DP-sublicensed and other projects IDs included. I'll take them out of any final release that goes on google code.

Version 4 looks great man. I do have one insy binsy itty bitty thing. Although I own one of those BP cables (color coded) i
a) cannot use it with BP4
b) Perfer using female jumpers

The only complaint I got is the pins are no longer labeled on the stop of the board. so I will have to write a cheat sheet or flip it over everytime i need to connect it to something.

not a big deal at all; just perhaps in future designs it would be nice to have it back.

Good call, we need to get that on v4.

Also along those lines; how do you feel about getting rid of the colors on the 'v' menu? I say this because:

A. version 4 doesnt even have a colored cable yet, does it?
B. Sparkfun's cable colors are differnt as I understand it (reversed right?)
C. It may cause issues for users who hookup wrong polarity and such.

It might be somthing to consider; just using the PIN names and numbers instead of any color coding...

Or if you want to get crazy; we should add a 'BP Settings' screen and you can color code (or just label) the pins how you want and store it in the EEPROM) Like in the settings it has:

1. Label/Nickname PINS in the Bus Pirate interface 
Settings> 1
Labeling Pins in the BP Interface
Labels must be no more then 6 chars, longer strings will be cut automaticly.
Label PIN 1 = GND> BLACK
Label PIN 2 = 3.3v> ORANGE
....
Settings>#
...
HiZ>v
1- GND    2- 3.3v
BLACK    ORANGE
0.00 v     3.26 v

:D That would be sweet! Just thinking outside the box! Then if you have some special project and you need to label your pins to match the projects pinouts its a possibility to digitally review which pin goes where!

That would be sweet too; if there was a Macro in each mode that printed out the pins you need like:

UART>(14)
UART> PIN 0 = GND > TO Ground
UART> PIN 5 = MISO > TO RX
UART> PIN 7 = MOSI > TO TX
....

That would be really sweet! and quite easy if you like that Idea let me know; I could easily pop that in there once I get the translation thing down :D and it should always be the same macro for each mode, I think (411) would be perfect! if the macros can go above 255 which I think there ints right? so they should! (411 = information in USA I dont know about other countrys.)

We do need to address both the cable, and the colors shown in the info screen. SparkFun cable (was?) backwards from ours, and on some Bus Pirates the shroud was also positioned so that seeeds cables were flipped. Making it adjustable, or just removing it all together, solves that issue.

[quote author="BrentBXR"]
That would be sweet too; if there was a Macro in each mode that printed out the pins you need like:

UART>(14)
UART> PIN 0 = GND > TO Ground
UART> PIN 5 = MISO > TO RX
UART> PIN 7 = MOSI > TO TX
....

That would be really sweet! and quite easy if you like that Idea let me know; I could easily pop that in there once I get the translation thing down :D and it should always be the same macro for each mode, I think (411) would be perfect! if the macros can go above 255 which I think there ints right? so they should! (411 = information in USA I dont know about other countrys.)[/quote]

This is already in the 'v' screen done. Every mode has its own string in the bpstrings that get printed when the mode is active. Moving it to every protocol is a waste of programspace IMHO. I know there is atm lots of space, but we run into this before (hence the v4 :))

About the cable colouring I personally want to ditch this option completely. It gave us lots of headaches, userquestions, troubles. Ian told the very short version of the cableproblem.

Ian told the very short version of the cableproblem.

no kidding. lol. In one of the videos I did a full talk and demo of the cable issues. In editing I was like 'who would ever want to watch this?' and removed it.

Hi
How to buy your hardware please send me distributor list

[quote author="DattaHinge"]Hi
How to buy your hardware please send me distributor list[/quote]
BP v4 is available at Seeedstudio, I believe it is a primary place to get it.
However, to get it stable you would probably need to update its' firmware.
Here is a link to the latest firmware v7.0 - http://http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498