-
I've written a small tool which creates a helper script, and can be executed on the board as suggested to create the environment. I'm sending the file in small 32 byte chunks as a byte array.
It goes like:
var s = require("Storage"); s.eraseAll(); s.write("index", "", 0, 15014); s.write("index", [60, 33, 68, 79, 67, 84, 89, 80, 69, 32, 104, 116, 109, 108, 62, 10, 60, 104, 116, 109, 108, 62, 10, 10, 32, 32, 60, 104, 101, 97, 100, 62], 0); s.write("index", [10, 32, 32, 32, 32, 60, 116, 105, 116, 108, 101, 62, 81, 55, 82, 70, 32, 77, 81, 84, 84, 32, 67, 111, 110, 102, 105, 103, 117, 114, 97, 116], 32); // ... goes on
The problem is, that only the first write succeeds, and only the first 32 bytes can be read from the entry. If I manually execute the lines in the interpreter, only the first write returns true, others are not even returning false. Any idea what causing this? I think something fails silently in the native code.
It doesn't seem to be offset related, if I change the second write from 32 to 33 or 31 it does the same.This works:
>s.write("test", "", 0, 20); =true >s.write("test", [0, 1, 2, 3, 4], 5); =true >s.write("test", [0, 1, 2, 3, 4], 15); =true >s.read("test"); ="\xFF\xFF\xFF\xFF\xFF\0\1\2\3\4\xFF\xFFÂ\xFF\xFF\xFF\0\1\2\3\4"
Also it seems I have more than enough memory left in storage:
>s.getFree(); =181528
-
-
-
I'm familiar with how to create Storage entries using the interpreter over the serial connection.
My problem is that with the Espruino CLI I can't seem to send other than the main script file going to
.bootcde
during the upload (this is done by the--config SAVE_ON_SEND=1
option).I tried to do something like this:
./node_modules/.bin/espruino --board ESP8266_4MB -o test.js --ohex test.hex --storage html:./portal/dist/index.html --config SAVE_ON_SEND=1 ./firmware/dist/app.js
It's not possible to remove the
--ohex
option, and thetest.js
output clearly only contains theE.setBootCode
part.Even if it's the only way to do it, I can't find any instructions on how to flash this hex file to the ESP8266 (probably with the esptool.py). But I would rather not do that and use only the Espruino CLI if possible.
I think it's clear now why I'm thinking about bundling the assets to the main script file instead.
Also it's funny that even though I don't connect to any device during the above command, it mentions that I'm using an old firmware.
Espruino Command-line Tool 0.1.30 ----------------------------------- --ohex used - enabling MODULE_AS_FUNCTION Explicit board JSON supplied: "ESP8266_4MB" You have pre-1v96 firmware. Upload size is limited by available RAM Writing output to test.js Writing hex output to test.hex
Am I using an old Espruino dependency or the board definition triggers this and there's a new ESP8266 name available I'm not aware of?
Mod: yep, if I leave out the --board switch it doesn't print that. -
Imo the current @types/espruino under DefinitelyTyped is incomplete. eg. there's no definition for the Storage module.
I've found this other one in this Github repository but have no idea where this came form, seems to be generated as well. Can't reach the owner.I've just finished porting my existing NodeMCU + Lua code to Espruino + Typescript, and it worked quiet well. Although one needs to be careful, because even though you can target ES6, some features are missing. eg. initially I was using the Map structure to handle some things, but that was not working and went back to basic JS dictionaries (where Typescript can still gives a bunch of type hints fortunately).
I wonder what other people use for transpiling and minification. I'm using Rollup + Uglify right now, but maybe Babel would do more and polyfill some missing stuff and make it a more transparent experience. I don't know if it's possible to define a more specific set of supported ECMAScript features for a transpiler; an up-to-date Espruino fitting profile could be done that way.
(Also I would love to play with this watch, but I was too late for the Kickstarter party, and it's kind of expensive now. :( Got me thinking if there are other open source watches available, and interestingly the PineTime seems to use a very similar hardware; I wonder if the manufacturer behind is the same or not.)
-
-
I would like to serve up a minified single HTML (including CSS, JS, images, etc.) from my Espruino. To minimize space, I'm going to gzip the resulting file and use the Content-Encoding HTTP header when serving it up.
I'm also thinking about inlining this gzip file in my Espruino JS code, and base64 encode it. What is the most memory efficient way to stream this from the Espruino, and not decode the whole string into memory first?
Or is there a better idea to do this? I don't have an SD card storage, just the flash of my ESP8266 board.
-
@Robin had to retry it a couple times before the image appeared. Did the same thing yesterday, but had no luck back then. Anyway, the image is now attached.
@MaBe I can give it a go on the weekend if you have anything specific in mind to try out. Thank you for the Github issue!
@Gordon sounds logical. This "hack" solves my problem here, because the longer edges are simply ignored by the modem. But I'm just lucky with my situation, other use cases might not be so forgiving.
-
-
Thank you, I've upgraded to the 'cutting edge' firmware (2v04.76).
I still experience some issues. The minimal code to reproduce it:
var csPin = NodeMCU.D8; csPin.mode('output'); digitalPulse(csPin, true, [0.03, 0.03, 0.045]);
I get only a single low-high transition in this case according to my logic analyzer.
Interestingly if I prepend this with two 1ms values, the microsecond transitions are generated correctly.
var csPin = NodeMCU.D8; csPin.mode('output'); digitalPulse(csPin, true, [1, 1, 0.03, 0.03, 0.045]);
And this does make the modem reset work, I can query it's version number afterwards.
Am I still doing something wrong?
-
-
Hi MaBe,
I'm using the hardware SPI of the ESP8266 (SPI1), and it has only one configuration. The documentation says I don't have to manually specify the MISO/MOSI/SCK pins if I'm okay with the defaults.
If sck,miso and mosi are left out, they will automatically be chosen.
However if one or more is specified then the unspecified pins will not
be set up.But you are right, it won't hurt to try manually specify everything if it doesn't work.
However the error is related to the digitalPulse call, not SPI. The line with the "wait for completion" comment fails as you can see with the timer timeout. The documentation of this function says:
It uses a hardware timer to produce accurate pulses, and returns
immediately (before the pulse has finished). Use digitalPulse(A0,1,0)
to wait until a previous pulse has finished.I have to wait for the pulses to go out before I can issue the reset command on the SPI bus.
Though today while I was browsing the documentation I've also found on the ESP8266 specific page thatThe esp8266 uses FreeRTOS with non-preemptible tasks and has extremely
limited code space for interrupt handlers, as a result, it is not
possible to handle certain peripherals at interrupt time and a task
has to be scheduled instead, which would be OK if tasks were
pre-emptible, but they are not. This means that functions like
digitalPulse have to use busy-waiting between edge transitions instead
of being interrupt driven.So maybe it's not even necessary, since the digitalPulse will be a blocking call on the ESP8266 if I understood correctly.
Anyway, I'm going to dig out my logic analyzer and see what's going on with the pins.
I've seen your previous comment sent out in the email related to the firmware version :)
As you can see I'm on 2v04 (below the logo). I don't understand why the espruno-cli says "You have pre-1v96 firmware. Upload size is limited by available RAM". -
I'm trying to port my NodeMCU code which communicates with the Ti CC1101 modem. Using the NodeMCU ESP8266 board (4MB Flash). I'm using the hardware SPI pins (D5-D7), plus the D8 PIN for chip select.
The only thing I'm doing so far is trying to reset the modem with the chip select line "wiggling" described in the modem's manual in the section "manual reset". This requires microsecond toggling then issuing an SPI command.
My code (generated from Typescript):
var cc1101 = /** @class */ (function () { function cc1101(spi, cs) { this.spi = spi; this.cs = cs; spi.setup({}); this.cs.mode('output'); } cc1101.prototype.sendCmd = function (cmd, cb) { this.cs.write(false); this.spi.write(cmd); this.cs.write(true); setTimeout(cb, 0.3, []); }; cc1101.prototype.readReg = function (reg) { return this.spi.send(reg, this.cs); }; cc1101.prototype.reset = function (cb) { // CS wiggling to initiate manual reset (manual page 45) digitalPulse(this.cs, true, [0.03, 0.03, 0.045]); digitalPulse(this.cs, true, 0); // Wait for completion this.sendCmd(0x30, cb); }; return cc1101; }()); function main() { var cc = new cc1101(SPI1, NodeMCU.D8); cc.reset(function () { console.log(cc.readReg(0xf1)); }); } E.on('init', main);
Uploading with SAVE_ON_SEND using espruino tool, I get this output:
Espruino Command-line Tool 0.1.30 ----------------------------------- Explicit board JSON supplied: "ESP8266_4MB" Connecting to '/dev/ttyUSB0' Connected You have pre-1v96 firmware. Upload size is limited by available RAM --] --] ____ _ --] | __|___ ___ ___ _ _|_|___ ___ --] | __|_ -| . | _| | | | | . | --] |____|___| _|_| |___|_|_|_|___| --] |_| espruino.com --] 2v04 (c) 2019 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:1024/1024, manuf 0xe0 chip 0x4016 --] --] > Upload Complete --] Uncaught InternalError: Timeout on Utility Timer --] at line 2 col 35 --] digitalPulse(this.cs, 1, 0); // Wait for completion --] ^ --] in function "reset" called from line 4 col 6 --] }); --] ^ --] in function called from system
What does this mean? The pulse can't be sent? Or is the pulse sending happening so fast that the hardware timer controlling it already finished when I'm invoking the wait so it starves out?
I should really wait for the pulse to complete, that's when I can send the RST strobe command to the chip.My NodeMCU LUA code for the same thing which works can be found here. Maybe it helps.
-
Thank you for explaining. I'm trying to put the pieces together, and Rollup seems to be the way to go.
I would like to use Typescript on top of allow these, so that's going to twist this a bit further.
(Interesting that I've found a more complete type definition in this repository for the platform; the @types/espruino definition is missing a bunch of stuff. I don't know where the first one came from, would be good to know. Can't reach the repository owner unfortunately.) -
I'm trying to use the new rollup-plugin-espruino-modules (the old one is not API compatible with Rollup anymore).
import { espruinoModules } from 'rollup-plugin-espruino-modules' import commonjs from 'rollup-plugin-commonjs' import { terser as terserPlugin } from "rollup-plugin-terser"; export default { input: 'src/main.js', output: { file: 'dist/bundle.js', format: 'es' }, plugins: [ commonjs(), terserPlugin({ compress: true, mangle: true }), espruinoModules({ board: 'ESP8266_4MB' }), ], }
Running rollup fails with this:
Error: ENOENT: no such file or directory, open 'C:\dev-esp\espruino-cc1101-q7rf\modulesÂ\.board_ESP8266_4MB.json'
Mod: okay, never mind, I've figured out. I needed to create the modules directory by hand, otherwise it fails. It's probably a bug.
Am I correct that this new module cannot upload the code to the board after bundling? I've seen the older plugin had the port/baud/save options for this, but not this.
Also is it okay to run the Espruino plugin after the Terser like this?
Okay, I've figured it out.
This line causes the issue:
s.write("index", "", 0, 15014);
If I put the length attribute to the first chunk of the actual data it works as intended. I don't know if it's a bug or intentional, but now it works correctly. Strange that with the small example it's not an issue.