Attempting to get SPI running on ESP8266 D1 mini along with RFM69/95 for USA - Git source link desired

Thr 2019.06.13

Okay - Found this:

https://github.com/espruino/Espruino/blob/master/boards/ESP8266_4MB.py

ref line #49    'spi' : 1,

but, unable to locate how this one hdwr SPI is setup. Pin map for 'cs' 'rst' anyone?

When using the hdwr setup from pin map link below - second image from end post #1 - and

https://www.espruino.com/SPI

I am led to believe that these are valid pins, as print does kick back what I sent without error:

SPI1.setup({ sck:D5, miso:D6, mosi:D7 });

>print(SPI1)
SPI: {
  "_options": { "sck": D5, "miso": D6, "mosi": D7 }
}

as when using the little loopback trick from #5

http://forum.espruino.com/conversations/307305/

>SPI1.send("Hello");
="Hello"
> 

Now on to RFM95

Note that freq 915 is required for USA and thus module RFM95 needed

ref RFM69 on Pico: https://www.espruino.com/RFM69
https://www.espruino.com/modules/RFM69.js
ref RFM95 attempt: http://forum.espruino.com/conversations/307305/

But, when I attempt to connect applying a pin value for 'cs' or 'rst'

var rfm = require("RFM69").connect({spi:SPI, cs:D8, freq:915}, function() {
    console.log("Connected");
  });

print(rfm);

I'm faced with un-initialized pins: (Note that 'rst' omitted for simple error return)

Uncaught Error: Function "send" not found!
 at line 1 col 10
this.spi.send([a|128,b],this.cs)
         ^
in function "w" called from line 1 col 11
b.w(47,170);if(170!=b.r(47))throw Error("RFM69 not found");b...
          ^
in function called from system
{
  "spi": {
    "spi": function () { [native code] },
    "cs": D8, "freq": 915 },
  "cs": undefined, "rst": undefined, "freq": 434 }
>

The resultant "send" not found! error seems to be as the pin for 'cs' D8 doesn't seem to initialize.

Successes so far:

While an overly ambitious desire to get working and provide a tutorial for the RFM69/95 module, as others seem to be having difficulty also, and realizing that most forum post references ended 2 years ago (late 2016), this task may be near impossible, but might be fun learning to see if the module could be re-written.

"To Boldly Go Where No Man Has Gone Before!"

I understand this is un-supported, uncharted waters:

https://www.espruino.com/Other+Boards

ESP8266 closest match

Found an article that had SPI running with Arduino on a D1 mini. Wanted to see if Espruino would work instead.

After reading the headaches from this install attempt, Jan 2018:

http://forum.espruino.com/conversations/315462/

and having a WavGat D1 variant, see image @MaBe link#18 lying around from a previous CN massive sale discount order I just couldn't resist, gave it a whirl. Surprisingly, in my case, after botching the wrong pull-up pin for flash, was able to get Espruino running with no headache on my part. 'Hello World' in under an hour!

AI Thinker ESP8266MOD

https://wiki.wemos.cc/products:d1:d1_mini

Re-Ordered

Pin	Function	ESP-8266 Pin
01 5V	5V	-
02 G	Ground	GND
03 D4	IO, 10k Pull-up, BUILTIN_LED	GPIO2
04 D3	IO, 10k Pull-up	GPIO0

05 D2	IO, SDA	GPIO4
06 D1	IO, SCL	GPIO5
07 RX	RXD	RXD
08 TX	TXD	TXD

09 RST	Reset	RST
10 A0	Analog input, max 3.3V input	A0
11 D0	IO	GPIO16
12 D5	IO, SCK	GPIO14

13 D6	IO, MISO	GPIO12
14 D7	IO, MOSI	GPIO13
15 D8	IO, 10k Pull-down, SS	GPIO15
16 3V3	3.3V	3.3V

 2v01 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:512/512, manuf 0xe0 chip 0x4016

>process.env
={
  VERSION: "2v01",
  GIT_COMMIT: "748a4d3",
  BOARD: "ESP8266_4MB",
  FLASH: 0, RAM: 81920,
  SERIAL: "a020a606-7bff",
  CONSOLE: "Serial1",
  MODULES: "Flash,Storage,hea" ... "r,crypto,neopixel",
  EXPTR: 1073643636 }
> 

In the meantime, I'll continue to research and will update here as I discover more. . . .

Check this on the Espruino on ESP8266 WiFi page: spi-implementation

