Now that the firmware can build for v3, it would be nice to know whether it actually works or not. Unfortunately I only have a v4 board here...

Right now lots of small bits and pieces inside Firmware/scripts are accumulating bit rot, and possibly do not work any longer. It's time to rescue what can be saved, give it a new coat of paint, and get rid of the rest.

I brought this up over on the forum, but not much came from it (no ones fault). Perhaps we could start taking the completed builds that @USBEprom puts up on the forum, and start placing them under the releases function within github. This would allow for people to quickly see all of the newest releases, instead of having to dig through the forum posts.

The main issue with this is that @USBEprom is not sure how this is done on github (totally understandable), so doing this would require some collaboration between him and someone with more github experience.

• Prepare builds for v3 and v4.
• Test builds.
• Bump version.
• Create build packages.
• Write changelog.
• Remove old packages from repo.
• Upload builds to Github.
• Announce the release on dangerousprototypes.com.
• ...and maybe on Reddit as well?
• ...also on HN, whilst we're at it?

From the report in #7:

MACRO(1) and MACRO(2) in 2WIRE protocol they do not work.
For what I can understand MACRO(1) fails due a wrong order in the lsb/MSB of the emitted bytes.
Also MACRO(2) fails but I do not know why, perhaps for the same reason of MACRO(1).

Hello,

I just loaded the latest firmware today (commit id: feb479a) and when I open up the terminal I am getting mostly garbage characters returned from a BPv4.

I am running the screen terminal emulator on Mac OSX El Capitan.

Any idea what might be causing this? Rolling back to the 7.0 release seems to make everything happy again.

Thanks,
Ryan

Work had been started to migrate protocol usage documentation from Dangerous Prototypes' wiki to a set of markdown pages to be put in the repo, there are a few more to be migrated.

• 1-Wire
• DIO
• HD44780
• I²C
• JTAG
• PC Keyboard
• PIC
• Raw 2 wire
• Raw 3 wire
• SPI
• UART

Might be an issue with the bootloader after upgrading to v7+ (it could be just me though, I was really hacking on mine early on in the fork)

HiZ>$
Are you sure? y
BOOTLOADER

(1)>   <disconnect>   <reconnect>
HiZ>

I was looking for feature in BPv3 hardware that enable one to configure AUX pin as an H->L or L->H interrupt i/p pin and use that modify the binary bit bang protocol to generate an protocol EVENT on the interrupt arrival. This will help in scripting several h/w devices. An exact same feature was already asked in
0x90/the-bus-pirate#5

Is this feature very difficult to implement, extending the binary bit bang protocol of BP.

Thanks in Advance

What is the status of the firmware for the Bus Pirate v3b (the sparkfun model)? Does the newest version load into the chip, and am I missing any features? Running i lists version 5.10 and these modes:

1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO

Maybe migrating the USB stack from the hacked up version that is currently running (and has not been updated in a few years now) to something a tad more modern and still supported could be beneficial to the project.

M-Stack is a GPL/Apache2 licensed USB stack for PIC microcontrollers that allows for a whole lot of options, and more importantly it is being currently maintained. It is available at http://www.signal11.us/oss/m-stack/ (or https://github.com/signal11/m-stack for the source code).

OpenJTAG support is currently only enabled for v3. There were some earlier attempts at porting said code to v4 but nothing stable ever came out of it, as far as I know.

Hi guys.
Now something a bit hard that I know nothing if it is possible to do or not.
Something that would be an enhancement.
Perhaps this is not the right place to put it, however here is what it is.
Into the dangerousprototypes forum at this link it started a discussion about possible improvements for the Logic Analyzer side of the Bus Pirate (http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=6210&view=unread#p56802).
In the course of that discussion it was provided a working solution with these features:

a) sampling rates up to 16 MHz
b) additional samples when using fewer channels (up to 32k for 1 channel)
c) trigger location anywhere in the buffer
d) backward compatible with previous Logic Analyzer modes

Known Limitations:

-Selecting a trigger position of 100% will set the position at 0%. Workaround is to use 99% instead.
-Due to quirks at 4 and 8 MHz sampling, there is jitter in the samples but the long term rate is exact.
For example, 4 MHz samples should be every 250 nanoseconds, but it is actually between 187 nanoseconds
and 375 nanoseconds between samples.
-If compiled without optimization, 1 MHz sample timing is off prior to the trigger.

Possible Future Improvements:

-Allow selection of channel(s) to be recorded at higher sample sizes

Enhanced Logic Analyzer (latest).zip

All the improvements are into the SUMP.c that is inside the released package of this Enhanced Logic Analyzer release which has too the hexadecimal compiled with option 1 ready to use, the ols.profile-buspirate-enhanced.cfg file to put into the analyzer client and some instructions on how use the thing.
I wonder if could be possible to merge the content of the SUMP.c of the Enhanced Logic Analyzer into the one inside the current repository so that new features are available.
I know nothing but I understand this must to be very hard to reach.
Thanks.

