Hi guys
an M5CoreInk with ESP32 in light or deep sleep still consumes a couple of mA (which is to be expected given the hardware architecture). However M5CoreInk allows to shutdown ESP32 completely and later wake it up from the RTC timer or alarm.
For an M5CoreInk in shutdown mode I've measured a current (at the battery) of only about 2.5 uA which is pretty good. And yes, the ink display retains the last image.
Cheers
Felix
Hello @m5stack
thank you for letting us know about the latest UIFlow 1.7.3 firmware. I appreciate it.
It is however very unfortunate that the M5Core2 PaHub bug has not been addressed in this update. I'd appreciate if your engineers fix that bug in the next update.
Or, as stated already many times in many places, please open source the UIFlow code so we can help you fix issues like that.
Thank you for listening.
Felix
Hi guys
Here is an explanation as to why it may take some time to fix: M5CoreS3 uses the SPI bus in a special way to control the LCD: MISO (normally an input) is reconfigured to be an output and is used as DC line (instead of a dedicated GPIO for DC). Unfortunately to access the SD card (which shares the SPI bus with the LCD) MISO needs to be an input.
In case you might be interested. I found a way to do this switching back and forth between input and output for Arduino.
Thanks
Felix
Hi guys
I've started to code a simple touch keyboard. I am still experimenting but I thought I'll share what I have so far.
You can find more pictures here: https://www.gwendesign.com/kb/m5stack/m5core2/#simple-touch-keyboard
You can find the code here: https://github.com/felmue/M5Core2/blob/fm-touch-keyboard-1/examples/Basics/keyboard/keyboard.ino
Happy Stacking!
Felix
Hi Van
you're very welcome. I don't have a partition map and so far I didn't need one. For the additional PSRAM I've added these two lines for M5Core2:
build_flags =
-DBOARD_HAS_PSRAM
-mfix-esp32-psram-cache-issue
(I am not sure if the second line actually is really needed still, but it doesn't seem to hurt.)
Cheers
Felix
Hi Van
you could try to define two environments and use lib_ignore to only compile one of the two libraries, depending on the selected device:
[platformio]
default_envs = m5stack
;default_envs = m5core2
[env:m5stack]
platform = espressif32
board = m5stack-core-esp32
framework = arduino
lib_ignore = M5Core2
[env:m5core2]
platform = espressif32
board = m5stack-fire
framework = arduino
lib_ignore = M5Stack
Cheers
Felix
Hello @koreanEggCoffee
yes, that is possible - I am powering my M5Atom this way.
However please note: There is no protection against wrong polarity so please be careful not to accidentally swapping 5 volts and GND.
I also suggest you disconnect the external 5 volts before connecting USB-C. Or in other words only connect one power source at the same time.
Please also refer to the M5Atom schematics which outlines the 5 volts connections between USB, 5v pin, Groove, LEDs and 3.3 volts regulator.
https://docs.m5stack.com/#/en/core/atom_matrix
Cheers
Felix
Hi guys
I've created an example showing how to partially update the ink display after the system gets powered on via RTC from a full shutdown. Pull-request
Cheers
Felix
Hello @jimbo_s
you'll need to have two I2C instances, Wire1 for internal stuff (AXP, Touch, RTC, etc.) on pins GPIO21 and GPIO22 and Wire for your sensor on pins GPIO32, GPIO33.
The M5Core2 library already set Wire1 up for the internal stuff:
Wire1.begin(21, 22);
so your sensor should use Wire. You can enable that on the correct pins by calling:
M5.begin(true, true, true, true);
the last true sets Wire up:
Wire.begin(32, 33);
You probably need to change the library for the sensor to use Wire instead of Wire1. How that is done depends on the library. Some allow to pass in the I2C instance to be used and some need to have every instance of Wire1 replaced manually to Wire.
The key here is to not mess with Wire1 else you loose all I2C communication within M5Core2.
Cheers
Felix
Hello @Zontex
Understood. Thank you for checking.
Maybe it could still be wired to a GPIO, but via a solder bridge, so it could be used optionally?
Anyways, I've soldered a wire from AXP IRQ to ESP32 GPIO35. I can detect now when USB (aka ACIN) has been connected or disconnected while ESP32 is in light sleep and use that to wake up.
Cheers
Felix
Hi guys
I think I found the issue. By default M5Core2 (running UIFlow 1.7.1) does not enable the internal 5 volts boost, therefore the LEDs are not powered.
@greenleaf when I add the following two lines to your Python code it works for me:
from m5stack import *
power.setBusPowerMode(0)
@veryalien for UIFlow add: Hardwares - Power - Set bus power mode (0), then use RGB LED unit set to Custom and SDA/TX set to 25 and Number set to 10.
Happy Stacking!
Felix
Hi guys
Power consumption update: even though the example keeps the M5CoreInk in shutdown mode (everything off except for the RTC) most of the time and only powers up for about 2 seconds every minute to do the update, the built in battery only last for about one week.
Thanks
Felix
Hi guys
UIFlow 1.7.1.1 for M5Core2 is out and it seems to fix the power issue on port A. I can now scan and use units on port A w/o the need to add the Set bus power mode 0 instruction.
Happy Stacking!
Felix
Hi guys
if you look closely you'll find that the schematics for M5Atom Matrix and M5Atom Lite are not completely the same. Apart from the RGB LEDs (25 vs 1) only the M5Atom Matrix has an MPU6886 internally which is controlled via I2C using GPIO21 and GPIO22.
However with the ATOM Stepper Motor Driver GPIO21 and GPIO22 are used for RST (Reset) and EN (Enable).
Therefore only M5Atom Lite can be used to control the ATOM Stepper Motor Driver.
Thanks
Felix
Hi guys
today I did a charging experiment with a fully depleted M5Paper battery. After about 2 hours the charger IC switched from charging to standby (according to the two LEDs I've soldered to the corresponding charger IC outputs).
I used a multimeter (connected directly to the battery) to measure the battery voltage. The voltage from the internal ADC, read via M5.getBatteryVoltage(), was about 5% higher than the voltage read by the multimeter for voltages below 4.2V. Above that the two values were pretty close. The reason for that is the voltage divider (3k / 11k) which when fed with 4.2V produces about 3.3V to the ADC input which is about the maximum a GPIO can take.
The highest voltage I've seen on the multimeter was 4.31V before the charging stopped. After which the voltage dropped back to 4.25V. I think that means the charger IC actually is setup for a 4.35V battery, but for some reason doesn't go all the way up to 4.35V.
Update: a possible reason is explained in the datasheet (Google translated):
==========
_______________Charge termination voltage setting The default full termination voltage V FLOAT set inside the chip is approximately 4.35V, but due to the large charging current, the internal resistance of the battery and the line Loss will cause the actual full-charge termination voltage to be lower than this value, resulting in battery failure The law is full enough. SLM6635 by an external resistor RPV to increase V FLOAT of Voltage, used to compensate various losses, or to satisfy different applications Special requirements for voltage.The compensation voltage can be calculated by the following formula:
Delta V = I bat (Standby mode) * RPV
If there is no need to compensate the V FLOAT voltage, it is recommended that RPV be set to 1kΩ.
==========
Thanks
Felix
Hello @gcormier
Unfortunately M5Paper doesn't have a charging indicator (eg. LED) and as you already noticed yourself the reported voltage is of almost no use either.
The thing is that the charger IC used in M5Paper has two outputs (charging and standby) which would indicate if the battery is being charged or not. Sadly though the M5Stack engineers decided to not use those outputs.
I did some measurements with my M5Paper and on average it did not take more than 3 hours to fully charge the battery.
So I suggest you keep it charging for at least 3 hours and it should be full.
Thanks
Felix
Hello @cerocca
the 1 to 3 HUB Expansion Unit doesn't have any active elements (like ICs etc.) in it - it simply 'forks' the connection into three. Or in other words, it doesn't matter to the 1 to 3 HUB Expansion Unit whether you use the 5 V pin with 3.3 V or 5 V. (That only matters to the modules you connect to it.)
For reference - check the schematic.
Thanks
Felix
Hello @oktawianito
I think the M5Core2 example for the GPS unit has not been fully adapted from M5Stack to M5Core2. It seems that by default HardwareSerial for ESP32 uses GPIO16 and GPIO17 but as you already mentioned on M5Core2 GPIO13 and GPIO14 should be used.
Try changing this line:
ss.begin(GPSBaud);
to
ss.begin(GPSBaud, SERIAL_8N1, 13, 14);
Thanks
Felix
Hello guys
M5Stack has defined three Groove ports A, B and C.
that said, from the perspective of the ESP32 almost any GPIO can be used for any function. Or in other words the above is not set in stone, but only what M5Stack has decided to use as their default.
So, yes, you could use the two GPIOs on port A as standard GPIOs. In Arduino you'd just wouldn't initialize I2C on these two pins and then you could use for something else.
In UIFlow that would happen (automatically) if for instance you attach the relay unit (which is an UART device) to port A and then use the respective relay blocks.
Regarding the PbHub: this is an I2C device which by default is plugged into port A. It has 6 ports, each providing an input and an output. These 12 pins are controlled by an microcontroller inside PbHub and the available functionality is limited to a given set. Check the list at the bottom here.
Now, in Arduino you use this library which takes care of sending the proper I2C commands to lets say turn on the output pin on PbHub port 1. Or read the input pin on port 6.
In UIFlow if for instance you connect the relay unit to PbHub port 2 (instead of directly connecting it to a Groove port) you then use the PbHub specific block to control the 6 ports on PbHub. Again which I2C command that requires to be sent to PbHub is done automatically by the UIFlow firmware.
So, for your project, @cerietke, using OpenHASP, the OpenHASP firmware for M5Core2 would need to know about PbHub to be able to control the ports on PbHub. I don't know anything about OpenHAB so I cannot tell if it could deal with PbHub or not. That is probably an question on the OpenHAB forum to ask.
Thanks
Felix
Hello @Schlabbermampf
just to be clear. The servos attached to the SERVO2 module will not be powered from the Battery Module (or the battery bottom of the FIRE). The Battery Module will only power the M5Stack device.
The SERVO2 module has a separate VBAT_2 line which is not connected to the VBAT of the Battery Module or M5Stack device. Check the schematic here. Subsequently the magnetic charger will only charge the battery for the M5Stack.
You'll need to attach a separate battery to the SERVO2 module directly at the DC INPUT (6 - 12V) using the provided thick wired cable. And it probably will need substantially more capacity than the 500mAh of the Battery module anyways. One servo has a rated Locked rotor current of about 750mA and your battery needs to drive 12 of them. See specification here.
And you'll have to charge the battery for the servos with an external charger.
I would probably start w/o the battery for the servos and initially power them through an external power supply. With that setup you could measure the DC current of the working robot and then depending on how long it should run from battery decide on the size and capacity of the battery. (Which will add additional weight to the robot.)
Thanks
Felix