New Event Scheduler

[burnsauce]

The AT (now R for repeat) feature requires a new scheduler to be implemented to prevent the inrush of equal-delay scripts from bogging down tele_tick(), causing i2c, trigger, slew, and display problems.

I propose a high-resolution priority scheduler to allow accurate synchronous events and fast response to asynchronous events.

[Dewb]

Anyone recall any details about implementation plans or hurdles for this idea?

[tehn]

I'm wondering if it's simply to have two schedulers and give one higher priority?

Almost a decade waiting ;)

[scanner-darkly]

i think the main idea was to simply have a dedicated queue for "system" events so that scripts that do anything heavy don't affect things like keyboard processing. as an example, if you currently set metro to something like 5ms or lower and put something like i2c commands in their, you will see keyboard input becoming sluggish.

but i'd also review what things get scheduled as events and whether they should be.

[Dewb]

Goals of a new scheduler could be

1. Prevent "heavy" scripts from interfering with input
2. Allow some restrictions to be relaxed, like the 10ms delay granularity.

In some ways these goals are opposed, but if overtaxing the hardware doesn't interfere with keyboard events etc., we can let users get themselves into trouble if they can get themselves out.

Here's a very small/simple behavior that I think could be improved. DEL.X and DEL.R behave more differently than their documentation and purpose would suggest. DEL.X 3 50: <command> will schedule the command at 50, 100, and 150ms from now, while DEL.R 3 50: <command> will schedule delays at 1, 51, 101ms from now. With the 10ms delay processing granularity, this pushes events into the next delay-tick. (IIRC TR.TIME is 20 in this screenshot.)

[tehn]

I'd support these changes!