I have just built a firmware for the BP3 by compiling from the current repository (February 4, 2017) with MBLAB 3.50 - XC16 1.30 putting flag only on "Do not override 'inline'" leaving the rest of its settings empty or disabled.
For Bus Pirate revision 3 optimizations 0, 2 and 3 are run out of space, the only valid ones are 1 and s, so i built by using them.
This report is about firmware optimized option 1.
My configuration.h is this:
configuration.h.TXT
(Pay attention at the fact that "github" does not allow me to attach configuration.h, not even by compressing it as zip, so I had to change its extension as txt.)

As check I began to test the SPI protocol trying to retrieve the JEDEC of different SPI chips discovering that the SPI protocol no longer works.
On all speed always I get wrong JEDEC on the terminal while actually it is totally correct on the bus as I verified by using a logic analyzer.
So timing and data exchange on the bus are always correct while the reads printed on the terminal are always wrong.
I have tried many chips and speeds but the result is always the same, SPI protocol does not work anymore in this latest firmware where the patch #23 is applied.
As countercheck I have repeated the same tests with a firmware built by compiling the repository issued immediately before the application of the patch #23 and everything works perfectly as supposed.
For what I know the only differences between the firmware that does work and the one that does not are:

The functioning firmware has not the patch #23
The functioning firmware has not the workarounds in order to unlock hardware I2C protocol

Here is the log of the terminal:
TERMINAL LOG.txt
(Note that it is not a terminal problem because I have tried different ones and the result is always the same, it does not matter the terminal program used, JEDEC is always wrong)

While here is a shot taken with the logic analyzer

I must add that in addition to the SPI memory chips the new firmware fails also with MMCs on SPI bus:
https://nada-labs.net/2010/using-the-buspirate-with-a-sd-card/

Really hoping someone can help, I am able to sniff in console mode and send and receive commands no problem with binary mode and the python scripts, but how do I go about reading the sniffed output in python ??

I know that 0x0f (15) calls the sniffer mode, but how can I read (and subsequently decode & format) the returned data packets ?

def sniff():
  i2c.port.write(b"\x0F")
  while True:
    print(i2c.response())

I tried the above but it only outputs loads of lines of a single zero, followed by carriage return ?

