One of the things I was looking into is a digital compass module.  These are modules that return a direction it is pointing relative to magnetic north.

I started by using the Bus Pirate to access and read the module.  I did that as below:

m <– for menu
4 <– for I2C
3 <– for 100KHz

I2C>(1) <– I2C Address Search
Searching I2C address space. Found devices at:
0x3C(0x1E W) 0x3D(0x1E R)

I2C>[0x3c 0x00 0x70] <–Set measurement mode to 8-average, 15Hz
I2C START BIT
WRITE: 0x3C ACK
WRITE: 0x00 ACK
WRITE: 0x70 ACK
I2C STOP BIT

I2C>[0x3c 0x01 0xa0] <– Set gain to 5
I2C START BIT
WRITE: 0x3C ACK
WRITE: 0x01 ACK
WRITE: 0xA0 ACK
I2C STOP BIT

I2C>[0x3c 0x02 0x01] <– Set to single-measurement mode
I2C START BIT
WRITE: 0x3C ACK
WRITE: 0x02 ACK
WRITE: 0x01 ACK
I2C STOP BIT
I2C>[0x3d r:6] <– Read 6 bytes
I2C START BIT
WRITE: 0x3D ACK
READ: 0xFF ACK 0xFD ACK 0xFF ACK 0x98 ACK 0x00 ACK 0x5F
NACK
I2C STOP BIT

This returned 0xFF, 0xFD for X, 0xFF, 0x98 for Y, and 0x00, 0x5F for Z.  This is Twos Compliment Form, which is best explained by this Stack Overflow Community Wiki.

X Coordinate (0xFF): Binary 1111 1111 + 0xFD: Binary 1111 1101

Y Coordinate (0xFF): Binary 1111 1001 + 0x98: Binary 1001 1000

Z Coordinate (0x00): Binary 0000 0000 + 0x5F: Binary 0101 1111

Ultimately, this is where I stopped.  I know it works, I have some ideas on how changes affect it.  Now on to an Arduino.

Arduino Micro Setup

I plugged this into an Arduino Micro on a breadboard as below.  The 5V, ground, pin 2/SDA, and pin 3/SCL were connected as shown (note that the compass on the left can be ignored – I have two and they are both in the breadboard just to keep them somewhere safe).

One of the more difficult parts of this is ensuring you’re in the correct pins on the Micro – the numbers are small and not centered on the pin.

The code is below.  I started with code from Sparkfun and modified it as necessary.

Right now, this is functional.  There will be more to come.

-73-

Ever since seeing the name badges from the Open Hardware Summit 2013, I wanted one.  I tend to make it to 2-4 transportation conferences a year, plus 3-5 hamfests, so having a cool looking badge is… well, just a want.

The front. Five buttons and an e-ink screen.

The back. Coin cell, on-off switch, microSD card, serial headers, and components.

First off, the e-ink screen idea is pretty awesome.  It maintains an image with the power off, which is a great feature (especially since there are only around 100 page turns on that coin cell).

The powerplant of this is an Atmega 328p.  The same Atmel processor used in the Uno, Pro, Nano, Fio, and some Lilypads.

Per the website, there are two unpopulated items – a realtime clock and a temperature sensor.  However, looking at the schematic and the board, I see the unpopulated realtime clock area in the upper left area of the board, but in looking just to the left of the 328, there is a temperature sensor – the only unpopulated area is for a 0.1 uF capacitor!

I didn’t even program the thing before fixing those little omissions.  I had to make a little change to the realtime clock I had is an NXP, and the doc calls for a TI chip.  The only difference – pin #3 is a backup power input on the TI chip, and on the NXP chip it is an interrupt output.  I clipped the pin prior to soldering.  I also soldered the ICSP and I2C connections, since I think I may end up using those at some point.

The first thing I did with the BADGEr is get a copy of the firmware that is on it.  After trying to use avrdude with an FTDI board, I did what I should have done the first time – used the Bus Pirate.  Using the connection instructions on Dangerous Prototypes’ website, I used the following avrdude command:

