While preparing for my SD tutorial, I realized it would be a long, uphill battle to debug SPI communications with a two-channel oscilloscope, especially when I had no prior experience on implementing SPI with AVR. To break the learning curve to manageable steps, I decided to get a Bus Pirate, a serial protocol tool I had heard a lot of good things about. What made the decision even easier was the fact that my local electronics supplier had just started selling the SparkFun version of Bus Pirate.
In this compact post, I’ll discuss my first impressions of the Bus Pirate, and try out the logic analyzer functionality.
Bus Pirate General Impressions
The first thought that crossed my mind when I saw the Bus Pirate in real life was how small the device was. As you can see, it’s hardly larger than an SD card. All the components are of surface mount type, LEDs included. USB cable was not included but fortunately I had several in my cable drawer. The thing does not need any other setup than plugging it in and installing the FTDI virtual COM port drivers. After that, it showed up as COM19 and I could connect to it with Putty. See the Bus Pirate 101 tutorial for installation details.
The v3 hardware is based on a PIC chip running at 3.3 volts and it took me a while to get comfortable with the power supply & pullup resistor logic – basically you can either use the Bus Pirate pins “normally” so an output pin is driven by the PIC, or in “open drain” mode, where a CD4066B analog switch connects the lines via pullup resistors to whatever is wired to the Vpu pin. This way, the Bus Pirate can interface with other than 3.3V devices (the PIC only pulls the line down or “lets it go” and the pullup takes the line high).
This part will utilize the previously made FAT library with a few tweaks – it turned out that some byte and word-sized values needed explicit casting to unsigned long so that the calculations worked as they should. The new library and all code shown here can be found from the updated project zip.
Initializing the SD card automatically
Instead of manually pressing 1, 2, and 3, we’ll now write a single function to initialize the SD card to SPI mode. For standard SD (not high capacity SDHC) cards, it’s enough to:
Send clock pulses for 80 cycles (“read” 10 bytes)
Send command 0x40 (it should return 1)
Send command 0x41 until it returns 0 (it returns 1 while the card is busy)
Send command 0x50 to set read block size (as well as write block size)
Here’s the code to do just that (sd_sector and sd_pos will be used shortly):
Finally back! Sorry for taking a while, but getting the SD cards to work required quite a bit of research! In this part of the tutorial, we’ll start talking with the SD card. Once you get that working, adding the FAT library developed in the previous part will be easy.
This tutorial will most likely be the most challenging covered in my blog so far, so beware: You may need to do some troubleshooting on this one! If you encounter problems, I recommend you to ask any questions at the AVR Freaks tutorial forum topic, so more people might be able to help you than just me!
Basic hardware setup: ATmega88 with UART console
The 3.3V UART I covered just a while ago will form the basis for this project. Only change we will be doing is to replace ATtiny2313 with ATmega88. This is because SPI, SD and FAT code will eat up almost 3 kB of program memory, and the ATtiny chips with that much program memory and separate RX/TX and SPI pins are not that common, while ATmega88 is readily available (48 and 168 work as well, of course). To accommodate the new chip, the following hardware changes are made to the ATtiny2313 version:
ATmega88 will require two ground connections
In addition to VCC, also AVCC for analog circuitry needs to be wired to VCC
Additional capacitor between AVCC and GND is recommended (I used 10 uF)
Programming header MOSI/MISO/SCK are also in different place
Before diving right into SPI communications for my SD tutorial, I wanted to have a 3.3V development platform that could output some meaningful status information, not just light a LED if something goes wrong. In this post, I will outline the basic testing platform that will be used in the upcoming part 3 of that tutorial, and discuss a little about UART on AVR in the progress. Here’s what we’ll build:
If you want to build it yourself, you’ll need:
ATtiny2313 or other AVR chip with UART pins (RX/TX) separate from SPI pins (MOSI/MISO/SCK)
20 MHz crystal (other speeds will work, too) and ~27 pF capacitors
4k7 pullup resistor for ATtiny2313 RESET pin
3.3V regulator such as LD1086V33 or some other 3.3V voltage source
2 filtering caps for the regulator input/output sides, 10 uF
MAX3232CPE or similar RS-232 transceiver that works on a 3.3V voltage
RS-232 port on your computer or a USB to RS-232 dongle
RS-232 to breadboard connector (home-soldered example seen above)
In the last week’s part 1 of my FAT and SD tutorial, we got as far as reading the file entries in root directory, and peeking into a file with hex editor. Now we’ll cover the file allocation table itself to enable reading longer files, and adapt the code into a small footprint FAT16 library!
File allocation table in FAT16
In the previous part, we learned that the data on a FAT-formatted disk is stored in clusters. In our test image, the cluster size was 32 sectors, i.e. 16 kiB (16 384 bytes). Let’s imagine a newly formatted disk with 100 free clusters, with the clusters numbered from 2 (the first cluster at the beginning of data area) to 101 (the very last cluster). Now let’s copy some files there:
File operation
File allocation
Copy HAMLET.TXT (193 082 bytes) to disk
Clusters 2-13 allocated for the file (196 608 bytes)
Copy README.TXT (353 bytes) to disk
Cluster 14 allocated for the file
Create SUBDIR on disk
Cluster 15 allocated for the directory file entries
Create 1.TXT in SUBDIR
Cluster 16 allocated for the file, a new file entry written to SUBDIR (beginning of cluster 15)
While writing my FAT+SD tutorial, I realized that my projects may soon contain both 3.3 V components like an SD card, and 5.0 V components like LCD displays or a MAX232 UART chip. Considering I only knew how to use resistors as voltage dividers, I decided to learn a bit more about voltage level shifting.
Having netted already two generous donations for this blog, I decided to spend the first one on $10 of components that could do the job, and employ my trusty, although not old, Picoscope 2205 to investage how they perform!
Simple low to high conversion: Flexible logic levels
When interfacing a 3.3V device with an AVR chip running at 5V, it is possible that no shifting is needed when communicating to the AVR chip. For example, the ATtiny13 datasheet specifies input low voltage as anything less than 0.3*VCC (1.5V when VCC=5V) and high as anything more than 0.7*VCC (3.5V when VCC=5V) – the 3.3V might be just enough to be reliably interpreted as “high” in your particular part combo. However, you might still want to consider the alternatives below, just to be sure.
Simple high to low conversion: Voltage dividers
The basic trick for lowering a voltage from, say 5V to 3.3V is to use two resistors in series, connected between the MCU pin and the ground. Because the voltage drop in each is proportional to the ohm value of each resistor, it’s easy to get any voltage between MCU VCC and ground from such a setup.
Basically, V0 = R1 / (R1+R2) * VCC. For example, if your MCU is providing 5V when an output pin is set high, you could have a 2k resistor (R2) and 3k resistor (R1) in series, resulting in 3V between the two resistors – that is because the 2k resistor “consumes” 2/5 of the overall voltage (5V->3V) and 3k resistor 3/5 of the voltage (3V->0V).
To see how it works in reality, I made a voltage divider from two 10k resistors, and measured both the voltage on MCU pin itself (the blue trace) and from between the two resistors (the red trace), when the MCU pin is set to alternate between low and high state 200 000 times a second (a 100 kHz square wave):
