Search results for:

Sun 2017.02.12

Thank you @MaBe for your quick response.

Could you please elaborate on

"start with erase_flash"

could this mean 'INITIAL FLASHING ON WINDOWS' in the link provided? Forgive me, but search did not dig up any detail on 'erase_flash'

ref:

double check your flash settings

Made three more attempts at 1v91 For a sanity check, went back to 1v84

1v84.tve_master_363580f Copyright 2015 G.Williams
WARNING: the esp8266 port is in beta!
Flash map 4MB:512/512, manuf 0xe0 chip 0x4016
>
=undefined
>process.memory()
={ "free": 639, "usage": 761, "total": 1400, "history": 517 }
>save()
=undefined
Erasing Flash.....
Writing...............
ERROR: Too big to save to flash (13092 vs 12284 bytes)
Deleting command history and trying again...
Erasing Flash.....
Writing..........
Compressed 22400 bytes to 7668
Checking...
Done!
>

As one can see, save() does work on this previous version. For me, 1v91 does not. Anyone else struggling with the new version?

Sat 2017.02.11

recap:
I had working 1v84 for over two weeks running on an ESP8266-12 stand alone

1v84.tve_master_363580f Copyright 2015 G.Williams

I was able to make at least fifty plus project revisions and used save() ten plus times

Today I decided to attempt a new (re)flash using:

espruino_1v91.122_esp8266.tgz 2017-02-11 22:06 632K

1v91.122 Copyright 2016 G.Williams

acquired from:
http://www.espruino.com/binaries/travis/­master/

referenced at:
http://forum.espruino.com/conversations/­299821/#comment13460303
@MaBe from ~02.07.2017 "You have to wait until the next release, or fetch a travis build"

ESP module is booting and can be seen in Windows 10 environment. Using WebIDE I am able to use 'Send to Espruino' icon to xfer code. Functions execute when prompted from command line.

However, save() results in immediate 'Disconnected' msg, and IDE shows orange icon in upper left. The same applies with an attempt to execute wifi.setIP(), the sole reason I performed the re-flash, in order to make use of the previously omitted setIP() function.

Have tried reflashing, but not back to 1v84 just yet. Have restarted WebIDE and browser instances with no luck.

Thr 2017.02.09

Thank you MaBe, Ollie and allObjects,

For those that are new to the ESP8266 and are following along, these are well documented examples that are a must read:

@MaBe
web page login to connect to an access point

@Ollie
confirmation on missing function and module load verification

@allObjects
spiffy template solution to runtime and development start objective

Robin

Wed 2017.02.08

While trying each of the available Wifi functions, ran into this 'documentation inconsistency' ;-)

Interestingly, wifi.getIP() functions as expected, trying to force a known IP addr using setIP() casues an error:

Uncaught Error: Function "setIP" not found!
 at line 1 col 6
wifi.setIP({ip:'192.168.1.71',gw:'192.16­8.1.254',netmask:'255.255.255.0'},functi­on(){})
     ^

I am typing into the left panel of WebIDE

var wifi = require("Wifi")
wifi.setIP({ip:'192.168.1.71',gw:'192.16­8.1.254',netmask:'255.255.255.0'},functi­on(){})

The spec reference:

http://www.espruino.com/Reference#Wifi

Currently this library is ESP8266 specific

Wifi.setIP
  Call type:
    Wifi.setIP(settings, callback)
Description
  The settings object must contain the following properties.
    ip IP address as string (e.g. "192.168.5.100")
    gw The network gateway as string (e.g. "192.168.5.1")
    netmask The interface netmask as string (e.g. "255.255.255.0")

