-
The problem might be the speed. Have you tried the Encoder module?
-
-
-
Just a hunch: ESP8266's flash is divided to multiple parts: Running code, SPIFS, OTA partition, etc. My guess is that's why you only see that much free flash.
There are compiler flags to set flash partition on the ESP8266, and I think separate compiler options to reserve space for Espruino's storage. -
New interpreter error: LOW_MEMORY,MEMORY
The
LOW_MEMORY
means the Espruino is low on memory, but it's just a warning, if you see it alone.
MEMORY
means Espruino definitely ran out of memory.You can try one thing: In the Web IDE settings, go to Communication, and
- check "Modules uploaded as functions"
- Save on Send -> set to "Direct to Flash"
Btw https://github.com/triestpa/Tiny-OTP fits this way, but there is an error running it:
Uncaught SyntaxError: Got '=' expected ',' at line 1 col 69 ...ports=class{constructor(a,b='utf8'){'base32'===b&&(a=e.decod... ^
I think Espruino doesn't support default parameters.
As Robin said, there could be couple of tiny issues preventing you from uploading code that runs fine on node or in browser...
- check "Modules uploaded as functions"
-
That is a limitation of the microcontroller:
You can't setWatch on two pins with the same number (eg. A5 and C5) - this is a limitation of the STM32F1
From the Known problems section in the Original Espruino Board's docs.
-
-
-
@neoniousTR Is https://estimote.com/ related to you, or just found another company doing JS on micros?
https://blog.estimote.com/post/186818671945/estimote-ai-beacon
"Cloud ide": https://ide.estimote.com (note for the webdevs out there: they ship sourcemaps, if anybody is curious :) ) -
Saw this on Nordic's site: : MIDI over Bluetooth LE
Not Espruino specific, not over Wifi, but might contain some useful info -
-
-
-
Commented out strings, outside of functions are not included in the upload? (yes?)
"it depends" :)
Without minification, all comments and whitespace is included!
By default the web ide does NOT minify your "main" code, but does minify the included modules. But check the minification in the settings. -
Fantastic! Anything I should change in the docs for Win10 users?
Just copy-pasted the relevant commands, and it did work. IIRC installation of esptool wasn't terribly difficult either.
Saw a couple of "probably won't work on windows" remarks, especially in the BLE parts, but seem to work just fine in with the built-in Bluetooth. Web bluetooth works with chrome.I did, but the first one I tried didn't work
Didn't try it, but that was my guess :)
-
Oh, best serialization is no serialization at all :)
Current progress: pretty happily pushing 128 * 16 bit values at 100ms intervals, and that is more than enough for this project.
Thanks Gordon!For the record, going below 100ms interval, the busy LED becomes almost always on, and the actual throughput doesn't increase (measured in the browser by the number of received "packets").
Edit: doing some math :)
Theoretical maximum data transfer:(1000 ms /7.5 7.5ms interval)* 20 byte packets = 2666
bytes / sec
Measured maximum:260 bytes * 10 times per second = 2600
bytes / sec
Is this pretty damn close to the theoretical maximum? :) -
Did work on first try (Win10) 👏
Did you look at Espressif's releases? -
I want to stream ADC data from the MDBT42 module via web bluetooth. The sampling & DMA part works nicely (thanks for the low-level library Gordon!). With 256x oversampling, I have a theoretical 781 effective sample / second. Each sample is an Uint16 value.
I have seen the Web bluetooth and Web Bluetooth Dashboard tutorials, and looks like that can work.
Need to fiddle with serialization, because JSON feels inefficient - 6 characters (worst case) to transfer 2 bytes of data. And the communication wasn't really happy at 160ms intervals :/My questions:
- any better solution than the "UART" between a browser and and nRF?
- any better serialization format for Uint16 array? Current idea: convert to hex, transfer without separator, and reassemble from 4 byte chunks. That's roughly 2/3 data usage compared to JSON, not sure about the CPU usage. And 😴
- I guess bluetooth layer itself takes care about data integrity & ordering. Right? :) Or should I add my own CRC or other error check?
- any better solution than the "UART" between a browser and and nRF?
-
-
Just a guess: do you use
print
orconsole.log
? Maybe this one in the troubleshooting My code works when I'm connected via Bluetooth but stops when I disconnectOr do you use any other library that might contain a
clearWatch
? -
Aside: You can pass in the CS pin to the send command like
var val = spi.send([0xC0,0xF4,3,4], PIN_CS);
Also, the setWatch docs say you can ask for the state of another pin, so you don't have to read it (might matter, as you don't have to spend the time to read it):
// Advanced: If specified, the given pin will be read whenever the
watch is called // and the state will be included as a 'data' field
in the callback data : pinI don't completely understand the snippets, for example, you don't call
setw
from B1's setWatch, but that call should be there, right?Why not just set up one setWatch once on the SCK pin, and ignore if the CS is not low? Ok, depends on how many other slaves are there, and how much CPU the watch uses...
So I guess you could
- use 1 setwatch on the SCK pin, pass the MOSI in as
data
- in the watch, check the state of CS, if not 0, just exit
- process the data as you wish :)
- use 1 setwatch on the SCK pin, pass the MOSI in as
-
Ah, now I got it. That's why I asked @Robin what is this about. And reading the latest comment, turns out it's just a piece of random code...
Sooooooo, originally Semtech gives users a formula in chapter 4.1.4! you don't need 64 bit integer, or more precise FP, just do the math, and multiply with 0.016384! as @maze1980 already pointed out. And now 915e6 makes sense as well: 915MHz frequency.
Quick aside: a good compiler probably can optimize away the bit shift and division, so the programmer just leaves it there instead of manually calculating / simplifying the formula. And most likely easier to follow the code.
-
Didn't you get something like
New interpreter error: LOW_MEMORY,MEMORY
Explanation hereJust some numbers: The Pixl.JS contains an nRF52832 that has 512k flash and 64k ram. And a lot of that is used by Espruino.
So if your code is really that over half megabyte of minified JS, it won't fit in the Pixl. With some serious wizardry to store almost all of your code in some external flash (something like SD card, SPI flash), and pulling in small chunks of that to work on some piece of data, it might work. But most likely you would have to forget about 99% of JS available in NPM, because it's just too big. Or for example there is noSymbol
in Espruino. -
Re: Clone: If someone knows that you are doing this, and maybe finds this forum :) can figure out how you are doing.
For example someone can go there, listen to BLE advertisements, and set up the same BLE advertisement with a separate device, and remove your BLE tag (or the item it's attached to).
Depends on how secure this must be. For example, LOGITacker uses nRF52840 dongles (kind of "bigger brother" of the nRF52832 in the Puck, but still just an easily available 10-15$ device) to attack Logitech wireless devices. And even take over a computer with taking over a keyboard / mouse.Of course I don't know your circumstances. If you don't expect such "high-tech" attack, just listening to BLE advertisement & checking signal strength is probably good enough.
The encoder module might be slightly better, because that is minified (less characters == faster execution).
If you can keep a steady RPM, and gradually increase the speed, you can figure out a rough limit of Espruino's setWatch processing speed.