Hello @sedir
you can use the RGB blocks (in Hardware) to control the 10 RGB LEDs in the M5GO3 Bottom.
UIFlow2 Project Zone example: M5CoreS3_M5G03Bottom_RGB_UIFlow2.0.4
Thanks
Felix
Hello @sedir
you can use the RGB blocks (in Hardware) to control the 10 RGB LEDs in the M5GO3 Bottom.
UIFlow2 Project Zone example: M5CoreS3_M5G03Bottom_RGB_UIFlow2.0.4
Thanks
Felix
Hello @taunushexe
the list blocks can be used for that. See example in UIFlow2 ProjectZone: M5Dial_Get_Values_From_Tuple_UIFlow_2.0.4
Thanks
Felix
Hello @seungmin
I wonder if the issue is only a too dark screen backlight setting? I created an UIFlow example which simply sets the screen backlight to the maximum. Does that help?
ProjectZone: M5DinMeter_BacklightSetFullBrightness_UIFlow2.0.4
Thanks
Felix
Hello @BrianR
that is not what I am seeing. With M5Dial UIFlow firmware v2.0.4--hotfix my GPS example in the Project Zone runs just fine. M5Dial_GPS_Unit_UIFlow2.0.2
Edit: Just double-checked:
Thanks
Felix
Hello @teastain
do you mean the GI (capital I for In) and GO (capital O for Out)?
That said, I think the strict one input and one output on port B is coming from ESP32 cores which would use one GPIO that actually only can be an input.
However the S3 variant doesn't seem to have this limitation anymore.
As I reported before I can set GPIO1 and GPIO2 of my M5Dial both to outputs and use them just fine.
And even if one or both of them are set as input in UIFlow firmware that should not prevent one from changing that in the user program. (Unless it is set as an input repeatedly in the UIFlow firmware.)
Note: I have not tested the same (both outputs) with an Arduino program.
Thanks
Felix
Hello @taunushexe
as @ajb2k3 mentioned only one GPIO (the second one) is used for the RGB unit. So the other GPIO can still be used as input. I created an example which uses GPIO1 as input to control the color of the three RGB LEDs in the RGB unit.
See UIFlow2 Project Zone : M5Dial_RGBUnit_GPIO1_as_input_UIFlow2.0.4
Thanks
Felix
Hello @ToughBJH
I tested with v2.0.3 and v.2.0.4--hotfix firmware and with either firmware GPIO1 and GPIO2 act independently.
BTW: v2.0.3 firmware has been built on 2024-03-21 whereas firmware v2.0.4--hotix has been built on 2024-04-16. The fact that both report 2.0.3 is probably just an oversight.
Not sure where to go from here. I'd say your M5Dial might have a hardware issue, but since your seeing it on both your M5Dials that seems a bit far fetched.
At this point in time I am out of ideas, sorry.
Thanks
Felix
Hello @ToughBJH
that is not what I am seeing. Please have a look at the UIFlow ProjectZone example M5Dial_PWM_GPIO1_GPIO2_UIFlow2.0.4.
It controls GPIO1 and GPIO2 independently. I verified it with the multi-meter and two LEDs (plus resistor).
Thanks
Felix
Hello @ToughBJH
in UIFlow2.0.4 after enabling PWM hardware I can add two Init Pin blocks, one for GPIO1 and one for GPIO2, set duty values for each and using a multi-meter I can confirm that both output the respective voltage.
Thanks
Felix
Hello @icemen267
here is a possible solution to use GPIO25/5 V/GND pins of the M5Atom to connect the RGB LED unit. You'll need some Groove2Dupont (M) cables for that.
===\----~~~
-- wh ------ > |
GPIO25 o ------ ye ------ > | S
5 V o ------ re ------ > | +
GND o ------ bl ------ > | G
===/----~~~
M5Atom Groove2Dupont(M) RGBLEDUnit
UIFlow2 Project Zone example: M5AtomLite_RGBLEDUnit_GPIO25_UIFlow2.0.4
Thanks
Felix
Hello @actuar
well there is different behavior regarding program flow after waking from deep sleep vs waking from light sleep.
After waking from deep sleep the program flow is (re-)started from the top. Which looks like a restart as it actually is a restart.
After waking from light sleep the program flow continues and does not restart.
Thanks
Felix
Hello guys
I just noticed that the internal PbHub unit v1.1 firmware has been made available. Thanks M5Stack engineers.
The new internal firmware version (v2) resolves the RGB issue and I am now able control more than just the first RGB LED.
You'll need an ST-LINK to flash the provided pbhub_v11.hex
file onto your PbHub unit v1.1. (I used the built in ST-LINK of this stm32 nucleo board.)
After flashing the new firmware it should report version to be 2.
Thanks
Felix
Hello @mcolan
according to the SAM2695 datasheet used in Unit-Synth MIDI_IN
is a 5 V tolerant input.
Thanks
Felix
Hello @jarkman
I assume you already have PSRAM enabled in your build, yes?
BTW: Not sure why but changing the frame_size from FRAMESIZE_QVGA to the camera native FRAMESIZE_QXGA helped a lot.
Thanks
Felix
Hello @flex
I can confirm that using init gps block with init BLE uart client block results in a crash. Tested with M5StickCPlus UIFlow2.0.4 firmware.
Note: when I add a 5 second delay in between the two init block I do not see a crash. However I did not confirm whether GPS or BLE still works.
Thanks
Felix
Hello @icemen267
no, the signal for the RGB stips is very specific - nothing else can be daisy-chained after them.
Maybe you could use some other pin of the M5Atom for the RGB strips? The you would have the Groove port free for the buzzer etc.
Thanks
Felix
Hello @icemen267
I don't think there is an update regarding PbHub v1.1. It would need an internal firmware change.
I don't have a lot of experience with LED strips, but I think you should be able to daisy-chain the two RGB strips, e.g. connect one directly to the core and the second to the first.
No, the TypeC2Grove Unit would help with powering the LED strip directly, e.g. not through the core, but it doesn't change the fact that current PbHub v1.1 firmware only supports one RGB LED.
Thanks
Felix
Hello @icemen267
please see this thread. It's a limitation / oversight of PbHub unit v1.1
Thanks
Felix