>process.env
={
  "VERSION": "1v84.tve_master_363580f",
  "BUILD_DATE": "Jan 10 2016",

Is the reference ahead of the intended functionality, or have I missed a glaring typo?
Robin

For clarification, are you inquiring on how to dynamically save the 'ssid' and 'password' to memory after program start, and 'save()' from the WebIDE command line won't suffice?

r/w the SD card perhaps? http://www.espruino.com/Internet#line=20­,20,39,46,67,79,91,108

Sat 2017.02.04

Finally got a bit of time to continue. Resistance on MOSI, MISO, CLK and NSS are all the same. ~22K pullup and ~5K pulldown when measured between the Vcc and Gnd pins. Every thing seems okay hardware wise.

When squinting at the trace solder pads I do see a blob between pins 2 and 3 , but this appears to be intentional. e.g. PVDD to DVDD

With as many views of this thread, 340 to date in a little over a week, I'm surprised no one has chimed in with detail on a KeyeStudio board.

I may purchase one of the blue MPN boards should I be able to source at Amazon. Since, sourcing via eBay etal, entails some surprising extra fees. Just got my charge card bill for my out of country purchase of Espruino Original, Pico and RC522 and was surprised that yet another fee shows up. Part cost, tax, HST exchange rate fee, S&H and now a currency conversion fee for out of country purchase on a charge card. Yikes! Will it ever end?? The cost to 'get' the part has now exceeded the cost 'of' the part. I wasn't able to find a MPN mfg board locally, but when I do, I'll piggy-back that with another order.

Thank you @allObjects for your attention to this post. I'm putting this module on the back burner for a few weeks to move on to something else that is more productive.
Robin

Fri 2017.02.03

Thank you @MaBe

That doc pretty much spells it out, doesn't it. I just wish I had the wealth of knowledge, right now, that those of you have, working with these modules. Still trying to run before I've learned to walk. It is of great help that there are those that keep up the support of we new arrivals. Thanks again.

@DrAzzy,

What on earth would you expect BTN to refer to? The ESP8266 module doesn't have a button on it!

Is that a polite way of calling me a D.A. ? I'm staring at my ESP8266 board with two buttons on it, and yes, I'm under the legal limit right now . . . .

Thr 2017.02.02

Good catch. I must have had a senior moment. That saved me a few hours of hair pulling of whats left. Thank you @MaBe

I knew I had seen the syntax on this site without the quotes, but I must admit I missed this from the Espruino Reference page

mode - The mode - a string that is either . . .

mind stuck in 'why doesn't this argument work now' mode and just didn't get back into gear for the basics. It should have dawned on me to create a variable from the literal to become compiler compliant. nasty accuracy checker. ;-)

Note: digitalRead/digitalWrite/etc set the pin mode automatically unless pinMode has been called first.

Now with the syntax corrected, this error pops up for the 'input_pulldown' on the ESP8266

ERROR: Pin state not supported

This only occurs on pulldown but pullup functions as expected.

Since I haven't seen documentation detail on 'input_pulldown' for the ESP8266, may I AssUMe that the Espruino Reference documentation is for Espruino boards only; the compiler is accurate and that the ESP8266 module doesn't have this feature available?

Thr 2017.02.02

Using the constant names located in ESP8266_BOARD.py link provided by @allObjects, and a snippet plucked from the example provided by @Wilberforce, I was able to r/w a GPIO pin and button input on the specific board I have.

Thank you both.

Attempting to explore further using pinMode() produced yet another error:

Uncaught ReferenceError: "input_pullup" is not defined
 at line 1 col 17
pinMode(pin_pu, input_pullup);

The spec Expresive datasheet p.14 indicates the ability to configure internal pullup or pulldown. The Espruino Reference page also shows the attribute 'input_pullup'

Even tried adding module var esp8266 = require('ESP8266'); without success. Is there another module I must add to allow the Pin class functionality to be usable on the ESP8266?

Robin

re:

does the dht11 sensor use analog input or digital?

@user73202 Have you taken a look at the data sheet yet?

http://www.micropik.com/PDF/dht11.pdf

Tue 2017.01.31

Hello @user73202, thank you for the clarification.

