'Is an attempt to re-write that library underway?'
Not really. I'm trying to understand how the current one works by dissecting it. If it has to come to a full re-write, Espruino will probably get "phase 2".
'Double check the pin mode.'
This somewhat gives me hope that my problem is still something fairly simple like that.
However I'm not sure what pinMode each pin should be in!
In my current test, with the same error 12 setup, before calling MFRC522.connect, all the affected (D14, D12, D13, D15) are "input_pullup". After calling it, the NSS pin is now "output".
'Has the 'NodeMCU' prefix been attempted? '
I stripped everything from the board, setup a breadboard with and LED and tested each NodeMCU pins. At this point, I'm fairly sure this 'prefix' is not useful to my board. Here are the results from the experiment :
NodeMCU.D0 NOT OK (D2 on board, GPIO16)
NodeMCU.D1 NOT OK (D3 on board, GPIO5)
NodeMCU.D2 NOT OK (D4 on board, GPIO4)
NodeMCU.D3 NOT OK (D8 on board, GPIO0)
NodeMCU.D4 NOT OK (D9 on board, GPIO2, ESP8266_LED)
NodeMCU.D5 OK (SCK_LED)
NodeMCU.D6 OK
NodeMCU.D7 OK
NodeMCU.D8 NOT OK (D10 on board, GPIO)
NodeMCU.D9 BREAKS CMD (D0 on board, RX, GPIO3)
NodeMCU.D10 BREAKS CMD (D1 on board, TX, GPIO1)
NodeMCU.D11+ UNDEFINED (11,12,13,14,15 undefined)
// OK Control + correct silk screen D pin
// NOT OK Control + Incorrect silk screen
// BREAKS CMD No more Espruino IDE console, unknown usability unplugged
// UNDEFINED These pins do not exist in the NodeMCU 'prefix'
However the GPIO numbers visible from under the board are easy to use with the normal D pins.
'save() with modules where .connect() initializes device (such as RFID reader MFRC522)'
Good read, but I understand how save() works, at least I think I do. Getting the Espruino to work without a computer was 1st order priority on Day 1, coming from Arduino. If I can get even just one read from the RFID using Espruino, I will feel confident dealing with everything else.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Happy 2020 everyone!
Thanks again for the answers.
Not really. I'm trying to understand how the current one works by dissecting it. If it has to come to a full re-write, Espruino will probably get "phase 2".
This somewhat gives me hope that my problem is still something fairly simple like that.
However I'm not sure what pinMode each pin should be in!
In my current test, with the same error 12 setup, before calling MFRC522.connect, all the affected (D14, D12, D13, D15) are "input_pullup". After calling it, the NSS pin is now "output".
I stripped everything from the board, setup a breadboard with and LED and tested each NodeMCU pins. At this point, I'm fairly sure this 'prefix' is not useful to my board. Here are the results from the experiment :
However the GPIO numbers visible from under the board are easy to use with the normal D pins.
Good read, but I understand how save() works, at least I think I do. Getting the Espruino to work without a computer was 1st order priority on Day 1, coming from Arduino. If I can get even just one read from the RFID using Espruino, I will feel confident dealing with everything else.