On Apr 4, 7:31 pm, mattschinkel <[email protected]> wrote:
> I see that your "task" procedures have non-blocking delays to blink
> the leds. What would happen if someone used _usec_delay(1_000_000) to
> turn on/off a led?
>
> My understanding of multitasking is that for example, if I create 2
> windows softwares and one has a large blocking delay or a forever
> loop, I would still be able to use the other software and the rest of
> windows at the same time
>
> Matt

As Simon the Sorcerer says, "That doesn't work". Windows/Linux/OS X
have "pre-emptive" multitasking and "co-operative" Multitasking.

As the article explains that kind of  Operating system supplied or
language provided Multitasking comes at a cost.
The cost is RAM and CPU cycles. Also lack of ability to precisely do
anything in on OS X, Linux and Windows as they don't support "real
time". Read up what platform you need for Real Time Java.

With my scheme you write the lower level code assuming it's repeatedly
called in a loop, Nothing ever is blocking. Unless it would block on a
RTOS kernel. you NEVER call _usec_delay for more than a few 10s of
microseconds. You never ever call the larger delays.

To do "traditional" Multitasking as per the non-real time of Windows/
Linux/OS X or the Real Time of Solaris, Realtime Linux, QNX, RTOS etc,
you need a CPU with a lot of RAM. Typically if you have ten tasks/
Processes, you need ten times the RAM and ability to have ten Stacks
that you swap between simply by swapping the value of the Stack
Pointer. The PIC 10 to PIC 18 only have one dedicated Stack and little
RAM.

My article tries to explain this and has two program examples, one is
Serial Port and one is a non-blocking delay. Also important though is
understanding the structure of the the whole program and how anything
not interrupt driven is all derived from a single high resolution
Timing Interrupt.

Re-read the explanation of timing and look at the whole catpadv2.jal
in projects/catpad_mw. The master  high resolution timer is in
catpad_main.

The catpadv2.jal forever loop is really equivalent to the Round Robin
scheduler of an RTOS.

The point is that you achieve the performance or better of
multitasking, without any kernel, no scheduler and no multiple stacks.

**************************

Instead of thinking of lower level procedures being called once and
returning when complete, the  idea is that lower level procedures are
called repeatedly. Each time they are called they either initiate an
action (returning false), do nothing (returning false because they are
blocked from Initiation or completion) or complete and return true.

The out parameters  replace Function returns. They are ONLY valid when
after a repeated call they return True,

Procedures (such as Delay or WriteEeprom)  are replaced by functions
that are repeatedly called, in a Data Flow design. When they return
true, they have "completed".

It's quite a different way of programming.  Imagine all the existing
program (which looks like a flow chart with decision diamonds)
replaced with a schematic. Many ICs are "clocked" at different speeds
by the RTC ISR updating software counters. The "forever loop" runs at
variable speed and the "ICs" in it have a data out Valid pin (the
Function True return on completion).  It's a sampled Data Flow Design
http://en.wikipedia.org/wiki/Data_flow_diagram






     .

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to