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.
Here is an example (Korean but you can using code, Simple Chat Server)
And I will publish this document in English as soon as possible. :D
I had the same problem. But I did decide to rename all my APs and every device connected. 30 minutes later, still can't get a device code, and it seems like it got stuck booting into the "Press next for instructions" screen, so I can't change the wifi if I wanted to :(
@heybin I’m sorry, I don’t understand why when you have it working for the stick and the stack. Looks like it’s time for M5Stack to build a UIFLOW port of the firmware for the camera. If you build it from the sicks firmware then half the work is done for you!
@mrtarantl said in Pinout of TFT display:
Thanks :D i am aware of that... I was searching for a pinout of this
The contacts are not damaged, it should be easy to solder it again on the board and it will probably work again...
Of course, if you have minimal soldering skills...
@ajb2k3 yes I did use the cooling module as well.
My thought was that there probably is some electrical interference when using the stepper and the servo module together. My solution in that case will be that i disconnect the mbus from the voltage regulator +wire completely to only power the steppers with the external power supply and do the rest with usb power to the m5Stack, so i am safe :D
Have the ezTimeLog example loaded up. It is printing lines at the bottom of the canvas, and shifting previously printed lines up, indeed just like a terminal screen watching serial output. I think I misunderstood the scrolling functionality as the ability to use buttons to go back through the history at the top that had already scrolled off the screen. I see in issue #24 you say "canvas.print creates a buffer in memory that stores every print until it has scrolled off the screen", so that's not the way it works - sorry for my confusion.
Indeed, creating menu items that don't do anything would be a possible solution. I tried that early on, but found that once the menu was drawn (or run), it merely sits and waits for buttons. I have not tried creating a function that does an .addItem, then runs the menu again, and run that function with an .addEvent. I'll give that a try as soon as possible. Is there a limit to the number of menu items, other than memory constraints? If I'm successful getting the "menu" to redraw, I'll let you know, and I guess I'll see what the limits might be!
Thanks so much, @rop, your work is very appreciated!!!
@lukasmaximus said in Button Unit Issue testing help please.:
I have tested the blocks associated with the single button unit and they definitely need some work.
Button press c shaped block only allows for a single press or release and the jigsaw shaped block
when combined with an if condition it throws an error that btn0_wasReleased or wasPressed is not defined.
These issues will be resolved in the next update and hopefully some extra functionality added.
Yeh, I was getting the btn0 is not defined error.
I've just taken several goes to write the firmware (I think my W7 laptop to blame).
It kept getting stuck in bootloader mode and wouldn't leave.
Finially got it to program and reset after pressing the on/off button twice.
Hi, We will put on sale a new product named "Bus" which is aimed for developers to expand I/O.
And here's the difference between with all cores. Maybe help you.
No, there was no COM-Port. As if it is not plugged or turned wrong around.
But as told, now it is ok. And i am glad it is. I like the M5s very much.
I still think, the capacitor solved it. But of course i am not sure.