Today's Hardware Friday post is another project from our Friend of the Blog, Paolo Patierno (yeah, yeah, I know, it seems like I'm posting his stuff all the time, but hey, it's cool stuff! ;)
Speaking of past posts...
- Get your .Net Micro Framework devices up with the μPLibrary!
- Machine 2 Machine with a MQTT .Net Library
- More Machine 2 Machine with M2Mqtt. Now with SSL/TLS and async events
- Modern UI Weather Station, .Net Micro Framework powered
- .Net Micro Framework : SPI, the high speed serial bus !
And today is a two for one day too!
At the same as SPI, analyzed in a previous article, the I2C (Inter-Integrated Circuit) is a synchronous communication bus used to connect and exchange data between a microprocessor and external devices; it was developed by Philips, now NXP, today it is "de facto" standard.
The I2C bus is also known as two-wire as it is characterized in all the effects of only two "wires":
SDA (Serial Data Line) : line for the data transfer;
SCL (Serial CLock) : clock for data exchange;
The lines abovelines are always characterized by a pull-up resistor that has the task of maintaining the signal "high" (logic 1) in conditions of idle while the interconnected components (master and slave) have the task of lowering the level to transfer a logic 0 and release it to bring it back to idle and transfer a logic 1, this behavior is typical of the open-drain lines.
Net Micro Framework : the supported classes for the bus
The. Net Micro Framework considerably simplifies the use of the I2C bus by using the I2CDevice class (namespace Microsoft.SPOT.Hardware, Microsoft.SPOT.Hardware.dll assemblies), whose constructor expects a parameter of type I2CDevice.Configuration to be suitably configured, this configuration allows you to set:
Address : slave address;
ClockRateKhz : clock frequency;
All the above configuration parameters are always closely tied to the device with which you want to communicate and to be found in the datasheet.
The I2C bus unlike the SPI is obviously not full duplex being characterized by a single data line and is even slower in terms of speed. The main advantage is that you do not have the complexity of a selection signal of the slave and be able to work in multi master mode.
The. NET Micro Framework enables you to use this bus very easily with a single class and the concept of read / write I2C "transactions" in order to perform the communication in a single "shot".
Very soon you will see a real example of application of this bus (like the SPI bus) with a managed driver I developed for an NFC chip from NXP
After the previous two articles describing the SPI and I2C buses and their use with the .Net Micro Framework, it is now finally time to see a practical application with my latest project available on CodePlex : uNFC – NFC library for .Net platforms !
Introduction : software and hardware support
This library allows to use NFC integrated circuit connected to your PC (via serial) or to embedded system based on Windows Embedded Compact or .Net Micro Framework.
It supports all three types of .Net Framework :
.Net Framework 4.0 for PC based on Windows 7 / 8 or embedded systems based on Windows Embedded Standard 7 and Windows Embedded 8 Standard;
.Net Compact Framework 3.5 / 3.9 for embedded systems based on Windows Embedded Compact 7 and Windows Embedded Compact 2013;
.Net Micro Framework 4.2 and 4.3 for embedded systems like Netduino boards and .Net Gadgeteed boards;
The library supports NXP PN532 chip but it also defines a little framework so that you can develop a managed driver for a new chip and change it without modifying the upper layers and interface to the user application. The support for PN532 chip provides all three possible communication channels for it : I2C, SPI and HSU. Tipically the HSU (High Speed UART) channel is used for connecting to a serial port on PC or Windows Embedded Compact based system. I2C and SPI connections are better for .Net Micro Framework based boards.
The development and testing was made using RFID/NFC Breakout board from Elecfreaks available at following link; The reference for PN532 managed driver is the official NXP user manual available here. For connection to a PC, you obviously need a converter USB - Serial TTL (such as the FTDI) with their drivers to interface to the reader always through a serial port (in this case virtual).
The managed driver for the chip PN532 is implemented by the PN532 class that has a reference to an instance of the communication layer that must implement the IPN532CommunicationLayer interface. In this way, we have the ability to choose which channel to use by providing an instance of a concrete class that implements this interface to the PN532 class constructor. The classes available are the following:
PN532CommunicationI2C : I2C channel;
PN532CommunicationSPI : SPI channel;
PN532CommunicationHSU : HSU channel;
The reader based on this chip is implemented through the NfcPN532Reader class that has a reference to the instance of the PN532 class. This class implements the INfcReader interface. This means that if we want to use another chip, we have to follow these steps:
Implement a class for the driver (such as PN532);
Implement a class for the reader that has a reference to the aforementioned drivers and implements the INfcReader interface;
The presence of multiple classes implementing the PN532 chip is closely related to the fact that the latter has more communication channels for interfacing.
Firstly, it should create an instance of one of the classes related to the communication channel and each of them is closely tied to the board on which we are working. Later that instance be provided to the constructor of the PN532 class and the latter must be passed to the constructor of the NfcPN532Reader class.
The INfcReader interface that it implements, exposes :
the Open() method to initialize the reader, specifying the type of NFC tag that we expect to be able to recognize;
the Close() method to close the connection to the reader;
the WriteRead() method to write and read to / from the reader;
TadDetected event that is raised when a tag is recognized by the reader;
TagLost event that is raised when the reader loses the connection with the tags recognized;
Using the last two events, you can register an event handler for each of them so that you can handle the recognition of a tag by the reader in and out of the tag itself.
The project is just beginning and I hope to have many feedback from those who will use it to improve it. The ability to build a driver for a different NFC chip architecture and integrate it without altering the higher levels, it can be a strength.
The reading and writing NFC tags is "raw" and there is no support for NDEF (NFC Data Exchange Format) but do not worry ! The Mopius team added me as a developer to the NDEF Library project and my goal is to realize the porting on .Net Micro Framework.
Now you're ready to add NFC to your next .Net Micro Framework project... Oh and don't forget that the source for the library is available too at https://unfc.codeplex.com/