First to explain the facts I have to make a premise.
I know nothing if this is the right place neither the contents are pertinent, since actually what I will describe is not directly related with the firmware for the Bus Pirate or its developing.
My purpose is not even to solve the matter, the only goal is to report the thing as reference for all.
So said, in order to investigate the weird behavior in the I2C protocol while using HARDWARE mode (#54 and http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8760), I tried to use I2CEEPROMWIN whose its source code is inside the Bus_Pirate-master.zip archive at the path \Bus_Pirate-master\scripts, where exactly there is the C source named I2CEEPROMWIN.c (https://github.com/BusPirate/Bus_Pirate/blob/master/scripts/I2CEEPROMWIN.c and https://github.com/mkschreder/the-bus-pirate/blob/master/scripts/I2CEEPROMWIN.c) from which I built the executable for Windows.
Seems to me I2CEEPROMWIN.exe does not work as expected since always it fails while reading the starting address simply by omitting him and shifting up all the bytes towards the high putting in the end a dummy 0x00 value.
(Follow-up to http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8763)
Here is an example.
This is the real content of the chip:

0x01 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x1F
0x02 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x2F
0x03 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x3F
0x04 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x4F

and this is what I2CEEPROMWIN.exe actually read:

0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11
0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x11 0x1F 0x02
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22
0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x22 0x2F 0x03
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33
0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x33 0x3F 0x04
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44
0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x44 0x4F 0x00

Also seems to me I2CEEPROMWIN.exe does not work while writing because although no alarm is displayed and indeed in the end it is stated that everything is successfully done, actually the content of the chip has not been changed in any way.
From the source (I2CEEPROMWIN.c) the syntax is this:

pc_serial [com?] [chip addr 0-8] [R/W] [file] (read len) (mem addr)

That it is not clear as it states that the address must be 2 bytes, while actually using

I2CEEPROMWIN.exe com3 0 R TEST 2048 0000
I2CEEPROMWIN.exe com3 0 W TEST 2048 0000

or

I2CEEPROMWIN.exe com3 0 R TEST 2048 00
I2CEEPROMWIN.exe com3 0 W TEST 2048 00

it does not make any difference for the result.
More, [chip addr 0-8] seems to make no sense because available blocks should be from 0 to 7, not from 0 to 8.
In fact 24xx64 has a memory capacity of 8 contiguous blocks (0-7) and data bus allow for only 8 chip (0-7) for contiguous addressing across multiple devices.
That is really weird at me.
Maybe the fault is due the syntax I use that is wrong, maybe it does not work anyway.
I think that I2CEEPROMWIN can be useful for debug simplifying it through the automation of test procedures, for instance by writing and reading of massive amount of data.
In order to deeper the matter I wrote at the beginning of this message I needed to make the chip content unequivocally so that it was easy to detect anomalies.
I2CEEPROMWIN would be a great choice but instead I had to fold on BusPirate_Control and scripting in order to reach the goal.

As mentioned in #7 (comment) - the Bus Pirate can, in theory, have more than just the four SPI speeds it supports at the moment. This task is supposed to track development for such a thing.

• Read datasheets for v3 (PIC24FJ64GA004) and v4 (PIC24FJ256GB110) to get the appropriate values for the two prescalers.
• Add the entries in the SPI module and get them accessible via the serial console.
• Make the entries accessible via Binary I/O mode.
• Test on v3.
• Test on v4.

Deprecate DS30's bootloader and use the standard USB DFU flashing method allowing for potentially better integration with fwupd and interoperability with existing DFU tools.

To automate testing, something useful would be an Arduino sketch that would exercise the protocols support on the Bus Pirate board. The only drawback would be having to plug and unplug cables from the Bus Pirate to the breadboard where the Arduino is placed, but that isn't supposed to be done every time after all.

From http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=8546 mentioned in #7:

hello,
i have a big problem using i2c whit the buspirate.
it seems there is a long delay after a start condition and any ACK/NACK.
IT IS ALMOST 2mS long.
and it is getting even longer when the baud rate of the buspirate is set to a lower rate.
normal i2c devises do not seem to care, sofar i could test it.
but i am trying to talk whit a smbus device, and that one does not like those long timeouts.

Deprecate DS30's bootloader and use something that follows Microchip's AN1157 application note allowing for potentially better integration with fwupd and interoperability with existing PIC flashing programs.

When I define BP_ENABLE_PIC_SUPPORT and/or BP_ENABLE_PC_AT_KEYBOARD_SUPPORT, I get many messages like BPMSG1237 undeclared (first use in this function). This happens because messages_v4.h/messages_v4.s have more messages than messages_v3.h/messages_v3.s

I tried replacing v3 message files with v4 to add the missing messages. However there are new errors:

build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x1e): In function `.L0�':
: Link Error: Cannot access symbol (_UART1RXRecvd) with file register addressing.
Value must be less than 8192. Suggest large-data model.
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x60): In function `.L0�':
: Link Error: Cannot access symbol (_UART1TXAvailable) with file register addressing.
Value must be less than 8192. Suggest large-data model.
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x68): In function `.L0�':
: Link Error: Cannot access symbol (_UART1TXAvailable) with file register addressing.
Value must be less than 8192. Suggest large-data model.
build/BusPirate_v3/production/_ext/1472/openocd_asm.o(.text+0x6c): In function `.L0�':
: Link Error: Cannot access symbol (_UART1TXBuf) with file register addressing.
Value must be less than 8192. Suggest large-data model.
make[2]: *** [dist/BusPirate_v3/production/busPirate.X.production.hex] Error 255
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

I am sorry to keep annoy but while compiling for Bus Pirate v3 using the current November 07, 2017 repository still I have same problems as I wrote here:

#54 (comment)

Plus a dangerousprototypes' forum user noticed that some message into SPI protocol are wrong:

http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&p=67167#p67164

In detail the thing is that by performing some commands while in SPI mode then the Bus Pirate v3 use wrong messages on the terminal:

SPI>[0x9f r r r]
/CS ENABLED
WRITE: 0x9F
READ: 0xC2
READ: 0x20
READ: 0x14
\CS ENABLED
SPI>

It is only a cosmetic issue because actually, despite the wrong message, everything works as expected, but it is really annoying
For what I know the problem started with repositories dated after the April 10, 2017 because some custom firmware I build starting from that repository and I released on the dangerousprototypes' forum do not have it:

http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&p=67167#p67167

Thanks.

The binary protocol hasn't changed with the introduction of the BPv4, which is just fine but it means that the two extra AUX pins cannot be controlled or interacted with via said protocol.

Changing this would mean bump up the revision on the protocol identifier (when there is one) and add/modify commands in a slightly more sensible way than the organically-grown set that is currently available.

As usual, there are some pros and cons to consider:

Pros:

• Can fully make use of all v4 pins, including AUX1 and AUX2.
• Allow for extra speeds in SPI/I2C/UART modes that were not defined or not available on previous firmware versions.
• Clean things up so the protocol documentation can be generated at the same time as the firmware, to make sure things are in sync.

Cons:

• Makes existing code that interacts with the BP obsolete.
• Needs to support both protocol revisions (although the old set can be left out at compile time).
• The protocol does not allow version negotiation, as in, it's the BP reporting the version and not the client broadcasting which versions it can handle.

This is not set to any milestone as I guess it'll take a bit of time to reach a consensus on how this should be carried out, as at the moment there is no clear way forward.

Seems like that ds30 gui is the only option for updating bootloaders but there are three issues that need to be addressed:

