Search results for:

Just a guess: maybe try to press the flash button while running the esptool?
I have some ESP32 boards with CP2102, and those flashed just fine...

@MaBe good find! It works!
Had some issue when tried to get the HW I2C working on the ESP8266. Probably it was just wiring, or dunno, that's why I had software I2C there. But just tried now, and it does work!

And one more bit of info: since the "hold master" measurement failed, tried the "no hold master" way of things with my code on the ESP32.

Software I2C & SHT21 fails the same way on Espruino Wifi board as well.

Other sensors on the same board (BMP085 and ISL29023) work with software&hardware I2C on Espruino Wifi and ESP32 without any problem with the same code.

Software I2c fails too on the ESP32.

Result with soft I2c:

Uncaught Error: I2C Error: Timeout (rd)
 at line 1 col 68
...is.i2c.readFrom(this.addr,3),b=a[0]<<­8|a[1]&-4;this.checkCrc...

in function "readTemperature" called from line 41 col 53
console.log('SHT Temperature:', sht.readTemperature());

That this.i2c.readFrom(this.addr,3)... fragment is from the minified module.

Result with hardware I2C:

ERROR: jshI2CRead:, Operation timeout because the bus is busy
Uncaught CRC Error

The Uncaught CRC Error comes from this line of the module.

Hi!

Edit: tested some more boards:

1. Espruino Wifi - ok! (hw I2C)
   
2. Pixl.Js - ok! (hw I2C1)
   
3. ESP32 - not OK, my original issue, details below
   
4. ESP8266 - OK! There was some issue previously with maybe my wiring?
   Tried to read an SHT21 sensor with an ESP32, but the SHT2x module did not work. Failed with CRC error, and got some console warnings about NACK by the IIC slave.
   Wiring is good, there are other I2C sensors on the same board, and those works It does work. Tried the code on an Espruino wifi, and works without any problems.
   
   

After digging into the datasheet, and the "hold master" measurement failed, tried the "no hold master" way of things...
You start the conversion, and poll the sensor: the SHT21 responds with NACK while the measurement is not ready. Later managed to use the CRC check and retry reading until the sensor actually finished conversion, so I have working code on the ESP32 as well. (give me some time, and will post it)

My guess is that the STM32 and ESP32 I2C implementation differs: on STM32 it tries to read until it gets proper response with ACK from the IIC slave, and discards NACKs. On the other hand the ESP32 just returns data even when the slave said NACK.
Does anyone know whether this is true (without digging into the C source code)?
If it's true, is there some "official" guidance how to handle this in modules? The code for the ESP32 is of course bigger, so I guess it wouldn't benefit everyone to overwrite the current module.

ESP8266 - used software I2C, temperature reading fails. Hardware I2C does work. Just had some unknow problem...
Temperature reading fails with an I2C Timeout error.
Humidity measurement works. I guess the Espruino interpreter + soft I2C is slow enough that readHumidity does not time out before the humidity measurement is complete (22-29ms accoring to the datasheet) readTemperature consistently times out (takes 66-85ms).
But this is not the same as the ESP32, where the I2C read succeeded & ignored the NACK.
Funnily enough my ESP32 code does work, but I guess simply because the setTimeout + speed of the ESP8266 + software I2C is slow enough.

Used the hardware I2C1 where I could:
ESP32: I2C1.setup({sda: D21, scl: D22}); I got the pins right, right? :)
Espruino Wifi: I2C1.setup({sda: B9, scl: B8});
Pixl.JS: I2C1.setup({sda: A4, scl: A5});
ESP8266: i2c.setup({sda: NodeMCU.D2, scl: NodeMCU.D1});

@Robin Of course I was wrong about the wrong order in the struct. Same behavior (GRB) with STM32.

@Gordon I think checking for 3 or 4 byte length, and throwing an error if the array length doesn't match the expectation is a valid. I guess 99% it's a programming error. Ran into it myself when messing with these LEDs. :)
Getting a clear error (IMO) is way better than debugging or blaming LEDs / the library / sample code.

