@crami25 Thanks for the comprehensive reply. It really helps to deepen my understanding. As you pointed out, I always check the M5 Unit's schematic first to assure the protective resistors when I connect the Units to an ESP developing board.
Posts made by liemph
RE: M5StickC + 18650C (HAT external battery) BAT pin
@m5stack This means that when the Stick is plug to the 18650C accessory, the 18650C accessory will not charge the internal battery?
RE: EXT.IO Unit and UIFlow 188.8.131.52
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 184.108.40.206 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:
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 220.127.116.11. 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 18.104.22.168 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 22.214.171.124 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
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
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 !
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?
RE: 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?
RE: Issue with Port C (UART) of M5Stack Fire (Finger unit OK but GPS No Good)
@liemph Try connecting the m5stack to a pc and opening a terminal connecting to the M5Stack.
the terminal may show more information.
I took the log file by using teraterm serial monitor program. I did not see any valuable information for debugging. This is the results:
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
mode:DIO, clock div:1
ho 0 tail 12 room 4
ho 0 tail 12 room 4
I (32) boot: ESP-IDF v3.3-beta1-696-gc4c54ce07 2nd stage bootloader
I (32) boot: compile time 19:36:27
I (32) boot: Enabling RNG early entropy source...
I (38) boot: SPI Speed : 80MHz
I (42) boot: SPI Mode : DIO
I (46) boot: SPI Flash Size : 16MB
I (50) boot: Partition Table:
I (54) boot: ## Label Usage Type ST Offset Length
I (61) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (69) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (76) boot: 2 factory factory app 00 00 00010000 001f0000
I (83) boot: 3 internalfs Unknown data 01 81 00200000 001ff000
I (91) boot: End of partition table
I (95) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0xe970c (956172) map
I (379) esp_image: segment 1: paddr=0x000f9734 vaddr=0x3ffbdb60 size=0x034dc ( 13532) load
I (383) esp_image: segment 2: paddr=0x000fcc18 vaddr=0x40080000 size=0x00400 ( 1024) load
I (386) esp_image: segment 3: paddr=0x000fd020 vaddr=0x40080400 size=0x02ff0 ( 12272) load
I (398) esp_image: segment 4: paddr=0x00100018 vaddr=0x400d0018 size=0xdbea8 (900776) map
I (662) esp_image: segment 5: paddr=0x001dbec8 vaddr=0x400833f0 size=0x12bf8 ( 76792) load
I (688) esp_image: segment 6: paddr=0x001eeac8 vaddr=0x400c0000 size=0x00064 ( 100) load
I (688) esp_image: segment 7: paddr=0x001eeb34 vaddr=0x50000000 size=0x00808 ( 2056) load
I (708) boot: Loaded app from partition at offset 0x10000
I (709) boot: Disabling RNG early entropy source...
I (709) cpu_start: Pro cpu up.
I (713) cpu_start: Application information:
I (717) cpu_start: Compile time: Mar 13 2020 19:36:49
I (724) cpu_start: ELF file SHA256: 0000000000000000...
I (730) cpu_start: ESP-IDF: v3.3-beta1-696-gc4c54ce07
I (736) cpu_start: Starting app cpu, entry point is 0x400836e4
I (0) cpu_start: App cpu up.
I (746) heap_init: Initializing. RAM available for dynamic allocation:
I (753) heap_init: At 3FFAE6E0 len 0000F480 (61 KiB): DRAM
I (759) heap_init: At 3FFCB2C8 len 00014D38 (83 KiB): DRAM
I (766) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (772) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (778) heap_init: At 40095FE8 len 0000A018 (40 KiB): IRAM
I (785) cpu_start: Pro cpu start user code
I (131) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Internal FS (FatFS): Mounted on partition 'internalfs' [size: 2093056; Flash address: 0x200000]
Filesystem size: 2031616 B
Used: 1605632 B
Free: 425984 B
I (359) [TFTSPI]: attached display device, speed=8000000
I (359) [TFTSPI]: bus uses native pins: false
W (534) sdspi_host: spi bus changed (1 -> 2)
E (577) sdmmc_sd: sdmmc_init_spi_crc: sdmmc_send_cmd_crc_on_off returned 0x106
[ M5 ] init sd card Fail
[ M5 ] node id:<deleted>, api key:<deleted>
I (2018) uart: ALREADY NULL
Please note that I deleted the node id and api key.
RE: Issue with Port C (UART) of M5Stack Fire (Finger unit OK but GPS No Good)
@liemph do you get an error message or just no response?
Your question alerted me. I used the GPS example provided by M5 for UiFlow. The LCD showed that the Time is 00:00:00, no data in Lattitude and Longitude, the Quality showed NO Signal. I tested it at home (inside my house). So is it possible that I have to look for a better place to get a stronger signal? However other devices using GPS work well inside my house.
Issue with Port C (UART) of M5Stack Fire (Finger unit OK but GPS No Good)
I am aware that there is an issue related to the UART port (Port C) of M5Stack Fire. However, using the UIFlow (1.4.5) I managed to connect and program the Finger unit normally. However, with the GPS unit, I failed to make it work. I do not understand why for the core works with the Finger unit but not with the GPS (same Port C).
How to get the magnetometer values from M5Stack Fire by UIFlow?
I am new to UIFlow. I managed to get the gyro, acceleration, and YPR with the UIFlow. I remembered that using the Ardunio IDE I could get in addition the x, y, z directions of the magnetometer in the M5Stack Fire. Why couldn't I get the same parameters with the UIFlow?
How to use two ENV units with PaHUB (UIFlow)
I am new to UIFlow and need your guidance.
I managed to get temperature, humidity, and pressure for a single ENV unit directly connected to my M5Stack Fire (Port A) using the UIFlow.
Next, I have a PaHub and two ENV units. I connect the first and the second ENV unit to the port 0 and port 1 of the PaHub. I checked and tried to understand the Pa.HUB UIFlow example provided by the github (Pa.HUB.m5f). But still I could not understand how to proceed from the example to my goal, that is reading the two ENV units sequently. Please help!