felmue
@felmue
Posts made by felmue
-
RE: Read SHT30 and SHT40 from ENVIII-HAT and ENVIV-UNIT at the same time
Hello @Ivanks
you are corrrect, SHT30 has an ADDR pin which allows to change the I2C address:
The address of the sensor can be changed dynamically during operation by switching the level on the ADDR pin.
However in the ENVIII hat the ADDR pin is connected to GND. See schematic here. This means In order to change the I2C address you'd need to modify your ENVIII on a hardware level.
In contrast, according to its datasheet, SHT40 doesn't have an ADDR pin - the I2C address is predefined and reflected in the part number (A -> 0x44, B -> 0x45)
Products Details
SHT40-AD1B base RH&T accur., 0x44 I2C addr.
SHT40-BD1B base RH&T accur., 0x45 I2C addr.Thanks
Felix -
RE: [Core Ink] Unwanted display refresh on startup
Hello @Spaghetto
the way I understand the system is that there are three levels of "screen" data. The sprite, the internal display buffer and the actual pixels on the screen. Now, to put something onto screen, first data is drawn onto the sprite, next the sprite is pushed to the display driver which compares the sprite data with the internal buffer and every pixel which is different is then changed on the screen.
So for example starting with a blank sprite, blank buffer and blank screen then update the screen two times (w/o shutdown in between):
sprite buf action screen 00000 | 00000 | ----- | 00000 draw to sprite 11000 | 00000 | ----- | 00000 push sprite 11000 | 11000 | SS--- | 11000 clear sprite 00000 | 11000 | ----- | 11000 draw to sprite 10001 | 11000 | ----- | 11000 push sprite 10001 | 10001 | -C--S | 10001
Note: action means the old state of the buffer is compared to the new and then a pixel gets either set (S), cleared (C) or is unchanged (-).
Now the same, but with shutdown and restart between first and second update:
sprite buf action screen 00000 | 00000 | ----- | 00000 draw to sprite 11000 | 00000 | ----- | 00000 push sprite 11000 | 11000 | SS--- | 11000 shutdown soft restart 00000 | 00000 | ----- | 11000 draw to sprite 10001 | 00000 | ----- | 11000 push sprite 10001 | 10001 | S---S | 11001
Note: the shutdown also turns off the power to the display driver and this clears the display buffer which leads to pixels only getting set.
The trick to avoid that is to setup the display buffer after the restart with the data it contained before the shutdown. In my RTC clock example I achieve this by waking the device up 2 seonds before the minute changes. This allows me to push the "old" data to the display driver first (which changes nothing on the screen), wait until the minute has changed (seconds equal zero) and then push the new data.
sprite buf action screen 00000 | 00000 | ----- | 00000 draw to sprite 11000 | 00000 | ----- | 00000 push sprite 11000 | 11000 | SS--- | 11000 shutdown soft restart 00000 | 00000 | ----- | 11000 prepare buf with old data draw to sprite 11000 | 00000 | ----- | 00000 push sprite 11000 | 11000 | SS--- | 11000 wait for minute change draw to sprite 10001 | 11000 | ----- | 11000 push sprite 10001 | 10001 | -C--S | 10001
Thanks
Felix -
RE: Stamp C3 mate. 3 adc instead of 4?
Hello @HappyUser
well, according to ESP32C3 documentation ADC1 has 5 channels (GPIO0 - 4) and ADC2 has one (GPIO5). Of the total six channels GPIO5 cannot be used together with WiFi. However GPIO0, GPIO1 and GPIO4 are available.
That leaves GPIO2 (RGB LED) and GPIO3 (button). If you do not need the button it should be possible to use GPIO3 after soldering a thin wire to it. To use GPIO2 however would require to remove the RGB LED I guess.
Thanks
Felix -
RE: M5 CoreS3 power drain issue.
Hello @lweiyen
if I am not totally mistaken this is U17 - it's used to power USB (OUT) when running from battery (and BUS is set to OUT).
Please see my drawing here and schematic here.
Thanks
Felix -
RE: Sorry, but new firmware breaks my projects... Again...
Hello @BrianR
after long hours of searching and trial and error I think I found the reason UART is broken on M5Dial UIFlow2 firmware v2.0.2 and later. At least the fix works for me. I've created a PR for M5Stack engineers to consider.
Thanks
Felix -
RE: Sorry, but new firmware breaks my projects... Again...
Hello @BrianR
sad but true. I can confirm that UART (id=1) in general is broken in M5Dial UIFlow2.0.3 firmware.
Note: M5Dial UIFlow firmware v2.0.1 was the last version where UART (Id=1) worked. In other words: It seems it got broken starting with v2.0.2 (as @BrianR stated).
@m5stack : please fix. Thank you.
Note: UART (id=0) is used for REPL connection and debugging, so not an option.
BTW: I've checked UART (id=1) on M5CoreS3 (UIFlow2.0.3 fw) and M5StampS3 (UIFlow2.0.3 fw) and both work ok.
Thanks
Felix -
RE: [Core Ink] Unwanted display refresh on startup
Hello @Spaghetto
the
RTC_Clock.ino
example I've provided ages ago (PR) got broken with the latest commits to theM5Core-Ink
library which now uses M5GFX library.You have two options:
- use the
RTC_Clock.ino
example as is, but with release version 0.0.7 of theM5Core-Ink
library which does not yet use M5GFX. - try my modified
RTC_Clock.ino
example which works with the latest version of theM5Core-Ink
library.
Thanks
Felix - use the
-
RE: M5Tough - RS-485 in Uiflow2
Hello @robski
you can use the blocks of the Modbus unit (with modified TX/RX pins) to control the internal Modbus interface.
Please see Play Zone example M5Tough_Internal_Modbus_ACSSR_UIFlow2.0.3.
Thanks
Felix