I'm sure you checked this out, http://www.espruino.com/Pico but just in case, does this pictorial provide some clarification, comparing the software pin labels to the board you intended on purchasing?

You used the phrase 'high schooler' which typically is representative of the education system here in the USA and not that over in Europe. Would that be an accurate assessment?

As you haven't provided much detail on project requirements and a due date, a 'Weather Logger' project, depending on the desired functionality, could be quite an intermediate undertaking and certainly not 'nooby' as you describe. Don't sell yourself short. Quite an admirable choice, indeed.

Have you considered doing a step-by-step picture or video blog and posting it to social media to add bonus points to the overall project? Heck, why not post here with some links to pics and vids as I'm sure others will appreciate your work and recognize your effort.

If you haven't been cautioned yet, when you pruchase your electronic modules, make sure you verify the voltage requirement of each before you buy online. Quick read each data sheet to verify, for should you wire a 3.3v device to a 5.0v supply, you will quickly learn you have just used up an expensive fuse, as you watch your purchase go up in smoke. While NOT plugged in, wire first, take a break, re-check your work then plug in the supply. Some components and modules might be a bit more forgiving than others, but no sense wasting hard earned money. This also applies to USB ports on PCs. While they may provide a 5.0v supply, one cannot keep adding parts to the project expecting the USB port to comply. ~500ma is about max for USB 2. Add up the current requirements, to determine the battery needs if portability was on your mind, or the minimum for a wallwort and voltage regulator.
Just my 0.02 worth.

Should you choose to complete this project, which I hope you will, I'll stay clued in to this forum to provide some guidance, should you run into a snag. Not going to do your work for you, but I and others may be able to shed some light on the direction you take. Give some consideration to the 'Pico' as mentioned by @Wilberforce in the previous post. I purchased both the original Espruino and the Pico and liked the ability to just plug the Pico into a USB port without a cable and I was up and running.

Best of luck and please keep us informed.
Robin

Hello @user73202,

will the pin numbers be all jumbled up?

To clarify, as I'm sure others will need to know before they respond, by "jumbled up", did you mean is there a one-to-one match between the header pinout on the board you plan on purchasing and the Espruino pinout as from the header; or, did you mean will the GPIO# still match even when at a different header position? e.g. are they mapped the same - Is GPIO5 still GPIO5?

I also am new to the Espruinosphere, and had tremendous results with this variant:
https://learn.adafruit.com/adafruit-huzz­ah-esp8266-breakout/downloads
(Note: Board came unpinned so be prepared to solder)

Carefully following the flash instructions http://www.espruino.com/ESP8266_Flashing­ allowed me to be up and running in under an hour.

Answering your question with this variant, all I can say is the AdaFruit variant pinout at the header does not match. This variant is also a trimmed down version having fewer GPIO pins available at the header.

I was just seeking a simple play toy and wanted to experiment with the WiFi over-the-air programming rather than being tied to the USB port via a cable. Once flash programmed, I've been testing code without the USB cable attached. Running as an access point and as a web server. Pretty cool!

At the moment, I'm still waiting myself for the same answer to toggling a single GPIO pin to power an LED sanity test. http://forum.espruino.com/conversations/­299480/#comment13445860
On a hunch, I'm going to say yes to your last question.

I know that waiting for a response from the team does keep one patiently waiting, I thought I'd pass along some tid-bits in the mean time.

Good luck, Have fun, and Hope this helped in the mean time.
Robin

Mon 2017.01.30

Attempting to learn the BTN and LED naming conventions for the ESP8266
What worked on the Pico causes 'Uncaught ReferenceError' errors when deployed to the ESP8266

Works on the Pico
if( digitalRead(BTN) == 1 )

Uncaught ReferenceError: "BTN" is not defined

Tried BTN0

Ultimately trying to read and write data to a pin and toggle on and off, the onboard and offboard LED's on ESP8266

