Search results for:

In my case, at first I thought I was doing things wrong when I tested the LCD with an MDBT42Q which I've been working with for some time.

Then I realized it was because I set the contrast too low. That way I ruled out that the LCD was the issue.

If you have another microcontroller (maybe an Arduino?) you can try out some sketches and see if you can rule out your LCD as being problematic?

Just tried this:

Serial1.setup(9600,{tx:A9,rx:A10});
I2C1.setup({scl:B6, sda:B7});
var lcd = require("HD44780").connectI2C(I2C1);
lcd.print("Hello World!");

And it's still the timeout error

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v07 (c) 2019 G.Williams
>Uncaught InternalError: Timeout on I2C Write BUSY
 at line 1 col 111
...|4,a|4,a,a,d,d,d|4,d|4,d,d])
                              ^
in function "a" called from line 1 col 7
a(51,1),a(50,1),a(40,1),a(12,1),a(6,1),a(1,1),{write:a,clear...
      ^
in function "a" called from line 1 col 133
...,a|4,a,a,d,d,d|4,d|4,d,d])})
                              ^
in function "connectI2C" called from line 1 col 842
...('HD44780').connectI2C(I2C1);lcd.print('Hello World!')
                              ^

Also, just a small observation: I feel I've been spoiled by the nRF52 chips because I keep expecting I can just assign any peripheral to any pin, whereas with STM32 there are only specific pins you can use for certain peripherals :P

I tried USB.setConsole(true) as well, as I saw the ! on the pins but that still didn't work. So maybe b6/b7 just isn't suited for hardware I2C1 and instead just use the other I2C peripherals?

Using software I2C seems to work with b6/b7

var i = new I2C();
i.setup({scl:B6, sda:B7});   
// PCF8574AT based IO expanders default to address 0x3F
var lcd = require("HD44780").connectI2C(i);      
lcd.print("Hello World!");

Doing it on I2C1 with B9/B8 works

Tried it again on I2C1 b6/b7 , got a slightly different error message this time:

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v07 (c) 2019 G.Williams
>Uncaught InternalError: Timeout on I2C Write BUSY
 at line 1 col 111
...|4,a|4,a,a,d,d,d|4,d|4,d,d])
                              ^
in function "a" called from line 1 col 7
a(51,1),a(50,1),a(40,1),a(12,1),a(6,1),a(1,1),{write:a,clear...
      ^
in function "a" called from line 1 col 133
...,a|4,a,a,d,d,d|4,d|4,d,d])})
                              ^
in function "connectI2C" called from line 1 col 807
...('HD44780').connectI2C(I2C1);lcd.print('Hello World!')

I just tried it out on my pico (pardon the contrast, but the Hello World is there)

However, I could only get it to work with I2C2

If I use I2C1 b6/b7 I get this error:

Uncaught InternalError: Timeout on I2C Write Transmit Mode 2
 at line 1 col 111
...|4,a|4,a,a,d,d,d|4,d|4,d,d])
                              ^
in function "a" called from line 1 col 7
a(51,1),a(50,1),a(40,1),a(12,1),a(6,1),a(1,1),{write:a,clear...
      ^
in function "a" called from line 1 col 133
...,a|4,a,a,d,d,d|4,d|4,d,d])})
                              ^
in function "connectI2C" called from line 1 col 807
...('HD44780').connectI2C(I2C1);lcd.print('Hello World!')
                              ^
Execution Interrupted

Here's the code I used to test with I2C2:

I2C2.setup({scl:B10, sda:B3});
var lcd = require("HD44780").connectI2C(I2C2);
lcd.print("Hello World!");

Good read!

Moving the logo out of a function should also help reduce reinitializing the var whenever it's called.

My bad here, looks like this won't matter since it looks like Espruino won't reinitialize the String anyway. This is just me being sensitive to these things because of how React behaves :P

No sorry. I don't have that sensor.

Got it, I'll see if there are any. Didn't realize there was this repo, this is the one referenced in the provision.sh script isn't it?

Anyway, thanks again @Robin and @MaBe for the support :)

Hmm looking at the targets, it seems that the nrf5x are custom code that applies to the nrf5x family, and that includes the i2s neopixel drivers.

At least for now I've got it working on the nRF52840 board I have; I'll have to try compiling for the nRF52832 based boards and see if specifying the LRCK pin on i2s would break anything (hopefully not).

I also chose D23 since the other boards (notably MDBT42Q) are choosing that, instead of the default D22. I thought that should minimize any breaking changes.

@MaBe yes, the boardfile already specifies SDK15 but I'm not sure if that affects neopixels.

Hey Robin, it's alright I think I got it working. Thanks for bringing up the topic, otherwise I would have just given up. I even used your [055,055,055, 055,055,055, 055,055,055, 055,055,055] test (which lights up all pixels white btw, no green led for me).

@Gordon it looks like LRCK is required to be defined, aside from SCK. I found a discussion on the nordic forums here: https://devzone.nordicsemi.com/f/nordic-q-a/55802/driving-ws2812b-neopixels-with-i2s-without-sck-lrck

Doing something like:

