You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
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.
@allObjects
@Robin, don't remember why I landed here... but:
Did you get this ever working?
Few things I notice glancing thru the thread:
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.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).
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... :/...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.
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).