While this tutorial worked on Pico had the same reference error issue with the LED constants on ESP8266 https://www.espruino.com/Control+LED+wit­h+Button

Uncaught ReferenceError: "LED1" is not defined

Tried LED and LED0

Looked over reference page: http://www.espruino.com/Reference#t_Pin

Pin class This is the built-in class for Pins, such as D0,D1,LED1, or BTN

Looking over the ESP8266 tutorial, no references appear to be made here either
http://www.espruino.com/EspruinoESP8266

Tried searching the Espruino on ESP8266 forum and I attempted the links below, but with no results

http://forum.espruino.com/microcosms/925­/
https://github.com/search?utf8=%E2%9C%93­&q=espruino
https://github.com/espruino/Espruino/tre­e/master/libs

Can someone point me to a Espruino reference link that spells out the convention please.

Sun 2017.01.29

@allObjects

Why could you read 4.8V on all three? I hope the VCC (3.3v) pin of the MFRC522 break out board was not a member of all three.

To clarify, the PC I powered the Pico with has three USB ports. Using each one at a time, showed a consistent 4.8v sourced. I always wired with the USB plug, unplugged, so there was never any moment when the 3.3v pin would have come in contact with 5v Vcc

I know that you have a different board... but I' confident that it is not a high-tech (4..6 layer) board hat has front and back top planes covered with all ground for RF reasons and 'hiding' the routing of the signal lines in between these two outermost layers...

Checked the board closely and while power is supplied through shielded 10 gauge solid wire to a screw down terminal block, I have in fact a 16 multi-layer board with 23 through hole feeds, most likely to connect the internal Bluetooth, WiFi, GPS and Puck magnetometer sensor. How did they get all those working parts in a PCB board so small? hmmmmmmmm . . . .

I missed fig 3 of section 7 of the spec. Your image detail puts into perspective the relative position of the MOSI and MISO pins. The dark green color of the conformal coat covering the board make it difficult to make out, but not impossible after two ales. I agree with your assessment that the parallel diagonal traces don't cross, so their connection to the header should be in the same relative order. Given that, it can only mean that the silk screen on this board is in fact accurate and the data page at the supplier of the reversed pins is of an earlier board release perhaps.

But, that makes my situation more perplexing. Since in order to have acceptable triggering, I had to cross connect MOSI to MISO and had many more triggerings using the tutorial code. When connected MOSI to MOSI, there are never any trigger events. So what is a person to do? The code shouldn't work with the data lines crossed, but it mysteriously does. As I started out in the initial post, don't open packages that arrive on Fri the 13th!

I'm at the point where shipping costs to return the KeyeStudio item for an even exchange are prohibitive and with the messing around one has to do re-packaging, purchasing a competitor product entails yet another 3-4 wk wait plus shipping costs.

Looks like I got stung on this, and stung big time.

Thr 2017.01.26

@Gordon post #10

have you updated the Pico's firmware?

Yes. VERSION 1v91 BUILD_DATE Jan 12 2017

However loads of people have used this problem without issue - so I'd maybe start from the assumption that it could be a wiring issue or maybe even a faulty reader

While searching the forums, only found two other entries centered around RC522 and two others with search term RFID and did not find a single mention of a non MPN manufactured board. I'll stress again that the pinout of KeyeStudio is different.

Re-wired the board a second time but still point out that the wiring diagram at the KeyeStudio web site is wired to their image which has the MOSI and MISO pins reversed from the silk screen on the board I have. So, went with the original assumption the board was correct, but was never able to get a card to trigger the recognition event until I reversed those pins. So which is correct?

Used the tutorial code verbatim, except for changing B2 to B1 for the Pico. Tutorial MFRC522

Your comments are helping, thank you.

More related in post xx below

Abandoned related post link - Sun 2017.01.29

Thr 2017.01.26

@allObjects post #8

