The Bus Pirate is a cheap, simple, Swiss army knife of electronic prototyping, capable of programming FPGAs, and writing to Flash memory. The uISP is possibly the most minimal way of programming Atmel chips over USB, using less than $5 in components. Although the uISP is using a slower chip and bit-banging the USB protocol, it turns out it’s actually faster when operating as a programmer for SPI Flash memories.
Most of [Necromancer]’s work involves flashing routers and the like, and he found the Bus Pirate was far too slow for his liking – he was spending the better part of four minutes to write a 2 MiB SPI Flash. Figuring he couldn’t do much worse, he wrote two firmwares for the uISP to put some data on a Flash chip, one a serial programmer, the other a much more optimized version.
Although the ATMega in the uISP is running at about half the speed as the PIC in the Bus Pirate, [Necromancer] found the optimized firmware takes nearly half the time to write to an 8 MiB Flash chip than the Bus Pirate.
It’s an impressive accomplishment, considering the Bus Pirate has a dedicated USB to serial chip, the uISP is bitbanging its USB connection, and the BP is running with a much faster clock. [Necro] thinks the problem with the Bus Pirate is the fact the bandwidth is capped to 115200 bps, or a maximum throughput of 14 kiB/s. Getting rid of this handicap and optimizing the delay loop makes the cheaper device faster.
So the atmel uses a RISC design while the PIC uses a CISC design. While the atmel chips usually do one instruction per clock cycle the PIC takes four cycle to do an instruction.
So now that I get a chance to bust out my math degree wouldn’t any atmel chip running at half the speed of a pic work twice as fast?
PIC18s come with an integral 4x PLL that means it actually could be running at ≈16MIpS when given a 16MHz clock.
…which is completely irrelevant. The buspirate uses a pic24 device, not the older 8-bit pic18 (or similar pic16, 12, 10).
The slowness of the 8-bit pic devices comes more from it being very hard to implement a c compiler for them due to having very few addressing modes and only one working register. The 16-bit devices are significantly more modern in that respect.
Unless, of course, you are running that AVR with the Arduino libs which can slow it down by a factor of 100 or more.
And how is that relevant to this conversation between two specific devices?
Embedded application performance is rarely related to clock speed or processor speed.
In the vast majority of cases it has far more to do with your peripheral hardware and how efficiently you use it in software.
Or, for anyone with any knowledge of embedded development, “Obvious Headline is Obvious.”
Relax, uISP is certified to be 146% arduino-free ;)
Erm. What were you expecting exactly? An optimised single purpose flash device with its own protocol is guaranteed to beat the Bus Pirate which was designed to be a general purpose interface tool. The 115200 baud serial link severely throttles the speed and the inefficient serial protocol doesn’t help it either.
If you want maximum speed for minimum price + effort then get a FTDI breakout board and use MPSSE to talk to the SPI device directly. Skip the uC entirely.
The role of the actual buspirate/uISP device here is just a usb2spi bridge. And buspirate’s serial protocol is pretty efficient (It’s mostly like serprog)
uISP isn’t a single purpose device, like buspirate – it’s a pretty multi-purpose tool, but with a different philosophy. When buspirate guys try to stick everything into one firmware, uISP just swaps the small firmwares as needed (true UNIX-way).
The bus pirate has an updated firmware for SPI programming. See here:
http://flashrom.org/Bus_Pirate
Yeah, I know. The results are already for the latest firmware. With the old one I left 16MiB flash writing for the night.
If you can get that kind of improvement with a device that uses bit-banged USB, I have to wonder how much better it’d get with a controller that supports USB natively, like a 32U4. (Or, if you want to get *really* fancy, something from the STM32 family.)
uISP-like dongle with STM32 is somewhere on my TODO list (since uISP is nearly 4 years old now), I even got the nice and shiny stm32f103ret6 for that case. Unfortunately, ST’s usb device stack is UTTER CRAP that is just asking to be rewritten from scratch. And I can’t find enough of free time to get it done in one long coding session.
Since I’m basing all of my projects on antares I want to make a generic usb device stack with backends to STM32F1/F4, PIC32 and vusb compatibility layer. And that just adds to the time requirements.
The Bus Pirate v4 does away with the external USB-to-serial converter, and is noticeably faster. Unfortunately, the firmware development has effectively stopped.
Given that the codebase for the Bus Pirate is shared for both v3 and v4, I’m not sure it’s entirely true to say that firmware development has effectively stopped.
Ian’s already stated there will be one final firmware release for the v3, and the v4 will be scrapped in favour of a v5 that is not using Microchip parts.
I think the cheapest AVR programmers are Chinese USBasps: ~$3 on aliexpress.
It’s also easy to re-flash them for custom v-usb projects – cheaper than a pro micro, and more IO than a trinket for arduino-compatible projects using USB.
Nah, they’re based of tiny2313, effectively rendering them quite useless. I’ve based my uISP of atmega8 since that’s the cheapest one that has bootloader support.
Definitely not true. The USBasp is based on the ATMega8. Have a look at the project site at http://www.fischl.de/usbasp !
I know, but I’ve seen a few Chinese usbasp clones that get the firmware stuffed into chaper attiny2313/4313, so I guess these are the cheapest.
You’re probabably thinking of the USBtiny.
http://dicks.home.xs4all.nl/avr/usbtiny/
They actually tend to be a bit more expensive than the usbasp clones.
One of the things I’ve done with the USBasp is use it to make a 2.4 msps logic capture device.
http://nerdralph.blogspot.ca/2014/05/24-megasamples-per-second-continuous.html