Teency 3.1 Compatibility with MFRC522 RFID Library

Status
Not open for further replies.
H

HGPAust

Member
Teensy 3.1 Compatibility with MFRC522 RFID Library

I have recently purchased a number of Teensy3.1 controllers, which I have been very impressed, especially the RTC capability. I am trying to build a project with the Teensy 3.1 that uses an SPI connection to the MFRC522 RFID card reader (SSRFIDV1.0 or RFID RC522 Reader IC Card Module) links to each manual are listed below. I have been using the libraries downloaded from http://github.com/miguelbalboa/rfid. Unfortunately, the teensy 3.1 will only read the 4 byte cards and will not register the 7 or 10 byte RFID Cards. Since this library works on the arduino Mega and Uno etc.(I have been able to read all RFID Card formats), which are all 8 bit processors and since the Teensy 3.1 is 32 bit processor, would this be the reason for the lack of functionality. If this is the case, can you direct me as to how to change the library or point me in the direction of someone who may know and be willing to help. I am very keen to stay with the Teensy3.1 if I can fix this compatibility issue.

Your advice would be greatly accepted,

SSRFIDV1.0 manual at http://www.elechouse.com/elechouse/images/product/13.56MHZ_RFID_Module/13.56MHZ_RFID_Manual.pdf
 
Last edited:
As an experiment, or as a work-around, could you use the tag reader's UART interface with one of the 3 UARTs on the Teensy 3?
 
stevech said:
As an experiment, or as a work-around, could you use the tag reader's UART interface with one of the 3 UARTs on the Teensy 3?
Click to expand...

Yes, that is one of the reasons for going to a SPI connection as to bypass the UART as it will read the 4 byte card but nothing else. The only way to read the other cards is to use the SPI, bypassing the UART and using the Arduino and supporting library. However, I desperately want to stay with the Teensy 3.1 as I need to use the built in RTC and I am a Teensy fan.
 
Last edited:
I'm not at all sure if this helps you...
If you're using a 522 RFID reader using SPI you might be better off going for something cheaper.

See

I'm not familiar with the library you're using, however I've used the above cards with Teensy 2

Ian
 
I ordered this one, just now. It's shipping from within the USA, so hopefully I'll have it sometime next week.

I'm afraid there's not much can I do to help until I get the actual hardware for testing.
 
ian said:
I'm not at all sure if this helps you...
If you're using a 522 RFID reader using SPI you might be better off going for something cheaper.

See

I'm not familiar with the library you're using, however I've used the above cards with Teensy 2

Ian
Click to expand...

Thanks Ian, I have been using these ones and moving my project to incorporate them, once again they work well with Arduino, I have used them with the Mega 2560, with the library linked below with no problems, however, when it comes to the Teensy3.1 it will one pick up cards with 4 bytes IDs. I have looked through the library files to find if it is something obvious but I am afraid it is way beyond my level of expertise. However, would love to learn more.

http://https://github.com/miguelbalboa/rfid
 
Paul, thanks I have been working on this project for weeks, however, I am afraid it is just beyond my knowledge. I would like to understand where the disconnect is. As previously mentioned, I have had this working on numerous Arduino boards such as the mega 2560 using the same aforementioned library with either the SSRFIDV0.1 or the RFID RC522 cards with no problems. It just will not even recognise any card that has more than 4 bytes for it ID.
 
Last edited:
I got a shipping notice, so hopefully I'll have this hardware soon.

I'm not very familiar with these RFID tags. That product I ordered seems to come with 1 thing to read. Will it have only a 4 byte ID?

If I'm going to need something else to test 7 and 10 byte IDs, please let me know?
 
Paul, I believe the MIFARE DESFire EV1 and the MIFARE Ultralight C have the 7 byte UIDs, while the MIFARE Classic has a 4 byte UID. I believe the encryption talked about in the standards are associated with access to the memory, however just being able to read the different card's is a great start. As I mentioned these cards are able to be read on both the readers previously mentioned readers when using the arduino and associated libraries. I hope this helps, if not please let me know.
 
Is the cheap hardware I ordered ok? See the link on reply #5.

If I need something else to reproduce this problem, please let me know. I do want to resolve this issue, and PJRC does have a small but reasonable budget to buy hardware for testing Arduino libraries. If there's something else I need to buy to scan a 7 or 10 digit ID, and if it's not really expensive, I can get it. But I'm not very familiar with this RFID stuff. If you can point me to the right hardware, we'll all save a lot of time.
 
That is the one I have ordered, it is cheap and uses the SPI connection. I also know these work with all the known RFID cards using the arduino and associated library.
 
Sorry a bit out of sink with the threads, I can not think of anything else in the way of hardware, I have been using both the RFID readers listed in my first post. I originally started my project with the teensy 3.1 with a serial connection using the UART, however it only READ THE 4 byte cards. I then went to a SPI connection, even removing the UART chip from the SSRFIDV1.0 to no avail. I then went to the other reader with the same result. I then tried the SPI connection on both readers using the libraries, prescribed above, with the Mega 2560 and arduino pro mino, both worked well and read all the cards tested(both 4 and 7 byte cards). As a result I thought it to be an issue related to the chip type etc. I hope this helps!
 