@@ -45,7 +45,7 @@ ret_code_t i2s_ws2812b_drive_xfer(rgb_led_t *led_array, uint16_t num_leds, uint8
 [#else](https://forum.espruino.com/search/?q=%23else)
        config.sck_pin      = 22;
 [#endif](https://forum.espruino.com/search/?q=%23endif)
-       config.lrck_pin     = NRF_DRV_I2S_PIN_NOT_USED;
+       config.lrck_pin     = 23;
        config.mck_pin      = NRF_DRV_I2S_PIN_NOT_USED;
        config.sdout_pin    = drive_pin;
        config.sdin_pin     = NRF_DRV_I2S_PIN_NOT_USED;

gets everything working.

I haven't tested and compiled with the nRF52832 boards with LRCK defined though, so I'm not sure if that would affect any of the functionality of the official boards.

Edit: the forum seems to mess up the diff, so here's a screenshot

Hello Robin, this is the another board with the nRF52840 that I'm using with Espruino. It has an nRF52840 chip (the bigger brother of the nRF52832 chip that can be found on the MDBT42Q). The chip can be programmed with multiple frameworks: MicroPython, Arduino, Mbed, Zephyr, and of course our beloved Espruino.

I am not sure what you mean by the Arduino code block image. When I use Arduino as the framework, the neopixels work. When I flash Espruino on the same board, the board locks up as soon as it hits the neopixel statements.

This is the nRF52840DK https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF52840-DK it is the reference development board for the nRF52840 chip by Nordic Semi.

The neopixels work on the same board when using Adafruit's Arduino core so I don't think it's the circuit nor the neopixels itself.

Callbacks are an option, but I tend to like promises more :P But still, that makes the actual call "nested" in a sense.

I'm looking for a possible way to just do

var data = hdc.read();

and it "just works." This would be possible with async/await but from what I can see it's not yet available in Espruino (yet).

If Espruino had a delay I can do away with the setTimeout and just delay for a few ms at that point and everything should work (this is actually how the Arduino libraries do it) but delay doesn't sound like the Espruino way of doing things.

For measuring voltages and current while being one step removed from high voltage, I think the INA226 or INA219 is the easiest to use.

If you truly wish to isolate the pixl from the rest of the van circuitry, you can get one of those split core sensors like https://www.sparkfun.com/products/11005 which will measure current, but not voltage. You can still use the INA226 for that though, without having to complete the circuit (and theoretically saving you from possible over voltages).

There's also this https://www.youtube.com/watch?v=cG8moaufmQs
that you might be interested in :)

You're welcome :) I can see that you used heatshrink as well, hopefully that helped too (sometimes it's larger for less compressible data but ymmv).

Looking forward to seeing your watchface!

I wasn't able to get @Alexandr 's code give the correct values so I tried doing it differently.

I tested the sensor with an Arduino and a library for the HDC1080 and then transferred the whole shield over to the Pixl.js for testing.

var exports={};

var C = {
  I2C_ADDRESS : 0x40,
};

function HDC1080(i2c, deviceAddress) {
  this.i2c = i2c;
  this.deviceAddress = deviceAddress;
}

HDC1080.prototype.read = function() {
  this.i2c.writeTo(this.deviceAddress, 0);
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const data = this.i2c.readFrom(this.deviceAddress, 4);
      const temp = data[1] | data[0] << 8;
      const hum = data[3] | data[2] << 8;
      resolve({
        temp: (temp / 65536) * 165.0 - 40.0,
        humidity: (hum / 65536) * 100.0,
      });
    }, 25);
  });
};

exports.connect = function (i2c, deviceAddress) {
  return new HDC1080(i2c, deviceAddress || C.I2C_ADDRESS);
};

I2C1.setup({sda:SDA, scl:SCL});
var hdc = exports.connect(I2C1);
setInterval(() => {
  hdc.read().then((e) => {print(e);});
}, 1000);

It's a bit raw for now but that's how it looks like right now, ready to be done as a module.

I do have a question for @Gordon , I had to use promises because I needed to wait a few ms for the sensor to be ready after setting the pointer for the read (otherwise I get an I2C exception). There isn't any ready pin for this sensor.

Would promises be the way to go, or is there some other way to "delay" the I2C read but still maintain a somewhat sychronous flow?

Edit: obligatory screenshot'

For Espruino, reducing the character count really helps a lot.

Maybe for date border, you can try drawing a static image instead of drawing it algorithmically? That way you just need to save the bitmap.

Moving the logo out of a function should also help reduce reinitializing the var whenever it's called.

Would be nice to have a BT Mac address of FFxFF :D Wouldn't that be unique?

Also, if this is a campervan and probably would be out and about the weather, maybe you can try getting the MDBT42Q breakout board for a permanent installation?

What I personally do is to try things out on my Pixl and when the code / connections are ready I use an MDBT42Q breakout instead. It's cheaper (so I won't feel as bad if/when it crashes and burns) and smaller, so it's easier to get it in an enclosure for waterproofing. Maybe even bathe it in some hot glue or epoxy/resin with some terminals sticking out for the ultimate in weather protection.

Glad to know the Pixl survived. I'm quite surprised at how resilient these boards are (I had a post here where I plugged in the lipo backwards on an MDBT42Q breakout and it only killed the voltage regulator, preventing damage to the actual chip).

Well that escalated quickly: https://twitter.com/shitoberfest

Hopefully we don't get any spam PRs just because of this :(

That example uses an STM32 based Espruino board. You'll need to use your own pins.

The nRF52832 based boards (yours is one) can have I2C on any pin. You just need to specify it.

See for example https://www.espruino.com/INA219 but instead of A4/A5 you can use D6/D7 or D11/D12 or any pin you want.

And yes you can connect your serial to D11 and D12

I think these are already good lists! :) Especially the documentation issues, which usually are the easier ones and great as someone's first contribution.