Interfacing

ACR122U NFC reader

Near Field Communication (NFC) is a type of Radio-Frequency IDentification (RFID) that allows a user to perform some form of action without making physical contact with something. Whereas, for example, pressing a key on a keyboard requires our fingers to make contact with the keyboard's keys with NFC we can place a smart card in proximity of a reader and it will do something.

A common use of NFC is in smart cards which contain an onboard circuit that is powered by the reader, in the case of passive smart cards. By comparison, active smart cards contain a battery and work at a much further distance than passive smart cards. One advantage of passive smart cards is as they do not require a battery and so the card should always work; nothing needs replacing.

One simple use of a smart card is to identify a user which in turn can be used to allow access to something, such as to unlock a door or to open a file on a computer. Examples of real-world uses of NFC are the Oyster cards used for transport in the UK, the Skylanders (and similar) video game toys and the security tags on valuable items in a shop. Some smart cards don't just act as an identifier; as with the example of Oyster cards, data can be written to the smart card (for example, a monetary value).

As my first venture into the world of NFC I bought from ebay the ACR122U NFC reader made by Advanced card systems ltd, for about £25. You can see the reader below with one of the five NFC cards that came with it:

The ACR122U is apparently a better version of the ACR122; it has a USB connection, is small and light and is rated at 200mA. When plugged into a computer a light turns red; when an NFC card nears the reader the light changes green and a short bleep is emitted. The cards have no markings on them and are Mifare 1K cards (they have 1K onboard writeable memory).

Also included with the reader was a CD containing drivers, doc & sample code; however, the same code was for an old version of Visual Studio and even after converting it to the new version I have (VS 2010) there was still problems running the code. So I started a new project and based it on the sample code that I couldn't get to run. Had to add Winscard.lib (32-bit) to the project since it uses the NFC reader functions; Winscard.lib and WINSCARD.h are provided on the CD.

The program I created simply identifies a number of smart cards using the UID (Universal IDentification) number stored on the card which is then associated with a name stored in the program. Simply connect the reader to your computer, run the program and you will see a message saying that the reader has been detected along with the reader's name. You can then click the 'Connect' button and if there is a smart card on the reader a name is displayed along with the UID of the smart card in brackets. You will need to change the UID's in the program to match those on your smart cards. To find out the UID of a smart card run the 'ACR122U Tool' program on the provided CD while the reader is connected to your computer. Then click  the 'Connect' button (next to the floppy icon) and select the reader from the drop-down. Go to the 'Reader commands' menu and select 'Get data' to get information from the smart card such as the UID. It's a good idea that once you know the UID to write it on a label that is then placed on the smart card.

Back to my program: if you run it without the reader connected to your computer then 'There is no reader' message box will show. The program window is then displayed but you won't be able to click the 'Connect' button. You will need to exit the program, connect the reader and run the program again. If you try to connect to a smart card that is unknown (that is, its UID isn't stored in the program) then an 'Unknown user' message box is displayed. Lastly, if you connect with no card on the reader then you will get a message box saying: 'Could not connect to the smart card.'

At the bottom of this page you can download 'NFC_Reader_test_1.cpp' which is the main source file of my reader tester program as previously talked about. The C++ file was written using Visual Studio 2010 but there shouldn't be a problem converting it to other versions of VS. I have commented in the C++ file what is happening as well as comments (starting and ending with '***') of things that need to be changed or added to make the program run better.

To cut down on download size I have only provided the main source file (NFC_Reader_test_1.cpp) which is part of a project you'll need to create. The project uses a form called 'Form1' which you'll need to add to your project along with a button on the form called 'ConnectBtn' which has the text 'Connect'.

