@liamharrison3 yes. the 18650 is connected in parallel with the M5StickC internal battery.

I can't make it work with a USB-C to USB-C cable either (running on a MacBook Pro 16' with Catalina). Using a USB-C to USB-A hub works....

That has been the situation with the m5stack cores since the beginning, unfortunately. There have been some users on twitter that added a capacitor as a solution, but there is no official fix from m5stack on this issue. See this discussion: http://community.m5stack.com/topic/1161/m5stack-gray-reboots-when-usbc-power-removed

@crami25 said in EXT.IO Unit and UIFlow 1.4.5.1: I'm experimenting with M5Stack products (core, stick, atom matrix) and various I2C units (PbHUB, EXT.IO and Color) trying to use UIFlow and Blockly exclusively (instead of Arduino): As describet in the data sheets, all M5Stack I2C units have different fixed I2C addresses , PbHUB at 0x61, EXT.IO at 0x27. According to their M5Stack data sheets you can change the corresponding I2C addresses by modifying the address-pins of the EXT.IO unit PCA9554PW (0x20-0x27) or by flashing a new firmware to the PbHUP 328 microcontroller assigning any new I2C firmware address you want (0x00-7F) into the arduino code. By the way, I did that: flashing the firmware of the PbHUB to an arduino UNO. It worked and it behaved as a PbHUB in blockly. Showing that the communication between the master (M5Stack devices) and the slaves (PbHUB, EXT.IO) is working, I set up the simplest output experiment programming microcontrollers: letting a LED blink on output pin 1 of the slave (The basic Arduino "Hello Word" experiment): I hooked up a LED with a 470 Ohm protection resistor in serial between output 1 (IO1) and GND. The goal of my experiments was trying to set up the BLINK experiment in UIFlow/Blockly first using the "add UNIT" utility, later on using the I2C command of the advanced section of UIFlow/Blockly. I waned to use the latter beeing able hooking up grove type I2C sensors to port A of M5Stack masters, which are not (yet) available or defined for M5Stack block coding. One such application I'm working on, is the DS2482 I2C to onewire chip, which could be used to hook up the popular DS18B20 Sensor to all M5Stack devices having a I2C PortA using UIFlow blocks and connecting the sensors to the I2C PortA instead of using another M5Stack port mandatory forh the arduino or mycropython library. One wire devices also let you commuicate with sensors up to 1000m away, the maximum distance for I2C devices is only 100cm if you are lucky ! For my experiments, I flashed the newest UIFlow 1.4.5.1 to my M5Stack core (black). It allows you to do the debugging on its screen. I downloaded the UIFlow/Blockly programs by WiFi or USB (comx Port) . In these comments I will show you step by step how it worked programming the EXT.IO. The first step was to attach the EXT.IO unit to portA and with short UIFlow program acting as a I2C scanner. The results showed that the i2C bus and the EXT.IO unit were responding. I used label0 on the M5Stack display: The dsplay showed "(39, 117)", 0x27 and 0x75 in hex, equivalent to the I2C addresses of the EXT.IO unit and IP5306 IC are responding . Then I added the EXT.IO unit in Blockly without modifying the code above: Downloading the program I got following error code on the M5Stack core display: ERROR I2C bus error (-1) So apparently something went wrong! Looking at the micropython code I discovered, that adding the EXT.IO unit, in addition to the code scanning and displaying the I2C devices following line was added to the Python program: ext_io2 = unit.get(unit.EXT_IO, unit.PORTA) Because my previous experiments with the color hub and the PbHUB didn't show this behavior, I figured out, that there must be a bug in the unit.get(unit.EXT_io,unitPORTA) library used in UIFlow 1.4.5.1. I erased my M5Stack core with the M5Stack burner (in Windows 10) and reflashed the core with UIFlow 1.4.5 and reloaded the program. Running the program showed no errors and worked as expected. So the bug for the EXT.IO unit library is only in the new UIFlow 1.4.5.1 and not in the 1.4.5 library. After that, I could finish my "Hello World" IO Test as mentioned above writing following code: In the next step, I wanted to say "Hello"/Blink using the advanced I2C blocks you also can usecommunicating with I2C devices using only blocks in UIFlow. You communicate with the I2C devices using their addresses and putting data in the appropriate registers.Looking at the data sheet for the PCA9554PW chip present in the EXT.IO unit, I used following data: - Address : 0x27 - Configuration Register: 0x03 (ones for input zeroes for input) - Polarity Data Register: 0x02 (set to 0 by default, not used in this context)) - Output Data Register: 0x01 (I used this for output to the blink pin) - Read Data Register: 0x00 For my "Hello"/IO Blink at pin1 I had to set pin 1 of the PCA9554PW to an output in the configuration register (0x03), and the sending zeros(0x00) (Led off) and ones(0x01) (Led on) to the output data register(0x01). Here is my UIFlow code (for UIFlow 1.4.5): So far everything worked. I reflashed my M5Stack core with UIFlow 1.4.5.1 and I had no problem executing the code ("Hello" LED blinking) with the newest firmware. So the problem seems to be in the library ! I hope M5Stack will fix in the one of thenext updates (as well as with the color unit library, where I showed in another community blog how you could fix the readings of RGB using an appropriate UIFlow. Another feature I didn't like with the UIFlow I2C blocks is that you have to enter the adresses, registers and bytes as constant hex numbers into the advanced I2C blocks. It would be nice to use variables instead constants.I fixed this my way using the feature in UIFlow defining Execute blocks, where you can insert your own micropython code into custom created blocks. Looking at the block for the blink code: in micropython this translates to i2c0.write_u8(0x01, 0x01) I now added two variables <Led1off> and <Led1on> to tmy blocks, defined two execute blocks: code into the corresponding execute blocks: i2c0.write_u8(0x01, Led1off) and i2c0.write_u8(0x01, Led1on) Then setting <Led1off> to 0 and <Led1on> to 1 did the work. Here is the final code: You can also do some pretty"blocking" putting the IO commands in functions: Hope my contributions to the community were useful ! crami25 Excellent and very useful posting. I am also exploring the UIFLOW using M5 Cores (Fire, Stick-C, and Atom) with M5 standard Units and Hats. Previously I used Arduino IDE. I have a lot of questions, but the first one is related to your successful experiment result on flashing an Arduino UNO to behave as an PbHub: (1) Did you flash the UNO using Arduino IDE? (2) I suppose you connect the M5 core I2C port with the SDA and SCL of UNO to communicate, but how about the voltage difference between the M5 (3.3 V) and UNO (5.0 V)? Could you explain in more detail on this issue?

