Create an Arduino sketch to test protocols on Bus Pirate boards.

[agatti]

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.

[kallisti5]

Oh, nice idea. That would help sort out all of the issues we've been seeing. How would the test execute from the BusPirate side?

[agatti]

No real idea at the moment. I'd say that for now it can be done with two serial devices and expect, although more automation opportunities appear if an ESP8266 is used instead of a classic AVR8 on the Arduino side (embedded HTTP+WebSocket server and so on...). Custom "maintainer mode" menus can probably be added to do something similar to what self-test does at the moment - it shouldn't take much memory and as far as I know there should be enough space in the code segment for such a thing.

If protocols are generated in software rather than in hardware then the need for moving cables around the breadboard disappears, but I guess that is to come at a later stage as software implementations may have bugs of their own... :)

If you've got any idea on how this is supposed to look like or (even better) want to work on this, be my guest - I've got to finish cleaning up and documenting all the modules before I move onto OpenOCD support for v4, so this task is up for grabs :)

[pixeldoc2000]

I like the idea!

My Question is it worth the effort? Which FW Developer is interested in this, has access to the Hardward and spare time?

I "vote" for an "arduino" is solution (this includes arduino compatible devices like WeMos D1 based ob ESP8266) because its a very popuilar Device, so maybe more people would use it. If we use Software Implementation of the Protocols (like SPI, I2C, ...) maybe we can use the same Arduino Pins for most Protocols?

