I did not make it public yet, because I need a second opinion about the implementation. So please give me all your inputs about what I did wrong and what can I improve.
PS:
I hope it will help some other people to, but for me it was a good exercise on how to make a particle library.
ok, so after one week there is no feedback.
maybe this type of sensor does not meet the public interest.
Before I make this library public available, I have one question and I need your advice:
Should I let debug info enabled in library, or should I disable all serial.print() used for debug?
I’m thinking to comment the “#define DEBUG_MODE_RFID” in order to eliminate the unnecessary communication through serial port and to minimize code execution time.
… but this just raised another question:
Speaking from the WebDEV point of view, the code from library can not be modified (comment/uncomment code) if you just include the library in your project. You have to copy/paste the code, so this implies that you know what you are doing => you know how to use a debug info. Correct?
Anyway I will add a short piece of text about enabling debug info.
Thank you for suggestion.
@botosu, yup, that web IDE issue is a problem. Defining the DEBUG flag in the demo app will only be good within that scope (and the #include files). One approach is to define the class constructor in the .h file and set a private class variable (debug_on?) in the constructor based on the DEBUG compiler flag. Perhaps @bko knows of a different approach?
hmm it’s a long time since I was writing C code, but in my good days the code between #ifdef and #endif will be ignored by compiler so the code will be a little bit smaller and faster with my approach.
with a private variable, we have some extra if decisions to execute… and this does not sound very good for me when we speak about a small CPU (I was some kind of ASM freak before the web era )