The problem here is that screen processing is very fast, so you won't acumulate 2 steps, it'll process them almost in real time.
Instead of hacking around, apply the time diff method to the encoder functions, increasing the steps by 2 instead 1, that will trigger the big step in the widgets processing .
Well, before modding widgets.c, I changed it few weeks ago. I'll revert some code to make it work, let me check that tomorrow.
What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.
I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope
Keep it up
What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.
I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope
Keep it up
Nice testing
Huh, why do I remember everyone complaining with the 1q0 pid settings?
110*
Before It was 40..60 kp or something like that.
People complained about stability issues after that.
Added big step support at the encoder / widget core level (Like it was ages before).
I had to remove that and use the click and rotate thing because I had found some kind limitations back then. I don't remember why. Or maybe a very silly mistake .
This firmware has had a lot of back and forths due that. First hittting a wall, remove/disable the feature to keep it working, and then restore the feature when the workaround was found.
Cuboy, your way depends on how quick/often the screen is processed, so it might behave differently in 36MHz and 64MHz speeds, also it will only work in the main screen.
Now everything in the system works that way. I must confess I never liked the click and rotate thing...
I committed directly through the web while I figure out how to make git working again.
Simple user/password was deprecated and git token is not working for me, neither ssh keys.
Check out the commits:
widgets.c
rotary_encoder.c
Re_Get function computes how many steps have passed since the last call and writes it to Diff var.
That way you won't lose steps if the processing is slow.
Diff can be positive or negative, depending on the direction.
I need to know the step number, regardless of the direction, that's why abs (absolute) is used.
Check rotate_encoder.h for RE_State_t structure description.
Yes, there aren't many other ways.. store the time and compare it, nasa science
You don't exactly know how often the screen update is called, the screen drawing will take more or less time depending on the widgets, causing a lot of jittering.
You needed 80mS because the whole screen is dma-erased and redrawed when the main screen is changed, it's faster than clearing and redrawing each widget, and needs to be done because some widgets slightly overlap, so updating only one would partially erase other nearby widgets.
But if I changed or removed a widget, that time would change, also if the CPU was faster or lower.
Working at the encoder level, you know it's called every 1mS, no matter what.
I don't feel it's tested enough yet...
Though you and Tugo did a great job, I need the same thing from more users.
By the other hand, others say they've been always happy with the settings.
See the problem here? This is plain stadistics, and I have very little feedback to get something clear
Otherwise the mindfucking will continue .
I tried the new pid again. Definitely not putting it back, adjusting it is **** difficult, extremely sensitive to tip changes, the old is much easier to tune.
The spikes and such are usually filter-related, but also high KD will cause them.
This time I tried a different adaptative threshold filtering, which helps with the noise but also with fast temperature trasients.
I'm actually pretty happy with it, heating up from cold to 360 hits 363-364 and goes down to 360 peacefully.
Of course, here the people will report wild stations attacking the user and running around the room!
I'm still unable to use Github... Will make test builds and upload them here.
Use github desktop, more easy, just clone and ready to play with it.
Yep, my fault. It exited to settings screen before, now goes to main, and there was a check I forgot to update.
That error means there was no free memory left to allocate a buffer to save the settings.
The checking issue also caused a memory leak, not freeing up the pid plot buffer on exit, so if you entered 3-5 times to the debug screen, it probably ran out of memory, causing the error.
For 32F103, I need to enter debug screen ~35 times for that error to happen, I would never have that issue unless I had a very long day debugging!
Don't use the debug screen for now, it's already fixed (or I think so) but I'll wait for more feedback before making new builds.
You can't imagine how useful the error reporting feature has become