The BusPirate could be automated via Script (http://dangerousprototypes.com/docs/Bus_Pirate_Scripting_in_Python) in Terminal or BitBand Mode. I've played with this in the past, it works ok.

With this aproach it might be possible to control both the BF and Arduino at the same time via one Script to do something like an automated test of various Protocols.

The basic setup doesn't sound to complicated but it depends on the Goal we are aming for. If we want to test if timing / delay / frequency or else on some Protocol is correct this may become a tedious task.

How much would some basic automated test help with further Firmware Development?

[agatti]

Automated tests would help a lot with regression testing and protocol validation, to begin with. Not everyone out there has hardware for each and every protocol BP can handle, for example. Take a look at bug #23 for example - I ended up fetching an I2C flash chip the other day just to be able to fully replicate the failing scenario (will work that out after Chinese New Year, though).

At the moment the development team seems to be basically just myself, although I'd love to have more contributions from the community :) and yes, I do have access to a bunch of boards that are either WiFi or BT capable if that helps. My only limitation at the moment is lack of access to a BPv3 (wonder whether BPv3 resellers will take notice and help development on hardware they currently sell), otherwise I'm pretty much covered.

Another point to consider is that if we go for something like NodeMCU or Espruino, the barrier of entry to write regression and validation tests gets dramatically lower. In theory that would be really beneficial, but again, only time will tell.

[marsfan]

This example on the arduino website. has everything needed to configure an arduino as an i2c slave. It should take all of 30 seconds create it.

And here is a forum post on how to make an arduino act as a SPI slave.

UART should be the eaisest. I know there is a 1wire library, but I have not researched it. JTAG is probably a no go.

[JarrettR]

Some comments on this:

DP originally did a demo board to do something like this. Earlier versions used a whole bunch of chips to test the protocols, later versions basically used a PIC16F1829 breakout board to emulate them, which made it more extensible and brought the price way down. A lot of information on them seems to have been scrubbed in the four years or so since DP has done much hardware work.

Moving forward, an Arduino test harness is likely the way to go instead of developing on PIC.

A board can be made with headers to plug the Arduino directly into the Bus Pirate, which avoids error-prone wiring and makes it painless to run tests.

So what Arduino-compatible do we want to use? A traditional Arduino form factor is unnecessarily huge. (In my experience) anything ESP8266-based is unstable and lacking in I/O. How about a Teensy of some sort?

I've never used one, could someone comment on viability, or another option?

If someone wants to start writing a testbed, I'd be willing to design a board to connect up the necessary I/O to the Bus Pirate's headers - It would be cheap through OSHPark (less than $5) and only require standard female and male header pins.

[marsfan]

@JarrettR You could go with an atmega328 with the uno bootloader. Get it in Dip format, make a simple breadboard to put it on, and bam, all you need is to add testing firmware. I had already been thinking about doing this with an uno just to test mine after a firmware upgrade.

[JarrettR]

To encourage community engagement, it's usually a better idea to keep it as simple as possible, so if not a Teensy, I'd recommend something off the shelf as much as possible.

This would allow someone to set up their own BP unit testing rig by following the instructions that could be very simple, like:

1. Purchase Teensy 2.0 (or whatever)
2. Purchase adapter board by clicking this OSHPark link
3. Solder female headers to these pins, male headers to these pins
4. Plug both the Teensy and the BP into the adapter board

Wiring up or programming a homebrew Arduino requires extra effort or basic knowledge that may turn potential contributors off.

[agatti]

@JarrettR the main issue with that approach is that you're bound to use a MCU that allows to have all hardware features (UART/SPI/I2C/etc.) pins to be reassigned at will on any pin it has - which the ESP8266 as you mentioned does not allow but neither do plain Arduinos unless you start using software-based protocols, at which point you may as well stick with an ESP8266 running the Arduino libraries.

From the top of my head the only MCUs I can think of that can allow such a feature set are Silicon Labs' CIP-8051 and EFR32 ARM series. Way too expensive in module form, and not available as DIP if I recall correctly.

Can you please elaborate a bit more about the ESP8266 instability? A NodeMCU board costs next to nothing these days and if software protocol implementations have to be used, then things can be wired up with a single female/female jumper wire ribbon strip.

[agatti]

@JarrettR however, if you want to go for the board route then I guess something like this would work for v4 (AUX pins select the protocol to switch to using software SPI), although it's using an Arduino Nano V3 instead of an ESP8266. Not really fond of the mux/demux IC pair though - I'd have used a CPLD and let it handle mode switch via SPI as well, but that would probably be a bit too expensive.

[agatti]

Now, the BPv4 can use the three AUX pins as bidirectional software SPI to set up the test scenario, but how about BPv3 which does not seem to have enough pins for such a thing? I would like to use the hardware UART on the Arduino for test scenarios only and not also for control if possible.

One other option would be to have a computer drive both the BP via the USB interface and the Arduino on a software UART (in the schematics I posted earlier I see D4 and D5 can be used for that), maybe a glorified version of Expect that uses two file descriptors for I/O rather than just one. That would be compatible for v2.5, v3, and v4 - albeit it will increase complexity considerably as then three software components need to be written (the BP test I/O code, the Arduino harness, and the cross-platform Expect-like program). In that case I can probably design and lay out the board in a couple of weeks (after I get some breathing room from my work engagements), but I do not realistically have the time to work on all three software components mentioned above, design the test suite, and fix the bugs that are going to be found.

Any ideas?

[JarrettR]

I'd totally forgotten about the Arduino Mini/Micro/Nano families, that is better (read: cheaper) than the Teensy.

These have an advantage over the ESP8266/NodeMCU in the following ways:

• Chip (ATMega of some sort) is better documented and supported by the manufacturer
• Board size and pinout is more consistent than the various NodeMCU versions (0.9/1/v3/etc)
• Same price, roughly, as the NodeMCU
• More available pins - The ESP8266 only realistically has like, 4-ish usable GPIO that are not special function pins

So I'm not seeing a compelling reason to use the ESP other than "cool factor". Although it is pretty cool :)

Agreed that adding a third toolchain, whether it's Expect, Python, or even the HDL for a CPLD is a decision that shouldn't be taken lightly .For routing pins to arbitrary outputs, we're looking for something called a "crosspoint switch". That MUX pair is an interesting way to do it, and CPLDs are sometimes used, too.

I'll sketch something up when I have time, but my inclination would be to do something similar to the MUX, but controlled from the Arduino. I understand the hesitation to use UART for control, but it looks like the only way for older BP boards?

A possible workflow could go like this:

1. User plugs test board (Arduino + supporting circuitry) into BP
2. Test board gets powered and immediately goes into UART test mode
3. User sends test command to BP
4. BP tests UART
5. UART verification confirmed, BP then sends test SPI command (or similar) to Arduino, and both system configure themselves for that
6. Goto 4 for other tests

[agatti]

The main issue with using the hardware UART for both control and test is that the UART is going to be programmed to operate at various standard bitrates (including custom ones) to exercise the UART sniffer/autobauding code. If by accident the BP and the Arduino bitrates go out of sync there's no way to recover things unless there's a watchdog on the Arduino to reset the bitrate to say, 9600 bps if there's no response within ten seconds or so and a suitable equivalent on the BP as well. Keep in mind that unlike the BPv4, the BPv3 does not have a reset button.

The problem would be avoided by using a secondary software UART on D4/D5 and a computer to orchestrate the whole lot, but again, at an increased complexity of the whole system. Again, choices are hard to make :)

That said, your workflow proposal does make sense - I'll think a bit more on how this all would fit in place.

[agatti]

By the way, I took a look at crossbar switches - they seem to be all targeted to high-speed data transmission and/or A/V data. Would something like an ATF16V8B work as well? It's also available as DIP, so folks who don't/can't handle PCBs can set things up on a plain breadboard and a handful of components.

[marsfan]

I can't help but think that a Cypress PSOC might help. They are pretty complex, but you could distribute a hex file and schematics for a simple breakout board to put on top.

The main advantage of a PSOC is they have some sort of multiplexing, I am not 100% sure how to change pin assignments during run, but it might be possible.

[agatti]

@Marsfan Cypress PSOCs do not seem to have cross-platform programming toolchains or IDEs, according to http://www.cypress.com/forum/psoc-creator-software/psoc-creator-linux-or-osx-w-or-wo-wine - that might be a problem since everything else is meant to be cross-platform.

[nodebotanist]

I am working on code for an ATmega328 bare chip that would suit this purpose (I was working on it for my Node.JS module that uses the bitbang functionality found here). The AVR code is here: https://github.com/nodebotanist/node-bus-pirate-tester. I have I2C slave working and am working on SPI. You're welcome to use my work, and I'll gladly post updates as I build this out on this thread.