There is no Delay in ssTEA

Seeing the Effect of Delay

Timekeeping Models

From Power On to Application On

SimpleSal Lives On A Mesa

Who needs a Software Engineer?

These are new posts stuck onto various surfaces within the site.

The View From the Outside

Welcome to the SimpleSal substack

A Starting Point

About SimpleSal

Delay as a Timekeeper interferes with this by delaying the Time at which the current Time is read. The time spent by Delay is lost to the App and ssTEA.

The rate at which ssTEA’s Agency operates is the “Agency Pace Period”. When the Agency Pace period is not a millisecond value, it is “planck”, and ssTEA operates each time the Arduino Host calls “loop”. Every loop checks for Events.

A value of 1, the value used in the video, sets the interval for checking for any Ready Events to 1 millisecond. The interval is 1) a period of Time in which ssTEA does not operate, and 2) the boundary at which ssTEA does operate.

Time-based events may have a “Recurrence Period”, a value which is added to the current Time each Time the event is granted Agency. The sum is placed in the “Time to Grant Agency” ssTEA data automatically by ssTEA, post-Event.

The balancing act between the ssTEA Agency Pace Period and the Recurrence Period of a Time event is that Events cannot recur faster than the Pace, but on the other hand, why check for ready Events every 1ms when all recur at 10ms?

The specific relationship is a function of the App’s understanding of Time. The value of the Pace Period may be changed in real time to affect ssTEA.

...<Seeing the Effects of Delay>...

The Classic model is in effect at all times at a low overhead cost. The Delay model is toggled on/off/on when the ssUI command “ss ro led delay” is entered by the user. The Delay model overwhelms the Classic model’s overhead, just as it overwhelms the App in the companion video to this video:

...<ssTEA Timekeeping model>...

...<there is no delay in ssTEA>...

The App as Timekeeper

The processor in a Mesa considered “embedded” is focused on the App and almost nothing else. Some overhead is necessary, such as Arduino’s, because there will always be software that is part of the Mesa support services.

When the Host such as Arduino has nothing to do in support of the App, it does nothing. Nothing for Serial to transmit or receive? No other interrupts? Done.

Thus all Time consumed and all Time measurements are within the context and the control of the App. The App has in its knowledge of Time the clock or software execution rate of the processor; the App knows how long things take.

The knowledge needed to relate clock rate to time of execution ranges from the clock frequencies of the Mesa and of the processor at this moment, the cost of memory accesses based where the memory is in the map; very deep.

The Host as Timekeeper

A more simple, reliable, portable solution: ask the Host to keep the Time. The Host does not necessarily understand all of the complexities in the knowledge required, but Hosts of multiple Mesa targets must have considered this concept.

The difference between LED On/Off and Delay is the the LED modifying software writes to a GPIO and then keeps going. The Delay solution using the processor is the same solution as the App Timekeeper: sit and count cycles. One benefit of having the Host do the delay is that Host tasks may get to run.

ssTEA as Timekeeper

The processor-based Timekeepers starting, maintaining, and ending the period of time with actions right now. ssTEA allows Events that occur when signals change or need to be change; the time between signal changes is for the App.

A computer processor begins executing when it is powered On, which is a result of the device supplying a clean supply of power to the processor.

The very low-level software that executes the boot sequence finds the image where it was placed in persistent memory by the developer. The image contains the software, which is called the Application or App.

The Arduino Host OS/Application model is that there is one call to a App function called “setup”, when the computer boot sequence completes; then there are iterative calls to an App function called “loop” until the computer halts. The Host supports interrupts and asynchronous communication in between the calls to the User’s “loop” function, taking very little time.

When there are no interrupts or other overhead, the focus and power of the computer belongs to the App to implement the features of the App.

The processor instantiates an AI, executing the App software in the Mesa.

Each of the activities involved in each step in the process consists of software.

Embedding software creates the need for sophisticated or simple alternative views into what is going on in the device. The thing going on is invisible.

The developer is probably working to get two devices talking to each other on the same Mesa, across a shared physical medium. Sensor devices implement the physics and then signal a computed result to the software. The computed result may be “an action was taken” or “you need to act”. How to see this?

The Software can only use what is available from the Context, and the Software cannot get more out of the Mesa and Reality than actually exists.

Software makes Mesas useful by creating a point of access to a feature.

The features of the Mesa are described by the collection of views in several forms: electronic circuit designs, mechanical design, industry standards.

With the exception of Physical Reality, everything has been made up.