1. Do we have the licence to redistribute the binary version of ds30 gui?
2. Reflashing the bootloader on Linux or on macOS might not be possible with a windows-only binary.
3. Downloading an updated version of the free ds30 gui version requires registration to a forum.

The plan here is to find a cross-platform alternative for flashing bootloaders that's not MPLAB-X IPE with a PicKit adapter.

Hi guys.
Is there somebody here who know the differences between SOFTWARE and HARDWARE mode in I2C protocol?
I thought the only one was about how synchronization is generated for the bus, but I am not sure it is just that.
In fact in the recent past thanks to agatti it was possible to free the HARDWARE mode for the I2C protocol also with Bus Pirate v3 (#39) but although in my device I have a silicon revision B8 (DEVID:0x0447 REVID:0x3046 = 24FJ64GA002 B8) I noticed a weird behavior.
The weird thing is that while doing thing on a I2C serial EEPROM via HARDWARE mode I can hit the chip only the first time, performing new access the answers are always wrong (0xFF).
So, for example, while performing read of data from a given block of memory I get them right only the first time because by repeating the command I get wrong data as 0xFF.
Take a look at this:

Bus Pirate v3.5
Community Firmware v7.1 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE KEYB LCD PIC DIO] Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA00 2 B8)
http://dangerousprototypes.com
HiZ>m

1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. KEYB
9. LCD
10. PIC
11. DIO
    x. exit(without change)

(1)>4
I2C mode:

1. Software
2. Hardware

(1)>2
Set speed:

1. 100KHz
2. 400KHz
3. 1MHz
   (1)>1
   Clutch disengaged!!!
   To finish setup, start up the power supplies with command 'W'
   Ready
   I2C>WP
   POWER SUPPLIES ON
   Clutch engaged!!!
   Pull-up resistors ON
   I2C>[0xA0 0x00][0xA1 r:256]
   I2C START BIT
   WRITE: 0xA0 ACK
   WRITE: 0x00 ACK
   I2C STOP BIT
   I2C START BIT
   WRITE: 0xA1 ACK
   READ: 0x00 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x11 ACK 0x1F
   NACK
   I2C STOP BIT
   I2C>[0xA0 0x00][0xA1 r:256]
   I2C START BIT
   WRITE: 0xA0 ACK
   WRITE: 0x00 ACK
   I2C STOP BIT
   I2C START BIT
   WRITE: 0xA1 ACK
   READ: 0x00 ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF
   NACK
   I2C STOP BIT
   I2C>

In order to fix I have to reset the Bus Pirate with command "#" and setting again all the I2C parameters.
Though 'Macro (1)' always works also by repeating it.
Despite the second and subsequent times it does not work while reading, it does while writing although on the terminal is showing wrong characters (0xFF).
Take a look at this:

I2C>[0xA0 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15]%:20[0xA0 16 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31]%:20[0xA0 32 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47]%:20[0xA0 48 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63]%:20
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
WRITE: 0x00 ACK
WRITE: 0x01 ACK
WRITE: 0x02 ACK
WRITE: 0x03 ACK
WRITE: 0x04 ACK
WRITE: 0x05 ACK
WRITE: 0x06 ACK
WRITE: 0x07 ACK
WRITE: 0x08 ACK
WRITE: 0x09 ACK
WRITE: 0x0A ACK
WRITE: 0x0B ACK
WRITE: 0x0C ACK
WRITE: 0x0D ACK
WRITE: 0x0E ACK
WRITE: 0x0F ACK
I2C STOP BIT
DELAY 20ms
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x10 ACK
WRITE: 0x10 ACK
WRITE: 0x11 ACK
WRITE: 0x12 ACK
WRITE: 0x13 ACK
WRITE: 0x14 ACK
WRITE: 0x15 ACK
WRITE: 0x16 ACK
WRITE: 0x17 ACK
WRITE: 0x18 ACK
WRITE: 0x19 ACK
WRITE: 0x1A ACK
WRITE: 0x1B ACK
WRITE: 0x1C ACK
WRITE: 0x1D ACK
WRITE: 0x1E ACK
WRITE: 0x1F ACK
I2C STOP BIT
DELAY 20ms
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x20 ACK
WRITE: 0x20 ACK
WRITE: 0x21 ACK
WRITE: 0x22 ACK
WRITE: 0x23 ACK
WRITE: 0x24 ACK
WRITE: 0x25 ACK
WRITE: 0x26 ACK
WRITE: 0x27 ACK
WRITE: 0x28 ACK
WRITE: 0x29 ACK
WRITE: 0x2A ACK
WRITE: 0x2B ACK
WRITE: 0x2C ACK
WRITE: 0x2D ACK
WRITE: 0x2E ACK
WRITE: 0x2F ACK
I2C STOP BIT
DELAY 20ms
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x30 ACK
WRITE: 0x30 ACK
WRITE: 0x31 ACK
WRITE: 0x32 ACK
WRITE: 0x33 ACK
WRITE: 0x34 ACK
WRITE: 0x35 ACK
WRITE: 0x36 ACK
WRITE: 0x37 ACK
WRITE: 0x38 ACK
WRITE: 0x39 ACK
WRITE: 0x3A ACK
WRITE: 0x3B ACK
WRITE: 0x3C ACK
WRITE: 0x3D ACK
WRITE: 0x3E ACK
WRITE: 0x3F ACK
I2C STOP BIT
DELAY 20ms
I2C>[0xA0 0][0xA1 r:256][0xA2 0][0xA3 r:256][0xA4 0][0xA5 r:256][0xA6 0][0xA7 r:256][0xA8 0][0xA9 r:256][0xAA 0][171 r:256][0xAC 0][0xAD r:256][0xAE 0][0xAF r:256]
I2C START BIT
WRITE: 0xA0 ACK
WRITE: 0x00 ACK
I2C STOP BIT
I2C START BIT
WRITE: 0xA1 ACK
READ: 0x00 ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF ACK 0xFF
NACK