@Robin Well, there are four colors per chip, so trying 4 bytes per pixel felt a good guess. Add some trial and error, and got them working.

(Edit: I was wrong, same behavior on the STM32) Regarding RGB / GRB: There is something that looks strange in the NRF driver

typedef struct
{
    uint8_t   green; // Brightness of green (0 to 255)
    uint8_t   red;   // Brightness of red   (0 to 255)
    uint8_t   blue;  // Brightness of blue  (0 to 255)
} rgb_led_t;

The first color in the struct is green, that might be the reason for the strange color order.

I will try it with an STM Espruino tomorrow.

Or simply it's banggood, the item and description is not expected to match perfectly...
Sometimes they list half a dozen part numbers in the name, and drop in the words like "replacement" or "upgraded"...
Watched some youtube videos about RGB and RGBW strips, and they mentioned that the color order may change between manufacturers and batches. They might be RGB, GRB, or RGBW, GRBW, etc. So if you plan on creating a long strip, better buy it together...

@allObjects Yes, mine are async ones. 4 pins on the LEDs, and the strips have 3 wires: GND, VCC, and Data in. Data out on the other end, and no clock signal.

Thanks for the comments! I guess didn't make it clear: it's working fine. Sorry for the confusion!

Just couldn't find any info in the docs or in the forum (TIL forum search doesn't search in message bodies). Not knowing the proper chip type didn't help either. So I thought just post what I found. Just to find out later, that info was already posted in different threads. These are nothing new after all...

@allObjects Didn't try, because it is working with neopixel.write. :)
That issue didn't affect me, because I use an NRF52.

But now I know more about these LED chips, thanks everybody!

Ok, there are more things to RGB / RGBW leds that I knew :)

The "RGBW WS2812B" Leds are from banggood. So maybe the seller knows what exact chip it usess...
For example (on MDBT42Q module):

require("neopixel").write(D14, [50,0,0,0, 0,50,0,0, 0,0,50,0, 0,0,0,50, 50,50,50,50, 50,50,50,0]);

produces green, red, blue, and three "white"s. Not visible on the image, but the uC is at the green side.

But the library throws an exception if I try to write a single RGBW pixel, because the array length is not divisible by 3:

require("neopixel").write(D14, [50,0,0,0]);

My writeRGBW idea would be simply a write that works with multiples of 4 bytes out of the box :)

(edited with some clarification) Just got a strip with "RGBW WS2812B" Leds from banggood. The good news is, the neopixel library it just works! If the number of LEDs is divisible by 3, or you pad it.
For example (on MDBT42Q module):

require("neopixel").write(D14, [50,0,0,0, 0,50,0,0, 0,0,50,0, 0,0,0,50, 50,50,50,50, 50,50,50,0]);

produces green, red, blue, and three "white"s.
But the library throws an exception if I try to write a single RGBW pixel:

require("neopixel").write(D14, [50,0,0,0]);

Tried to dig into the c code, and create a writeRGBW method, initially I thought it's just checking for different length :) But that rabbit hole is a bit deeper with all the device specific drivers...

@Gordon you have done a great job documenting the build process, had a custom build for the MDBT42Q module in a couple of minutes!

Do you plan to modify the library for official support? Or just add the workaround to the docs?

Hi, I guess the list is outdated again :)

Another question (that probably should go somewhere else): Do you have aliexpress / amazon / banggood / geargbest / etc affiliate link?

If others are like me, maybe they too order random stuff from all around the world, and a few% of that could help. Or maybe not, don't know how reliable are these...

@allObjects Thank you for the explanation, I guess now I understand the why as well!

Thanks a lot @allObjects for confirming it!

One thing: the module code does work on the Pixl.JS!
If I just copy-paste the whole module code "on the right hand side", without require-ing it, it can display all the measurements on the LCD too without any problem.
Had it running with 1 second refresh for a couple of hours, without any problems.