Your detailed response was well written and was easy to grasp. One is able to observe you have a complete understanding of the subject matter and you do have a knack for the ability to get into the mind of the reader. Following along was easy, and the reader will appreciate that, spending the additional time to format the content in order to make it an easy read.

Bravo, Well Done.

You might consider adding the post #8 section as a followup to your link in the same post.

but wait, there's more . . . post #9

Appreciate the observation on recognizing the 'Gem' statement from post #5 I firmly believe that which I stated.

Thr 2017.01.26

@MaBe post #7

As I mentioned I had tried several variants, of which the one you posted was one of them.
Although the function compiled, run time errors continued, which caused me to create the post to which you responded. So as not to confuse, and make it obvious I was working with 'prototype' I used what was shown as the best example. Thank you for the response.

Wed 2017.01.25

Thank you Gordon, that answered my first two questions.

Anybody see anything glaringly obvious as to why this doesn't return the expected result?

Using the existing module 'read' function and adding a function to the instance object, while maintaining the same existing coding format.

mfrc522Instance.getver = function() {
  var ver = this.r(R.VERSION);
  console.log("[766] version: " + ver); 
};

Using the spec p.37

37h VersionReg shows the software version

and p.66

9.3.4.8 VersionReg register Shows the MFRC522 software version

Tue 2017.01.24
Would any viewer that has hands-on experience with a KeyeStudio board please chime in.

A quick thank you to those that just responded. A wealth of detailed information has been presented and it is all welcomed.

Life's challenges have just gotten in the way of living life and I'll need a bit of time before I can respond to each post response in detail. Those explanations will get me started, and in the mean time . . . .

I picked up a high quality RFID card, (would MIFARE be more politically correct as the RC522 chip is a subset of RFID?) and found some surprising detection characteristics. Unlike the security card readers for building access, the scanning technique for KeyeStudio is quite different. Most readers I have encountered needed to be swiped across around an inch or so above the surface, holding the card relatively flat. This KeyeStudio reader required a bit of fiddling to get consistent detection. I discovered the need to approach the antenna at a 45 degree angle, with the card at a 90 degree plane, then remove the card a quarter of an inch above to get the actual trigger as seen by the Pico tutorial software sample. Not sure if this was the intended method and how it was designed, but it seems to be the only way to get a consistent trigger detection event.

Anyone able to add their swipe surprises if that different than what I described above?

I also tried several different setInterval() settings around the ' nfc.findCards(function(card) ' wrapper and noticed I could get the consistent detection I described previously. The problem is that the detection now triggers a 255 error code as indicated earlier, or the 'Found Card' text response, but without the variable 'card' containing any data. I tried a quick fiddle with that section, with no success.

As I dive into the overriding of existing functions, what would be a good place to start in attempting to determine why the 'card' variable never contains any data?

Also related, any ideas on how/where to look for the culprit that is causing the 255 error at the lines inside the req() function?

var err = this.r(R.ERROR);
  if (err) throw new Error("MFRC522 Request Error "+err);

The callback getCardSerial() calls req() so I guess both need to be inspected.

Still studying the module and trying to understand this black box. Along with the data sheet, this is proving to be a bit intimidating. I'll imagine I'll make further progress by the time this is read overseas tomorrow. More later . . . .

cont:

Gordon,

Would you be so kind as to provide a means that would enable me to override a function in the MFRC522.js module.

I've tried a method, and several variants, I have used before inside the DOM, but realize this environment is not Html development. [1]

ex:

var orig_MFRC522req = MFRC522.prototype.req;
MFRC522.prototype.req = function(){
    orig_MFRC522req();
    print("inside override and err is: " + err);
};

My attempts produce the following error:

Uncaught Error: Field or method "prototype" does not already exist, and can't create it on undefined
 at line 1 col 30
var orig_MFRC522req = MFRC522.prototype.req;

My hope is that I may garner additional detail that will assist in verifying this board and connectivity.
Robin

[1] http://stackoverflow.com/questions/48145­50/how-to-override-a-function-in-another­-javascript-file