avrdude -c buspirate -C”..\etc\avrdude.conf” -P COM9 -p m328p -U flash:r:”C:/badgr.bin”:r -b115200

** CASE SENSITIVE **

The -c option tells avrdude what programmer avrdude is using.

The -C option tells avrdude the configuration file.  In my case, I’m running this from somewhere down in the Arduino IDE folder, and relatively speaking, backup one and then into the etc folder.

The -P option is the port number (in my case, COM9)

The -p option is the part number, in the case of the BADGEr, it is an ATMega 328p and per this page, that is the correct string to use.

-U is the operation.  ‘flash’ is the part of memory to work with, r means to read, the next part is (obviously) the file path, and the final r is for ‘raw binary’.

-b115200 is the connection speed.  My Bus Pirate is setup for 115200 bps, so I used this.  It will not work if incorrect.

Once I ran this (well, twice because I forgot the final r option in the -U portion), I got a raw file with the code on the device.

It takes a while…

It took 1,048 seconds, or about 17.5 minutes.  For a 32 KB file.  There’s some fixes for that HERE.  Use them well.

Initial Programming Experience

After screwing around for several days trying to load the BADGEr from SPI, I fixed one of my FTDI boards and got it to work.  My advice here: don’t even mess with trying to load sketches via the SPI interface.  It won’t work (and I’m not sure that was ever intended).

Initial Program

Thoughts

The battery included died very quickly.  I think my next improvement will be a better battery!  This DOES need a good power source when programming.  I initially used my Bus Pirate to power it while programming it from the FTDI cable.

-73-

This is the last of the series of using the Bus Pirate and the Bus Pirate Demo Board.  This one is using the SPI EEPROMs.  The board has two of the same EEPROM (well, one is SOIC, the other is DIP, but other than that, they’re the same).

Connections

The power connections for this are the same as the connections you’d use for an I2C device – ground and power (I used 3.3V) + pull-up to Vin.

The data connections are pretty simple because the Bus Pirate is marked with MISO, MOSI, CLK, and CS (Master In Slave Out, Master Out Slave In, Clock, and Chip Select) and the demo board is marked with MISO, MOSI, SCK, and CS (there is one difference, and the process of elimination fixes that!).

Writing and Reading to the EEPROM

There are two steps to write to the EEPROM – send a write-enable command and then write to it.

[0x06] – write enable command

[0x02 0 0 1 2 3 4 5] – 0x02 is write, 0 0  is the address to write to, and 1 2 3 4 5 is the data to write

[0x03 0 0 r:5] – 0x03 is the read command, 0 0 is the address, and r:5 means read five bits.

—

That’s it with the demo board!  Expect that the Bus Pirate will make more appearances on this blog, though.

-73-

This is the second post on the Bus Pirate Demo Board I2C, showing the MCP4725 digital to analog converter and the PCF8563 real-time clock.

Connections

Like the last post, the ground and Vin need to be connected, and VPU (the pull-up resistors) need to be connected to the Vin as well.  CLK on the Bus Pirate needs to be connected to SCL, and MOSI on the Bus Pirate needs to be connected to the SDA pin.  There are other connections that will be necessary and will be different for each.

Digital to Analog Converter

The additional connection that needs to be made for this is the ADC connection on the Bus Pirate should be connected to the OUT pin on the demo board.  This will allow you to see the output.  As shown in this video by Mike Parks, it is pretty easy to address and use.

(1) – macro to search for address

[0xc8 0x0f 0xff] – turn the analog output to full

v – show voltages

Note the ADC voltage, which is at 5.03V (the max it will show).

To change things, try using [0xc8 0x01 0x00].  It will set the voltage to 0.30V.  using …0x00 0x00 will turn the ADC to 0V. It is linear from 000 to FFF hex, so 800 (0x08 0x00) is half, and so on.

Real-Time Clock

