-
Tue 2019.12.31
var r = digitalRead( pagelink ); console.log( "r = " + r ); >r = verified
'sadly I cannot find the datasheet PDF you are referring to. The page you linked tells me there is no text there'
Wow! and can verify the same. Interestingly, the page was there yesterday. I copy-n-paste'd the URL myself, at least I thought it was myself, and I double checked the link went there!
So, I did what the page suggested and used search, with the 'site:' qualifier keyword:
Google: RC522
site:
wiki.keyestudio.com/The first link returned, does go to that source, but in the Google results, one may observe it is a dynamically built link. (look for the right arrow in the Google returned result) Note the subtle difference in that result:
https://wiki.keyestudio.com/Ks0067_keyestudio_RC522_RFID_Module_for_Arduino
I wonder which server is misbehaving?The .pdf there (page bottom) is a dynamically built link too, that goes to:
https://drive.google.com/file/d/1y5gT93RtHHQI40PYx_bER9iw_LE40p9K/view
Now I know I'm dreaming, but in my dream I clicked on the above links to make sure ;-)
'I can refer to the Dxx pins directly, by referencing the GPIO number instead.(Duh!). So I dropped my WemosD1 object to use D pins exclusively.'
and
'The error is consistent on 3 different pins now, D15, D16 and D0.'
Has the 'NodeMCU' prefix been attempted? The one mentioned in the first link in conversation #12951616 found in #3 post, and I believe what MaBe was referencing also?
'I did not need special numbers or modifications with the Arduino library'
Is an attempt to re-write that library underway? IMO, while a nice exercise in functionality language translation, actually a big waste of time. Both my different mfg modules worked with the simple eleven line snippet from the tutorial in the link from #1 post.
'it doesn't know what the SS pin is'
re: NSS pinDouble check the pin mode. Have been burned many times when resetting a board and not explicity (re-)setting. I have seen NSS pins with both pull-up and pull-down internal. That would mess with chip select.
Tonight is proving to be quite a learning experience.
In the MFRC522 module :
In the SPI reference :
My "pins" are simple Numbers, not Pin objects.
Inspecting the C file using the reference link, it looks like the function is looking for a Pin object. Link here, line 215.
So here I'm thinking that is my problem, it doesn't know what the SS pin is.
In fact the second phenomenon making me think about that is that the error code is the same as the pin number entered.
So I re-read the Espruino on ESP8266 page, again, and again. Now I understand my WemosD1 object is no longer required. I can refer to the Dxx pins directly, by referencing the GPIO number instead.(Duh!). So I dropped my WemosD1 object to use D pins exclusively.
Giving the MFRC522.connect function a proper Pin object changed the behavior drastically I think. I still get the same Error message, but the error code is now 12, regardless of what SS pins I use.
Now I can't help but notice this is the exact same error code as in Github issue #258 previously linked.
Their code was using software SPI, which I have just re-tried. MFRC522.findCards returns undefined without errors. Its not doing anything.
Shorting MISO to MOSI allowed me to verify that both HW and SW SPI are working (following the quick tip from Gordon here).
If I physically disconnect the SS pin, the error is 255. The error is consistent on 3 different pins now, D15, D16 and D0.
Its getting late now.
I'll have to take a look at the code on the Keyestudio Wiki, to compare it with the values in the MFRC522.js library. @Robin, sadly I cannot find the datasheet PDF you are referring to. The page you linked tells me there is no text there. And the page I was able to find only has a garbage PDF full with the same information as the wiki page.
I did not need special numbers or modifications with the Arduino library, so I'm assuming they will be the same, unless they have something special for Keyestudio detection.
I also want to try and communicate manually with the RFID sensor, essentially emulating what the library is trying to do.
No success tonight but digitalWrite(myHopes, HIGH);