Summary of One-chip sound player.
This project develops a high-quality sound player using a single PIC12F1840 microcontroller and an SD card. The chip's 32 MHz clock (overclocked to 33 MHz) enables 8MIPS performance, while the hardware SPI module drives the SD card at 8MHz for efficient data streaming. Audio is output via PWM through a MOSFET amplifier. Custom drivers handle SD/MMC/SDHC cards and a minimal FAT16 filesystem, utilizing a circular buffer to manage audio data flow between storage and playback threads.
Parts used in the Single-Chip Sound Player:
- PIC12F1840 microcontroller
- SD card (supporting SD/MMC/SDHC/RS-MMC/HS-MMC/miniSD/microSD/transFlash)
- MOSFET amplifier
- Speaker
- OSCTUNE register (for overclocking)
The purpose of this project was to create a sound player that can play high quality sound using nothing but a single chip (plus an SD card for data storage).
The chosen microcontroller was the PIC12F1840. It was chosen because of its fast clock rate (up to 32 MHz). Since microchip PICs have this atrocious property of executing one instruction every four clock cycles, this results in 8MIPS performance.
The second reason for the choice was the hardware SPI module – bit-banging SPI is not hard, BUT doing it fast enough to sustain the sound playback would be – the hardware SPI module helps by allowing the SPI clock to be as high at 8MHz without using nearly as much CPU time as bit-banging would. The reset of the circuit design was easy: the PIC outputs a PWM waveform to drive the speaker, which is amplified by a MOSFET, PIC’s SPI controller talks to the SD card, and another GPIO is used to provide power to te SD card allowing it to be powered off and thus letting the circuit sleep in very low power mode (nanowatts of power used). The pic is overclocked using the OSCTUNE register to 33MHz from the stock speed of 32MHz.
The SD card driver is my own work, and supports SD/MMC/SDHC/RS-MMC/HS-MMC/miniSD/microSD/transFlash and whatever others are in that family. Card is initialized at 375KHz (which is within spec), and then the bus is clocked at 8MHz for data reads/writes. The driver is peculiar for a few reasons, mainly because it does not try to be an abstraction between the SPI bus and the caller, thus the driver will init the card, and set it up to stream sectors to the caller. The caller then calls spiByte() directly to read sector data. Every 512 calls, a call to sdNextSector() is needed to notify the SD driver that we want the next sector & properly wait for it to start.
Since there is some time between the end of streaming of one sector and beginning of streaming the other, buffering is used for audio data. The buffer is a simple circular buffer that the audio thread reads from, and the SD thread writes to. When buffer is full, SD thread busy-waits for a slot to open to write data into. Since SD cards do not care how much time passes between clock ticks, this wait can be as long as needed.
The filesystem driver (uFAT) is also my own work, and is a tiny tiny FAT16 implementation. It supports only: short filenames, only FAT16, only read, only root directory. It can: enumerate files’ names/sizes/flags and return the set of sector extents a file occupies. A sector extent is defined as a contiguous range of sectors (a “fragment” in FAT terms). The caller then reads those sectors by itself (allowing the caller to thus avoid the needless layer of abstraction and thus time waste).
For more detail: One-chip sound player.
- Why was the PIC12F1840 chosen for this project?
It was selected for its fast clock rate up to 32 MHz and its hardware SPI module. - What is the maximum clock speed of the microcontroller in this design?
The PIC is overclocked using the OSCTUNE register to 33 MHz from its stock speed of 32 MHz. - How does the system achieve low power consumption when not playing sound?
A GPIO pin powers off the SD card, allowing the circuit to sleep with nanowatts of power usage. - At what speed does the SD card bus operate during data reads and writes?
The bus is initialized at 375KHz and then clocked at 8MHz for data operations. - What type of buffer is used to manage audio data between the SD thread and audio thread?
A simple circular buffer is used where the audio thread reads and the SD thread writes. - Does the custom filesystem driver support long filenames or subdirectories?
No, it supports only short filenames, FAT16, read-only access, and the root directory. - How does the caller interact with the SD driver after initialization?
The caller calls spiByte() directly to read sector data every 512 times. - What happens when the circular buffer becomes full?
The SD thread busy-waits until a slot opens to write data into the buffer.
