RFID / NFC support

Issue #34 resolved
connochaetes created an issue

Hi.

First of all, thanks for microBlocks. I ‘m trying to use my micro:bit with a RFID device. I ’ve got a “PN532 NFC RFID Module V3” (which offers I2C) and a “RFID Kit RC522”. It would be possible to buy another model, for they are generally not too expensive.

In the past, I tried to get things running via Snap4Arduino - sadly, without any success.@Joan Guillén i Pelegay Thanks for your support: https://github.com/bromagosa/Snap4Arduino/issues/242


I found these articles online:
https://www.hackster.io/infchem/lies-drahtlos-nfc-textnachrichten-7eae5c

https://github.com/infchem/pxt-calliope-grove-pn532

Obviously, Mirek Hancl (a teacher from Northern Germany) found a way to get things running by using MakeCode/PXT, a Calliope and a “Seeed Grove NFC Device”.


→ Would it be possible to achieve something similar with microBlocks? (… and in the future with “Snap!”?)
A first step for me would be to simply read out a tag ID.

Best wishes.

Comments (40)

  1. John Maloney repo owner

    I found some documentation here:

    http://wiki.sunfounder.cc/index.php?title=PN532_NFC_RFID_Module

    Although I’m not sure if it matches the module you have.

    MicroBlocks has blocks for interacting with devices via I2C and SPI so, in theory, you should be able write a MicroBlocks library to interact with this device, using the Arduino library as a guide.

    As a first step, I’d write a simple Arduino sketch to test the device itself. Sometimes these super-cheap devices from AliExpress don’t work as expected. If that works, the next step would be to use the MicroBlocks I2C blocks to talk to it. The I2C blocks are only visible if you select “show advanced blocks” in the MicroBlocks menu (the menu you get when clicking on the MicroBlocks icon or right-clicking on the top bar). Right now, they appear in the “Advanced” category, but we’re about the change the palette. After that change, they will be in the “Comm” category (but still visible only in advanced blocks mode).

    If you get to the point where you can talk to the device with I2C, you’ll be well on the path to success. After that, its a matter of studying the Arduino library and documentation to understand what I2C commands you need to issue to start a RFID read and what registers you need to read to get the result.

    If you make a library for this, please post a link to it here. We don’t yet have a webpage for user-created libraries, but we hope to set one up once MicroBlocks gets into beta.

  2. connochaetes reporter

    Thanks for your friendly response (especially the advanced blocks explanation). I ‘ve successfully tested both devices via Arduino IDE. I guess, I ’m in need of a further hint at this point - some kind of “I2C for dummies” tutorial. In theory, the next step seems quite clear. Regarding my experiences with Snap4Arduino, it ‘s quite a step for me to find the appropriate I2C command just by reading the device’s documentation.

  3. connochaetes reporter

    Thanks for microBlocks 0.2.1. In the meantime, I ‘ve been testing several RFID / NFC devices. Sadly, there ‘s no success by now. I ’m still looking for an I2C “hello world” tutorial.

    I noticed, that the microBlocks library folder is growing. Is there any supported RFIC / NFC device by now? It would by quite helpful for me, if there was a plug-and-play device.

  4. John Maloney repo owner

    Nice video! It looks like they are using a NFC card from DFRobot:

    https://www.dfrobot.com/product-892.html

    That particular card has been discontinued but there are many others. Unfortunately, we’re pretty swamped with higher priority projects. NFC is cool, though, so we may eventually get around to writing a library for it. Sorry I can’t give you a better answer…

  5. connochaetes reporter

    Since there ‘s so much going on… (Thanks for the latest improvements! They ‘re just great.) … Did I miss out on something regarding this issue?

    There has to be someone with the skills and time to connect a RFID / NFC device via Microblocks to a micro:bit.

  6. John Maloney repo owner
  7. connochaetes reporter

    Thank you for the good news and thanks to Citilab for the progress. Since I already got the RFID device, all I can do right now, is to wait for the upcoming Microblocks release.

  8. connochaetes reporter

    Thanks to you and thanks to the José. That ‘s very friendly. For I was quite curious, I made a quick (but sadly unsuccesful) check a few moments ago.

    Soon, I am going to give it more attention. In order to avoid rookie mistakes: Obviously, the library works with the “Citilab ED1”. Do I have to make any adjustments (e. g. PIN numbers), in order to use it with my “micro:bit”? I am going to set the PN532s DIP switches to I2C, connect

    GND → ground

    VCC → 5 V

    SDA → SDA pin 20

    SCL → SCL pin 19

    and use this script …

    … while placing RFID tags near the PN532 device.

  9. John Maloney repo owner

    If you’re working with a micro:bit then you should power with 3.3v (which you probably would since that’s what’s available on the edge connector. The other connections sound correct.

  10. connochaetes reporter

    Now, I gave it some time, but there 's no success by now. Here 's what I 've done:

    First of all, I checked out the PN532’s I2C functionality (e. g. the correct DIP switch setting) using an Arduino Mega 2560 and the Arduino Web Editor following the I2C part of this Wiki: http://wiki.sunfounder.cc/index.php?title=PN532_NFC_RFID_Module (BTW a quote: “The integrated 3.3V voltage regulator provides 3.3V or 5V working voltage for your choice.”) Using different RFID tags I got the expected result (different UID values).

    Afterwards, I connected the PN532 with 4 jumper wires to the micro:bit’s breakout board: GND, 3.3V, SDA (pin 20), SCL (pin19). I connected my micro:bit via USB with Microblocks and checked out the basic functionality (e. g. the display of the smiling face). So far, so good. But still the only thing, I got from the “read PN532 RFID” block is “0”.

    ___

    I am quite thankful for your help so far. I understand, that this RFID issue might be of minor interest at this moment. But still: It would be great, if someone could run a test with a micro:bit. Perhaps, it 's just a detail that I failed to see.

  11. John Maloney repo owner

    I don’t have the RFID board to test, but here’s some things to check.

    First, check the power: The markings on the board don’t make this obvious, but it looks like the pin marked 5v on the 5-pin connector should be connected to the 3.3v pin of the micro:bit. That pin is the power supply input for the board. The pin marked 3.3v is the regulated output (which you won’t need). If you have a volt meter, you might verify that you get 3.3v output on the 3.3v pin with the micro:bit providing power to the 5v pin.

    Think, although I believe you’ve done this already, just double-check that you’ve set the jumpers on the board to use I2C (not SPI).

    Now, select “show advanced blocks” from the MicroBlocks (gear) menu. That will show a category called “Comm”. Use the following block to try to read data from your RFID board:

    If you get -2 (as shown), then the micro:bit is not able to talk to the RFID board. Check the power and your wiring again. If you get 0 or a positive number from this test, I2C is working! Try the RFID library again.

  12. José García

    Hello,

    I send a photo of my connection. As John said it’s necessary to configure the jumpers in I2C mode.

    Hope, this helps!

    Jose from Citilab

  13. connochaetes reporter

    Thank you very much.

    I double checked the DIP switch setting. → It ‘s the same one that worked with my Arduino I2C script. It 's the same one from José García’s picture.

    I double checked the pin connections of SDA and SCL.

    Sorry, I did not see that my PN532 differs slightly from the one mentioned on the Wiki http://wiki.sunfounder.cc/index.php?title=PN532_NFC_RFID_Module (4 pins instead of 5 pins on the edge). Mine is the one from the picture that José García sent.

    The block “i2c get device ‘36’ register ‘0'“ gives me a “0”. So, I’m assuming that I2C is working. (Yay!) Am I right?

    Sadly, I ‘m not finished yet: “PN532getFirmwareVersion” doesn’t give me “[50, 1, 6, 7]” but instead “0”. 😞

    Where’s the mistake?

    BTW: Here’s the Arduino program’s output.

    Hello!
    Found chip PN532
    Firmware ver. 1.6
    Waiting for an ISO14443A Card ...
    Found an ISO14443A card
    UID Length: 4 bytes
    UID Value: 0x63 0x50 0x53 0xA3

    Seems to be a Mifare Classic card (4 byte UID)
    Trying to authenticate block 4 with default KEYA value
    Sector 1 (Blocks 4..7) has been authenticated
    Reading Block 4:
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

  14. John Maloney repo owner

    The block “i2c get device ‘36’ register ‘0'“ gives me a “0”. So, I’m assuming that I2C is working. (Yay!) Am I right?

    Yep! You’d get a -2 if it didn’t get a response from the board.

    You might try reading registers 244, 245, 247, 252, or 253. They should give various non-zero, positive numbers.

    The i2c protocol for this chip makes heavy use of multiple byte transfers, and it’s possible that those are handled differently by the ED1 and the micro:bit. Do you happen to have any other microcontrollers that can run MicroBlocks (e.g. an ESP8266 or ESP32 board or an AdaFruit board)? If so, you might test the library on that board.

    We’re making progress!

    José, if you see this could you post your most recent working version of the library? It’s possible that the version in the MicroBlocks repository has an error, possibly introduced by me or Bernat. It would be nice to make sure we’re using the exact version of the library that you tested.

  15. connochaetes reporter

    This sounds quite promising.

    You might try reading registers 244, 245, 247, 252, or 253. They should give various non-zero, positive numbers

    😞 …? - At this time, all I can get my hands on are an Arduino Mega 2560 and a micro:bit. (I’m willing to make a small investment and buy another board if that might be helpful.)

    • Perhaps, someone at the Citilab can find a few minutes replace the ED1 with a micro:bit.

    Again: I am very thankful for your time, your quick responses and your helpful thoughts.

  16. John Maloney repo owner

    Thank you for this file, José. This is a little different from the RFID MicroBlocks library that Bernat created from it so it will be helpful to test the original version. Thanks for offering to test this a micro:bit, too.

  17. Bernat Romagosa

    I think the only thing I changed is that I hid all auxiliary blocks. I could be misremembering, though 🙂

  18. connochaetes reporter

    @ José García : I used your linked file … and …

    it 's all working right now without any problems.

    Thanks to you all for your wonderful software and the friendly help.

  19. John Maloney repo owner

    Excellent! Thank you for creating the RFID code, José. We may have introduced a small typo when we converted it into a library. Will check and fix the library if necessary.

  20. connochaetes reporter

    … a small typo …


    Thanks for the explanation. That would have been my final question on this issue. I compared the two slightly different block definitions and realised that I there 's much to learn… :)

  21. John Maloney repo owner

    I’ve revised the RFID library. It would be great if someone with an RFID board could test it.

    https://bitbucket.org/john_maloney/smallvm/src/master/gp/Libraries/RFID.ubl

    Thanks!

    José and Bernat: I renamed a few things (e.g. the “=RFID” block). Let me know if you’d prefer different names. I left “get PN532 firmware version” as a basic (not advanced) command since it is a good check that the board is connected and responding to I2C commands.

    This library will be included in the next MicroBlocks release.

  22. connochaetes reporter

    Thanks for uploading the new library. I had to replace “myBlock” with José's SAMCONFIGURATION blocks to make it work. Now, it 's just fine. (Sorry for just sending screenshots instead of ubl / ubp files.)

  23. connochaetes reporter

    I gave it a try. You 'll have to do a small change. Please replace the new blue blocks “PN532sendCommand” and “PN532readAckFrame” with the purple ones “_PN532sendCommand” and “_PN532readAckFrame”.

  24. José García

    Works for me too, but I have problems if no RFID card is present. The idea with “get PN532 firmware version” was to detect the presence of RFID, but “_PN532readAckFrame” hangs without RFID board, at least in ED1 (hangs microBlocks until I disconnect it).

    Do you know why this happens?

  25. John Maloney repo owner

    The call “i2c device _ read list _” may be hanging. I’ve seen i2c calls hang on other boards when there were no pullup resistors on the SCL/SDA lines. (Pullup resistors are included on most i2c boards.)

    I will see if connecting some other i2c board prevents the hang. In that case, the “get PN532 firmware version” block should still fail, of course, but hopefully without hanging.

    I’ll dig into this. Thanks for reporting it!

  26. John Maloney repo owner

    I’ve reproduced it. “i2c device _ read list _” is hanging when there is no device with the given address. It be more robust. I’m starting a new issue for this…

  27. José García

    I think the problem is in VM implementation of primI2cRead, !Wire.available() hangs on not connected devices. Maybe something like this will work:
    Wire.requestFrom(deviceID, count);
    int i = 0;
    while (Wire.available()) {
    int byte = Wire.read();
    FIELD(obj, i + 1) = int2obj(byte);
    i++;
    }
    return int2obj(i);

    The same with readI2CReg but doesn’t hang because the code returns before !Wire.available(). One proposal:

    Wire.requestFrom(deviceID, 1);
    if (Wire.available()) {
    return Wire.read();
    } else {
    return -2;
    }

    Regards

  28. John Maloney repo owner

    Yes, you’re exactly right, reading from unconnected i2c devices is what is hanging.

    I didn’t try Wire.available(), but I’ve implemented another solution that raises an error when you write to an unconnected i2c device. Since you have to write before you read, that error halts the task before it tries to read (which would hang). That solution will be in the next release. It is already pushed, so if you do a “pull” and build a VM from source you can try it yourself. I’ve tested it on both the micro:bit and ESP32.

    When I get a chance, I’ll try using Wire.available(). It’s possible the the call to Wire.available() will, itself, cause a hang.

    If that idea works then couldn’t hurt to have a check in i2c read as well as in write.

  29. John Maloney repo owner

    Hi, José. Your idea of checking Wire.available() in read appears to work. The call doesn’t hang, even when there is no i2c device at the given address. In the tests I did (using the micro:bit accelerometer), Wire.available() returned a non-zero value as long as a write request had been sent immediately before. (An i2c transaction is a write operation followed by a read operation. The simple MicroBlocks i2c get/set device register operations combine the write and read operations. But for more complex i2c interactions, such as those needed to interact with the PN532 RFID chip, the write and read operations – often involving multiple bytes – are separate and independent.)

    I will include this check in the next release. When that release comes out, it would be great to verify that it works with the RFID library. I worry that we might get false failures if the i2c device is slow to respond. In that case, a work-around is to add a short “wait” between the i2c write and read calls in the library code. But I’m hoping that won’t be necessary.

  30. José García

    Hi John,

    I have compiled a VM for ED1 with the attached file and works fine without nothing connected, with RFID and also with the TC34725 color sensor code that I'm writing. In fact, I had some hangs before, due to a defective connection, and now works fine even with the old cable.

    I hope to finish the TCS3475 color code soon, works better than the sensor we used in Faber.

    Regards

    https://cloud.citilab.eu/s/Zd22D5Rk5Wy6KPm

  31. Log in to comment