The RTL uses the same SDA, SCL, and power connections as above, and those are the only necessary connections.  However, the ADC and AUX connector CAN be used if wanted.

Setting and retrieving the time can be done using the following (ref):

(1) – address search macro

[0xa2 2 0 13 23 15 7 3 14] – 0xa2 is the address, 0 is the location to write, and I’m writing

[0xa2 2 [0xa3 r:7] – 0xa2 is the address, and 2 is the address to READ from in the next command, 0xa3 is the read location, and it reads 7 bits.

It seems to me that connecting the AUX on the Bus Pirate to the CLK pin on the clock should be measurable (by using f in the BP interface), but I’m not seeing a reading, so it may not be the correct way to use that.  However, when I took the AUX wire and held it to pin 1 on the RTL IC and read the frequency, it came up to 60 Hz, and was not controlled by sending commands to the 0x0d address.

-73-

The Bus Pirate Demo Board has five I2C devices: two 24AA02 EEPROMs (2 KBit), one TC74 temperature sensor, one MCP4725 D/A Converter, and one DS1307 Real-Time Clock.  This post is about the EEPROMS and the TC74 – next week’s post will be about the D/A converter and the RTC.

Pull-up Resistors & Connections

One thing that is not documented well enough for non-engineers is the pull-up resistors.  They are pretty important for I2C devices and results can be weird.  What needs to happen is to have BOTH the 5V and pull-up lines to the Vin pin on the demo board.  I used a breadboard for now, although I have a different Bus Pirate cable on the way to make this a little easier.

In both the cases in this post, the CLK pin on the Bus Pirate gets connected to the SCL pin on the demo board and the MOSI pin on the Bus Pirate gets connected to the SDA pin on the demo board.

EEPROMs

Both of the EEPROMs are interfaced the same way.

Search for the EEPROM Addresses:

(1) is the address search address

[0xa0 0 3 2 1] – 0xa0 is the address to write to, 0 is the location in that address (the top), and 3, 2, and 1 are the values being written.

[0xa0 0][0xa1 r:3] – 0xa0 is the address, 0 is the location in the address.  0xa1 is the read command, and r:3 indicates to read three bits.

[0xa0 0xfa][0xa1 r:6] – this is to read a MAC address from the chip.  Unfortunately, I can only seem to get all F’s from these chips… I’m not sure if I’m doing something incorrect or if the chip’s spec has changed since the instructions on Dangerous Prototypes were written.

As a final test, I cut the power to the board (w) and turned it back on (W) and read the chip to see if the values were still there.  They were.

TC74 Temperature Sensor

The TC74 Temperature Sensor is an interesting device to use.

(1) – standard address search macro

[0x9a 1] – 0x9a is the address, 1 is a value to write.  We don’t really care what it writes, we just need to do this to read the chip.

[0x9a 0][0x9b r] = 0x9a is the write address, 0 is a partial command to select the temperature register, and 0x9b r reads the register.

The value returned is 0x16, which is 22°C, or 71.6°F.

…next week – more I2C goodness!

-73-

In learning how to use the Bus Pirate, I started with the one-wire area of the demo board.

First off, important notes:

• I’m using the v 3.8 Bus Pirate.  The pinout is different than some of the others.
• I’m using a Sparkfun Bus Pirate cable.

My cable is as follows:

Black: Ground
White: 5V
Grey: 3V3
Purple:VPU
Blue: ADC
Green: AUX
Yellow: CS
Orange: MISO
Red: CLK
Brown: MOSI

The first part of this is based on using the DS2431 1,024 bit (1 kilobit?) EEPROM.  The second part is using the DS1822 temperature sensor.

1K EEPROM

I used the instructions on Dangerous Prototypes as a guide.

This is how I had the demo board hooked up.

I hooked the ground (black) to the ground, the 5V (white) to Vin (the 3.3-5V pin), and MOSI (brown) to One Wire.  Then, open the bus pirate and get into one-wire mode (m {enter} 2) and turn on the power (W).  Then, issue the search macro ( (240) ).

Use (240) or (0xf0) to search the one-wire bus. The bus pirate will return a list of all items on the bus. In my case, I have two EEPROMs (thanks to not being able to get a part) and a temperature sensor.

Writing to the EEPROM to a Temporary Location

I write a string of numbers to one of the EEPROMs here.

To write some values to the EEPROM, I used the following:

(0x55) (2) 0x0f 0 0 8 7 6 5 4 3 2 1

(0x55) is the macro to ‘match 64 bit address’

(2) is the macro to the address of the EEPROM I’m writing to

0x0f is the command to write to the devices scratch pad

0 0 is the location to write to

8 7 6 5 4 3 2 1 is the data that I’m writing

Reading (Verifying) What I Wrote

I read that string of numbers here.

To read the string of numbers, I used the following

(0x55) (2) 0xaa r:3 r:8 r:2 r:2

The first two are similar to above – (0x55) to match the address and (2) for the macro to the address I wrote to.

0xaa is the read scratch pad command

r:3 reads the authorization code (needed to permanently write the data)

r:8 reads the data I wrote in the last step

r:2 reads the CRC

r:2 this is all ‘1’s

The final r2 returns 0xFF, which is 2 bytes of 1s, in decimal this is ‘11111111’ ‘11111111’.

Permanently Writing the Data

I permanently write the data here.

To permanently (well, permanent until I rewrite it) write the data to the EEPROM, I used the following:

(0x55) (2) 0x55 0x00 0x00 0x07

(0x55) (2) is the same as above

0x55 is the command to write the scratch pad to memory

0x00 0x00 0x07 is the authorization code from above

Verifying the Write

I verify the write here.

To verify the write, I used the following:

(0x55) (2) 0xaa r:3

(0x55) (2) is the same as above

0xaa is the read command (same as above)

r:3 means read three bytes.  The data that is returned is 0x00 0x00 0x87, which is different from before

Reading Back the Data

I read back the values here. These are permanently written to the EEPROM.

To read the data, I used:

(0x55) (2) 0xf0 0x00 0x00 r:8 r:8

(0x55) (2) is the same as above

0xf0 is the read command, but this is read from the memory, not the scratch pad

0x00 0x00 is the address

r:8 r:8 reads 8 bytes, twice

The first string returned is 0x08 0x07 0x06 0x05 0x04 0x03 0x02 0x01, which is the data we wrote.  The next string is 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00, which is data that was never written, so it is all zeros.

That’s it!  I read and wrote to a small EEPROM.  If it isn’t obvious from the picture above, this is about the same size as a small BJT transistor.

Reading from a DS1822 Temperature Sensor

The DS1822 is a one-wire temperature sensor that is also the size of a BJT transistor.  Reading from it is pretty easy and was described on Hack-A-Day by Ian back in 2008.

This is in the same setup as above, so looking in the screenshots above, the proper address for this device is (1).

Reading from a temperature sensor.

To read from the device, two commands must be entered:

(0x55)(1) 0x44

(0x55)(1) 0xbe r:9

The first command is a “Convert temperature” command, which basically tells the sensor to read the temperature.

The second command reads 9 bytes from the sensor.  The important part are the first two bytes.  In the example above, the first two bytes are 0x71 0x01.  This translates into being read as 0x171 (see note).  That 0x171 needs to be converted into decimal, in this case 369.  That number then needs to be multiplied by the resolution, which if never changed is 0.0625.  That comes out to a temperature of 23.06C, or 73.5F.

-…-

This is the first of a multi-part series.  Next installment in this series (hopefully next week) will be the I2C bus, although depending on the length (there are several chips there), it may be broken into two parts.

-73-

A few weeks ago, I got a Free PCB from Dangerous Prototypes for a Bus Pirate.  This is a pretty cool hardware swiss army knife that I’m still learning how to use.

This is the bus pirate in front of the terminal background.

I had a few issues with the build (none a fault of Dangerous Prototypes or the PCB manufacturer).  First off, I didn’t get the LEDs on correctly the first time, and I’m pretty sure I didn’t get the USB one right the second time, either.  Also, I didn’t get good solder joints on the PIC24.  I was seeing problems that were identical to these reported on the DP Forum, and feared that the FTDI chip was fake.  After removing the FTDI chip and pulling one from another FTDI board I had, I tried sjaak’s advice of pushing on the chips and found that if I pushed on one part of the PIC24, the VREG light came on, so I reflowed the solder on both chips and voila!

I also learned that PIC chips aren’t as easy as Arduinos to burn, and after initially finishing the PCB, I had to order a PICKit3 to burn the chip.  It wasn’t a big deal to order the PICKit, but it was a nearly week delay as I inadvertently (and unknowingly) selected a shipping option that used UPS for the long haul from Ft. Worth to Cincinnati and then used the postal service to deliver it the last 2 miles from the post office to my house (to use another ham’s quote, “you get the incredible slowness of the ground services + the normal 2 day delivery of USPS. you save cents. yay!?” … yeah, that’s about right – 100 cents to add two days to the delivery time).

I did slightly deviate from what I think was intended with this – this was built for a USB Micro connector, but I put a USB Mini connector on it.  It hangs off a little, but I’m fine with that (I have minor personal reasons too, but it really boils down to preference).

I also deviated on the connector.  I didn’t look back in my order history to get the correct connector, and ended up with an incorrect connector.  So I put header pins on it and called it done.

A final thing I learned was the value in over-ordering.  Since I’m not a pro in this, my parts orders tend to be small, and normally there is a price break at 10.  Having extras on hand means that as soon as I get a PCB, I can start building right away.

Thanks to Dangerous Prototypes for the PCB!  I’m already learning a lot about using it and I’m (of course) using my last free PCB build to learn more about using it.

-73-

After building my first PCB a while back and starting to attempt to use it, I decided that the smart thing to do would be to finish build #2, which is a Bus Pirate Demo Board.  This demo board has a handful of chips that can be used to test a Bus Pirate (or in my case, a Bus Pirate Shield): 5 EEPROMs, a temperature sensor, a digital-analog converter, and a real-time clock.

My biggest hold-ups were ordering parts… I certainly have a bit to learn about SMD sizes, as I ordered some that were a bit small:

Too small!!!

Finally, after a few extra parts orders, I finished it.  I’m getting better at soldering SMD devices, although I should probably invest in a soldering station with adjustable temperature control and a better assortment of tips.  My Radio Shack iron runs very hot.

The completed board.

This will make an appearance in a forthcoming blog post, particularly after I get more into using the Bus Pirate Arduino Shield.

-73-

The bus pirate Arduino shield is a discontinued item from Dangerous Prototypes. I picked up the PCB via a free PCB coupon a while back, built it a few months later, and then finally decided to use it because I think I have something to use it with. Note the key word – think. This is what happens when a traffic engineer plays with electronics.

The shield was not easy to get started with, mostly because I had to look (and look, and look) for source. I finally found it on Toby Jaffey’s Github Page. Once I loaded it, I found that connecting with Tera Term (and likely any terminal emulator) on that COM port using 19200 baud 8N1 no flow control worked and I was able to play around doing things like:

>led 1 (turns the mode LED on)

>led 3 (turns the mode LED to a fast blink)

led appears to be 0-6, with 0=off, 6=on, and 1-5 are blink rates, slow to fast.

help and version are pretty self-explanatory.

Stay tuned for more, but in the meantime, here’s a picture of the setup.

The Bus Pirate Arduino Shield is the shield sitting on top of the Arduino in the background. The item in front is the Bus Pirate Demo Board that I’m using to test the shield. There are a few joints that I missed soldering and there are a few missing capacitors.

There’s going to be a lot more to post as I start into this.  Incidentally, this is to assist with the Android App.

-73-