Require-ing BME680 library is broken on Pixl.JS? #1266
Replies: 14 comments
-
Posted at 2018-12-28 by @allObjects See no issue with the module: in both - http://www.espruino.com/modules/BME680.js and http://www.espruino.com/modules/BME680.min.js - module files, I see the functions as part of the exported and by require retuned object I assume you got all the details right, down to possible typos and internet connected... The modules is kind of a kitchen sink... it provides access to the connectXYZ functions as well as to the Just upload from the IDE on the right side / from the edit pane this code:
In console - on the left side you can then play around line by line with:
I hope this will help debug the issue... |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-28 by AkosLukacs Thanks for the input! Really weird, tried almost exactly what you recommend before posting, but no luck. I did import the DHT module only to verify that require does work. And it does work: Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-28 by AkosLukacs So, just manually copy-pasted the module's code, renamed Edit: it does work both with the minified and non-minified code if I just copy-paste it. But doesn't work with
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-28 by @allObjects This behavior is indeed weird... What raised some suspicion that require() / IDE uploader does not do what it is supposed to do is the error message I see in one of the screen shots... I do not know where it comes from, but if upload is not going straight and untouched, things are out of whack... To go closer to require() / IDE uploader context, take a look at this conversation about Module development. It describes how the module cache can be loaded. It goes similar to your approach, but requires less meddling with the source code. You just plug it in, unminified or minified. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-29 by DrAzzy Hm, I'm using BME680 without issue.... My hardware is (essentially) an Espruino board - only with the RDT instead of RCT chip, and adjustments to board def to tell it about the extra ram and flash. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-30 by AkosLukacs Thanks for the answers, I think something is wrong with the Pixl.JS! If I "send" this single line of code The Pixl.JS prints Both running 2v00. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-30 by @allObjects @AkosLukacs, let me fire up my Pixl and see what it does. I do not have a BME680, but that should through an exception way beyond successful upload. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-30 by @allObjects ...same issue for me... This is the code I'm uploading:
This is what the load shows upon clicking the Upload button:
Screenshot attached below shows the whole story, from connect thru the failure. The actual error - New Interpreter error... - happens at the end of the upload. Will do a few other tests. Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-30 by @allObjects Testing on a PICO same code... and get expected output: Since I do not pass an I2C argument, actually none, I get what I deserve... but clearly,
I suspect/conclude, that something upon reception when Pixl is writing the module to the Modules cache, it fails. Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-30 by @allObjects Last, and 'giving up' test is uploading the following code:
The multi-line string in the single back tick quotes is the minified code from espruino.com/modules/BM680.min.js and seems to be just too much for Pixl to handle on reception. Pixl starts to create the cache entry - you can find it w/
There is too much node.js like stuff going on... (...things held floating...) This module was written a bit too Arduino-ish... where the crunch work happens at compile time in the IDE and BEFFORE upload to the board... and not what happens in ESPRUINO: NOT much in the IDE except finding nested require, all crunching ON the BOARD, AFTER the upload. Pixl has obviously not enough memory - my uneducated assumption - to do that heavy lifting. PICO can do it. You are NOT out of luck... just up for some significant work. Rewriting the Module would need some significant work... and absence of regression tests makes it worse. My approach of rewriting would be a base module containing the 'class'/constructor BME680 w/ the Constants - C - and making C accessible via the 'class'/constructor BME680. Subsequent uploads and extensions of this 'class'/constructor function would add the sensor areas as desired and reference the Constants C always via the 'class'/constructor BME680. Also, some name shortening and more JS like programming have to be applied... I know that there is a way to allow constants to be folded in, so they are not around anymore with these long names. Using one and the same constant definition in all the Main and Sub May be @gfwilliams has a better answer... Attachments: |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-31 by AkosLukacs Thanks a lot @allObjects for confirming it! One thing: the module code does work on the Pixl.JS! I suspect the issue is indeed with the |
Beta Was this translation helpful? Give feedback.
-
Posted at 2018-12-31 by @allObjects ...this is due how the Espruino JavaScript interpreter works: every time a JavaScript expression completes - in level 0 - on upload, it is executed and the source string is released and interpretation resources are freed up for next expression. ...just a reasonable guess. The way I emulated the upload is what actually happens on upload, which is not in level 0, where as @AkosLukacs did it, it is in level 0. In other words, it is a way to overcome temp memory issues... this is another reason why @gfwilliams's Espruino JavaScript interpreter interprets from source and not from some byte code to deliver this high-level environment in a memory resource constraint setting, as all the power-frugal mc are. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-01-02 by AkosLukacs @allObjects Thank you for the explanation, I guess now I understand the why as well! |
Beta Was this translation helpful? Give feedback.
-
Posted at 2019-01-07 by @gfwilliams Ok, so the issue here is really the Basically the BME680 module is big - 10k minified - and the default upload method uploads as a string, which them has to be parsed (using another 10k) and then executed (using another 10k). The easy fix for this is actually just to turn on Other option is also change the options so that everything is uploaded direct to flash (which will save a bunch of memory). OR... you could save the BME680 module to storage as a string (named something else like |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2018-12-27 by AkosLukacs
Hi!
Tried to interface to a BME680 , but fails a rather strange way. Tried to use the example, but
Errors at the
.connectI2C
part: Function connectI2C not found!If I just require in the module, like this
I should be able to use it "on the left side", right? But can't, there is no connectI2c or connectSPI or BME680 properties on the
bme
variable.It does work if I require a DHT22. The connect function can be called from the REPL side.
Hardware: Pixl.Js, 2v00; the BME680 is connected thru I2C on A4 and A5. (on a pimoroni breakout board)
I2C and the module seems to work OK: Reading the module's JS code, found that there is a module Id, and I could read that Id without any problems.
The upload of the code does take a couple of seconds, there are no errors. Looked at the module's JS code, and should work. Or at least should do something, but does nothing. As if nothing is exported...
Anybody has any idea what might be the problem?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions