Posts made by Pensive

OK - I had to find my ownn solution to this:

The problem lies with using the loop to run all the updates. If you do that - and manage your program from the loop then you need to use globally declared instances of all the buttons. If you try and create button ways dynamically via procedure they are scoped within that procedure - and they are disposed of automatically (whether you like it or not!!) when you exit the function/procedure and return to the Loop.

SO

I only use the Loop for switch case statement to invoke the loopProcedure for each given page.

I create a mode variable currentPage, and a dedicated loopProcedure for every page of the project (loopMainMenu, loopPlaybackPage etc. etc.)

Each loopProcedure draws the screen, invokes the necessary buttons and handlers for that page locally, and then starts a local do-while (currentPage=loopMainMenu){} loop to provide all the typical loop based functions like m5.update(); to keep the button system ticking and battery management going for that page. It stays in this while loop until the back button is pressed or the system navigates to another page somehow (by repointing the currentPage variable).

It is the button handler functions that can then change the page which cause the while loop to exit back to the main Loop - and the entire loopProcedure then disposes of everything related to the old page, and a new page loopProcedure is then invoked through the switch case statement in the Loop.

It's a bit clunky because I would prefer that the library itself simply supported dynamic disposal and invokation of global objects - and having a loop for each page is going to get quite bloaty quite quickly but wit ha little care and some carefully designed functions we can reuse most of the code not related to button invokation.

I'm not able to post any code I'm afraid - but it works and you can leave some global buttons like button C is my back button and that wil never change, buttons a and b are also global (but all could be defined locally if required).

I hope that helps someone in the future.

Hi all

 My project has multiple screen pages.    
 At the moment I'm using m5button and it's working great, but if you define 2 buttons in the same screen space only one of them fires.

(I was originally going to set up a tonne of button handlers; all of which would check and only fire if the "currentPage" was the page they were on.)
So approach 1 doesn't work.

So I changed my definitons to create new pointer instances and accesing the functions via "->" instead, allowing me to create and dispose of them at will.

However of course when you invoke them from within a function or procedure in your main file the scoping is limited to the current function or procedure and they are automatically disposed of outside of that function.

So my solutions might be:

1. roll my own M5 button with disposal features.
2. Amend the M5 button in the core source and submit the changes to M5stack - this will fundamentally break everyones code. although its not a particularly painful fix I doubt it would be adopted. I dont know why they didnt support creation and disposal from the outset.
3. Just write my own button handler instead.

Does anyone have any comments or tips? Have I missed something that I can do effectively using m5button library?

I'm thinking I might do 1) but it's probably as much work as 3) - possibly more (as I do not need many of the features - just need touch and release.)

Is there any option for item 3) I can use from a 3rd party thats ready to roll?

thanks for any guidance

Jon

Hi all

  Has anyone successfully managed to get anti aliased fonts working?

 M5.Lcd appears to be an incomplete subset of TFT_eSPI; I've tried creating a TFT_EFT Sprite which is bound to the pointer for the M5.Lcd:

TFT_eSprite spr = TFT_eSprite(&M5.Lcd);

but it looks like the actual code to load the Smooth fonts has been left out of M5.Lcd for some reason....this is a great shame.

see here : https://github.com/komikoni/M5Stack/commit/6b47f2e79d150588728537d61641cd9e1ea5ed88

It looks like I'll have to patch my library to make it work, which I'm not too keen on.

no response from M5stack on any of the threads so far that i can see.

Hmmm.....do i implement a custom patch? I would prefer to remain vanilla for my current project...but if I push a submit they might reject it because it breaks something else. If they would just respond and comment why it's been left out (i.e. it breaks x, y, and z if we enable it) then at least I could make an informed decision to live without or implement.

@jimwsmith said in Core2 how to know the current battery level:

