I'm currently working on a project for possible commercial use, which centres on keeping track of a prodution line, for instance, using NFC chips and an arduino. I am hoping to make it possible, so when i scan an NFC tag with a PN532 NFC Shield, a unique identifier can lead me to other information stored in someway on the arduino itself.
I have external EPROMs and/or SD Cards I can use, but I can't seem to find an easy way to have a searchable table of items. The info only needs to be a couple of fields, and I want to try and avoid having to write all this info onto the tags, as I am having trouble getting the shield to write to my NTAG203 tags, so if anyone could help me out with that too ,that'd be great.
Sorry for the long post, this is the first time i've been here. Thanks anyway, Aidan
Forget relational databases on Arduino! You would need an RPi for that. But if you need to look up a couple of fields, an RDBMS would be overkill anyway. Like PaulS asks, how much data are we talking? How many IDs, how many bytes in total, for the IDs and associateddata?
Thanks for your reply guys, its a fair amount of data, A few hundred records maybe. At a few bytes each. And yeah probably editiable. Is that just impossible on the arduino?
I was thinking about using an RPI, and just using a mysql connect library for the arduino. Would that be my best bet, or just getting rid of the arduino all together and getting an RPI header with the ability to connect to stackable arduino shields?
Given this level of information, I would say with complete confidence "definitely maybe". Can you be any more precise? How many is a few hundred likely to be at maximum? 8 bytes in total including the id? Why would that be less if you encode them? How quick must the lookup process be? I am thinking the Arduino Uno for example has 1K of eeprom. Would that be enough? Extra eeprom or ram can be added via i2c bus or spi bus, but that would be much slower.
because of the project I am using it with, the theoretical maximum would be about 250, but that's not to say i mightn't need to extend that. and yeah including the id, which would probably need to be 2. and i mean encoding them because for instance, three of the 'bytes' i need to store are only 5-6 bits each, if that makes a difference in the long run?
Actually now that i'm thinking about it, as well as this I would probably need another table, with around a dozen records, but at maybe 20bytes each. And yeah I would use external storage. Is an RPI starting to look better at this point? Or should I try and store all this data on the NFC chip, so I don't have to look it up?
Thanks
I think an RPi would be overkill. Arduino Mega 2560 has 8K RAM and 4K EEPROM.
What about the other questions from my earlier post? Does your external storage need to be removable? Non-volatile? What will happen when an ID is detected?
One way to do it would be to put the data you want in fixed width records on the SD card. At startup, read the ids into an array in RAM and use it as an index into the SD file so you can simply seek to the record you want. Of course, depending on how fast this needs to be, you might find a 'full table scan' of the SD file every time you see a new ID might be sufficient.
Thanks for all your help guys. I've made the decision to go with an RPI, connected via serial to the arduino, which is still acting as the NFC reader. I did this because I really think I do need a relational database, because there isquite a bit of different data I need to store with the tags, and I still can't figure out how to write to them.
Ill also need to do commands like, has this tag been scanned today, if so, yada yada, and so I think a relational database would be easier and faster for that. Thanks for your help anyway guys:)
