Page 34

EETE SEP 2014

PROGRAMABLE LOGIC Beating the mobile barcode block By Ted Marena The problem that barcode readers have with screens on most mobile devices can be overcome using a simple FPGA-based reference design Imagine being able to buy a gift card and text it to a friend. The card would contain a barcode that could be read from the mobile phone screen in the shop to redeem the gift. There is a snag though – traditional laser-based barcode readers cannot read a barcode displayed on an LCD, such as found on smartphones and other mobile devices. This is because the laser bounces off the screen rather than reading the information. However, it is possible to make an LED emulate the barcode reflection and actively transmit the information to generic barcode Fig. 1: The barcode emulator sits between the application processor and the LED. scanners. Basically, it creates a fake reflection that fools the scanner into thinking it is seeing a barcode. The scanner reads the data coming from the LED rather than reading the barcode and thinks it is seeing a barcode. Though designed for mobile devices, this reference design can be used with any product that has an LED by transferring barcode data from the application processor to the LED; the design acts as the data control and buffer between the two and is based on the iCE40LM ultra-low-power FPGA and sensor manager from Lattice Semiconductor - see figure 1. The LED used could be the back light for the mobile phone’s screen, but more commonly it would be one of the small LEDs such as the flash LED, signal indicator LED or selfie LED. This could be a monochrome or white LED. As it is just creating a fake reflection, the colour does not matter. The emulator connects to the application Fig. 2: Functional block diagram. processor via the SPI (serial peripheral interface) bus using a clock frequency set to 10.8MHz to enable fast communications to and from the processor. The iCE40LM prepares the data and sends them to the LED with the frequency, duration and interval required by Code 39 barcode encoding. The correct frequency is achieved by using a dynamic clock generator that sweeps the frequencies at which the LED emits the signal so it can be used by just about any barcode reader. The system operates at 27MHz and the SPI bus should have a voltage of 1.8V and the LED a 3.3V input and output. The reference design consumes just 356 LUTs (look-up tables), so it can fit into a device as small as an iCE40LM1K. Because the design is based on an FPGA, it is fully customisable. This means other barcode emulation standards can be accommodated by changing the data acquisition depth of the FIFO, creating an IO bridge between the LED and the processor or creating additional custom logic. When this FPGA is used in this application, it has a core voltage of 1.2V and is available in a small 25-pin WLSCP package with a 0.35mm ball pitch and a footprint of 1.71 by 1.71mm, which means it will fit into most smartphones. If space is not as critical, the device is also available in packages with a 0.4mm ball pitch with either 36 balls measuring 2.5 by 2.5mm or with 49 balls measuring 3 by 3mm. It will operate from -40 to +100˚C. Functional operation Figure 2 shows a block diagram of the functional operation of the design. Data are received from the processor, formatted and stored in a data buffer. When the control commands are received and processed, the barcode logic reads the buffer content and converts the data into serial signals that drive the LED. It will continue to do this until it receives a stop signal. The top level of the barcode emulation is found in a module that contains the SPI slave-to-application processor, control registers, data buffer, barcode logic and power-on-reset module. The firmware register and a counter are used to create the different clock frequencies. The SPI interface-to-application processor is in the SPI slave module that waits until an interrupt is received from the processor. When a read command is received, it sends commands to the read registers. The module then receives the read data and sends them to the application processor. When a write command is received, it decodes the command and sends the appropriate data to the registers. The module that contains the control registers and data buffer stores the data for the LED in a buffer and decodes the control signals from the processor to initiate or stop data transmission to the LED. The control signals processed are code delay rate, code bit rate, number of cycles, start and stop. Additional Ted Marena is Director of Product Marketing at Lattice Semiconductor – www.latticesemi.com 30 Electronic Engineering Times Europe September 2014 www.electronics-eetimes.com


EETE SEP 2014
To see the actual publication please follow the link above