Thanks mike, I did read it completly but wasn't quite clear on that. Matt.
On Apr 4, 3:23 pm, "m...@watty" <[email protected]> wrote: > 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 > Designhttp://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.
