Skip to main content ↑ ↓
Topic: Bus Pirate AVR port? (Read 13854 times) previous topic - next topic

Bus Pirate AVR port?

Has anyone ever attempted to port or clone the Bus Pirate to an Atmel AVR microcontroller?

These days, Bus Pirate supports an awful lot of stuff. Assuming that any port or clone wouldn't be 100% identical, what what would be your "must have" features?

For me, I'd say:
  • Bus Pirate command line syntax "[ 0x80:6 r:9 ]"
  • Raw "BBIO1" mode
  • SPI
  • I2C

Re: Bus Pirate AVR port?

Reply #1 –
Perhaps a stupid question: Why you  want to port it to a different platform?

With the buspirate (in its current form) you get support (however the support is done by people in their sparetime but general most things are solved) on the hardware and software.

Re: Bus Pirate AVR port?

Reply #2 –
I don't want to start a PIC vs AVR fight. But, Atmel's AVRs do have some good features:

  • Cross platform gcc toolchain, easier for Linux/OSX users
  • A huge existing user base (Arduino)
  • The LUFA USB host/device library (allowing single chip USB-CDC bus pirate)

I noticed that Ian said that there was demand (http://fletchtronics.net/bumble-b-pirate#comment-103) in the past. Did anything ever come of this?

Re: Bus Pirate AVR port?

Reply #3 –
No, there was never any development. The PPS features of the 24F PICs are pretty sweet and hard to replicate on other hardware without fancy routing.

I'm actually in the progress of porting LUFA to the PIC :) They have a good code base, I just wish I had been able to find it earlier.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate AVR port?

Reply #4 –
Interesting, I hadn't considered the PPS issue. What's it being used for, to mux all of the PIC signals into the 2x5 header?

LUFA's great. There were murmorings of an ARM port a while back, so there is precedent for porting it to non-AVRs.

Re: Bus Pirate AVR port?

Reply #5 –
PPS assigns all the various PIC hardware modules to the 5 IO pins (SPI, frequency generator, frequency measurement, UART, and some things that are still unused. CAN too on chips that support it).
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate AVR port?

Reply #6 –
[quote author="jrt"]Has anyone ever attempted to port or clone the Bus Pirate to an Atmel AVR microcontroller?[/quote]
I have worked with a great deal of microcontrollers over the decades. There's nothing really that special about the AVR. The PIC tends to have more Flash than the corresponding AVR model. That said, I would really like to make one of my next new projects based around the AVR because I'd like to compare the experience to the work I've done on the PIC.

However, the Bus Pirate is basically a finished product. It doesn't really matter whether it is PIC or AVR because you're buying it to use the features, not to develop software for the processor. Is there really that much new development being done on the Bus Pirate firmware? Maybe that's a stupid question since I'm not a Bus Pirate customer. If the AVR world really is that much bigger, then it seems like someone would have created the AVRBP already. The beauty of open hardware is that anyone can start from the latest Bus Pirate designs and try to duplicate the features on AVR. As others have pointed out, though, the PPS feature could be a make-or-break feature.

If anything, you should buy a Bus Pirate as a workbench tool to help you develop your next AVR platform!

Re: Bus Pirate AVR port?

Reply #7 –
For me, the AVR's killer feature is the gcc port. Being able to use the same compilers and dev tools from Linux/Windows/OSX and target ARM/AVR/x86 and others simplifies things. That said, MPLAB is a very polished tool.
But, indeed, the AVR is just another 8bit micro.

I started out with programming PICs in C, but the Linux dev tools always lagged behind which limited my hardware choices.

I do own a Bus Pirate, it's a great tool. But, the firmware, syntax and ideas needn't be limited to just one hardware design. That's the beauty of open source.

Re: Bus Pirate AVR port?

Reply #8 –
Thanks for the perspective.  How do the Linux dev tools for PIC compare to AVR?  How good is the debugger (gdb?) for AVR?

I briefly used some kind of open source compiler for the PIC on my Mac, but quickly realized that I needed the debugging capabilities of MPLAB.  I did not use the portable compiler long enough to rate its code generation.  The Microchip compiler has decent code generation, but they seem to change the implementation with every release, so it's too much trouble to keep track of their progress in detail.

I was really happy that Microchip released a version of their PICkit2 programming software which runs on OSX.  I have used that more often, because once the firmware development phase is complete, there's no real need to run MPLAB just to program a new chip.  I can't remember whether they released the source for that, though, or just an OSX binary.

My goal would be to eventually be able to host PIC development from my Mac, but I sort of gave up on this.  My Macs are still all PowerPC, but I gave in and bought a used Intel Mac so I could run XP.  Still, if I could never run Windows again it would be great!

Re: Bus Pirate AVR port?

Reply #9 –
I can't really comment on the modern Linux PIC tools. Last time I tried was almost a decade ago with the PIC16F84, sdcc has probably helped things along. Even so, I imagine that getting the Bus Pirate firmware to compile wouldn't be easy.

I use gdb (openocd + JTAG) to debug ARM mcus, but haven't tried it on AVRs. It would only be possible with the higher end parts with JTAG support. But, for the kind of things I do, an LED and a scope usually suffice.

I do my AVR development from the Mac, CrossWorks have a gcc toolchain and I use avrdude with a TuxGraphics AVRUSB500 (the code that the Bus Pirate AVR programmer is derived from).

Re: Bus Pirate AVR port?

Reply #10 –
Thanks again for the details on your setup.

Based on your description, it sounds like you're not using a debugger for AVR development. In that case, it doesn't seem like AVR is much of a win over PIC.

Still, I hope to have a reason to design something with the AVR soon, so I'll keep a bookmark on this topic as a reference to the tools.

Sorry for hijacking your question. Since I don't need the Bus Pirate, I guess I don't really have an answer.  But if this is really important to you, then perhaps you could try porting the source so that it could cross-compile for multiple MCU targets.  Not sure how difficult that would be, and you'd probably need to add an abstraction layer, but it sounds like an interesting challenge.

Re: Bus Pirate AVR port?

Reply #11 –
It is an interesting challenge.

I'm working on a clone to the AT90USB162, it's still early days though.

Re: Bus Pirate AVR port?

Reply #12 –
So, to clarify; you're working on a Bus Pirate clone that's based around the AT90USB162?  Sounds cool!

If so, then keep me posted.  I'd like to follow along.  I am particularly interested in the USB variants of the AVR, so your choice is welcome.

That might be a little tight, though, with only 16K of program memory.

Re: Bus Pirate AVR port?

Reply #13 –
It's definitely going to be tight, especially with the default 2K DFU bootloader. HalfKay (http://fourwalledcubicle.com/blog/archives/235) is appealing, but it's closed source. So, there's currently no bootloader, ISP only.
The ATMEGA32-U2 is pin compatible, cheaper and has 32K/1K, so I'll probably end up with that.

Code: [Select]
AVR Memory Usage
----------------
Device: at90usb162

Program:   14110 bytes (86.1% Full)
(.text + .data + .bootloader)

Data:        418 bytes (81.6% Full)
(.data + .bss + .noinit)

That's with USB-CDC serial, USB-OpenOCD-JTAG, USB-Mass-Storage, I2C, SPI and a flashing LED.
None of the code is actually from Bus Pirate, I implemented the command syntax from the manuals, so it's not 100% identical.

The basics seem to work, here's a couple of sample scripts that I can cat > /dev/ttyACM0:

Code: [Select]
# 24LC16B, I2C EEPROM
i2c

# Write 0x10,0x20,0x30,0x40 from address 0
[0xA6 0 0 0x10 0x20 0x30 0x40]

# Set read pointer to 0
[0xA6 0 0]

# Read 4 bytes
[0xA7 r:4]

Code: [Select]
# MCP23S17, SPI 16 pin expander
spi

# Initialise
[0x40 0x0A 0x28]    # WR_REG(0) IOCONA      SEQ_OFF|HAEN

# Turn on GPIOA-0
[0x40 0x00 0x00]    # WR_REG(0) GPIOADIR    ALL_OUTPUT
[0x40 0x12 0x01]    # WR_REG(0) GPIOA       GPIOA-0

# Turn off GPIOA-0
[0x40 0x00 0x00]    # WR_REG(0) GPIOADIR    ALL_OUTPUT
[0x40 0x12 0x00]    # WR_REG(0) GPIOA       GPIOA-0


# Read GPIOA
[0x40 0x00 0xFF]    # WR_REG(0) GPIOADIR    ALL_INPUT
[0x41 0x12 r]       # RD_REG(0) GPIOA       read


It's currently running on a custom board (http://blog.hodgepig.org/articles/000006-flatworm/index.html) which has been bodged to run at 3v3. I'll make some more details and firmware available once I sort out the pullups and power supplies.

All of the features (especially USB) are ifdef'd. So, it should run on a regular Arduino or ATTINY without too much work. Though, it's worth noting that the Arduino doesn't have any UART flow control.

Re: Bus Pirate AVR port?

Reply #14 –
Thanks. I have several datasheets, including the AT90USB162, but I had not heard of the ATmega32-U2 yet. Downloading now...

I knew about the ATmega32U6, but that's for a bigger project that needs more I/O.