I suspect the issue is indeed with the require part, so yes, @Gordon will have some fun puzzle after he comes back from his holiday :)

Thanks for the answers, I think something is wrong with the Pixl.JS!

If I "send" this single line of code var bmeMod = require("BME680"); from the IDE, it does work on the Espruino Wifi, but does the aforementioned weirdness on the Pixl.JS

The Pixl.JS prints New interpreter error: LOW_MEMORY,MEMORY, and memory usage is different:
Calling process.memory() on the Pixl.js prints 2378 free, 122 usage.
Calling process.memory() on the Espruino wifi prints 6203 free, 945 usage.

Both running 2v00.
On the same machine, tried a couple of times, and the Pixl.JS works fine otherwise: the BME 860 works, if I directly upload the whole module code...

So, just manually copy-pasted the module's code, renamed exports to bmeManual, and uploaded to the Pixl.JS. And it works, and the measured values feel realistic (see the screenshot).

Edit: it does work both with the minified and non-minified code if I just copy-paste it. But doesn't work with require-ing the code. Don't know what's going on...

Thanks for the input! Really weird, tried almost exactly what you recommend before posting, but no luck.
A screenshot is attached of the code + the REPL result to show exactly what I tried to do.
But no luck. Looks like the require-d BME680 is just an empty object (look at the print-ed result and the autocomplete result just at the top of the highlight.

I did import the DHT module only to verify that require does work. And it does work: dht.connect is indeed a function. but the BME680 is empty???

Hi!

Tried to interface to a BME680 , but fails a rather strange way. Tried to use the example, but

var bme = require("BME680").connectI2C(i2c);

Errors at the .connectI2C part: Function connectI2C not found!

If I just require in the module, like this

var bme = require("BME680");

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!

Honestly, no idea. Theoretically you can remove the IDD measurement jumper, and connect to a different board.
Both STM's and TI's board have an additional uC for power measurement, and maybe the protocol maybe not that well known...
Ti's solution looks like heavily tied to their IDE (measuring function level power consumption sounds nice tho). Couldn't find more info about STM ones.

@Gordon capitalize your last line, it's simply brilliant :)

Altho not exactly correct if you are other timezone than the UK, and want to get your local time.

5V supercaps have significant internal resistance, IIRC in the 10-100Ω range. Radio transmission would most likely cause a brown out. Don't know if espruino and the radio runs at 2.5V...

Actually a couple of uC vendors have tools for power measurements, just for inspiration:
STM has ammeter in some newer Discovery boards: Cortex L4, Cortex L0
Ti has Energy trace in the MSP432 Launchpad.
Atmel has Power Debugger as a standalone tool with jtag and other debug stuff.

Regarding the size of the board: have you considered BGA package? I guess that could be a significant increase in assembly price (x-ray and stuff for bga), and definitely not quickly-handsolder-a-proto friendly, but still...

Don't know, if you can still get leaded (lead metal) solder, but that has a lower melting point. (obviously not for production && wash your hands after).
Flux can help a lot. Even if you have rosin cored solder.

@Gordon Given that this would be a "connected" thing, what about external storage? I'm thinking about

• OTA FW upgrade (although not as required as in a non-scripting micro)
  
• Storing certificate(s)
  
• Storing Js/Css/Html (if this would act as a http server)
  
  

Maybe a uSD card slot, so the user can add any storage?

Or just the place in the layout for an easy-to-buy uSd socket, and don't populate it by default to keep cost low?

Cool :)
edit: and sending the reply with ctrl-enter works, nice :)

Actually I hoped that you know the microcosm.app guys :)

If you don't have any "is my site still alive" ping-thing, there are a few reasonably good free ones. Of course if you can actually do anything about it. Not much point annoying yourself if you can't fix it...
I'm using uptimerobot. And recently found out that the ebil MS / Azure also has one similar service for free that supports somewhat advanced tests with multiple geolocations too.