Instead by using SOFTWARE mode I have not any problem performing all the commands I want without getting wrong answers.
I know that due the different PIC used the Bus Pirate v4 has always had the HARDWARE mode unlocked as opposed to v3, which also depends on the silicon revision (http://ww1.microchip.com/downloads/en/D ... 00470j.pdf).
Is there someone who owns the v4 and can confirm that it is the intended behavior?
Otherwise it is very likely to be a bug.
Thanks!

I have been trying to update the boot loaderwith this file, but the ds30 updoader says I will overwrite the bootloader on my bus pirate.

What's more, when I try to proceed, it just says that it has nothing to do. How can I fix these errors?

From the report on #7:

Seems that DIO does not work.

Bus Pirate v3.5
Community Firmware v7.0 - goo.gl/gCzQnW [HiZ 1-WIRE UART I2C SPI 2WIRE 3WIRE DIO] Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. DIO
x. exit(without change)
(1)>8
ERROR: command has no effect here
Clutch disengaged!!!
To finish setup, start up the power supplies with command 'W'
Ready
Syntax error at char 2
DIO>

As mentioned in #19, the string packer tool right now brings everything in, regardless of the configuration settings being chosen. Something smarter would be to update the string packer to read a series of flags from the command line and selectively include/exclude strings from being merged in the .s file and referenced in the .h. A quick and dirty approach for this would be to include the #defines in the .txt and let them pass through in the generated .h/.s files.

Now that Microchip made available its full-featured USB stack available under a compatible licence for inclusion in Bus Pirate's code, it's time to get things up to date on that front.

As mentioned by @andersm in #37 the code is available at https://github.com/MicrochipTech/mla_usb - which makes it sort of suitable for adding the code as a git submodule to make things easier to handle.

Since Signal11's M-Stack USB library is also available under the same licence as Microchip's, if the new USB stack proves to take up too much space or creates unnecessary issues during integration things can be moved over to that one if needed.

uart.c line ~524:
uint32_t uart_get_baud_rate(const bool quiet) {
size_t samples;
uint32_t current_sample;
uint32_t bit_sample;

BP_MISO = LOW;

bit_sample is not initialized.
Warning at compilation:
../uart.c: In function 'uart_run_macro':
../uart.c:524:12: warning: 'bit_sample' may be used uninitialized in this function

Used at line 658:
if ((samples > 0) && ((bit_sample == 0) || (bit_sample > current_sample))) {
bit_sample = current_sample;
}

Dangerous Prototypes' original firmware did not use hardware I2C due to hardware bugs in PIC24FJ64GA004 chips with revision A3 or A4.

Now that hardware I2C is enabled again and the appropriate workarounds detailed here have been applied, we need to test those on real hardware.

The catch: the code is experimental and it may or may not mess up with your hardware, just in case.

To test it, find out if your board is running one of those chips by using the i command, and if so make sure that BP_I2C_USE_HW_BUS is defined for Bus Pirate v3 in your copy of configuration.h, rebuild, and stress test I2C read/write/etc capabilities on the board.

I have just built a firmware for the BP3 by compiling from the current repository (February 4, 2017) with MBLAB 3.50 - XC16 1.30 putting flag only on "Do not override 'inline'" leaving the rest of its settings empty or disabled.
For Bus Pirate revision 3 optimizations 0, 2 and 3 are run out of space, the only valid ones are 1 and s, so i built by using them.
This report is about firmware optimized option 1.
My configuration.h is this:
configuration.h.TXT
(Pay attention at the fact that "github" does not allow me to attach configuration.h, not even by compressing it as zip, so I had to change its extension as txt.)

As check I began to test the 2WIRE protocol trying to retrieve the ATR of a SLE4442 chip card discovering that the 2WIRE protocol no longer works.
Always I get wrong ATR both by performing macros and by inserting directly the commands.

As countercheck I have repeated the same tests with a firmware created by compiling the repository issued immediately before the application of the patch #23 and everything works perfectly as supposed.
For what I know the only differences between the firmware that does work and the one that does not are:

The functioning firmware has not the patch #23
The functioning firmware has not the workarounds in order to unlock hardware I2C protocol

Here is the log of the terminal:
TERMINAL LOG.txt
(Note that it is not a terminal problem because I have tried different ones and the result is always the same, it does not matter the terminal program used, ATR is always wrong)

The real and right ATR actually it is the usual 0xA2 0x13 0x10 0x91 of that kind of cards, while this latest firmware always reads 0xAA 0x11 0x11 0x99 which is totally wrong.

What does this warning mean? I am trying to build a firmware from the latest revision of this repository. It builds successfully with the changes I have shared through my pull requests. However:

1. it tells me this warning - regardless on what optimization level I use
2. if I ignore a warning and upload this firmware to my BPv4:

HiZ>~
Disconnect any devices
Connect (ADC to +3.3V)
Space to continue <--- it freezes here!

My build environment: Ubuntu Linux 16.04.1 x64, MPLAB X v3.40 and MPLAB XC v1.26 compiler with PRO mode enabled (60 days free evaluation license, so that I could enable "3" level optimization for speed) When I build a BPv4 bootloader it does not give me this warning, boots flawlessly and feels to be more stable than previous (you could download it here)

I suspect this problem is because of incorrect linker settings or caused by configuration of a linker script, some functions code is overlapping, but still could not figure out what stuff exactly is overlapping!!

Memory regions - beginning part of p24FJ256GB106.gld linker script:

MEMORY
{
  data  (a!xr)   : ORIGIN = 0x800,         LENGTH = 0x4000
  reset          : ORIGIN = 0x0,           LENGTH = 0x4
  ivt            : ORIGIN = 0x4,           LENGTH = 0xFC
  aivt           : ORIGIN = 0x104,         LENGTH = 0xFC
  program (xr)   : ORIGIN = 0x2000,        LENGTH = 0x289F8
  config4        : ORIGIN = 0x2ABF8,       LENGTH = 0x2
  config3        : ORIGIN = 0x2ABFA,       LENGTH = 0x2
  config2        : ORIGIN = 0x2ABFC,       LENGTH = 0x2
  config1        : ORIGIN = 0x2ABFE,       LENGTH = 0x2
}

__CONFIG3 = 0x2ABFA;
__CONFIG2 = 0x2ABFC;
__CONFIG1 = 0x2ABFE;

__IVT_BASE  = 0x4;
__AIVT_BASE = 0x104;
__DATA_BASE = 0x800;
__CODE_BASE = 0x200;
... ... ...

Below is a memory map info that I receive in the end of build process:
(seems normal on the first glance, but maybe it conflicts with a linker script?)

xc16-ld 1.26 (A)

Program Memory  [Origin = 0x2000, Length = 0x289f8]
section                    address   length (PC units)   length (bytes) (dec)
-------                    -------   -----------------   --------------------
.text                       0x2000               0x8a2           0xcf3  (3315)
.const                      0x28a2               0x5de           0x8cd  (2253)
.text                       0x2e80             0x13914         0x1d59e  (120222)
.dinit                     0x16794               0x280           0x3c0  (960)
.text                      0x16a14               0x7f6           0xbf1  (3057)
.isr                       0x1720a                 0x4             0x6  (6)
.shared.dinit              0x1720e                 0x2             0x3  (3)
                 Total program memory used (bytes):        0x1fb18  (129816) 52%

Ivt Memory  [Origin = 0x4, Length = 0xfc]
section                    address   length (PC units)   length (bytes) (dec)
-------                    -------   -----------------   --------------------
.ivt                           0x4                0xfc           0x17a  (378)

Aivt Memory  [Origin = 0x104, Length = 0xfc]
section                    address   length (PC units)   length (bytes) (dec)
-------                    -------   -----------------   --------------------
.aivt                        0x104                0xfc           0x17a  (378)

Data Memory  [Origin = 0x800, Length = 0x4000]
section                    address      alignment gaps    total length  (dec)
-------                    -------      --------------    -------------------
.bss                         0x800                   0          0x1004  (4100)
.bss.end                    0x1804                   0          0x1000  (4096)
.bss                        0x2804                   0           0x468  (1128)
.data                       0x2c6c                   0           0x210  (528)
usb_data3                   0x2e7c                   0           0x100  (256)
.bss                        0x2f7c                   0            0x76  (118)
.data                       0x2ff2                   0             0xe  (14)
usb_bdt                     0x3000                   0           0x200  (512)
.bss                        0x3200                   0           0x1a8  (424)
.bss                        0x33a8                   0            0x62  (98)
.data                       0x340a                   0            0x76  (118)
.bss                        0x3480                   0            0x7a  (122)
.bss                        0x34fa                   0             0xa  (10)
usb_data                    0x3504                   0             0xa  (10)
.bss                        0x350e                   0            0x30  (48)
.data                       0x353e                   0             0x4  (4)
.bss                        0x3542                   0             0x6  (6)
                 Total data memory used (bytes):         0x2d48  (11592) 70%

Dynamic Memory Usage
region                     address                      maximum length  (dec)
------                     -------                      ---------------------
heap                             0                                   0  (0)
stack                       0x3548                              0x12b8  (4792)
                 Maximum dynamic memory (bytes):         0x12b8  (4792)

A script-driven approach has been tried here: http://www.willdonnelly.net/blog/bus-pirate-serial-wire/ . Something worthwhile would be to reimplement this natively without the need for bit-banging data lines.

As reference, seems that with firmwares built starting from repository dated July 16, 2017 and July 20, 2017, then is not possible to gain BOOTLOADER by issuing command "$".
By doing it then Bus Pirate v3 has a reset but it does not enter into the BOOTLOADER mode.
Firmwares built using option '1' and option 's'.

Hi guys, sorry for disturbing.
As mere curiosity, wanting to set a different customized default baud rate for the terminal how is it supposed to do it?
Normally the default baud rate for the Bus Pirate is set at 115200bps to communicate via terminal.
Now, if for instance wanting to set it to 2000000bps, what should be done to achieve the goal?
I have tried to build a custom firmware that has 2000000bps as default speed for the terminal, sadly without success though.
I have seen that the necessary parameters are inside source code in line 171 of main.c and line 247 of base_io.c, so I changed the latter as follow:

247 1 /* 2000000 bps */

I do not care that labels into the menu of the Bus Pirate are consistent (it would be better if they were but right now I can wait for that), only that the Bus Pirate starting itself at 2000000bps as default setting instead of the usual 115200bps, but my edit does not work.
The firmware is compiled correctly but then it is not possible to communicate with the Pirate Bus through the terminal even though the COM port is recognized right.
Luckily enough it was possible to put the right firmware by tying PGD and PGC on the Bus Pirate!
Any hint?
Thanks in advance!

I am struggling to understand bulk_trans, I thought that I could use it to read multiple bytes by repeatdly calling read_byte() in a loop but it only returns the first 3 values and then repeats the 3rd value and does not appear to read any more.

Would appreciate if anyone can help with this ?

def get_bytes():
  i2c.send_start_bit()
  i2c.bulk_trans(2, [0x16, 0x19]) ## WR ADDRESS
  i2c.send_stop_bit()
  
  out = []
  i2c.send_start_bit()
  i2c.bulk_trans(1, [0x17]) ## RD ADDRESS
  
  data_len = 20
  while(data_len):
    out.append(ord(i2c.read_byte()))
    if data_len > 1:
      i2c.send_ack()
    data_len-=1
  i2c.send_nack()
  i2c.send_stop_bit()

  print(out)

The output is:

[232, 28, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11]

But I know for sure that the value 11 is not the actual value in 17 consecutive addresses !

Would it make sense to move the hardware schematics, gerber files, and CAD models to another repository? There is plenty of stuff in there that is of limited usage for whoever wants to grab an updated firmware, after all.

Right now, BPv4's bootloader will hang after checking the state/version via pirate-loader --hello, and the only way to recover from that situation is to either power cycle the board or press the reset button on the board itself.

Would it be possible, to make (all, even older) firmware versions available via fwupd? This way, we Linux users could update/downgrade firmware VERY easily and comfortable! :D

Migrated from #10, original description follows:

What does this warning mean? I am trying to build a firmware from the latest revision of this repository. It builds successfully with the changes I have shared through my pull requests. However:

1. it tells me this warning - regardless on what optimization level I use
2. if I ignore a warning and upload this firmware to my BPv4:

HiZ>~
Disconnect any devices
Connect (ADC to +3.3V)
Space to continue <--- it freezes here!

My build environment: Ubuntu Linux 16.04.1 x64, MPLAB X v3.40 and MPLAB XC v1.26 compiler with PRO mode enabled (60 days free evaluation license, so that I could enable "3" level optimization for speed) When I build a BPv4 bootloader it does not give me this warning, boots flawlessly and feels to be more stable than previous (you could download it here)

I suspect this problem is because of incorrect linker settings or caused by configuration of a linker script, some functions code is overlapping, but still could not figure out what stuff exactly is overlapping!!

Hello there.

I'm trying to compile the firmware from source since my BP v4 came without the UART mode.

I'm using xc16 version 1.33 with MPLAB v4.05 . When I try to build & Clean (like it says on dangerous prototypes documentation) the following is shown on display:

CLEAN SUCCESSFUL (total time: 58ms)
.
.
.
"/opt/microchip/xc16/v1.33/bin/xc16-gcc" ../dp_usb/cdc.c -o build/BusPirate_v4/production/_ext/1241334144/cdc.o -c -mcpu=24FJ256GB106 -MMD -MF "build/BusPirate_v4/production/_ext/1241334144/cdc.o.d" -g -omf=elf -DXPRJ_BusPirate_v4=BusPirate_v4 -no-legacy-libc -mlarge-code -mlarge-data -O0 -I"../../microchip/include" -I".." -mcci -msmart-io=1 -Werror -Wall -msfr-warn=off -finline -save-temps -finline
nbproject/Makefile-BusPirate_v4.mk:337: recipe for target 'build/BusPirate_v4/production/_ext/1472/base.o' failed
../base.c:42:9: error: unknown configuration setting: 'COE'
make[2]: *** [build/BusPirate_v4/production/_ext/1472/base.o] Error 255
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory ''
nbproject/Makefile-BusPirate_v4.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory ''
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 3s)

Okay, so I'm having issues with flashing my BP3. Of course, the PGC/PGD trick works, but I'm trying to do this automated from with an app. The pirate-loader does the following in "fixJumps" sets the jump address to 0xa800, which is the beginning address of the DS30 bootloader. However, the DS30 bootloader sets a vector at 0xabf8 (the last 8 bytes of program memory).

Which should be used?

As an aside, I can't compile the DS30 loader to save my life. The linker does not want to put 6 bytes at 0xabf8.... I'm currently using ASM30 (v3_31), can not tell the linker version.... :<

Finally, the pirate-loader fails on all the 7.00 fw, it appears to be about the last page erase.

Want all these as separate issues????

I removed support for Bus Pirate v1A with e0f0d3b, which was for a device that is almost six years old now. I don't know how many Bus Pirate v2 users are out there, and therefore whether to remove support for it or not.

This question should probably be read as "Should we focus only on V3 and V4?", though. I personally only have one v4 unit and when performing cleanups or changes I cannot validate anything involving v3 devices. If somebody has such a thing and is willing to help out in testing, then please speak up...

A more precise way to perform delays should be implemented as this might mess with timing-sensitive protocols such as 1-Wire. Unfortunately I bricked my v4 and I'm away for a week so I can't really work on this at the moment, but before the bricking I made 1-Wire work more reliably by changing the amount of time being waited, and my logic analyser all of a sudden would detect the protocol state changes.

Something that on paper should be more accurate would be this (assuming the number of milliseconds is in W0 and that it's running on a v4 board, which means it can execute 16 instructions each microsecond):

  sub #1, w0    /*  1 / 16 */ /* Compensate for first batch of NOPs */
  nop           /*  2 / 16 */
  nop           /*  3 / 16 */
  nop           /*  4 / 16 */
  nop           /*  5 / 16 */
  nop           /*  6 / 16 */
  nop           /*  7 / 16 */
  nop           /*  8 / 16 */
  nop           /*  9 / 16 */
  nop           /* 10 / 16 */
  nop           /* 11 / 16 */
  nop           /* 12 / 16 */
  nop           /* 13 / 16 */
  nop           /* 14 / 16 */
  nop           /* 15 / 16 */
  nop           /* 16 / 16 */

.loop: 

  nop           /*  1 / 16 */
  nop           /*  2 / 16 */
  nop           /*  3 / 16 */
  nop           /*  4 / 16 */
  nop           /*  5 / 16 */
  nop           /*  6 / 16 */
  nop           /*  7 / 16 */
  nop           /*  8 / 16 */
  nop           /*  9 / 16 */
  nop           /* 10 / 16 */
  nop           /* 11 / 16 */
  nop           /* 12 / 16 */
  nop           /* 13 / 16 */

  sub #1, w0    /* 14 / 16 */
  bra z, .end   /* 15 / 16 */
  bra .loop     /* 16 / 16 */

.end:

  nop           /* 16 / 16 */ /* Align to 16 cycles for when W0 is 0 */

However I can't really try this out at the moment, if somebody with a logic analyser or a PIC simulator or a PicKit and a spare board wants to get wild with this, that'd be awesome!

As stated. I'm intending to grab a flyswatter2 from tincan tools as a more 'proper'
jtag interface for u-boot development, but wish to at least test I've got the right pinout.

I wished to update my firmware to support openocd/jtag, and cloned the repo, and
attempted to flash via
./BPv3-firmware/pyrate-loader_lnx --dev=/dev/ttyUSB0 --hex=bootloader/BPv3-Bootloader-v4.4.hex

It all goes well until it hits here: Erasing page 42, a800...ERROR [50]

As it currently stands my bus pirate is unusable. Tips for recovery/getting this done?

Right now we've got BusPirate/Bus_Pirate, BusPirate/hardware, and BusPirate/bp-cases. Maybe a bit more consistency won't hurt in the long run, so I guess we should migrate to one single repo naming scheme. Any ideas on that?

Hello, I need a JTAG programmer, and I want to know if I could use the buspirate in this case or I have to get a programmer

Right now there are two separate pirate-loader codebases, one for each model. Ideally there should be only one tool to be used for uploading both firmware types.