Looks like the RMF96 and SX12xx modules have different parameters. The RFM69's connect's first parameter should be the SPI object, not an object with an spi property:

// from the docs:
rfm = require("RFM69").connect(SPI2, {cs:B10, rst:B1, freq:434}, ...
// your code:
rfm = require("RFM69").connect({spi:SPI, cs:D8, freq:915}, ...

Thanks @MaBe for your immediate response,

re: 'The hardware SPI uses the pins shown in the board layout (CLK:D14, MISO:D12, MOSI:D13, CS:D15).'

I also found this tidbit:
"Also look at the NodeMCU.XX pins: http://www.espruino.com/Reference#NodeMC­U"

http://forum.espruino.com/conversations/285936/#12951616

SPI1.setup({ sck:NodeMCU.D5,miso:NodeMCU.D6,mosi:NodeMCU.D7 });
print(SPI1);

which gets me past this error:

>ERROR: Cannot change pins used for flash chip

and, which produced: (mapping the same as in the link you presented)

>SPI: {
  "_options": { "sck": D14, "miso": D12, "mosi": D13 }
 }

and surprisingly

>SPI1.send("Hello");
="Hello"

Still works. To confirm, I reset(1) and re-uploaded.

Then, removed the jumper, and as expected, the data seen:

="\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF\xFF"

So, I believe SPI is now working, but the mapping of 'cs' and 'rst' is still problematic.

Using the same format:

>NodeMCU.D8
=D15

But when I try that format for 'cs':

var rfm = require("RFM69").connect({spi:SPI, cs:NodeMCU.D8, freq:915}, function() {
    console.log("Connected");
  });

print(rfm);

Still seeing error:

Uncaught Error: Function "send" not found!
 at line 1 col 10
this.spi.send([a|128,b],this.cs)
         ^
in function "w" called from line 1 col 11
b.w(47,170);if(170!=b.r(47))throw Error("RFM69 not found");b...
          ^
in function called from system
{
  "spi": {
    "spi": function () { [native code] },
    "cs": D15, "freq": 915 },
  "cs": undefined, "rst": undefined, "freq": 434 }

We can still see that 'cs' is not being accepted.

Was hoping to find the source under the hood for where the other errors are occurring, when the value of 'cs' isn't being detected.

It appears we were updating at the same time. . . .

Good catch @AkosLukacs!

I had been playing with that as I kept getting WebIDE syntax errors R-Hand editor side, and wondered, as no one had success in either of the other forum links if one or the other was a typo.

But, with a bit of fiddling,

var rfm = require("RFM69").connect(SPI1, {cs:NodeMCU.D8, rst:NodeMCU.D0, freq:915}, function() {
    console.log("Connected");
  });

print(rfm);

'cs' and 'rst' are now recognized.

>SPI: {
  "_options": { "sck": D14, "miso": D12, "mosi": D13 }
 }
Uncaught Error: RFM69 not found
 at line 1 col 58
...row Error("RFM69 not found");b.w(47,85);if(85!=b.r(47))throw...
                              ^
in function called from system
{
  "spi": SPI: {
    "_options": { "sck": D14, "miso": D12, "mosi": D13 }
   },
  "cs": D15, "rst": D16, "freq": 915 }
> 

The "RFM69 not found" error seems to be from ~L080:

https://www.espruino.com/modules/RFM69.js

The part I'm still struggling with is that in order to get a correct syntax check, I need to use
the NodeMCU.Dx format, I seem to get errors, as it might just be that those GPIO pin designations just don't exist for the D1 mini. Is it ESP8266, ESP32, RFM69, or Espruino under the hood?

Still searching for the Git source that might explain the NodeMCU.Dx mapping to see if limitations exist there.

Still searching for the Git source that might explain the NodeMCU.Dx mapping to see if limitations exist there.

https://github.com/espruino/Espruino/blob/master/targets/esp8266/jswrap_nodemcu.c

AFAIK, on the ESP8266, only some pins are truly general purpose input and output pins. Lots have restrictions either during boot, or don't behave nicely either as input or output. Nodemcu.D8 == GPIO15 might be one of those pins, but not certain about it...

MaBe 1    Google Search0

Thank you.

That file seems to have its contents commented out.

Backing up to the parent and taking a look, I found:

https://github.com/espruino/Espruino/blob/master/targets/esp8266/jshardware.c
L853

/**
 * Initialize the hardware SPI device.
 * On the ESP8266, hardware SPI is implemented via a set of pins defined
 * as follows:
 *
 * | GPIO   | NodeMCU | Name  | Function |
 * |--------|---------|-------|----------|
 * | GPIO12 | D6      | HMISO | MISO     |
 * | GPIO13 | D7      | HMOSI | MOSI     |
 * | GPIO14 | D5      | HSCLK | CLK      |
 * | GPIO15 | D8      | HCS   | CS       |
 *
 */

I might be getting breakout board pin reference D8 mixed up with ESP8266 pin label D15 as:

>NodeMCU.D8
=D15

But, if I attempt to return that code to either the GPIOxx or removing the 'NodeMCU' prefix, I'm greeted with:

ERROR: Cannot change pins used for flash chip

Conclusion: The only syntax available means is to use the prefix 'NodeMCU' for the pin assignments. This also agrees with the Arduino table, second to last image in #1 above.
I'm also guessing here that the 'D' prefix for the ESP8266 pin, is also the GPIOxx number and not the breakout board silkscreen pin number. e.g. D15 == GPIO15 but is silk screened D8

Now, back to why the external hardware isn't responding to the code running on the D1. . . .

But, if I attempt to return that code to either the GPIOxx or removing the 'NodeMCU' prefix, I'm greeted with:

Looks like a pin between D6 and D11 is used in your code

https://github.com/espruino/Espruino/blob/master/targets/esp8266/jshardware.c#L409-L413

MaBe 2    Google Search0

I found these forum references:

http://forum.espruino.com/conversations/285936/#12951616
'There are definitely pins you can't touch because they're used for the flash chip (the 6 pins at bottom of the esp12E modules)'

http://forum.espruino.com/conversations/307305/
'These are used by the internal flash chip - you will have issues if you use these pins!'

and they both agree with L409-L413 in the jshardware.c assert source note.

So it appears for this particular board, that the prefix 'NodeMCU' must be used for the pin assignments.

More for tomorrow, take a fresh look at all the 'D' references and compare with the pin images.

@Robin, don't remember why I landed here... but:

Did you get this ever working?

Few things I notice glancing thru the thread:

1. SPI is a constructor ('class' / prototype) and, for example, SPI1 is an instance of it. Espruino firmware has - for convenience (and some other reasons) - pre-constructed/created SPI instances - SPI#: SPI1, SPI2, ... SPIn - for as as many hardware SPIs the board / chip has... and allows to construct/create - with spiXyz = new SPI() using the SPI 'class' / prototype object - any number of software SPI objects - on any available/ qualifying pins. Available/qualifying pins means pins that are not already used for other things on the board, such as on any ESP8266EX chip based board to talk to the external FLASH where the software resides, and can be put in the SPI required pin modes.

2. Because some chips allow the use of different pin sets to be used for their hardware SPIs, you still have to setup the pins of the already Espruino pre-constructed/created SPI# instance(s).

3. In post #1 you initialize pre-constructed/created SPI1 instance (referenced w/ SPI1), but when it comes to using it in the connect, you use the SPI constructor reference... which gives you all kind of grieves until up to post #5. If you would have used SPI1 instance reference and supplied the .connect(...) arguments correctly, you would never end up with .send() not found. After fixing the arguments list and 'silently' move to the use of the SPI1 reference, things started to move forward. Kind a surprise that the missing the reference issue has not been mentioned... that shows that the eye reads what the pre-occupied brain expects to be read... :/...

4. Next obstacle was what pins you can use... Espruino firmware also pre-constructs/creates the Pin instances and provides the respective references - such as A0, A1,... D0,...D1,... and hides (encapsulates - one of the core properties of object-oriented programming paradigm) the specifics how Espruino firmware knows about and deals with the pins on a low level - close to the hardware - for each particular chip / board. That allows the rest of the Espruino firmware and also you in your application - on a high level - to deal with pins conveniently, simple and always the same way, despite they may be - and are - implemented differently, sometimes even differently on the one and same chip / board. For convenience for NodeMCU boards - in order to match the silk screen port numbering which can be different from the numbering/naming of the pins of the chip - this NodeMCU pin map object / class has been created and can be used to reference much more obviously the pins in the code.

5. You mention syntax to be the issue. The argument list was the only syntax issue there was. The other issues were issues of referencing the right things. Even with the NodeMCU class (object) it is 'just' a matter of referencing - just as you state in the very last phrase of your last post (pos #11).