Faster Benchmarks With Slower Hardware


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.

22 thoughts on “Faster Benchmarks With Slower Hardware

  1. 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?

      1. …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.

        1. 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.”

  2. 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.

    1. 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).

  3. 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.)

    1. 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.

    1. 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.

    1. 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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.