Fullscreen HTML5Med Res (??MB)HTML4

Touch-Screen Digital Audio Recorder Pt.1 By ANDREW LEVIDO Want to record & play back with CD sound quality? With a compact hand-held unit with a colour touch-screen? Now you can. This device records to & plays back from a standard SD card and doubles as an SD card reader when connected to your PC via its USB interface. A single AA-size lithium-ion cell provides hours of record or playback time and is recharged via the USB port. W HAT’S THE FIRST thing you will notice about this Digital Sound Recorder? It has no external controls! Just like smart phones and tablets, everything is done via the touch-screen. All its inputs and outputs are at the top end of the case – stereo line inputs with adjustable gain, a mono external microphone input jack and an in-built electret microphone, with two settings for gain (again, via the Touch-screen). 40  Silicon Chip Audio output is via a stereo line output jack (3.5mm socket) and a headphone jack (3.5mm socket) with its volume adjustable via the touchscreen. Also at the end of the case is the SD card socket and a single LED that indicates when card read or writes are in progress. And there is a mini USB socket for communicating with a PC and charging the battery. It records and plays standard WAV format audio files and is compatible with any PC or Mac. It supports 16-bit stereo PCM coded files at sample rates from 8-96ks/s. The touch-screen display is a 72mm (diagonal) QVGA (quarter VGA or 320 x 240 pixels) TFT model. It has a white LED backlight and supports 262 thousand colours (although only 65 thousand are allowed for by the software). siliconchip.com.au PCM AUDIO LINE IN CODEC CONTROL MICROPHONE IN INTERNAL MIC 12MHz CODEC (IC1) 12MHz LINE OUT PARALLEL DATA LCD & TOUCH SCREEN TOUCH SCREEN 32kHz MICROCONTROLLER (IC3) PHONES OUT USB DATA & POWER SPI DATA SD CARD POWER SUPPLY (IC2,REG1) POWER STATUS & CONTROL CARD STATUS Fig.1: the block diagram of the Touch-Screen Recorder. A TLV320AIC23 CODEC (IC1) takes care of all the analog signal processing, plus analog-to-digital and digital-to-analog conversion of the audio streams. This interfaces to a PIC32 micro (IC3) via two serial data paths (PCM audio & CODEC control) and the micro in turn drives an LCD touch-screen display and an SD card. Microcontroller IC3 also provides USB support. We have made the user interface intuitive, with on-screen buttons and text, and the display also shows the date, time and battery charge state. To conserve the lithium cell, the backlight automatically dims after 30 seconds of touch-screen inactivity and it immediately brightens again when the screen is touched. The recorder goes to sleep after a further 30 seconds of touch-screen inactivity, provided it is not recording or playing and is not connected to a USB power source. Simply touching the screen wakes it up again. When a PC is connected, the recorder can be put into SD card reader mode. The SD card will appear to the PC (or Mac) as an external disk drive, so files can be transferred back and forth. Mind you, to transfer a lot of files it will be quicker to remove the SD card from the recorder and insert it directly into your computer or a dedicated card reader. So why would you bother to use this recorder rather than using your smartphone? The quick answer is great sound quality. This recorder gives you CD sound quality which your smartphone simply cannot! How it works For all of its fancy features, the Touch-Screen Recorder only uses a couple of chips. Basically, all it has siliconchip.com.au is a CODEC (coder-decoder), a PIC32 microcontroller and the LCD touchscreen This is shown in the block diagram of Fig.1. The TLV320AIC23 CODEC takes care of all the analog signal processing, plus analog-to-digital and digital-to-analog conversion of the audio streams. This interfaces to the PIC32 microcontroller over two serial data paths, one bidirectional path for the PCM audio data and one single-direction path for CODEC control. Two of the microcontroller’s three Serial Peripheral Interface (SPI) modules are used for these interfaces. The CODEC requires a 12MHz crystal for timing and provides a buffered clock output, so we have used this to provide the main clock input for the microcontroller. The microcontroller’s third SPI module is for communication with the SD card. Two digital inputs monitor the state of the card presence and write protect switches in the SD card socket. The LCD is driven via an 8-bit parallel interface with read, write and chip select lines. Although mechanically integrated with the display, the touchscreen is electrically separate and is essentially an analog device, so it is connected to pins on the micro that can double as analog inputs. More details of how the touchscreen works are given later. Main Features • • CD sound quality • • SD card memory Colour touch-screen with no external controls Powered by a single AA-size lithium-ion cell; recharged via an on-board USB port The USB socket connects directly to the microcontroller and the 5V USB bus power feeds a dedicated lithium-ion battery charger IC. The battery voltage can vary from 4.2V to 3.2V and is regulated to provide a 3V rail for all of the electronics (except for the display backlight that uses the unregulated battery supply). The microcontroller monitors the battery voltage via an ADC input and this, together with status outputs from the battery charger and regulator, allows the micro to display battery status. More detail Let’s now refer to the main circuit diagram for more details – see Fig.2. At the top lefthand corner, we can see that the stereo line input jack (CON1) is connected to the CODEC line input, pins 19 & 20, via voltage dividers June 2014  41 10Ω VCC 100nF ×2 100nF LINE IN 2.2 µF 2 x 5.1k 20 2.2 µF CON1 2x 5.1k 22pF 19 22pF 18 2.2 µF MIC IN 17 LK1: BOTH 5.1k CON2 16 LK2: INT ONLY INTERNAL MICROPHONE MIC1 14 1 8 27 AVdd HPVdd BVdd DVdd LLINEIN MODE RLINEIN SCLK VMID 100nF 2.2 µF LINE OUT 12 23 CS MICBIAS BCLK DIN LRCIN IC1 TLV3 20 AIC 2 3 –IPW LLINEOUT DOUT LRCOUT 2x 100k CON3 2.2 µF 13 100 µF 9 PHONES OUT 100 µF CON4 10 CLKOUT RLINEOUT LHPOUT XTO RHPOUT XTI 21 3 4 SCLK DATA 5 CDCS BCLK PLAY 6 REC 7 SYNC MCLK 2 VBUS 26 D– D+ X1 12MHz 25 AGND HPGND DGND 28 15 11 2x 100k DIGITAL GROUND ANALOG GROUND 22 24 SDIN MICIN 100 µF 22pF 22pF VCC VBUS USB 1 2 3 4 5 VCC STAT1 CON7 1M 1 2 BATT CHGIN STAT1 USBPWR IC2 LM3658 2.2 µF STAT2 USBSEL 5 ISET EN TS PAD 3 STAT2 1M VBAT 10 1 7 2 B+ 6 3 2.2 µF 4 4.7M B– B1 8 D VIN VIN SHDN G 10k 5.1k 100nF S 8 VCC 7 SENSE REG1 MCP1725 5 PGOOD –3.0 Li-Po/Li-Ion CDELAY 2.2 µF 4 NTR4170N 1M 6 GND Q4 9 VOUT 10nF 4.7M VBATMON USBP SC 20 1 4 TOUCH-SCREEN DIGITAL AUDIO RECORDER and 2.2µF blocking capacitors. These dividers ensure that the input impedance is approximately 10kΩ and attenuate the line level signal, which can be as high as 2V RMS, to a maximum of 1V RMS – the full scale input level for the CODEC. The CODEC contains a digital gain/ attenuation stage for the line input that can be set to any value between 42  Silicon Chip -34.5dB and +12dB in 1.5dB steps. The line inputs can be muted under control of the micro (IC3). The mono microphone input (CON2) is connected to the CODEC via another 2.2µF DC blocking capacitor. The onboard electret microphone element is connected to the switch terminal on the microphone jack so that it is switched out of circuit when an exter- nal microphone is plugged in. Pin 17 of the CODEC provides a low-noise DC output to bias an electret microphone. This can be connected either via link LK1, labelled BOTH, to both the internal and external microphones or via Link LK2 (labelled INTL) to just the internal microphone. The CODEC provides a fixed +14dB microphone gain stage followed by an siliconchip.com.au VCC VCC 2.2 µF ×3 57 SDA3/RD2 2 PMRD/RD5 3 4 18 5 17 RD4 PGED2/RB7 PMA14/RD11 PGEC2/RB6 PMA15/RD10 CON5 RD7 SCLK 49 DATA 51 CDCS 54 BCLK 4 PLAY 6 REC 5 SYNC 8 MCLK 39 VBUS 34 D– 36 D+ 37 470Ω 33 A PMD0/RE0 RD1/SCK3 PMD1/RE1 RD3/SDO3 PMD2/RE2 RD6 PMD3/RE3 RG6 PMD4/RE4 RG8 PMD5/AN22/RE5 RG7 PMD6/AN23/RE6 RG9 CLKI/OSC1/RC12 VBUS PMD7/AN27/RE7 CLKO/OSC2/RC15 D+ USBID/RF3 RB2/AN2 λ ACTIVITY LED1 RB4/AN4 K 21 STAT2 22 PGOOD 23 VBATMON 11 USBP 43 47 X2 32kHz 48 RD8 RD 10 52 WR 9 45 R/S 8 44 CS 7 55 RST 31 60 23 61 24 62 25 63 26 64 27 1 28 2 29 3 30 40 RB8/AN8 INT0/RPD0/RD0 6 Vcc 32 Vcc 16 LEDA 33 IOVcc D0 RD D1 WR D2 R/S D3 CS D4 RST D9 D10 ERXD2/RF1 RB5 ERXD3/RF0 RD9/SDA1 AN12/RB12 SOSC1/CN1/RC13 SOSCO/CN0/RC14 AN13/RB13 RPB15/RB15 SDO4/RPF5/RF5 RB14/SCK4 SD14/RF4 Vcap 2.2 µF AN11/RB11 20 22 35 36 D6 37 D7 2.2 µF D11 D12 D13 D14 D15 5 12 13 14 15 XPOS 34 21 NC 17 18 19 20 YPOS 14 XNEG 13 YNEG D 12 G 42 LCDPWR 46 LEDBLPWR Q1 NTR4170N S D G Q2 NTR4170N S Vss 9 Vss 25 Vss 41 59 58 2x 1M additional +20dB gain stage that can be switched in or out under software control (ie, via the touch-screen). The microphone input can also be muted under software control. For the audio outputs, the CODEC’s internal DACs feed line output buffers that provide fixed-level line outputs on pins 12 & 13. The 2.2µF blocking capacitors prevent any DC bias appear- SDCARD SKT CP 27 CD WE 28 9 1 2 3 4 5 6 7 8 SDCS 30 32 MOSI 29 SDCK MISO 31 24 4x 100k 5 4 3 2 1 D TEST CON8 SDPWR G Q3 NTR4170N WP CON6 S Fig.2: the complete circuit diagram for the Touch-Screen Recorder. It’s based on CODEC IC1, PIC micro IC3, touch-screen display LCD1 and an SD card. IC2 (LM3658) provides the charge current to the lithium-ion cell (when the device is connected to a USB port) that’s used to power the device. The recorded audio data is stored on the SD card and played back under the control of IC3. siliconchip.com.au 3 4 D5 LCD1 320 x 240 PIXEL COLOUR LCD GRAPHIC DISPLAY WITH LED BACKLIGHT & TOUCH SCREEN PANEL D8 2 VCC RB10/AN10 AVss 1 IM0 RB9/AN9 22pF 22pF 56 53 RB1/AN1 RB3/AN3 STAT1 50 IC3 16 PIC32MX695PIC3 2 MX695- RB0/AN0 F512H 15 D– 11 LEDK MCLR Vdd LEDK 38 LEDK 35 GND 26 Vdd VUSB3V3 Vdd LEDK 10 GND 19 AVdd Vdd TPY– 7 TPX– 1 TPY+ ICSP VBAT 100k TPX+ 100k ing at the line output jack (CON3), and 100kΩ resistors ensure that the outputs remain referenced to ground. The DAC outputs are also fed to an internal headphone amplifier whose gain is digitally adjustable from -73dB to +6dB in 1dB steps. 100µF blocking capacitors ensure decent low-frequency response, with low-impedance headphones. If required, the CODEC’s audio LM3658 LED NTR4170N 6 D K A G S 10 1 5 GND PAD UNDER CENTRE inputs can be routed to its outputs to provide an analog bypass path. We use this feature to allow monitoring of the signal being recorded. During playback, this bypass function is switched off. All of the audio circuitry within the CODEC is referenced to a voltage mid-way between the positive supply and ground. This voltage appears at June 2014  43 YPOS SPACING BETWEEN LAYERS EXAGGERATED FOR CLARITY YPOS XNEG XPOS XNEG YR+ XR– XPOS XR+ YR– STYLUS YNEG the VMID pin of the CODEC (pin 16) and is bypassed by a 100nF capacitor. The CODEC has four different power supply inputs, two for the digital parts of the circuit and two for the analog parts. The two digital supplies, DVdd (pin 27) and BVdd (pin 1), are connected directly to the 3V rail, as is HPVdd (pin 8), the supply for the headphone amplifier. These are bypassed by a pair 100nF ceramic capacitors and a 100µF electrolytic. The supply for the analog circuitry, AVdd (pin 14), is derived from the 3V rail (VCC) via a simple RC filter consisting of a 10Ω resistor and a 100nF capacitor. Care has been taken with the PCB layout to ensure that power supplies and ground planes for the analog and digital parts of the circuit are connected so as to minimise the conduction of digital noise into the sensitive analog circuitry. The digital side of the CODEC consists of a standard digital audio interface on pins 3-7. In our case, the CODEC is configured to be the master. It outputs a bit clock on pin 3 and a frame sync pulse on pin 7. The frame sync pulse indicates the start of a data frame that consists of the left and then right data words. The bit clock operates at 12MHz or 6MHz, depending on the data rate selected, and the frame rate is equal to the sample rate. For example, at 48ks/s the bit clock rate is 12MHz and the frame rate is 48kHz. The record data stream from the CODEC appears on pin 6 and the playback data stream from the micro 44  Silicon Chip YNEG appears on pin 4. Although the CODEC is capable of a number of different word lengths, we use 16-bit words exclusively. If configured correctly, the SPI module in the microcontroller can operate in a framed slave data mode compatible with this data stream – the challenge is to keep the data flowing fast enough so that the audio stream is played or recorded seamlessly. As mentioned above, a second SPI port is used to configure and control the CODEC. This is a one-way interface on pins 21-24. Connecting pin 22 to VCC selects the SPI mode (the CODEC also supports I2C for this interface) and the usual chip select, clock and serial data lines are used to receive command data from the microcontroller. Finally, the CODEC clock is derived from a 12MHz crystal connected to pins 25 & 26, with associated 22pF loading capacitors. The 12MHz clock output from pin 2 drives the microcontroller’s clock input to provide the system clock when the microcontroller is awake. Touch-screen display As mentioned above, the display is a QVGA colour TFT (thin film transistor) LCD with white LED backlighting. The display incorporates an ILI9341 driver chip configured for an 8-bit or 16-bit parallel interface. This display driver chip contains a large number control registers and a display memory which has one 18-bit data word for each of the 76,800 pixels of the display. Each 18-bit word defines the 6-bit intensity of each of the red, green and Fig.3: the resistive touch screen is formed using two separated layers of plastic film, each coated with a transparent resistive compound. These effectively form two wide resistors, one in the horizontal (X) direction and one in the vertical (Y) direction. When the screen is pressed, the two films touch and this creates a pair of voltage dividers joined at the point of contact. blue sub-pixels, permitting 262,144 colours per pixel. 18 bits is an awkward size to work with given an 8-bit bus, so the display controller allows for the 18 bits to be mapped to a 16-bit word where each pixel is represented by 5 bits or red data, 6 bits of green data and 5 bits of blue data. This is known as 5:6:5 RGB and permits 65,536 colours which is more than sufficient for our application. As we use an 8-bit interface, it takes two write operations to set one pixel of the display. The display driver connects to the microcontroller through the abovementioned 8-bit data bus, a chip select line and read and write strobes. A single address line on pin 8 of the display determines whether data is written to or read from the control registers or the display RAM. A reset line allows the microcontroller to reset the display to a known state prior to configuring it. The backlight is driven by a PWM signal from the microcontroller via Mosfet Q2. As noted earlier, the backlight is fed from the unregulated battery voltage, to maximise the possible brightness and to minimise the power dissipation in the regulator. Mosfet Q1 is used to disconnect the power entirely from the display in sleep mode. We found this necessary since the sleep current of the display was several tens of micro amps. Touch-screen operation The touch-screen is physically integrated with the display but is electrically quite separate. This one is a resistive touch-screen and is formed siliconchip.com.au +3V +3V +3V 100k 100k ADC 100k ADC YPOS XPOS ADC +3V YPOS XPOS YPOS XPOS XR+ YR+ XR+ YR+ XR+ YR+ XR– YR– XR– YR– XR– YR– XNEG YNEG TEST IF TOUCHED XNEG YNEG MEASURE Y POSITION XNEG YNEG MEASURE X POSITION Fig.4: the software polls the touch-screen 100 times per second with the configuration shown at left. If the screen is touched, the ADC will read a low value since the maximum resistance of the touch-screen is much lower than the 100kΩ pull-up resistor. The micro then reads the X and Y positions as shown at centre and right. from two layers of plastic film, each coated with a transparent resistive compound and separated by a small air gap. One film has conductive bars printed across the top and bottom edges, while the other has conductive bars printed down each side. The two plastic films effectively form two wide resistors, one orientated in the horizontal (X) direction, and one in the vertical (Y) direction, as shown in Fig.3. When the screen is pressed with a finger or stylus, the two films touch at the point of contact. This effectively creates a pair of voltage dividers joined at this point. If a voltage is applied between the two X terminals, the voltage measured at one of the Y terminals (while the other is open circuit) will be proportional to the Xcoordinate of the touch point. Similarly, if a voltage is applied between the two Y terminals, the voltage measured on one X terminal will be proportional to the Y-coordinate of the touch point. A bit of scaling and offsetting is required in software. However, it is relatively straightforward to calculate the position of the touch point in terms of the X and Y coordinates of the display pixel on which it occurs. Fig.4 shows how this is done. Note the 100kΩ pull-up resistor on the XPOS line from the touch-screen. This resistor helps detect when the screen has been touched. In normal operation, the software polls the touch-screen 100 times per siliconchip.com.au second with the configuration shown in Fig.4 on the left. If there is no touch, the ADC will read a high value. If the screen is touched, the ADC will read a low value, since the maximum resistance of the touch-screen is much lower than the 100kΩ pull-up. If this test shows that the screen is touched, the micro commences the process of reading the X and Y positions as shown in the centre and right of Fig.4. When the Touch-Screen Recorder is in sleep mode, the ADC is shut down to save power, so we need another way to detect a touch and thus wake the microcontroller. The same configuration of inputs is used as for the touch detection described above but this time the XPOS input pin is configured to provide an interrupt when there is a change of state. Touching the screen changes the normally high level on this input to logic low, triggering an interrupt which wakes the microcontroller. slider. These are also connected to the microcontroller via 1MΩ pull-up resistors. The SD card’s ground pins are switched to ground via Mosfet Q3, which is turned on in normal operation. This allows the SD card to be disconnected in sleep mode, since some cards draw as much as 10mA when idle. Mosfet Q3 is also used to “hard reset” the SD card if necessary. SD card interface The entire circuit, with the exception of the LCD backlight, operates from a 3.0V rail (VCC) derived from the single lithium-ion cell via a low drop-out linear regulator (REG1). This is a Microchip MCP1725 device that can maintain regulation with a dropout voltage of only 50mV at light load. This is important because the lithium ion cell has a nominal voltage of 3.7V. Fully charged, it produces 4.2V but as it discharges, its output drops to 3.2V or below. The regulator has an open-collector The SD card socket (CON6) is connected to the third SPI port on the microcontroller, on the right hand side of the circuit. 100kΩ pull-up resistors are used on each of the lines are required by the SD card standard since some cards apparently power up in open-collector mode. Once the SD card is configured, the outputs switch to totem-pole drivers for speed. The card socket also has switches for detecting the presence of a card and the position of the write-protect PIC32 microcontroller The other connections to the microcontroller include the in-circuit programming header (CON5), the 32kHz crystal and associated loading capacitors, the USB data and bus voltage sensing lines from the USB socket (CON7) and a single LED to indicate SD card read or write activity. Other pins are used for control and monitoring of the power supply as described below. Power supply June 2014  45 APPLICATION MIDDLEWARE EVENT PROCESSING WIDGETS & GRAPHICS DRIVERS DRIVER DRIVER DRIVER DRIVER HARDWARE DATA PUMP POWER SUPPLY LCD TOUCH SCREEN REAL-TIME CLOCK DRIVER CODEC FAT FILE SYSTEM USB MSD CLASS DRIVER USB DEVICE DRIVER SD CARD USB PORT Fig.5: a simplified view of the firmware architecture which is effectively split into three horizontal layers. At the bottom, working directly with the internal peripherals and the external hardware is the “Driver” layer. This is then followed by a “Middleware” layer and then an “Event Processing” layer – see text. output (PGOOD, pin 5) that pulls low if the regulator output falls below 96% of the nominal 3.0V (at approximately 2.88V). The microcontroller software responds to this by ending any recording or playback in progress and putting the recorder into sleep mode. This is necessary to prevent permanent damage to the lithium ion cell which can occur if it is discharged below 2.7V. Mosfet Q4 provides polarity protection, against inserting the lithium cell backwards. The cell has a fairly low impedance and could damage the regulator and other semiconductors if inserted wrongly (as we discovered the hard way). A series diode can’t be used in this case because the battery has to charge as well as discharge and in any case, we can’t really tolerate the relatively high voltage drop of a diode in this circuit. The Mosfet is ideal for the job because the channel can conduct in either direction if the gate is positive with respect to the source pin. If the cell is inserted backwards, the Mosfet will be off and the body diode will be reverse biased, so no current will flow. The microcontroller reads the battery level via a voltage divider consisting of two 4.7MΩ resistors. These high values were chosen to limit the current drain of the divider, which is connected across the battery. The cell itself is charged by IC2, an LM3658 lithium-ion or lithium-poly­ mer charger, designed to run from USB. It uses a complex, multi-stage charging process and can monitor battery temperature, although we don’t use this feature. 46  Silicon Chip IC2 also limits the current drawn from the USB port to 100mA or 500mA, depending on the level of the signal on pin 4, to ensure the current drain remains within USB requirements. USB devices are not supposed to draw more than 100mA until they indicate this requirement and are enumerated by the host. Pins 6 & 7 of IC2 are open-collector status outputs that indicate the charger state. The software reads these inputs and uses the information together with the cell voltage to display the battery status. When not connected to a USB port or charger, the battery indicator displays HIGH, FAIR or LOW to indicate remaining battery capacity. When the unit is connected to a charging source, the indicator displays CHRG or FULL or ERR to indicate whether charging is in progress, complete or has failed for some reason. The battery charger indicates an error if the battery cannot be charged within a 5-hour period, usually indicating a faulty battery. If this error occurs, the USB power must be removed and restored to reset the battery charger. Firmware description The firmware for the Touch-Screen Recorder is relatively complex and a full explanation of its workings is beyond the scope of this article. However, let’s provide a broad overview. Fig.5 shows a simplified picture of the firmware architecture which is split into three horizontal layers. The green shaded boxes indicate pieces of third-party code that were incorporated into the design. At the bottom level, working directly with the internal peripherals and the external hardware is a series of drivers. The aim of these drivers is to hide the devicespecific details and provide a programming interface independent of the hardware. Ideally, we could replace the hardware (say by using a different display) and only have to modify the relevant display driver. Similarly, the same display could be used in another project and the driver should be usable without modification. By way of example, the LCD driver hides the device specific instructions necessary to configure the display driver chip behind a ‘C’ function that initialises the display. Another function draws a single pixel of a specified colour at a point defined by given X and Y co-ordinates. Other functions are available to draw solid blocks of pixels, to shut down and wake up the display and control the backlight. These functions are exposed to the upper layers in the relevant ‘C’ header files. All the device specific complexity and any local variables or functions are hidden away within the driver. Unlike the LCD, some of the drivers have to respond to real-time events (like a touch on the screen). These drivers need some mechanism to let the system know that an event has happened, and the system needs a mechanism to manage and make sense of the unpredictable influx of events. There are plenty of possible approaches but we have elected to handle this with an event queue. The drivers post events to a first-in first-out (FIFO) queue as they occur. They are dealt siliconchip.com.au with in turn by the event processor, which we discuss below. Middleware layer A middleware layer is used when an advanced level of abstraction is required between the drivers and the application. Continuing our example from above, it would be handy to have a mechanism to draw more complex items on the display, such as lines, shapes, text and icons. These requirements are neither application specific like the top layer, nor are they hardware specific, like the drivers. The graphics middleware module, for example, calls on the driver functions that draw a single pixel or block of colour and exposes useful higherlevel functions. One such function draws a line between any two points in a specified colour or thickness. Another draws proportional width text. In fact, this module provides routines for drawing filled and empty circles or arcs, rectangles and roundcornered rectangles, for rendering text and drawing icons. Not all of these are used in the Touch-Screen Recorder, since this module was developed for and has been used in other projects. Also in the middleware layer is the data pump (responsible for shifting data between the CODEC and the SD card), the FAT file system and part of the USB stack. Lets look at these in a bit more detail. Data pump & file system In many ways, the data pump is the beating heart of the Touch-Screen Recorder. It has to move data between the CODEC and the SD card at a sufficient rate to avoid glitches in the audio. The CODEC produces (and consumes) data at a rate proportional to the sampling rate, number of channels and the word size. We use a fixed 16-bit data width and two channels, so each audio sample is four bytes long. At 96ks/s we have a data stream of 384,000 bytes per second to contend with. In contrast, reading and writing files to and from the SD card is a discontinuous process. Data is stored in clusters of 512-byte sectors that may be distributed around the disk in a non-contiguous manner. By the way, the SD card must be formatted with a FAT file system (this is how most cards are formatted out-of-the-box). FAT32, FAT16 and even the older FAT12 formats are supported. Files siliconchip.com.au The top side of the PCB carries the SD card socket and the LCD touch-sceen. We will show you how to build it in Pt.2 next month. can be played from or recorded in any directory and file names up to 128 characters are supported. Each recording is made in a new file that is given a unique name based on the date and time. For example a recording made on 16th May, 2014 at 2:57:20pm would be written to a file named REC140516-145720.WAV. The file system has to consult the file allocation table on the disk to know where to find or place the next cluster of the file being read or written. All of this takes time. Add to this the fact that SD cards are based on flash memory that has a relatively long write time. When we write to the SD card, the data is actually written into an internal RAM buffer (which is fast) but when this buffer is full, the card must write the contents of this buffer to the flash, a process that can take a few hundred milliseconds or more. The precise time will depend on the write speed of the card and the size of the internal buffer. In general, newer cards are faster than older ones. Thus, we need to use a pair of internal buffers in the data pump so that one can be filling (to use recording as an example) with data from the CODEC while the other is being written to the SD card. As long as the write time does not exceed the buffer fill time, the system will be ready to write the next buffer as soon as it is filled. If the write time does exceed the fill time, we will find ourselves trying to write and fill the same buffer. This would lead to audible glitches. The PIC32 microcontroller we have chosen has 128kB of RAM. We found we could allocate up to 96kB of this for the data buffers (two buffers of 48kB each). At the fastest data rate, we fill one of these buffers every 125ms. This is enough to cater to most SD cards. At lower data rates, the SD card write times become less of an issue. At 8ksps, the buffers each take 1.5s to fill. The data is shifted between the CODEC SPI and the buffers by DMA (direct memory access), so no processor intervention is required in this process. When one buffer is filled or emptied, the DMA unit automatically switches over to fill or empty the other one and an interrupt is generated. Code in the interrupt service routine takes care of reading or writing the data to or from the SD card. The activity LED (LED1) is lit when this is in progress. The file system used in this project is called FatFS and was developed by a Japanese hobbyist who goes by the online name of ChaN. This free file system is available at http://elm-chan. org/fsw/ff/00index_e.html and has an open license for hobbyist or commercial applications. It has proven to be far more robust, better documented and much faster than other file systems we tried, including one from Microchip. USB stack We do, however, use Microchip’s June 2014  47 The end panel of the Touch-Screen Recorder provides access to the line input and output sockets, the micro­ phone & headphone sockets, the USB socket and the SD card socket. USB stack (available free from their website). This consists of a large number of files containing the driver code to control the USB interface peripheral and the higher-level elements of the USB stack necessary to implement a USB Device. In USB-speak, entities can be either a Host (typically a PC) or a Device, like the Touch-Screen Recorder. When first connected, a USB Device makes itself and its capabilities known to the Host through a process called enumeration. During enumeration, the Device must tell the Host what class of device it is so that the Host can load the appropriate driver. There are a number of standard Device classes for which common operating systems have native drivers. Examples include (1) the Human Interface Device (HID) class for computer mice and keyboards and (2) the Mass Storage Device (MSD) class for hard disks, memory sticks and the like. The Touch-Screen Recorder is configured to appear as a MSD class Device and so will appear to a Windows, Mac or Linux operating system as an external disk drive. Interestingly, the USB Mass Storage class does not rely on the Device’s file system but rather presents the disk drive to the Host as a SCSI disk and uses the intelligence at the Host end to make sense of the data. The MSD firmware does, however, require the user to provide drivers to handle the basic communication with the media, such as reading or writing a sector. Fortunately, the requirements of the FAT file system and the MSD system are similar, so only one set of drivers is required. Unfortunately, the MSD stack only ever reads and writes a single sector at a time, whereas the FAT file system makes use of multisector reads and writes that are much faster for the bulk transfer of data. This means that data transfer to and from the SD card over the USB interface is relatively slow. Event-driven programming At the top level of the architecture, an event manager controls the specific functionality of the Touch-Screen Recorder application. The various drivers and middleware modules post messages to the event queue to signal that some particular event has occurred. The event message indicates the source of the event and any important details. For example, the touch-screen driver posts a message if the screen is touched and includes the X and Y co-ordinates of the point where it occurred. In the Touch-Screen Recorder, events are posted by the touch-screen driver (Press, Still Press, Release, Invalid), the SD card driver (SD Inserted, SD Removed), the real-time clock (One Second Tick, Half Second Tick), the data pump (Recording Stopped, Playing Stopped) and the USB driver (Device Disconnected, Device Detached, Device Attached, Device Ready). Many different error events can also be posted, although these are handled in a slightly different way as described below. After initialising the various subsystems, the main flow of execution enters a loop where it constantly monitors the event queue. Whenever an event is found in the queue, it is popped out and processed by calling the appropriate routines to handle that event type. Error events are not posted to the queue in the same way as other events, since event processing is serial and there may be several events in the queue ahead of the error event. We don’t want to wait until all the pending events are handled before dealing with the error. Using the ‘C’ standard functions for “non-local jumps” (<setjmp.h>), we can ensure errors are processed immediately as they occur. If any function throws an error, the program flow switches immediately to the event handler, where the error is handled as if it had just been popped out of the queue. There is no need to finish processing the current event or to wait for any pending events. The event processing architecture provides a very robust and reliable framework for the Touch-Screen Recorder firmware and allows the addition of new functions with minimal chance of ‘breaking’ anything. Next month in Pt.2, we will give the assembly details, provide some performance graphs and show how to use and set up the Touch-Screen SC Recorder. Issues Getting Dog-Eared? Are your SILICON CHIP copies getting damaged or dog-eared just lying around in a cupboard or on a shelf? Can you quickly find a particular issue that you need to refer to? REAL VALUE AT $14.95 PLUS P & P Keep your copies of SILICON CHIP safe, secure and always available with these handy binders Order now from www.siliconchip.com.au/Shop/4 or call (02) 9939 3295 and quote your credit card number or mail the handy order form in this issue. *See website for overseas prices. 48  Silicon Chip siliconchip.com.au