[2] http://www.ericfeminella.com/blog/2011/1­1/19/function-overwriting-in-javascript/­

Mon 2017.01.23

Gordon,
Thank you for responding promptly. As your T.Z. is six hours ahead of mine, my hope is to get something to you before your day is over. I'll handle your questions in the reverse of that asked.

I checked as I wired the board, that I made sure I had a solid ground and that the RC522 was connected to the Vdd 3.3v bus. Just did a sanity check and my VOM indicates the Vdd rail is 3.2v and the 5v rail is 4.8v. I switched USB ports and found all three are 4.8v The Pico seems happy, so we'll live with that for now.

Regarding the error codes. As soon as the board powers up and I send the tutorial code via the IDE, without a RFID key card, today I'm getting values of 2, 4, 80, 84 and an occasional 255. [ 0010, 0100, 1000, 1100, 11111111 could these be error flags perhaps? ] Is the error code in hex or is my assumption wrong and this is really decimal?

There doesn't seem to be any pattern or sequence, just those values but at every interval as the tutorial code requests. Sometimes "Found card" with no value for the variable 'card' is displayed and the tutorial program immediately exits, leaving the right arrow prompt. This occurs even though there is no RFID card within range. Bizarre.

If it is felt that, this maybe a normal communication state then my observation that the KeyeStudio silk screen for MISO and MOSI are swapped on the board I have and the pics at the supplier site for the Arduino wiring diagram are (and opposite) accurate. [4b]

Thanks for the clarification on MISO-MISO and MOSI-MOSI. However, this seems counter intuitive as the MISO verbage 'Master In' imples that the from signal should be from a pin of 'Master Out' on the sending device, and therefore MISO-MOSI (incorrect). I'll continue to ponder this as I have accepted your clarification.

What would you suggest as the next step?

Is there a way to use RST or pull the MISO pins and using console.log() statements, get some onboard RC522 data to provide some clues?

I took a peek at the module MFRC522.js [7] and possibly could start a new instance and build out slowly with new method names, and lots of console.log() statements in hopes of attempting to understand the logic, but I'm not sure where to start and what would be valid result data.

Has anyone used and had success with the KeyeStudio mfg board? I was able to get that in two days combined with an existing order through Amazon. The MPN mfg board which seems to be readily available in Europe was a three week wait via eBay.

Just wondering if this manufacturer has been proven yet.

I appreciate your input Gordon, although you probably want to spend more time with the Puck. I'm a late starter here and only learned of the Pico just after the New Year and the Puck wasn't available yet. Will continue to plug away at this RC522 to get at an answer.

Robin

BTW this Pico is a sweet gem of an idea and I see this taking off over here in the States.

For those following along a great wiki on the SPI bus and wiring MOSI and MISO
[1] https://en.wikipedia.org/wiki/Serial_Per­ipheral_Interface_Bus

Thank you Spocki for the quick response. Good eye on the embedded comment, but that wasn't it. I had block commented out an iteration of the tutorial code, and had to remove the stars to allow the block comment to compile. While creating the forum post in a vanilla editor, I missed the commented out part as it wasn't in color. Proofread, proofread.
Good catch there in any event.

Regarding the code. I'm just using the tutorial as in [2] above: https://www.espruino.com/MFRC522
Note that docs show only Espruino pinout using B2 and B1 is required for the Pico as explained in [3] above.

Regarding a schematic I thought that page [3] above, explained that well enough but if a pin-to-pin table would help:

RC522   Pico
1 Vcc      Vdd (3.3v)
2 RST    -
3 Gnd     Gnd
4 MISO   B4
5 MOSI   B5
6 Clk       B3
7 NSS      B1
8 IRQ      n/c

Not sure if reset should be held in any particular state. Haven't found documentation, yet.

In case it isn't clear, my board (green) mfg is KeyeStudio not the MPN brand (blue) referenced on page [3] available via eBay.