@pensive Here is a link to the battery log code (it was do

Thank you :D

Will update here once it's implemented and pushed

Sorry for multipost but I could also store the values in byte values with the first byte for the unit and second byte for the decimal would probably retain accuracy across all 100 values but store it all in 200 bytes. Simple bit of code for each query.....more clockticks though, I dont want to underestimate the parasitic load of constnatly performaing unnecessary calculations.....

Ahh: found this: https://en.wikipedia.org/wiki/Half-precision_floating-point_format

But not supported by arduino which is freaking wierd. floating point iwth half the memory usage? Yes please.....

But since its not supported a full lookup table is neater. others can save ram if they like but im not too bothered. This board has oodles of it.

@pensive said in Core2 how to know the current battery level:

the most accurate and lightweight solution would be a lookup table. It could mimick that curve exactly at every percentage point using only 100 float values - and a very simple function:

Actually I could do it using a handful of float "keyframes" at key points and calculate an interpolated percentage on the fly. Which is better - less ram / sketch ram? Or less CPU ticks? I would normally just burn a full lookup table to free up clockticks but memory can be a valuable resource too....

100 * 4 bytes = 400 bytes + headers of sketch ram for the full lookup table.

I could probably reduce this to 100 bytes but at a realtime processing cost (which will cost battery!). I'm leaning on the full lookup table idea.

@jimwsmith said in Core2 how to know the current battery level:
As you can see the line is reasonably linear until the very end.

Great thank you! It's the super steep drop off at the end that is messing with everything as the algorithm in the example code just draws a straight line from 3.2v to 4.2v so up until the steep drop off it says you have almost 50% more battery than you actually have! at that dropoff point the voltage is about 3.65v - so the percentage calculation at that point in the graph will read 45%!!!

I've observed the same phenomenon in reverse when charging - it looks like you are charging really quickly because you hit 45% really quickly then it takes forever to make it the rest of the way - no wonder - you're only 20% charged!

the most accurate and lightweight solution would be a lookup table. It could mimick that curve exactly at every percentage point using only 100 float values - and a very simple function:

byte returnBatteryLevel(float currentVoltage){}

@jimwsmith would you be willing to share that spreadsheet with me so I can pull the voltages out? I'd be happy to commit this function back to the M5core2 master so we can all report (more) accurate percentages.

@revta getting to a projected time left would be a step 2 in this process - the first being getting an accurate percentage left, the second projecting how quickly this will diminish based on knowlegde of the battery and the current draw. I think this part is getting much more complicated as it will be drastically affected by different battery capacities (Faces kit or the battery stack units etc.) as well as the current draw - this is not so much the case with Step 1 so step 1 would be much more universal function and I think will remain reasoably accurate across battery capacities.

I implemented and tested this last night; While the calculation in the m5core2 factory test is linear - the battery performance is not.

My little Core2 lasted for 5 hours and 40 minutes.

At about 5 hours and 25 minutes it was showing 20% (my battery meter turns red at 20% :) ), but the last 20% dropped off in 15 minutes. You can see this shown in the graph above for Li-ion batteries (i dont really know how close that is to the real performance of these batteries.

We can extrapolate that as being a total life of 1 hour and 15 minutes - based onthe last 20%

Does anyone know of a better curve solution someone has already done?

If not I know the solution:
Leave it to run down, pinging out to sdcard its battery voltage, current draw (for information) and the time elapsed.
Then we can build a graph - just like the one I linked to based on the specific battery in this device - a new, healthy battery at room temperature - using a fairly normal level of power consumption.

Then I can build a lookup table to represent this in code for this device.

We could also build tables at different consumptions/temperatures if we wish as this will all affect when the "last 20%" fade kicks in. Upshot would be it will be much more accurate than this basic linear calculation is - so I'm going to do this later.

thanks for the help @felmue - ive got it working now - i think i must have been pretty tired because I have no idea how all 3 attempts failed.

It works with .waspressed and by attaching a handler to events for the M5.BtnA - I have no idea what I was doing wrong all 3 times.

I found one issue - it was a silly mistake in my handler logic :D but this does not explain .ispressed not working before.

Maybe its something to do with a lack of sensitiviity as well - but the important thing is - they do work and I've got it working.

But trying to make a button bigger all the way down to 280 does not seem to work - which is a shame becasue I have to make 2 declarations to the handler. but thats ok.

Thank you

@mb

The m5button engine supports swipe gestures and the sprite engine can animate your graphics.

Not aware of any m5 animation engines that handle that but maybe have a look at the Raphael animation engine - its very neat and might inspire you to port it for m5 sprite.

Could also look at bounce.js - the maths to calculate easing is not complicated.

@felmue

Yes I am calling the update; I have 9 other buttons working fine and the touch button works just not below the bottom of the screen.

I note that that example uses waspressed instead of ispressed.

I’ll try the example and I’ll try waspressed instead. Unfortunately this implementation prevents the use of gestures and double taps with these buttons but I can live with that.

I would much prefer to get this working through the button library though

I've tried M5.BtnA.IsPressed() and that didn't work.

So I tried M5.BtnA.addHandler(xxxx,TE_TOUCH) - that didn't work.

So tried creating a button that went down to 280 on the Y axis - that also doesn't work.

Has anyone got the 3 touch buttons to work?

Similiar problem here - Ill start a new thread in case its a different issue