Hat does not work (G26, G0) when I connect USB with code with MU.
fraramon opened this issue · 13 comments
Hello, I have looked for a good code editor like MU to write my python code and I have been surprised that when I connect my M5StickC Plus to RoverC and connect USB the I2C (G26, G0) is lost.
In this way it is impossible to work. Working with blockly is not serious for me, I need to edit code with MU or another python code editor.
Can somebody help me. Thanks for all the help.
Hello, make sure your device is setup on USB mode then install vscode (visual studio code) and install the following addon: https://marketplace.visualstudio.com/items?itemName=curdeveryday.vscode-m5stack-mpy
using visual studio code you should be able to access your device, read and write code without problems.
Hi @fraramon
using @Zontex 's instructions I am running the below I2C scan code (uploaded via connected USB) and it successfully detects an attached ToF hat. I assume RoverC will be detected as well. (I cannot test as I don't own one.)
from m5stack import lcd
from machine import I2C
lcd.clear(0x000000)
lcd.orient(3)
#i2c = I2C(freq=400000, sda=21, scl=22) # scan internal I2C devices
i2c = I2C(freq=400000, sda=0, scl=26) # scan hat I2C devices
devices = i2c.scan()
if len(devices) == 0:
lcd.text(0, 0, "no i2c dev found", 0xFF0000)
else:
lcd.text(0, 0, "i2c dev found: " + str(len(devices)), 0xFF0000)
y = 1
for device in devices:
lcd.text(0, y * 20, str(hex(device)), 0xFF0000)
y = y + 1
Could you elaborate about how you figure out that I2C is lost? Care to share your code?
Thanks
Felix
Hello, thank you very much for your answers. When working from (visual studio code and USB mode) it does work, but it has the disadvantage that every time I run the program I have to reset the device and debug with pymakr, it is also difficult because I have to connect and disconnect it if I don't want to. have locks. However when I work with MU everything works perfectly there is no type of blockage, the workflow is perfect (That is if it works in APP mode), but it has the problem that the I2C port (G26, G0) disappears.
If you want to do the test with MU. You have to put the device in (APP mode), after installing MU go to the file editor and open the folder C: \ Users % user \ AppData \ Local \ Mu \ Paqs \ mu \ modes and open the esp.py file . Find the valid_boards block in the file and add one more line.
valid_boards = [
# VID, PID
(0x1A86, 0x7523), # HL-340
(0x10C4, 0xEA60), # CP210x
(0x0403, 0x6001), # CH552
(0x0403, 0x6015), # Sparkfun ESP32 VID, PID
]
Hello @fraramon
Same I2C scanner code I've posted above works fine for me using MU (after adding the missing line to valid_boards - thank you for the hint) and the device in app mode. I can scan the internal bus getting 3 devices or the hat bus and getting one device (if one is attached). What do you get when scanning the internal bus? Hat bus?
Thanks
Felix
Hello, thank you very much for your code, felmue, effectively making use of the I2C class, the ROVERC port and address appears in both USB and APP mode, but the problem is that the "hat.get (hat.ROVERC)" function uses the i2c_bus class internally and this one does not get the data well, it works only on USB mode. I think the problem is not hardware, the problem is software.
from m5stack import *
from m5ui import *
from uiflow import *
import i2c_bus
import time
import unit
import hat
setScreenColor(0xF11111)
# 0x38 is address of HAT ROVERC
# In this way you always get the I2C well (USB Mode,APP Mode)
i2c1 = I2C(freq=400000, sda=0, scl=26)
print(i2c1.is_ready(0x38))
# In this way only I2C is obtained well (USB Mode)
i2c2 = i2c_bus.easyI2C((0,26), 0x38)
print (i2c2.available ())
# When a reference to the hat is obtained, internally, it use i2c_bus.easyI2C
hat_roverc0 = hat.get(hat.ROVERC)
I've done so many tests that I don't know what else to do.
My conclusion is that the hat are not well implemented in APP mode due to a software or initialization problem that M5Stack will know about.
If you have any more ideas I can do, thanks for all the help.
Hello @fraramon
If I run your code (using app mode and a ToF hat) I get the same results. The first method (I2C class) detects the hat all the time, the second one (Easy I2C) not. But I think that's because your code currently tries to initialise two I2C instances both using the same pair of pins.
If I run below code (after rebooting the stick) which only uses the easy I2C method the ToF hat is detected every time:
import i2c_bus
# 0x29 is address of HAT TOF
ToF = i2c_bus.easyI2C((0,26), 0x29)
print (ToF.available ())
Cheers
Felix
Hello @felmue
If you run this last code that you have sent me from MU, does it work?
import i2c_bus
# 0x29 is address of HAT TOF
ToF = i2c_bus.easyI2C((0,26), 0x29)
print (ToF.available ())
Hello @fraramon
yes, that code runs fine for me from MU, device set into app mode, ToF hat is detected every time I run it.
Thanks
Felix
Hello @felmue
It does not work for me. Something happens with the HAT ROVERC that does not work :)))).
import i2c_bus
# 0x38 is address of HAT ROVERC
RoverC = i2c_bus.easyI2C((0,26), 0x38)
print (RoverC.available ()) # False
print (RoverC.i2c) # I2C device: 1, I2C(1, scl=26, sda=0, freq=400000)
I have given you the results they give me, could you give me yours ...
Sorry for so much trouble ...
And thank you very much for everything ...
Hi @fraramon
sure, here are the results with ToF hat (I don't have a RoverC).
import i2c_bus
# 0x29 is address of HAT TOF
ToF = i2c_bus.easyI2C((0,26), 0x29)
print (ToF.available ()) # True
print (ToF.i2c) # I2C device: 1, I2C(1, scl=26, sda=0, freq=400000)
BTW: Have you tried another I2C device besides the RoverC?
Thanks
Felix
Hello @felmue.
I have the HAT JoyC and the same thing happens to me.
As a curiosity, see what data it gives me.
from machine import I2C
i2c1 = I2C(0, scl=26, sda=0, freq=400000) # False
print (i2c1.is_ready (0x38))
i2c2 = I2C(1, scl=26, sda=0, freq=400000) # False
print (i2c2.is_ready (0x38))
i2c3 = I2C(freq=400000, sda=0, scl=26) # True
print (i2c3.is_ready (0x38))
i2c4 = I2C(freq=400000, sda=0, scl=26) # True
print (i2c4.is_ready (0x39))
i2c5 = I2C(freq=400000, sda=0, scl=26) # True
print (i2c5.is_ready (0x40))
Thanks
Francisco
i was having issues with using GPIO0 as an IO pin as well, and bumped into this thread. not sure if you got to the bottom of this, but looking at the schematic i see that GPIO0 is attached to UART_GP0_CTRL of Serial-USB chip. i haven't looked into what "USB mode" does on the m5stack but my guess is that it makes use of the control lines in addition to RX/TX of the USB serial device for some signaling? could this potentially cause the interference of the pin?