Thank you for your response.
Robin

Sun 2017.01.22
Just jumped into the world of IoT and finding the Pico an undiscovered gem that is about to shine. Toyed with it, running through the gears, while waiting for parts to arrive for fun development.

Here in the USA to reduce an order shipping cost through Amazon Fulfillment I orderd an RFID module to interface with the Pico. [1] The module arrived Friday the 13th. Oooooh, Beware. Superstition aside, read over [2]. Seemed simple enough.

As other tutorials went without a hitch, was surprised when I kept getting:

"Uncaught Error: MFRC522 Request Error 10" which repeated ad infinitum.

in function called from system
Uncaught Error: MFRC522 Request Error 2
 at line 1 col 190
...("MFRC522 Request Error "+a);a=this.r(20);return this.ra(18,...
                               ^
in function "req" called from line 1 col 35
{this.w(26,7);return 0<this.req(38).length}
                                   ^
in function "isNewCard" called from line 1 col 17
{this.isNewCard()&&a(this.getCardSerial(­))}
                 ^
in function "findCards" called from line 9 col 3
 });
   ^
in function called from system
Uncaught Error: MFRC522 Request Error 10

<< repeat >>

What I did to troubleshoot. Unfortunately no O-Scope to assist here:

This Espruino forum reference indicated to change B2 to CS/SS/SDA B1 [3]
I also changed the second line of code [2] to reflect that:
var nfc = require("MFRC522").connect(SPI1, B1/CS/);

The supplier video [at 02:46] indicates to make sure IDE is set to 9600, and verified the Espruino IDE was set to 9600, it's default. [4b]

From that same web page, I re-checked the pinout and found the KeyeStudio PCB had silkscreen that differed from their pics at their website. The supplier image silk screen shows pin 4 as MOSI and pin 5 as MISO which are reversed from the silk screen on the boards I have.

The board that arrived - also without a silk screen rev level
Pin
1 Vcc
2 RST
3 Gnd
4 MISO
5 MOSI
6 Clk
7 NSS
8 IRQ

It's not clear in the documentation whether MISO should be wired to MISO -and- MOSI wired to MOSI. Should these be crossed as in RS232 Xmit-Recv ? hmmmm

How I first wired KeyeStudio (as the silk screen correctness is unknown) [5]
pin 4 as MISO to Pico B5 SPI1 MOSI
pin 5 as MOSI to Pico B4 SPI1 MISO

I reversed those pins and then got different error msgs:
140 0x8C
  02 0x02
  10 0x0A

Was hoping that I could identify a bit(s) that was/wasn't toggling here.

Off to read the spec sheet [6]

It appears that without a scope to assist in watching the clock signals, an option might be to model the MFRC522.js module [7] being careful to use new function names, so as to avoid any name collisions with, that which is already part of the Espruino build. I realize the MFRC522.js module has yet to be built out and I may be one of the few that have made an attempt with RFID. Would like to push on even if I end up with all the arrows in my back. [definition of a pioneer]

Any insight would be greatly appreciated.
Robin

Note to self: Don't accept future shipments on Friday the 13th

[1] Part order RC522
https://www.amazon.com/gp/product/B016KE­9D2U/ref=oh_aui_detailpage_o02_s00?ie=UT­F8&psc=1

[2] Module MFRC522
https://www.espruino.com/MFRC522

[3] Forum post on RC522 and Pico
http://forum.espruino.com/conversations/­269348/#comment12328121

[4] Supplier documentation
http://www.keyestudio.cc/h-pd-118.html
code:
http://www.keyestudio.cc/h-nd-95.html

[5] Pico pinout
https://www.espruino.com/Pico

[6] RC522 Spec Sheet
https://www.nxp.com/documents/data_sheet­/MFRC522.pdf

[7] Module MFRC522.js
https://www.espruino.com/modules/MFRC522­.js

[eof]