Posts made by felmue

Hello @daniel-edge456

in UIFlow2 v2.2.6 using touch blocks for M5Paper and then look into the Python tab I get the following code to get touch coordinates:

if (M5.Touch.getCount()) > 0:
  x = M5.Touch.getX()
  y = M5.Touch.getY()

doing the same with power blocks I get:

Power.deepSleep(1000, True)

to put M5Paper into deep sleep.

Thanks
Felix

Hello @huanfai

looking at the soucre code for UIFlow2 device firmware I think authentication keys are fixed to default values. See here and here.

In ohter words I don't think the RFID blocks in UIFlow2 can handle anything different than default authentication keys.

Thanks
Felix

Hello @oracle_sod

ok, I see, the DFRobot version has an UART interface. M5ExtIO2 GPIOs can be set to multiple modes (input, output, ADC, servo, neopixel and PWM) but I am afraid none of these modes can be used for an UART connection.

According to the wiki page RX is used to select the mode, this could be achieved via M5ExtIO GPIO set as output.

However the TX line sends data with 9600 Baud, which I doubt M5ExtIO2 can handle.

That said, what is the reason you don't connect all three Ultrasound units directly to the M5Core? That would require 6 GPIOs.

And if you could live with the fact that all three Ultrasound units use the same mode you could get away with only 4 GPIOs, 1 GPIO to select the mode for all three units, and 1 GPIO for each unit to receive the UART data.

Thanks
Felix

Hello @oracle_sod

Note: I don't have the UltrasonicIO unit so my conclusions might be inaccurate.

Looking at the Arduino code, I see it uses a function called pulseIn() which does some sort of timing. I doubt it exists on the EXTIO2 unit so you would have to emulate this functionality yourself.

BTW: I think an easier setup would have been a PaHub unit with three Ultrasonic (I2C variant) units connected to it.

Thanks
Felix

Hello @Robertof

hmm, using variables in MQTT publish works for me.

How are you testing your code? Make sure your test software uses a different MQTT client id than your UIFlow2 code, else the first registered client gets kicked out.

BTW: my example is in the Project Zone, named M5CoreS3_MQTT_4Relay_UIFlow2.2.5

Thanks
Felix

Hello @lenswerks

afaik Unit CatM GNSS (U137) uses a SIM7080G which can not use both, a LTE and GNSS, at the same time due to some shared RF circuitry.

See this posting on Stack Overflow.

Thanks
Felix

Hello guys

some ideas for the next version of M5StamPLC:

1. switchable 5 V on Grove ports
2. switchable 5 V on extension port
3. LED indicators for the relays
4. LED indicators for the inputs

Notes for 1.: the existing ICs can be used by connecting output (P3) of (U5 PI4IOE5V6408) to the enable (EN) of (U4 LPW5209AB5F) instead of having EN tied to SYS_5V.

Notes for 2.: the existing ICs can be used by connecting output (P1_0) of (U4 AW9523B) to the enable (EN) of (U8 LPW5209AB5F) instead of having EN tied to PMU_5V.

Thanks
Felix

Hello @Krmiller

GetVBusVoltage() exists in M5Core2 library as well. See here.

Thanks
Felix

Hello @Krmiller

have you tried getType() to determine the correct AXP? See here.

For AXP2101 you could try getVBUSVoltage. See here.

Thanks
Felix

Hello @iainmac

you probably need to adjust the GPIOs used for I2C. You can find the GPIOs M5Dial uses for port A here. (Section HY2.0-4P)

Thanks
Felix

Hello @DR_Froggy_rD

I am afraid that doesn't work. A PaHub is for i2C devices (red Grove connector); the PDM unit is an I2S device (white Grove connector).

BTW: that is the reason in UIFlow2 PaHub doesn't show as option when the PDM unit selected.

Thanks
Felix

Hello @rammelsberg

I don't see solder jumpers and I cannot find the source code for the firmware running in M5GoPlus2 so no, I don't think you can easily modify the I2C address.

Thanks
Felix

Hello @s1y99

ok, now I understand - thank you for clarifying about the closed source M5Core firmware.

BTW: for RST and IRQ you could set no jumper and then solder a wire each to the desired GPIO on the M5Stack bus connector.

Thanks
Felix

Hello @s1y99

I am confused. Your own firmware, the one you write for your M5Core (which talks to the LoRa module), is closed source? How come? Are you not writing your own firmware?

I already wrote that it is not possible to jumper LoRa V1.1 the same as the older one, please see my previous post.

MOSI, MISO, SCK and CS/NSS can be setup to use the same GPIOs, however RST and IRQ cannot be jumpered to be the same.

So in conclusion: If for whatever reason the firmware running on M5Core (controlling the LoRa module) cannot be modified then it is not possible to substitute the older LoRa module with the new one.

Thanks
Felix

Hello @RadghKris

I think it might help to include epdiy.h before Unified.h in your code. E.g.

#include <epdiy.h>
#include <M5Unified.h>

Please see this post.

And maybe also check this documentation - Section 6.Program Compilation & Burning.

Thanks
Felix

Hello @drbob

my example should give you a head start. Please have a look here.

Thanks
Felix

Hello @rammelsberg

well, there is an I2C address conflict between M5CoreS3 Touch and M5GoPlus2 as both use I2C address 0x38.

Interestingly when I use M5CoreS3 with M5GoPlus2 in UIFlow2 I can control a servo and use the touch screen. However this is only true for servo 1,2 and 4. When I try to use servo 3 the system locks up.

Note: I have not tried to control DC motors.

So I'd expect some issues and do not recommend to use M5GoPlus2 with M5CoreS3.

Thanks
Felix

Hello @JensH

please check my example in UIFlow2 Project Zone: M5Paper_WLAN_Test_UIFlow2.2.5

Thanks
Felix

Hello @turgu

FWIW: in M5PaperS3 the eInk display is directly controlled by ESP32S3.

In M5Paper the GPIO WaitBusy() checks is GPIO27 which comes directly from IT8951 so I guess if the line never goes HIGH either IT8951 is not (properly) powered or defective.

Anyhow, have you tried to change the code to ignore the busy state of IT8951; maybe add some small delay instead.

BTW: I measured GPIO27 and when M5Paper is running it's being pulled up. I don't see a pull-up resistor in the schematics so I guess IT8951 is pulling it up (when not busy).

Thanks
Felix

Hello @KamilB

I do not have the hardware to test this myself, but I think you might want to pull GPIO12 HIGH to make sure you're talking to BMI270 only. See here.

Thanks
Felix