@lukasmaximus said in Ui Flow support for onewire and ds18x20: hey @fb24 onewire and ds18x20 are only supported in micropython version 1.12 uiflow micropython is based on version 1.11 if you are familiar with micropython I suggest you flash your M5Stack device with the latest micropython, I did a short video series on how to use M5Atom with micropython 1.12 and I will be doing some videos shortly on how to use other M5Stack devices with micropython 1.12 I am now using Micropython 1.12 BUT not on M5, but other ESP (bare) development boards. I managed to use the M5 Units and Hats connected to the ESP development board. My question is If I flash my M5Stack Fire or other M5 cores with the latest Micropython is there any python libraries for accessing the internal functionalities of the cores? For example the LCD, AXP? Another assumption is that we could not program the core with UIFLOW, isn't it?

Thanks! it works.

Can I power Atom from grove and ext pin also?

Solved it, it returns the result in Dec, and not in Hex, don't know if there is a way to convert DEC to HEX

Hi ajb2k3, thanks for your response. I found this thread that explain issue M5 Stickc Arduino samples - Temperature reading issue but i can not find any thread that report some solution, could you help me ?

Apparently this was caused by accidentally writing 0x0 to AXP192_DCDC13_LDO23_CONTROL which turned off DCDC1 which provides power to ESP32 chip. The behaviour I was seeing was normal boot and then the firmware turning DCDC1 off. I was able to revive the M5StickC by connecting G0 to GROUND and randomly doing short and long power button presses while trying to erase flash. After few tries erase flash command suddenly succeeded.

Hi again ajb2k3, I am not sure why but it does not seem to work with my set up. Here is the code I am using for the stickC to trigger camera. Where would I put the code you suggested? Thanks in advance! #include <M5StickC.h> #include <BlueMagic32.h> #define LED_PIN 10 #define TRIGGER G0 void setup() { M5.begin(); Serial.begin(115200); pinMode(LED_PIN, OUTPUT); digitalWrite(LED_PIN, HIGH); BMDConnection.begin("BlueMagic32"); BMDControl = BMDConnection.connect(); M5.Lcd.setTextColor(TFT_WHITE); M5.Lcd.setTextSize(2); M5.Lcd.setRotation(3); M5.Lcd.fillScreen(TFT_BLUE); } void loop() { // read data int value = digitalRead(36);// read the pin(0: not detectd 1: detected) M5.update(); if (M5.BtnB.wasPressed()) { ESP.restart(); } if (BMDConnection.available()) { M5.Lcd.drawCentreString(BMDControl->timecode(), 80, 34, 2); if (M5.BtnA.wasPressed()) { BMDControl->toggleRecording(); } if (BMDControl->isRecording()) { M5.Lcd.setTextColor(WHITE); digitalWrite(LED_PIN, LOW); } else { M5.Lcd.setTextColor(TFT_GREEN); digitalWrite(LED_PIN, HIGH); } M5.Lcd.fillScreen(TFT_BLACK); } if (M5.BtnA.wasPressed()) { BMDControl->toggleRecording(); } if (BMDControl->isRecording()) { M5.Lcd.setTextColor(RED); digitalWrite(LED_PIN, LOW); } }