"Lloyd E. Sponenburgh" wrote in message
.70...
snip

I am from the old-school M/L situation, where I not only wrote the
application, but usually wrote the underlying OS and designed the
hardware. In that scenario, it is "easy" to do simultaneous control of
numerous processes. Just get out the assembler, and DO it!

LLoyd

That's awesome, if you have seen the example programs these days you know
where I'm coming from.

I was taught things like:

Loop:
If start_button_not_pressed then goto Loop
motor_run_contactor = 1
Loop2:
if stop_button_not_pressed goto Loop2
motor_run_contactor = 0
goto Loop

Things like that completely tie up the processor waiting for a button to be
pressed, and the processor will do nothing else unless there are interrupts
or some sort of multi-tasking operating system to handle it.

What they should be teaching would be more like

Loop:
If start_button_pressed then motor_run_contactor = 1 (or do other
processing that button press requires) // no holding up processor waiting on
a button to be pushed
if stop_button_pressed then motor_run_contactor = 0

.... //here you can do things that need to be done if the button has been
pressed or not.
.... // or add other code that can execute every loop
....
....

goto Loop

Now to prevent something like the processor being tied up, and not
responding to the buttons, you would use a watchdog timer to reset if a
single iteration of the loop took too long.

I learned to stop programming like the typical examples and start
programming free running loops by both a more experienced programmer and by
learning to program PLC ladder logic.

I can't speak for others but I know learning by bad examples made it more
difficult for me to get a program to handle more than one thing at a time.

RogerN