Now that’s a “good pirate”!

There comes a time you will have to implement a chip with some sort of serial protocol. Be it a traditional UART or flexible I2C or fast SPI bus, these are all more or less ubiquitous these days and many micro processors implement several or all interfaces and some even having multiple ports. In most cases, these busses are not difficult to use, though one must be very detailed oriented to be successful. Transfer the wrong byte code or even the wrong “bit value” and the MCU may not receive any data or get the wrong result - this can be very confusing indeed.

So what’s the real problem here is that whereas in many other disciplines one can sort of stack up the tower of knowledge (slowly build out one layer of newness at the time), implementing a bus means:

• understanding the chip to interface to - the specification can be quite large, the explanation from the manufacturer terse and less than ideal

• the microprocessor may be new to you and/or the bus specification may be new or different

• the code you are writing is new and unproven

• the hardware design is new, a draft and unproven

So if it doesn’t work, the bits and bytes, blurbs and bubbles you send to the chip do not elicit the response you expected. What’s next? How can you verify your understanding of the response (perhaps it is correct after all) vs some problem in the stack of technologies? Best is to take out some of the dependancies, some of the unknowns and replace this with a known.

Bus Pirate Session interfacing a MAX77975 using I2C

In many cases, I like to start understanding a chip new to me by sticking it on a breadboard, providing it the required power and hook up an oscilloscope, voltmeter or anything else that allows me to probe that little sucker. For serial interfaces, the ideal tool is a serial interface protocol tester. There are many to choose from, expensive ones and low cost ones. The latter can be surprisingly effective, no need to go for the Rolls Royce serial protocol analyzer right out of the gate ! I like to use the venerable “Bus Pirate” made by Dangerous Prototypes. This little device allows you to interface to a SPI, I2C, UART bus from your Mac via the USB bus and the terminal (yes PC is fine also, I just use a Mac though). Hook up the BusPirate, with a USB cable to your Mac and type “screen /dev/cu.usbserial-XXXXX 11500 8n1”. Be sure to replace them "XXXX” with your specific device number. Right after that command press return and if all that stuff was successful, you should be presented with a prompt “HiZ>”. Not too amazing, no? Press the letter “m” and return and you’ll see a little menu the BusPirate presents to you. From thereon select your bus and protocol options. This little write up is not a lecture on the BusPirate, there are many websites dedicated to that so look it up.

So now complexity of understanding is brought back down to understanding the chip you’re interfacing. Non of that custom code you wrote, hardware you developed or MCU that’s new to you sits in your way. Spend time to understand the chip’s registers, what it needs to make it work, and how it responds, then build your custom code around that. Heck, later on when you put your hardware and custom code together, you can use the BusPirate to listen to your MCU blabbering away at the chip to see if everything is indeed as you understand it to be i.e., the BusPirate is not just for 1-0-1 chip interfacing.

What is perhaps less than magical is the BusPirate’s command line interface. Yes, amazing Dangerous Prototypes put all that menu and command line stuff in the little device but it is hard to remember the codes, build up your own code sequences, and verify the results. This becomes tedious quickly if not error prone. Ahhrrgg, what is an engineer to do? Well, build some Python interfacing code over course! At first, this may seem counter intuitive. Remove most of the complexity and now you’re throwing complexity (python code) right back into the ring?

Snippet of Python interfacing the BusPirate using home grown comms library

Ah yes, but Python code is very easy to read, I mean it is VERY EASY TO READ ! Just a few lines to interface the serial port and send some commands down to it. Yes some complexity is brought back into the game this way but the benefits quickly become visible by repeating command line sequences that work over and over again. So I started to write a small BusPirate interfacing library that allows the chips I need to be tested and spied upon. No wait ! I started by scouring GitHub first to see if someone else had already done this… riiiight? (never start first to build stuff yourself, you’ll be busy forever). But I could not find a library that worked or fit my purpose. So after a week and some days I now have a library that not only interfaces to the chips I have a need for, it abstracts away the specific BusPirate-y interfacing things and allows anyone to add their own chip specifications writing a bit of JSON.

Since the BusPirate can interface to multiple devices at once (which is really just a side effect of the specific protocol being used), I can now have some Python code interface e.g., a sensor chip (imaging something, a GPS, an accelerometer ? you name it), read its data, mess around with it and control a second device on the bus reacting to what was read and converted (say a motor control or …). What is so neat about this set up is that a lot of the complexity is removed by using the Python middle man code. Python language by itself removes complexity by not using pointers and other common language obstacles. Python logic can be debugged on the Mac with a full fledged debugger. Whereas many MCUs boards are debugged with printf statements or a LED blinking. Yes, JTAG or SW debug interfaces are possible but you may not have the pins available in your design or the IDE may not directly support such debug interfaces or they are simply too costly. That middle layer Python is a godsend in many cases. Oh, you’re a hardware kinda person, no touchy any code? Well you’re limiting yourself enormously and frankly many companies may not hire you if you have no code exposure at all. Go study some Python!

I am planning to put that BusPirate lib into the public domain so the next guy/gal in my seat doesn’t have to start from scratch. Interested? Lemme know !