In Form1.h (the form's header) you will need to add the following:

private:

void init(); //Perform startup tasks

void connectToReader(); //Connect to a reader

private: System::Void Form1_Load(System::Object^  sender, System::EventArgs^  e) { //Perform startup tasks before the main window is displayed

init(); //Perform startup tasks

}

private: System::Void ConnectBtn_Click(System::Object^  sender, System::EventArgs^  e) {

connectToReader(); //Connect to a smart card contained by a reader

}

The above code first declares two functions (init() for performing startup tasks and connectToReader() to connect to a smart card on the reader). Then we have the Load() function which is called once when the program starts to do the initialization and ConnectBtn_Click() to connect to the smart card when the Connect button is pressed.

A number of ways to make better the program is to create a class for the NFC reader so the code is more secure and can be re-used easier. Polling is also something useful to add as this would allow the reader to continually be checked for a smart card rather than having to click a button.

You can check out a list of smart card and other security functions such as those used in the NFC reader software by going to:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa374731(v=vs.85).aspx

Analog Devices Evaluation Boards

Please go to Analog Devices Evaluation Boards.

Arduino

For an introduction to the Arduino and various Arduino projects please go to Arduino.

AVR Butterfly

The AVR Butterfly by Atmel is a neat little module that can be worn as a name badge but does so much more that just display a name on its LCD. At the heart of the unit is an ATmega169 8-bit microcontroller of which the Butterfly was designed to show off the capabilities of. Also on the Butterfly is a mini joystick for navigating the menus displayed on the LCD, a simple speaker for playing basic sounds, a thermistor to sense temperature, connections for reading a voltage, and on some versions of the Butterfly an LDR to report light levels (you can solder your own LDR if it wasn't included). The Butterfly is powered by a CR2450 cell which is larger than the more standard CR2032 but lasts longer. For programming and communication the Butterfly has RS-232, JTAG and USI; wires or connectors can be soldered to the board as needed for the ports. 

As the Butterfly comes pre-programmed you only have to press up on the joystick and then you can move around the menus to set the name, play some music, and so on. You can read more about the Butterfly here:

http://www.atmel.com/Images/doc4271.pdf

It is possible to download a name to the Butterfly by connecting it to a computer's RS-232 (COM) port (either built-in or by using a USB converter) and sending the name using a terminal program (you can find more details in the link above). However, I found that I could only send two characters-any more and the Butterfly would just take the first two characters. The problem turned out to be poor wording of the official documentation and online sites. You actually have to send each character individually since the Butterfly requires a delay between the characters. Because the string needs to be terminated by a carriage return you can send the last character and the carriage return together.

The Butterfly can be programmed using AVR studio 4 (newer versions are not compatible):

http://www.atmel.com/tools/STUDIOARCHIVE.aspx

It's best to get the most recent version which is 4.19.

One of the features that does not work on some Butterfly units is the so-called self programming which lets you re-program the Butterfly's microcontroller via its RS-232 port. The cause appears to be a boot fuse that is not set but there are a number of ways to get around it.

AVRProg (Tools menu in AVR studio) is what can be used to actually program the Butterfly's microcontroller. It waits for a '?' to detect the Butterfly and that is why you press the joystick down when you select AVRProg so that it transmits the '?' character (when the Butterfly is in bootloader mode). I had tested with a terminal program and the Butterfly did transmit '?' characters when pressing down on the joystick while in bootloader mode.

From looking online I found a way to connect to the Butterfly using a terminal program so that it would then work with AVRProg:

http://downloads.smileymicros.com/Butterfly/Butterfly%20Frequently%20Asked%20Questions.pdf

(Section: My butterfly doesn't communicate with my PC.)

Now, when I selected the AVRProg option the Butterfly was detected and I successfully read the flash and EEPROM memory of the microcontroller in the Butterfly. However, I was using a USB to COM port and have to change the port number to COM2 as its default name 'COM8' did not work, even after telling AVR studio to check 8 COM ports.

DS1307 Real Time Clock Module With AT24C32 EEPROM

As part of another project, I needed a real time clock so I would have an accurate way of keeping and displaying the date and time. You can use a microcontroller to keep track of the date and time but it will not give great precision and will loose the date and time should the power be lost. A real time clock module overcomes these problems and I was able to buy one cheaply from ebay.

The module contains a DS1307 real time clock that handles hours, minutes, seconds, days, months, the date, and year. There is also an AT24C32 32Kb EEPROM, which like the DS1307, uses the I2C 2 wire protocol and can be accessed using an unique device ID. You can run an Arduino program to check for I2C devices connected to the module and retrieve their device ID's. For the module I got the device ID's are 80 for the EEPROM and 104 for the RTC.

There is also space for a 3 terminal component, such as a DS18B20 temperature sensor, which uses the 1-wire bus system and has its own data connection. There are other modules that include a DS18B20 as well as a DS1307 and an AT24C32 so it is likely that the same circuit board is used. It would be simple enough to solder a sensor to the module as the connections have already been provided.

Although a row of connections are provided on both sides of the board, the GND, VCC, SDA, SCL and DS connections are connected together from both sides. The BAT and SQ connections, which are unique to the RTC, are only on one side. Since both the DS1307 and AT24C32 share the same bus, there is only really need to make use of the row of connections that include BAT and SQ, if they are even needed.

A LIR2032 3.6V rechargeable battery is used by the module so that the DS1307 can continue to keep the date and time when there is no external power connected (5V) through VCC and GND. While the module will update the time without a battery connected the date and time will be gone when the external supply is removed. Although I have not tested it, supposedly the module contains a circuit to recharge the battery, when external power is applied to the module. Since the date and time can only be read when external power is connected, the battery will most likely be kept topped up.

Elektor Development Boards

Please go to Elektor Development Boards.

ESP Wireless Modules

Please go to ESP Wireless Modules.

FPGA

Please go to Field-Programmable Gate Array.

Interfacing to a Computer

As much as technology has progressed in a good way, for some, older computers are better for connecting you own circuits to, as you will soon see. The most popular way for hobbyists to interface with a 'modern' computer was by use of the parallel port, which was originally designed to communicate with printers (and then later was used to connect scanners and other devices to). Because of the parallel port being used to interface with more complicated peripherals, the parallel port's capabilities were expanded, such as to add bi-directional control of data. This resulted in several parallel port modes that could be selected from the computer's BIOS settings, to emulate the different modes, to maintain backwards compatibility to devices connected to the parallel port.

The parallel port is very useful for interfacing because it contains eight data lines that can be configured as either all inputs or all outputs, as well as several other signals that are always input and further signals that are always output. To use the parallel port, there are a number of control structures in memory which can be accessed through software.

To give you an idea or what is possible with the parallel port, you can connect switches which software can detect and respond to (which would be handy, for example, to trigger an alarm). You can also connect lights to the parallel port which software can turn on and off, which would be good, for example, to warn a user of a problem. And then you can get more advanced such as to update LCD and LED displays by using the parallel port.

You may be thinking that a type of interface that was once used only for printers but can actually be used for so much more, seems too good to be true. Well, it kind of is depending on what computer you have and this brings me back to the first paragraph of this section where I mentioned that older computers were better for interfacing. The problem is that some operating systems, including Windows XP, Windows Vista and Windows 7 prevent direct access to hardware ports such as the parallel port. However, there are ways to get around that, by using a special parallel port driver, for example. But that's if you even have a parallel port on your computer as especially with laptops, most computers nowadays don't even have a parallel port, replaced with USB which is not as straightforward for interfacing with. There are, however, USB to parallel port adapters but using them for interfacing with your own projects may not work.

One way to interface with a computer that does not have a parallel port (or cannot be accessed through software) is to use a USB experiment interface board. This gives you a number of inputs and outputs to which you can connect switches, lights, etc. and communicate with them using a driver.

Interfacing to Super Mario 64

Please go to Interfacing to Super Mario 64

Jog Wii pedometer

I had bought a 'Jog' pedometer for the Wii from a 99p store thinking for that price I could perhaps modify it and use it for something else. It turns out it was well worth getting as upon opening it, as you can see below, it not only uses a readily available microcontroller, it has various debug connections that where no doubt used during manufacture.

The microcontroller is an Atmega169vp which has support for an LCD so that makes sense why it was used in the pedometer. There is also another, much smaller chip, with the numbers '033 946 001' written on it that I have been unable to find information on. However, it is most likely a 1-axis accelerometer used to detect movement of the hips; there is even a connection near to the chip marked 'X' which further suggests the chip is an accelerometer.

As well as what looks like a serial port (RXD and TXD) and an SPI port (MOS, MIS and SCK) there are in addition what could be JTAG connections to the microcontroller. There are also VCC and GND connections which are the same power connections as would be provided by the Wii remote.

The packaging and instructions for the pedometer are in Spanish and the product no doubt is unofficial. It works by connecting to a Wii remote as well as having a nunchuck connected to the pedometer. With the Wii turned on the pedometer can be used to count steps without even having a game loaded. However, if used with any game in which the nunchuck is used to control an on-screen character, pressing the nunchuck stick will not move the character unless the pedometer detects the person is walking.

To test the pedometer I purchased a Wii adapter breakout board designed to be connected to a Wii nunchuck or any other device that plugs into the Wii remote. Using the adapter there is no need to cut any wires as the adapter just plugs into the nunchuck connector (or, in this case, pedometer) and provides connections to power and the I2C data and clock limes.

In examples I have seen of interfacing a nunchuck with an Arduino some people power the nunchuck with 5V, others a lower voltage. Since a Wii remote runs on 3V and assuming there is no step-up circuitry, most likely the nunchuck was designed to run on 3V. However, it may be the nunchuck's processor has a wider voltage range and can run on 5V. Certainly, the Atmega169vp in the pedometer can run on 1.8V to 5.5V. Nevertheless, to be on the safe side as there are other components in the pedometer, I powered the pedometer on 3V using the breakout board and with a nunchuck connected to the pedometer it worked as normal, counting steps.

Large LED Dot Matrix Display

Please go to Large LED Dot Matrix Display

micro:bit

Please go to The micro:bit.

MikroElektronika Development Boards

Please go to MikroElektronika Development Boards.

NXP Semiconductors Development Boards

Please go to NXP Semiconductors Development Boards.

NRF24L01 Transceiver

If you need a way to communicate wirelessly at low cost then the NRF24L01 transceiver is a very good choice. In a small size it combines both a transmitter and receiver that operate at 2.4GHz, although it cannot transmit and receive simultaneously. One of these transceivers can talk to a maximum of six others

The device operates on the voltage range 1.9V to 3.6V but has 5V tolerant inputs. This means that while the NRF24L01 must not be supplied with more than 3.6V, it can still be connected to a microprocessor that runs on 5V. If you are using an Arduino with the NRF24L01 then you can use the 3.3V output available on most Arduino boards to power the NRF24L01.

To test out wireless communication using two NRF24L01 modules I used an Arduino Uno and an Arduino Mega. You could use two Arduino Unos or two Arduino Megas or other combinations but I happened to have those two Arduinos. I powered each Arduino using 9V (6 X AA) supplied to each of the Arduino's VIN input. I could have used PP3 batteries but they won't last as long as using AA batteries.

You can see the set-up above with the Arduino Uno on the left and the Arduino Mega on the right. The Arduino Uno acts as the transmitter using the NRF24L01 which sends a value to the Arduino Mega depending on the switch pressed (only four of the switches are used but I so happened to have those lot of switches already so it made sense to use them). The Arduino mega, which acts as the receiver via its own NRF24L01, lights up an LED relating to the switch that was pressed.

Olimex MSP430 Development Boards

Please go to Olimex MSP430 Development Boards.

pcDuino

Please go to The pcDuino.

PIC Microcontrollers

For an introduction to PIC microcontrollers and various PIC projects please go to PIC Microcontrollers.

Raspberry Pi

Please go to The Raspberry Pi.

Shimafuji Development Boards

Please go to Shimafuji Development Boards.

Super Mario 64 Real HUD

Please go to Super Mario 64 Real HUD.

All content of this and related pages is copyright (c) James S. 2011-2024