Last edited:
Paul,

It would probably be helpful to have some cards which you know for certain use a 7 byte ID, particularly as this is what HGPAust is struggling with. It's quite likely the cards bundled with the reader are 4 byte. In essence, both are readily available but 4 byte IDs are no longer unique.

A quick look around the web suggests to me that all of the Arduino code out there derives from example code published by www.B2CQSHOP.com in China. AFAICR when I was using these RFID readers I based my code on a slightly more readable version.

Something that jumps out at me at the start of the program:

#define uint unsigned int
 
HGPAust said:
That is the one I have ordered, it is cheap and uses the SPI connection.
Click to expand...

Was there supposed to be a link in reply #11?


ian said:
It would probably be helpful to have some cards which you know for certain use a 7 byte ID, particularly as this is what HGPAust is struggling with. It's quite likely the cards bundled with the reader are 4 byte.
Click to expand...

Where can I buy a 7 byte ID card?

A quick look around the web suggests to me that all of the Arduino code out there derives from example code published by www.B2CQSHOP.com in China.
Click to expand...

I've been looking at the miguelbalboa copy, linked from the original post. Any chance you could point me to these other copies?

About the code, I took a very quick look, even though I don't have any real hardware yet.

My first guess would be the 2 structs in MFRC522.h. Perhaps they need the "packed" attribute on 32 bit platforms? Like this:

Code: 
    // A struct used for passing the UID of a PICC.
    struct Uid_struct {
        byte        size;           // Number of bytes in the UID. 4, 7 or 10.
        byte        uidByte[10];
        byte        sak;            // The SAK (Select acknowledge) byte returned from the PICC after successful selection.
    } __attribute__((packed));
    typedef struct Uid_struct Uid;

    // A struct used for passing a MIFARE Crypto1 key
    struct MIFARE_Key_struct {
        byte        keyByte[MF_KEY_SIZE];
    } __attribute__((packed));
    typedef struct MIFARE_Key_struct MIFARE_Key;
 
I purchased two blank cards today via eBay, however, they were purchased from China and may take up to a month to get here. From what I understand cards that are compliant with the MILFARE DESFire EV1 standard have UID of 7 Bytes as confirmed in the data sheet that was posted with the cards on eBay. I will test them on the Arduino setup when they arrive to ensure they are compliant and have a 7 byte UID. If you can't source one at your end, I will send one across, however by the time it gets here it may be quite awhile. The ones I have used for testing in the past are in constant use and unfortunately cannot be released. The link below illustrates the cards and their associated data sheet:

http://www.ebay.com.au/itm/NFC-Tags...faultDomain_15&var&hash=item4acaf598a7&_uhb=1
 
Last edited:
I believe all mifare cards are available with 7 byte UID now(?) I suspect DESFire might be a bit special (DES encryption)
Google shows me plenty of UK suppliers of 'mifare classic 7 byte cards'
The code I've used is linked in reply #13
 
Did anyone try the packed attribute idea from #14? I still don't have hardware, so I can't try it. I do have a reader and 7 byte card on order, but the card is coming from China, so it may be a few weeks until I have all the hardware needed to test.

I can tell you there are 3 common issues with 8 bit code porting to 32 bit platforms. The most common is putting 2 bytes from I2C into a 16 bit signed integer (common with motion sensors). A similar issue involves passing data through int pointers, where the pointer is initialized with the address of a 16 bit variable (eg, the variable is int16_t but the function's pointer is "int*").

The third issue involves using structs as data templates, where an array of bytes is access as a struct (usually though a pointer, initialized with the array address). On 8 bit AVR, structs are always packed together. But on 32 bit platforms, often the compiler will align the elements of the struct to 32 bit boundaries, which greatly improves performance, but it leaves small gaps in memory between the items in the struct. The packed attribute tells the compiler to pack the data together, the same as if it were on an 8 bit platform.

This library appears to use that technique, where data is received from the card into a byte array, then a struct pointer is initialized to the address of the array. That's why I suggested trying the packed attribute in reply #14. Please give it a try and let me know if it solves the problem?
 
Last edited:
Unfortunately, I have not been able to get the library functional as yet! I will continue to try and locate the fault.
 
Hey Guys,

Any news on this potential 32bit issue on the Teensy 3.1? (works fine on the Teensy 2.0)
As I'm also stuck with my Mifare Ultralight card (7 bytes) that can't be read.
 
I just got one of these modules and some tag and cards to play with. I got the Balboa's library and out of the box it really dosn't work, get a lot of disconnect, etc. Even on DUE the library have the same problems so Iìve tried the Paul suggestions but got the same results. I've tried several mods on pointer side but the library it's a bit too hudge and I'm lost in code, get only small success.
So I got an early version that it's much smaller and modified for Teensy3.x and SPI transaction, it's really basic but good start point!
https://github.com/sumotoy/RFID/tree/master
At list it works with Teesny3.x and DUE.
 
Status
Not open for further replies.
Back
Top