Posts made by vkichline

Felix; thanks for the tip in the Grove pinout; exactly where I was stuck after experimenting.

https://docs.m5stack.com/en/arduino/arduino_development mentions the new stamp-pico, but falls short of mentioning what library/header one uses in an Arduino Stamp sketch for it.
Would it use M5Atom.h?
Thanks!

@josestevez; no habla espanol muy bien, pero Visual Studio Code con PlatformIO es mas rapido siguente el primero vez.

3 & 4. Plus PlatformIO as well.

Replace #include <M5Stack.h> with #include <M5Core2.h>.

It would be nice to have a Magnetometer Unit.
I'd like to experiment with using one to do course correction for an autonomous robot.
Something simple to calibrate would be nice.

Rop, all the included examples run fine.
I found that the problem is that Button::_hidden is uninitialized. I will open an issue.

Now I can easily add hit and miss sounds to my button testing app. Will update soon.

Thanks for the checkRotation function!
I've just glanced at the Sound stuff (very nice!) but am still working on Touch.
I wrote a test to determine what the minimal effective touch button size is (https://github.com/vkichline/ButtonSizeTest).
When I moved it from PlatformIO (for development) to Arduino (for publishing) I moved from your master branch to the M5Sound branch. The app built, but did not run in M5Sound. (It drew one button and stopped. I haven't looked into it yet.)

Are you making touch changes in M5Sound as well?

I wrote a program to see what a reasonable minimum size touch button is: https://github.com/vkichline/ButtonSizeTest
It's a test you play: it lets you choose what size button and what spacing; it makes a bunch of buttons and asks you to press eight of them. At some point you should stop getting perfect scores.
I'd be interested in hearing what people find a usable minimum to be.

Caution: to use this app, you need RopG's PR for M5Core2. You can download the touch button version of the lib here: https://github.com/ropg/M5Core2.

Rop's latest sample (M5Sound, in this forum) make me wonder what a reasonable, minimum size and spacing should be for TouchButtons. At almost 80 X 60 pixels, the DTMF buttons are usable, but already require some care with only 12 on the screen.
I dug up an old passive capacitive stylus (the kind that looks like a soft pencil eraser) and found it increases speed and accuracy. Maybe a 50 X 50 pixel button would be usable with the passive stylus (doubling the number of buttons available.)
I see that there are active capacitive styluses available with much smaller tips. Does anyone have one? Does it work well with the Core2?

Nice, efficient implementation of the dtmf sample. I see btn.userData came in handy!
The audio quality is great, completely free of pops and clicks.
I think I'll add checkRotation() to my system library!

Works like a champ!
If we ever meet, I will buy you a beer.

@felmue That's a very simple change and works great! Thanks a million!
Still on the topic of "Is there a Brain Genius in the House?" I have one more PlatformIO question:

When I compile Core2 programs that allocate lots of memory, they work if built on Arduino but fail at runtime if built on PIO. It seems that Arduino is somehow dynamically aware of the 8MB PSRAM, while PIO is not. I believe PIO uses the board def to select ..\partitions\default_16MB.csv, which seems to limit app0 to 64K. I bet that's it.

So when I execute a statement like disp.createSprite(320, 240) it works fine if I build with Arduino, but PIO tells the Core2 it doesn't have that much RAM, so it fails. The factory test program likewise won't run if built as an M5Stack-Fire on PIO.

Does anyone have a definition for an M5Stack-Core2 board and an appropriate partition map for it for PIO?

I'm trying to build M5Stack Core2 projects on PlatformIO (on Windows, if it matters.)
I've been tracking RopG's Fork, so M5Core2 was in my project's lib folder, and things worked fine.
Now I've moved it to the [user].platformio\lib folder, and I have problems.

If the M5Stack library is NOT installed, the project compiles and links and this is the Dependency Graph:

|-- <M5Core2> 0.0.1
|   |-- <Wire> 1.0.1
|   |-- <SPIFFS> 1.0
|   |   |-- <FS> 1.0
|   |-- <FS> 1.0
|   |-- <SPI> 1.0
|   |-- <HTTPClient> 1.2
|   |   |-- <WiFi> 1.0
|   |   |-- <WiFiClientSecure> 1.0
|   |   |   |-- <WiFi> 1.0        
|   |-- <SD(esp32)> 1.0.5
|   |   |-- <FS> 1.0
|   |   |-- <SPI> 1.0

However, if both M5Stack and M5Core2 libraries are installed in [user].platformio\lib, I get this Dependency Graph:

|-- <M5Core2> 0.0.1
|   |-- <Wire> 1.0.1
|   |-- <SPIFFS> 1.0
|   |   |-- <FS> 1.0
|   |-- <FS> 1.0
|   |-- <SPI> 1.0
|   |-- <HTTPClient> 1.2
|   |   |-- <WiFi> 1.0
|   |   |-- <WiFiClientSecure> 1.0    
|   |   |   |-- <WiFi> 1.0
|   |-- <M5Stack> 0.3.0
|   |   |-- <FS> 1.0
|   |   |-- <SPIFFS> 1.0
|   |   |   |-- <FS> 1.0
|   |   |-- <SPI> 1.0
|   |   |-- <HTTPClient> 1.2
|   |   |   |-- <WiFi> 1.0
|   |   |   |-- <WiFiClientSecure> 1.0
|   |   |   |   |-- <WiFi> 1.0        
|   |   |-- <Wire> 1.0.1
|   |   |-- <SD(esp32)> 1.0.5
|   |   |   |-- <FS> 1.0
|   |   |   |-- <SPI> 1.0
|   |-- <SD(esp32)> 1.0.5
|   |   |-- <FS> 1.0
|   |   |-- <SPI> 1.0

Everything compiles, but I get innumerable linking errors like:

.pio\build\m5stack-fire\libb51\libM5Core2.a(M5Core2.cpp.o):(.bss.M5+0x0): multiple definition of `M5'
.pio\build\m5stack-fire\lib3c8\libM5Stack.a(M5Stack.cpp.o):(.bss.M5+0x0): first defined here
c:/users/van/.platformio/packages/toolchain-xtensa32/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: Warning: size of symbol `M5' changed from 332 in .pio\build\m5stack-fire\lib3c8\libM5Stack.a(M5Stack.cpp.o) to 1856 in .pio\build\m5stack-fire\libb51\libM5Core2.a(M5Core2.cpp.o)

My platformio.ini is plain vanilla:

[env:m5stack-fire]
platform = espressif32
board = m5stack-fire
framework = arduino
monitor_speed = 115200

I've tried it with incredibly trivial projects, it's always the same.
Any suggestions? Is anyone successful at this?

Works like a champ! Thanks, Felix--sorry it took me so long to circle back and try it out.
Rop has reved two more times; I'm on the latest and this seems to work fine.

Sorry, I wasn't clear, but it sounds like we're on to it.
Keep the M5StickC board selected, but change:
#include <M5StickC.h>
to
#include <M5StickCPlus.h>

Are you using Arduino or UIFlow? May be the same in both cases:
The first time I programmed my M5StickC PLUS, I included the old M5Stick library, and got exactly the visual effect you mention.
Use the M5StickCPlus library for Arduino.
I haven't used UIFlow for a while, but perhaps there you need to be sure to select the M5StickC PLUS board and not M5StickC.

The PLUS has a larger display, so the library compiled for the older, smaller display only addresses part of the LCD.

I've updated TouchGoal with long touches and better syntax. It's ready to go. BTW, I consistently get 100% scores now, so Touch is doing exactly what I want it to do.

I've added another testing program you may be interested in as well: TouchView.
It displays events to the screen as well as to the serial port. I like to test in an easy chair.
The A button turns E_MOVE an and off, B enables/disable long touches, and C toggles key repeat.
A good way to look for unexpected events. Looks clean to me.

I did report one bug I'd call a show stopper; #22. (I added a lot of issues, so it could get lost in the soup):

• Run events_buttons_gestures_rotation
• Double-tap top-left button. Turns blue. Good.
• Swipe up. Display inverts. Good.
• Double-tap button named "top-left" (now at bottom-right.) Button named "bottom-left" (in top-right position) becomes blue. Error.

Also, the file M5Touch.h didn't get updated; it has at least one example program (the first example in the top level file) which does not compile. I opened detailed issues at https://github.com/ropg/M5Core2/issues. It looks like a lot but most are typos.

I know I'm a noisy gong, always with the nits and quibbles, but on the whole this is excellent! I'm surprised at how reliably the gestures work; I took a stab at that myself and it was far from trivial. The two-finger support and rotation really go above and beyond as well! A huge leap forward for the Core2 platform.

Tried your changes and I can successfully double-tap every time now. Excellent!
I will add long presses to TouchGoal as soon as I figure them out. But today's my anniversary, so until later!

You're welcome to include it! Some additional tests for what shouldn't happen and a few comments about the best way to detect things would make it more valuable.
It's always nice to have a comprehensive suite to walk through after making 'improvements'. I could see TouchGoal being useful for testing subclasses of buttons, zones, etc.
When you think about it being used for testing subclasses, are there any additions you can think of? It's mostly positive testing now, few negative checks. (For example, you should not get this event before that event in this case...)