We already discussed this topic 7 months ago in
=> 5V input concern on M5StickC :
where I posted my first comment in the M5Stack community blog.
Here are some additional explenations:
If you look at the schematics for M5Stack modules and units using Atmega 328 slaves:
-> All Atmegas 328 are powered by 5V Vcc.
-> The Makey unit, the Joystick unit and the Servo Module use 470 Ω resistors between the SCL/SDA lines and the corresponding grove connector or the SCL/SDA lines M5Stack_BUS (pin 18/GPIO22 and pin 17/GPIO21, common standard for the ESP32).
-> In the pbHUB 328 SCL/SDA are connected directly to the grove connector (red) without the protecting in series resistors.
In normal cases connecting 5V devices and 3.3V devices communicating via the I2C bus without protection causing no problems (bricking the ESP32) can be explained how I2C communication works:
If you connect a pin of a 5V device (eg the 328) defined as an output and as high (1) to an output pin of a 3.3 V device (ESP32) defined as low(0), the 3.3V device tries to sink the current. The maximum current the ESP32 can sink is only 12mA (https://esp32.com/viewtopic.php?t=2384). The maximum output current the 5V-328 can provide 20mA and more. If the current is higher, the output Voltage will drop. Each condition is more than an otput pin of the ESP32 can sink. So the possibility bricking parts of or the whole of the ESP32 is high. Connecting a 470 Ω resistor between the to pins limits the worst case current to 8mA, which is safe for both devices in case of bad programming: It's also good practice connecting the "hello world" blinking led using a current limiting resistor to Vcc or GND in order to avoid stress on the diode (you don't now how much max current it can draw) or the output pin (you don't know how much max current it can provide. There are also some bad examples sticking the LED directly into the UNO header between IO13 and GND! https://github.com/LequiosCreative/arduino-blink-led ).
On an I2C communication bus you normally only have one master and one or more slaves. The master always has the command on the I2C bus: It clocks the SCL line (Clock line) using a pin as an output. The SDA line is used transferring commands and datas to and from the slaves. At the beginning of a transmission the master sends an address and the appropriate commands to a slave and the SDA pin of the master is set as an output. If the master expects datas transmitted from a slave after sending a "read input values" command, the master switches its pin for the SDA line to an input allowing the slave sending data over the sda line switching its SDA pin from an input to output. So, under normal conditions, the SDA lines of the master and the slave, if the protocol is implemented correctly, never should be simultaneously configured as outputs.
So good practice would be to insert 470 Ω resistors in the SCL/SDA lines as also recommended in the I2C hardware specifications. Thank you for your question. From now on I will always use my 328s (plain 328, UNO, micro, mini, attinys 85/86/861) communicating on the I2C bus with ESP82/8266 devices using the protective resistors. Comment: According to the I2C protocol, a slave is allowed to pull the clock line low if the slave isn't ready sending data, overriding the master SCL line ! In this case there would be a problem for master/slaves combination communicating on different voltage levels.
Suggestion to M5Stack team: I opened the PbHUB hub and found the two 103 SMD (10 kΩ)
pullup resitors connected to the SCL/SDA lines but nowhere any 470 SMD (470 Ω) resistors on their printed circuit board. So it seems that their schematic is correct ( https://docs.m5stack.com/#/en/unit/pbhub). In my opinion, in their future designs they should add the protective resistors recommended as they already have implemented in their other hubs and modules using the Atmega328 as an I2C slave.
Add: You can find a better explanation how the I2C communication works here : https://howtomechatronics.com/tutorials/arduino/how-i2c-communication-works-and-how-to-use-it-with-arduino/
Add2: If You want to build an I2C arduino slave from scratch, here is step by step tutorial:
You can use your M5Stack device instead of the RasPi.
In their example, they are connecting the UNO 5V I/O pins without protecting resistors and pullup resistors (as I did) directly to the RasPi so called "non 5V tolerant 3.3V" GPIO pins ! But they drew the same conclusions as I did above:
""You should really pay attention when you connect 2 pins between those boards. Usually you’d have to use a level converter between 3.3V and 5V. But in this specific case we can avoid using one.
If the Raspberry Pi is configured as a master and the Arduino as a slave on the I2C bus, then you can connect the SDA and SCL pins directly. To make it simple, in this scenario the Raspberry Pi will impose 3.3V, which is not a problem for the Arduino pins.""
Thanks for the reply. Got the Arduino library example to work. Looking forward to a UIFlow fix. See my review at: Another Uncontrollable Bug: BugC from M5Stack: https://www.facebook.com/thomas.andrews.357/media_set?set=a.2587374321367103&type=3
You should charge your battery to full. Do you tried to calibrate your sensor?
Press and hold the right C key to start the machine, and release the key after hearing the "drip" sound. The sensor will enter the calibration setting, and keep the host horizontal and still. After 3 seconds, the sensor calibration is completed, and it will automatically enter the balance mode after the calibration is completed.If you found that Bala cannot keep balance during use, it can be solved by trying to calibrate the sensor.
@kurthofman said in UIFlow : Units are not available:
I'm using M5 Fire with firmare 1.0.3 in Chrome.
The update sorted out a minor bug with the Unit box but the ones with the blue symbol over them are not working yet.
iIRC I seam to remember something on one of the Esp32 forums with a similar issue. I think it was something to do with bus clock speed issue. I think it was down to the clock being set to high for the psram.
@jpilarski said in issue with remote in 1.0.3:
Nice work on the adc, iic, and on adding more unit blocks. Unfortunately it looks like there are issues with the remote blocks. They look to be overlapping on screen and make it difficult to properly select remote blocks.
What web browser are you using to load UIFlow as it worked fine for me.
@felix42eu said in Hardware Variantion and Firmware Compatibility:
OK, I did not know that arduino was not fully supported. thanks.
is m5go and m5fire a different product? I do not think so.
where are the sources of the versions located if they are open source? or do you mean the binaries are free (I found them in the M5burner replease)
The espressif idf is a topic which I have too look deeper into.
All sources, documents and specs are found on github.
Some of the docs are a little out of date though.
some of the "grove connection" units are found on the seeedstudio grove website.
In your reply above you mentioned firmware 1.0.1 for the stick but in the M5-burner download it only has version 1.0 of the uiflow firmware for the M5stick. Can you please verfiy which firmware is the most recent. Also will the MPU9250 work with the M5stick in uiflow. thanks
Thanks this is helpful to see. Much appreciated. I still think it would be great at some point for you to add a section to the uiflow documentation that covers the blocks located under the advanced tab.
thanks it works great used this library
and this basic code to test
from machine import I2C, Pin
i2c = I2C(0, sda=21, scl=22)
sensor = tcs34725.TCS34725(i2c)
@jpilarski said in makey:
I am having some difficulty understanding the makey unit. I can make it beep if I put one end of a wire in the LED pin and touch other end of the wire to various pins. I get some sounds playing through the m5stack speaker and some on the makey's buzzer. Why are there multiple pins with the same number. Should I be able to just touch the pins with my hand and register a touch. Also can you explain how to use this device in UIFLOW. Again I can get a few beeps from the makey using UIFLOW but I'm not sure I understand the pins to use or how to work with the makey blocks. It did make some great beeps and I am excited to use. Last question is does the firmware on the mega328 ever need to be updated. thanks
This is the biggest issue that takes getting used to when moving from Atmega to esp32. The Atmega's pins are "Set function" in arduino however the esp32 using a mux controller to control the pins resaulting in a matrix of multi function I/O pins that need to have functions set in code.
I would like to request that color is defined in the blocks in a way that allows the user to select one of 2 color block options
you can add color by using a general color swatch selector like you have currently on most blocks
you can add an RGB block that allows color to be treated as variables.
I feel like these two color options should be broken out as two color blocks that can be added onto the blocks as needed. Currently you have color broken out as three variables in some of the ui blocks but in none of the graphics blocks and this is limiting. What I am suggesting is all tools requiring color require the user to add on a color block and the color block can be one of these two types (color swatch, or RGB variables). I think this can help make the interface cleaner since you don't have to have all these redundant blocks but rather a single block with the option to select how color is to be defined. This gives the user way more programming options since they can opt to use a swatch when needed or to use RGB number values or variables if needed.
Also I think you need a list block to define the length of an array. It would also be great to have a block for list pop.