Adjust divider

[Ralim]

• Please check if the PR fulfills these requirements

• The changes have been tested locally
• There are no breaking changes

• What kind of change does this PR introduce?

trying to resolve 691abd5#commitcomment-119722175

• What is the current behavior?

• What is the new behavior (if this is a feature change)?

• Other information:

@discip Could you please test if this changes anything 🙇🏼

[discip]

@Ralim
Unfortunately I have to disappoint you:
Still all the same (except for the boot-logo).

Just to clarify:
The device starts as expected (boot-logo seems to be better now), but after some time browsing the menu and changing values, the mentioned behavior occurs. 😭

[Ralim]

@discip
No issue with you reporting issues 🤣
Just frustrating I still haven't found it (yet).
Still havent been able to replicate here, but have pushed more things that it could be if you could re-test when you have time.

[discip]

Recent changes have improved stability a bit, but it's still not 100% reliable compared to before #1713.

Sometimes the OLED just froze, but based on the subsequent observation of changed values ​​in some places, I assume that only the monitoring of the changes stopped while in the 'background' key presses were still being registered.

Very often the OLED will just randomly display something like an explosion (pixels spreading out from the center).

Also, the vertical slide animation is still a bit bumpy. No consistent movement.

I'd really like to help but have absolutely no idea what to look for. 😞

[Ralim]

Recent changes have improved stability a bit, but it's still not 100% reliable compared to before #1713.

Sometimes the OLED just froze, but based on the subsequent observation of changed values ​​in some places, I assume that only the monitoring of the changes stopped while in the 'background' key presses were still being registered.

Very often the OLED will just randomly display something like an explosion (pixels spreading out from the center).

Yeah I have no real idea on this at all. I'm trying to make hackarounds to make it closer back to how it originally was but I'm running out of differences I can find. At this point if the above doesnt fix it (I dont overly expect it will but you never know) I'll start disabling transitions entirely to see if its those, if it is then they may get annexed.

Also, the vertical slide animation is still a bit bumpy. No consistent movement.

Yeah on devices where the I2C transfer speed isnt constant (Miniware devices since we cant use DMA on clone IC's), it will vary a little. At the moment we are running it "as fast as possible" to try and be as close to the old method as we can. I can slow it down which will make it smoother; at the cost of it being slower. Alternatively can make it move two lines at a time but then it will be more jumpy.

I'd really like to help but have absolutely no idea what to look for. disappointed

Honestly neither do I, I cant reproduce this on any of the devices to hand so far.

[discip]

@Ralim

This seems to finally work now. 🎆 😃 👍 🎆

I did test this for both TS80P and PinecilV2.

I'll start disabling transitions entirely to see if its those, if it is then they may get annexed.

Please don't. Please keep the vertical transition.

What I can't wrap my head around is the fact that the transition worked before and now there is no way to achieve that?

Could this be done by splitting the 'build process', so that the built for the miniware devices is done the previous way and the built for eg.: S60 / TS101 the new way?

(Miniware devices since we cant use DMA on clone IC's)

Is there a way to distinguish between cloned and original IC's.
If so, could we differentiate between these built-wise?

I hope you don't get me wrong.
I really don't want to complain.
But it's a big sacrifice that previously flawlessly supported devices are now somewhat crippled.

By the way:

I haven't been able to figure out what's causing this yet, but for some reason some settings are being changed without any interaction.
For example, almost all numerical values ​​have been changed to 20.
I'll try to narrow down the root cause.

[Ralim]

What I can't wrap my head around is the fact that the transition worked before and now there is no way to achieve that?

Could this be done by splitting the 'build process', so that the built for the miniware devices is done the previous way and the built for eg.: S60 / TS101 the new way?

Basically: I really don't want to split the implementations between 16 high and 32 high screens; as it means even more things to be tested before any PR can be merged. The only way I keep things moving at any sort of speed is to keep as much code as possible 1:1 across devices to reduce complexity.

Options are :
that we only update every second line (or similar)
we get I2C IRQ implementation faster
we get I2C DMA working on all the clones
or maintain two implementations

Its doable to maintain two implementations.
have also been pondering other ways to make this faster, but needed something to work for now.

More than happy to make an issue to track improving the situation here.

(Miniware devices since we cant use DMA on clone IC's)

Is there a way to distinguish between cloned and original IC's. If so, could we differentiate between these built-wise?

Not that works on all of the clones other than hard coding a long list of serial numbers. We also don't have the code space to support swapping this at run time.

I hope you don't get me wrong. I really don't want to complain. But it's a big sacrifice that previously flawlessly supported devices are now somewhat crippled.

Feel free to show your annoyance at their shitty designs by not buying Miniware products 🤷🏼

By the way:

I haven't been able to figure out what's causing this yet, but for some reason some settings are being changed without any interaction. For example, almost all numerical values ​​have been changed to 20. I'll try to narrow down the root cause.

Would love a way to reproduce this, will definitely be keen to fix it.

[discip]

@Ralim

Basically: I really don't want to split the implementations between 16 high and 32 high screens; as it means even more things to be tested before any PR can be merged. The only way I keep things moving at any sort of speed is to keep as much code as possible 1:1 across devices to reduce complexity.

Ok, I got it. 😃

Options are :

• that we only update every second line (or similar)
• we get I2C IRQ implementation faster
• we get I2C DMA working on all the clones
• or maintain two implementations

Not that works on all of the clones other than hard coding a long list of serial numbers. We also don't have the code space to support swapping this at run time.

Not an option!

Would love a way to reproduce this, will definitely be keen to fix it.

I was able to reproduce this on both the TS80P and the Pinecil V2.
What I did:

1. Flashed the latest dev.
2. Performed a factory reset manually.
3. Went through the menu and changed all the relevant values.
4. Left the menu by going past the last entry.
5. Realized the soldering temp, the boost temp and the sleep temp were all set to 20. 🤷🏻‍♂️

Hope this helps narrow it down at least a bit.

regards