2
int val1 =(mfrc522.uid.uidByte[0]);
int val2 =(mfrc522.uid.uidByte[1]);
int val3 =(mfrc522.uid.uidByte[2]);
int val4 =(mfrc522.uid.uidByte[3]);

String valA=String(val1);
String valB=String(val2);
String valC=String(val3);
String valD=String(val4);
uID=valA+valB+valC+valD;

The function above with mfrc522.uid.uidByte[x] is from the MFRC522.h Library by Miguel Balboa and it is initialized as byte there. But when I initialize the val1 to val4 as byte, the desired number doesn't appear. I don't intend to print the uID to serial (as someone may suggest that to readily print to serial as it converts it automatically to some ASCII strings), but instead in the client.print() of the Ethernet library along with other codes. I want to save it into another "greater" variable in terms of speed and memory allocation. The Arduino community warns about the use of String as it uses additional decoding which is not needed as well as may crash Arduino and make Arduino run out of memory. And somehow, I experience some lagging or hanging in the serial, which I thought maybe due to the use of Strings variable. Please help me. I've read some sprintf() concatenations and free() but not well documented, I'm quite confused on their explanations. :)

  • It sounds like you want to print the UID to serial. Have you tried using "mfrc522.PICC_DumpToSerial(mfrc522.uid);" ? – David Cary Sep 13 '15 at 17:05
1

sprintf() is a nicer way to do that (imo), however, there's nothing wrong with what you've done-- if you don't have a ton more code, I'd continue to use it.

It's simple and that's a lot more important that speed most of the time. Also, the likely memory usage isn't enough to worry about.

In my experience, once I got past 1500 bytes SRAM (dynamic) memory usage, I ran into trouble. But my projects have a ton of code. I've read through the String class code and it's totally reasonable-- you're not likely to experience lag there.

My bet is that the lag is due to the timeout period, try making it smaller.

0

The UidByte[] is a 10 character array, loaded with the tag ID (this is an RFID reader) by the library.

Your code is attempting to put a character value into integer variables.

What you mean to do (I think) is to read the string as a number - this would be val=atoi(mfrc522.uid.uidByte) which relies on there being only numeric data in the ID string - or at least, will only read the leading numbers (if any). Also, there are 10 characters in the string - if you want to limit this to 4 you will need slightly more code.

If you have a tag on which you set the ID then this is usable, for your tags at least; but you can't rely on numeric uid's being universal.

If your intent is, as you say, to include it in a longer string, then the overhead of atoi is completely unnecessary and you should just handle it as a string. I think you have misunderstood the warnings about strings, there isn't a problem just handling short chunks of fixed-length data as strings, and I think you are inadvertently causing trouble by extra conversions.

  • The poster's concerns are based in real issues with dynamic memory allocation on small systems, and while they may not occur here is what could hopefully turn out to be a reuse-in-place allocation case, it is also not necessary to allocate a bunch of dynamic Strings to accomplish this goal at all. If the size of the intended result is known or reasonably bounded, byte/character values can be directly written to appropriate positions in a C string. – Chris Stratton Jul 11 '15 at 15:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.