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

Re: Bus Pirate v4 hardware

Reply #45
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

Re: Bus Pirate v4 hardware

Reply #46
[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.

Re: Bus Pirate v4 hardware

Reply #47
[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  :(

Re: Bus Pirate v4 hardware

Reply #48
[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...

Re: Bus Pirate v4 hardware

Reply #49
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?
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #50
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!

Re: Bus Pirate v4 hardware

Reply #51
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.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #52
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?
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #53
Hmm... bug noted for the next revision

Re: Bus Pirate v4 hardware

Reply #54
@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.

Re: Bus Pirate v4 hardware

Reply #55
[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!!!

Re: Bus Pirate v4 hardware

Reply #56
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

Re: Bus Pirate v4 hardware

Reply #57
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)

Re: Bus Pirate v4 hardware

Reply #58
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

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.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate v4 hardware

Reply #59
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