Hello Bean and SX/B Users;

Generally my needs for SX programming require numerous simultaneous timed tasks to be running, and more often than not, those tasks need to be rather deterministic in their timing. This need prevents me from using SX/B as it will not permit (I believe) multiple tasks to be run concurrently. So the wonderful work you have done in implementing SX/B effectively cannot be utilized by users with these requirements, and we are relegated to continue to work in SX/Assembler. What a pity.

So I was musing about this, and started some experimentation in simplifying and adapting one of my (non-preemptive) RTOS methods the see if it could be integrated into SX/B. At this early point in my tests, I am able to have several timed tasks running concurrently and fairly deterministically by invoking a fairly simple calling method that lends itself to macro instancing, and takes on the behaviour of your blocking "Delay" loops.

In my case the loop is tested, and if not expred, then it is exited to carry on with the next thread in the program sequence. I believe what your delays need can be served by my approach, but I'm not privy to the internal operation and requirements of SX/B, so I'm making assumptions at this time. Also, it is still early in my experimentation, and there could be diappointments. Howver, if you could successfully incorporate this concept into SX/B, the effect of this would be to make it unblocking, permitting multiple timed threads to operate mostly independently although there will be some restrictions.

I am polling the SX/B community to see if this concept has sufficient interest for me to work out the remaining details - if possible-, and submit it to yourself for consideration.

What is the interest??

pjv,
It would be great to have that in sx/b.
I remember from MSX basic, it had a ON INTERVAL=nnn GOSUB construct
which would allow to define a subroutine that would get called at regular intervals.
Accompanied keywords were INTERVAL ON (start interval timer), INTERVAL STOP
(stop interval timer), INTERVAL OFF (disable interval timer) and INTERVAL RESUME (at subroutine end).
At the start of such a subroutine was an implied INTERVAL STOP to prevent
calling the subroutine from within the subroutine in case it took longer
than the interval time. At the subroutine end was an implied INTERVAL RESUME.
I can imagine having INTERVAL0 to INTERVAL9 to support 10 scheduled tasks.

pjv,
 Currently the delays in SX/B are just calculated from the clock speed.
 How does the delay look "give up" it's time slice when in a loop ?
 So if you have a "PAUSE 1" and the thread is given a time slice every 10uSec, then does it just "give up" it's slice 100 times ?
 Of course the compiler would need to "know" at compile time that the thread has a 10uSec time slice.
 How do you handle the __PARAMx variables in global RAM ? Do they need to be swapped for every task at every time slice ?
 Can you show some pseduo code of how you think it should be done ?

Bean.

Peter (pjv),
I asked a simillar question, in another post, as to whether SX/B could do something along the lines of what you described. The answer, the SX/B compiler, at this time, does not have the "horsepower" to do that.

So, out of curiosity, what are your thoughts on how you would implement some thing like that, in SX/B. Are you thinking inline asm code, super macros, or do you have another solution.

Yes, I am interested in seeing a solution, but it would have to be whithin an SX/B context. I just started playing around with the Propeller, and it dawned on me, for my application at least, what a powerfull combination a Propeller and an SX52 protoboard make.

Hi Bean;
Please, my testing on this for possible SX/B implementation is still in the early stages, and won't likely proceed if there is not sufficient interest...... I still see a fair bit of work ahead.

As you know, I have developed a full multi-threaded pre-emptive RTOS for the SX28, as well as a more simple minded non-pre-emptive co-operative RTOS (more like a scheduler really) that consumes less resources. Both of these are written in assembler, and I expect the pre-emptive unit is likely not compatible with SX/B; too many conflicts. It is the simpler co-operative RTOS that has a chance.

Please correct me if I'm wrong, but my understanding is that SX/B stalls in a delay loop whenever a timing event takes place, such as serial communications. the processor hangs until the loop is completed, and no useful work can be done during this period. In fact, no other tasks can run simultaneous with these delay loops, and that is why SX/B serial communications cannot transmit and eceive at the same time.

What I'm proposing (and this is a feature of both my RTOS schemes) is that timing is effected by scheduling things to occur, not by waiting for a certain number ol wait loops. What would need to happen is that SX/B be modified to eliminate its delay loops in favor of using a scheduling approach. In such a case, when a timing function (delay) is required, the calling program initiates a timer, and then immediately releases the processor to carry on with the next thread, and the timing function (delay) is performed in the background. When the timer has expired, it picks up the thread that called it at the point where the call was made.

There will undoubtedly be some restrictions and compromises making this approach not possible for all SX/B applications, but I believe it has a good shot at being reasonable for most.

pjv,
  I am definitely interested in seeing some multi-threaded support from within SXB!  This is something that I keep thinking I am going to need...  but so far have always managed a way to serialize my programs to produce a sufficient result.  However, I do not expect this will always be the case.

  I have wondered why things like serial communication and sound generation do not "spawn" a separate process and run in the background like processes do in Unix.  Yet when I think about how this would need to be accomplished on a device with such limited RAM, I quickly conclude that each application would likely need to be custom designed to maximize the available resources.  Or perhaps the compiler would need to be supper-smart in order to figure out how to best optimize everything.

  I have to give kudos to Bean and the others who are contributing to the development of SX/B.  I fully intended to delve deep into SX assembly and only expected to dabble in the free BASIC compiler that was available.  So far I have found almost the complete opposite to be true.  SX/B meets most all of my "basic" needs and I only dabble in assembly language when I need tight control of something or timing is critical.

  So yes, I would like to see a multi-threading option for SX/B.  Certainly.  I would also enjoy seeing how you are accomplishing multi-threading in assembly even now.  I have looked at several examples of how others are doing this and keep thinking, "Someday I will need to do this.  Someday!"  So the more you care to share, the better for the SX community, I would said.

  I hope you are inspired to do this!

Hi Terry and All;
I have been doing considerable further work on this version of multi-threading the SX, and I am more convinced than ever that is could be fairly readily incorporated into SX/B.

At present I have 8 (probably a reasonable maximum for demanding requirements, but can be easily expanded for mre modest needs)  threads operating "simultaneously".... one 9600 baud transmitting UART and one receiving that data (both software bit-banging), one thread triggering the TXUART transmission every 3 milliseconds, one 100 KHz square-wave generator, one 10 KHz square wave generator and one 3.3 KHz square wave generator.

These are just simple code samples to prove the OS design..... any code could be used as long as there were not too many simultaneous demands on the processor. After all, it is only a co-operative RTOS, not a pre-emptive one. So at very high demand moments, there can be some jitter in the high speed wave generators. The 9600 UARTs are rock solid.

The consumption of resources is fairly nominal; two registers per thread plus three timer registers. Each thread stores the number of ticks unil the thread will run again, and also the point in its thread where it will resume operation. This latter permits convenient branching at specified intervals or events.

The processor overhead is about 30% when high speed is involved; fairly high for tight and really busy applications, but  for modest for most.

In this version I have chosen the basic clock tick to be 5 uSec, and that is the fastest reasonable speed; from that a 100 uSec and 1 mSec tick are generated, and all threads run their slice of work based on multiples of any of those.

In the co-operative scheme each thread runs for a short while, such as inputting one bit in a UART, and then, instead of entering a delay loop, it relinquishes the processor back to the OS for another thread to have a go. The relinquishing thread notes where it left off, and when it gets another turn (after it's number of ticks from its chosen 5 uS/100 uS/1mS clocks have expired), it picks up where it left off, or alternately branches to another part of the thread.

I believe I have most of the bugs worked out, and would like to hear if you are interested in incorporating this concept into SX/B, thereby making it multi-tasking. Frankly though, there has not been much expression of interest in this concept..... perhaps many don't have the need, or don't understand the benefit of this.

Hi Peter,
I'm interested!

I have the need and I understand the benefit, but I've had trouble making use of the counters and stack with low-level languages. SX/B gives me enough familiarity with something else I already know (BASIC Stamp) that I can get much closer to the SX architecture. Although I want to make the time to learn, I just can't justify it when Parallax has other priorities for me and my free time goes towards machining. But every now and then, I build something that needs the SX for control and I throw a Proto Board at the project, but I find myself thinking like a Stamp programmer. That's okay from my perspective though, because after small amounts of hands-on experience Guenther's book and the SX/B commands make a lot more sense to me. SX/B is an educational tool of its own and I learn by using it.

If SX/B were able to provide some kind of multi-threaded support I'd be really happy. Even simple (for you) tasks like counting and generating pulses, running a UART and detecting button presses are examples of some things I'd like to do with SX/B. Even if it's a combination of ASM and SX/B, I could handle it if I didn't need to further tweak the ASM aspects of the OS. I know that you're thinking "no problem in ASM, Ken".

I think there are other customers in my situation, who've spent lots of their time with BASIC Stamps but would appreciate having far more horsepower and concurrent processing for just a couple of bucks, especially if SX/B took them there.

Ken Gracey
Parallax, Inc.

"I think there are other customers in my situation, who've spent lots of their time with BASIC Stamps but would appreciate having far more horsepower and concurrent processing for just a couple of bucks, especially if SX/B took them there".

I was looking at multitasking with the SX/B and basically it seems that  the multitasker is merely an ISR that divides the currently called ISR amongst a schedule .  
If you want something called more frequently, you give it more slots.  Since this specialized ISR jumps to the code, it would seem to me that the code could be in SX/B or assembler.  It just cannot be too long and overrun the ISR - 50% or less of the interrupt interval would allow the main program time to get something done.

While I haven't tried it, I suspect it is quite possible.  I refer to an old Ubicom document for a code prototype in SASM. See Dual UART Virtual Peripheral Implementation-AN39 [Nov 2000]
Frankly, it seems so simple in SASM that I might be harder in pure SX/B.

How about a set of standard VPs for the compiler, much like the Javilin does.

SEROUT, SERIN, PULSOUT, PULSIN, ANALOGIN, RCTIME, FREQOUT, etc.

Something like:

INTERRUPT 200000
 VPSERIN SInPin, "T2400", array_buffer, byte_head, byte_tail, byte_bitCnt
 VPFREQOUT SFreqPin, 1000, byte_progress
RETURNINT

Start:
IF byte_head <> byte_tail THEN
  char = array_buffer
  INC byte_tail
  byte_tail = byte_tail AND $0F
  ' Do something with "char"
ENDIF
I guess each VP would have to take the same number of cycles no matter what to keep everything sync'd.

Bean.

Hi Kramer;
Your suggestion is one way to tackle things, but then the time slot allocations are not dynamic which it needs to be for effective load sharing. In the scheme I'm proposing each thread can dynamically allocate when it needs to run again, (if at all, such as after a boot procedure), and it can also switch tasks in and out. There can be any (reasonable) number of tasks, but ony 8 running at one time in my current set up. That number (8) is not a hard number, just one that I chose. The more concurrent tasks that are running though, the more interaction (jitter) there will be, especially if the tasks are called very frequently, such as 100 KHz and up.

Achieving this is not as simple as you may think ..... at least that's my experience. But then what do I know. There are a lot of folks more capable than I am out there !

pjv,

  Will you be sharing your source code with the SX community?

  I think what you are offering could be quite useful.  Others more qualified than I will need to weigh in on the feasibility of incorporating it directly in SX/B.

Bean,

  Virtual peripherals that run in the background in SX/B would be great!  I am envisioning a Serin command that receives a specified number of bytes in the background then calls a user-defined subroutine to process the data when it is ready.  For Serout, I envision it sending a declared number of bytes from a buffer, then calling a user-defined subroutine when the buffer in empty.  The user-defined subroutines could be as simple as setting a flag or more complex such as processing or formating data.

  From my perspective, having the VP call a subroutine when it needs more data or has data ready to be processed is more useful and seems like it would make more efficient use of CPU time.  Sure I can always check the registers to see if more data is ready or needed but I think having the VP trigger a call to that section of code is a better approach.

Other thoughts...

  It seems like a code-generating "Wizard" might be useful here.  It could ask you questions about your clock rate, the number of tasks to be run, the required update frequency of each task, etc. and maybe warn you that although you requested an update frequency of X for task Y the best that can be achieved with the current configuration is a rate of Z.  When the "Wizard" completes it would generate a section of code to achieve the functions requested.

Peter,
I think that there is a good response to this. Remember, that there are a lot of people on here that are not too verbal (like myself). I am very interested. I think you're right that some users might not know the power this could bring. It's our job to enlighten them.

Hi Sparks;
You are definitely correct in being concerned about interaction in the case of this co-operative O/S. If one permits a thread to run for too long, then the various "tick clocks" well get jitter in them. And in severe cases, ticks could actually be missed; so you are probably right that some sort of "helper" would be useful to keep the unaware from outstripping the processor's capacity unknowingly.

Regarding your example of receiving a number of bytes, and then calling a routine to process them, the current implementation (although in ASM, not yet in SX/B) already supports that. This is where the task switches to another routine. Tasks can also launch and terminate other tasks, as well as terminate themselves.

Sure, I'll share this O/S with the community, but I want to do some more develoment and testing first, as well as write a good description of it as well as how to properly use it.... there are some restrictions. For example, the normal CALL/RET instructions cannot be used because different threads could (and certainly would, except for the most trivial cases) screw up the order and data on the call stack. So I have implemented  CALL and RETURN macros and a "virtual stack" concept where each thread takes care of its own. This area could still use some further development and improvement...... its a little unelegant.

In the mean time if anyone wants to try it (with the current warts) before I'm ready to release it globally, please express your interest. I will of course need to make up some descriptive information first.

pjv,
I am sure you can write something far more sophisticated.
Nonetheless, having something simple serves more as a bridge for learners to move from PBasic to SASM.
If people don't want to learn SASM, dynamic allocation is quite convienient.

It seems to be a split between being the educator or the rapid deployment of commercial uses.

PJV
Given the # of people that have asked how to make a BS2 multitask, I am surprised there hasn't been more interest in this thread. Maybe if you changed the title to Multitasking SX/B it would get more attention. A LOT of people would love to have a multitasking module for the Boebot.

Rick,
Here is something I setup last week. I converted my assembly VP library
to sx/b. Thanks to sx/b I no longer need macros to define VP code sections.
The SUB declarations take care of that now, so the library is easier to read.
Most subroutines however still have assembly. No escape from that for VP
I expect but there are subroutine you call from basic that set and retrieve
data from the VP's. It is not finished (or even properly tested) but it
shows in the test file how one would use the library.

I did some thinking about how threads could be supported in sx/b.

The following should apply, I think:
threads (lets call them tasks) should be coded in sx/b.
This means the __PARAMx will be used and therefore need
to be saved on each context switch.
Let a task be just a subroutine that is declared in advance (like FUNC and SUB)
with just 1 constant parameter, the task interval time in TASKTICK units.
eg. myTask TASK 100
TASKTICK equals a userdefined constant number of isr cycles.
To reduce the required resources, let there be only 1 context switch.
This calls the taskScheduler (which is generated by sx/b, based on declared tasks).
The taskScheduler executes outside the ISR and is called every TASKTICK.
It decides which task to call based on task interval time.
In effect, the mainloop code is interrupted by the taskScheduler.
It is the responsebility of the programmer to make sure the task subroutines
return within 1 TASKTICK unit. Using a statemachine in a task subroutine
will resolve any timing issue, if necessary.
Having 1 context switch also means the mainloop code continues before another task is
called that interrupts the mainloop code.
An option would be to have a rambyte per task to support on-the-fly task interval time.
This would allow a task to reschedule itself with a higher priority (could be useful
in case a statemachine is used inside a task).
Tasks that need tight timing should be written as drivers, something like my library setup.
This would mean the interrupt section should not contain sx/b code, as the compiler
can generate the entire isr code from supplied drivers and tasks.
Perhaps it is sufficient to specify a 'task' keyword:
interrupt task {,rate} 'interrupt line identifies isr used by drivers and tasks returnint
Or perhaps TASKTICK should be passed via interrupt keyword
interrupt 100,{rate}
Comments please.

Peter,
 I'm a little worried... because I think I'm actually beginning to understand how the task scheduling thing works!

 It sounds do-able. Let me think about the implementation and I'll post another reply.

 It would be very cool to get this implemented in SX/B.

Bean.

Peter,
 It is a requirement that the tasks be run-time configurable ?
 That will make it somewhat harder.

Bean.

What do you mean by runtime configurable?

To be able to start/stop/change TASKTICKS at run-time. I guess that would be a requirement wouldn't it ?

Bean.

Bean,
I attached a test program I am working on.
The Reschedule subroutine does not work yet, but I hope it shows
what I have in mind. I am testing using sx/b for the scheduler.
Once we have the fastest algorithm to achieve this, it could be
changed to assembly because in the end the compiler will
insert the scheduler code.
Note that I defined the tasks at this moment just as SUBs
with predefined interval times in the tasklist.
Once you have the TASK identifier, the compiler can fill the tasklist.

put taskId      , 0, 1, 2, 3, 4, 5, 6, 7
put taskInterval,10,13,17,23,29,34,37,41
put taskDelay   ,10, 3, 4, 6, 6, 5, 3, 4
 

 What happens if two tasks are scheduled to run on the same tick ?

Bean.

Yes, that is the idea. With a deltalist you only need to decrement the first entry.
With 2 tasks scheduled for the same time, the 2nd delay entry in the list is 0.
Since only 1 task is permitted to run that would give an extra delay of 1 to
the 2nd task. We need therefore to adjust the 3rd entry next time around
so other tasks do not have this extra delay. This is easily detected if the first entry
holds 0 upon TaskSchedule entry.

I changed Reschedule.
We need to find the correct entry for the new entry0 value.
Reschedule still does not work.

 ' initialization code here
'init lists in sorted order (this would be done by compiler based on task interval times)
put taskId      , 0, 1, 2, 3, 4, 5, 6, 7
put taskInterval,10,13,17,23,29,34,37,41
put taskDelay   ,10, 3, 4, 6, 6, 5, 3, 4
Main:
 ' main code here
 goto main
'insert new entry0 at correct position in list
SUB Reschedule
 index=1
 sumDelay = taskDelay(1)
 do while taskDelay(0) > sumDelay
   index = index+1
   sumDelay = sumDelay + taskDelay(index)
 loop
 insert = index-1
 if insert > 0 then
   for index=1 to insert
     indexMinus1 = index-1
     temp = taskId(indexMinus1)
     taskId(indexMinus1) = taskId(index)
     taskId(index) = temp
     temp = taskDelay(indexMinus1)
     taskDelay(indexMinus1) = taskDelay(index)
     taskDelay(index) = temp - taskDelay(indexMinus1)
     temp = taskInterval(indexMinus1)
     taskInterval(indexMinus1) = taskInterval(index)
     taskInterval(index) = temp
   next
 endif
 insert = insert+1
 taskDelay(insert) = taskDelay(insert) - sumDelay
return

At first run
taskId       =  0, 1, 2, 3, 4, 5, 6, 7
taskInterval = 10,13,17,23,29,34,37,41
taskDelay    = 10, 3, 4, 6, 6, 5, 3, 4
The 2nd run should occur in 3 ticks, entry0 (task0) must be rescheduled
At 2nd run
taskId       =  1, 2, 0, 3, 4, 5, 6, 7
taskInterval = 13,17,10,23,29,34,37,41
taskDelay    =  3, 4, 3, 3, 6, 5, 3, 4
The 3rd run should occur in 4 ticks, entry0 (task1) must be rescheduled
At 3rd run
taskId       =  2, 0, 3, 1, 4, 5, 6, 7
taskInterval = 17,10,23,13,29,34,37,41
taskDelay    =  4, 3, 3, 3, 3, 5, 3, 4
The 4th run should occur in 4 ticks, entry0 (task2) must be rescheduled
etc.

I got Reschedule working.
I simulated it using a javelin.
See the attached text files for timing tables.

The timing tables show:
If N tasks are running, the minimal interval time should be N.
If all tasks have identical interval time, they should have different start delays
We could define a TASK to take 2 constant parameters: startup delay and interval
eg. myTask TASK 3,10
Bean, you mentioned start/stop a task.
In my test program I support 8 running tasks, but since the taskId are loaded into ram,
we could define more tasks, but only 8 can run simultaneously. A few bits of the taskId
could serve as flags (status,suspend,dataready) which the mainloopcode can test.
Lets say 3 flags (b7-b5), then there still can be 32 tasks.

Since the arrays must be preloaded by the compiler, I think the task parameters
are best stored as data, using iread to preload the arrays.

From a user point of view, it might be better to specify a task interval time as a rate,
just as with interrupt. The compiler can calculate the interval time ticks. Also, the
initial taskDelay can be set to 1 for all tasks, meaning 1st task runs at 1, 2nd task runs at 2, etc.
After a task has run, it will be rescheduled using its interval tick.
So we can use myTask TASK rate where rate equals the number of times per second the task must run.
The totalTaskRate equals the sum of the 8 tasks with the highest rates.

From this TASKTICK can be calculated.
Example:
interrupt rate is 100_000 (isr cycle time is 10usec)
8 tasks all with rate 50, then totalTaskRate is 400
TASKTICK = isrRate/totalTaskRate = 100_000/400 = 250
TASKTICK should calculate into range 1 to 256, if not, the user must specify another interrupt rate
or other task rates.

Bean, you suggested that TASKTICK should be runtime configurable. I don't think that is
wise, because TASKTICK is global to all tasks. Better to change a task's interval tick to
adjust the task rate.
With the given test program, a task can easily change its own interval tick. When a task runs,
and it alters its interval tick, it will be rescheduled with this new tick upon return.
The only problem with changing interval ticks (eg. taskrate), is that TASKTICK also should be
recalculated then, and because of that, also the interval ticks of all tasks. However, if a task
changes its interval tick for a short time, and then restores the original value, it may
not give problems at all.

Peter,
 This is starting to sink in. So here is a dumb question... Is it possible to run two task during 1 tick ? (one after the other, not one interrupting the other).

Bean.

Since a task is just a subroutine, there is nothing stopping you
to call another task directly from a task. As long as both tasks together
take less than 1 TASKTICK unit there is no problem. If they do take
longer you miss a TASKTICK.
The demands are actually the same as for the isr.
You cannot have more cycles than assigned (via TASKTICK) or ticks will be missed.
It really depends on the application if that matters.
For a task that blinks a led it would not matter if a tick was missed.

Okay I'm missing something vital here... I thought that if a task took longer than 1 tick the interrupt would keep track of that and adjust the next task.

Why won't something like this work ? I don't see what all the "context switching" is doing...

  
DEVICE SX28, OSC4MHZ, TURBO, OPTIONX, STACKX
FREQ 4_000_000 
LED1    PIN RC.0 OUTPUT
LED2    PIN RC.1 OUTPUT
LED3    PIN RC.2 OUTPUT
LED4    PIN RC.3 OUTPUT 

cnt           VAR Byte
task_ID       VAR BYTE (4)
task_Interval VAR BYTE (4)
task_Count    VAR BYTE (4) 
  
INTERRUPT 100
  GOTO HandleInt 
  
TASK1   SUB 0
TASK2   SUB 0
TASK3   SUB 0
TASK4   SUB 0 
  
HandleInt:
  FOR cnt = 0 TO 3
    DEC task_Count(cnt)
    IF task_Count(cnt) = 0 THEN
      ON cnt GOSUB TASK1, TASK2, TASK3, TASK4
      task_Count(cnt) = task_Interval(cnt)
    ENDIF
  NEXT
RETURNINT 

  
  
PROGRAM Start 

  
  
Start:
  PUT TASK_ID, 0, 1, 2, 3
  PUT TASK_INTERVAL, 10, 50, 75, 100
  PUT TASK_COUNT, 1, 1, 1, 1 
  ' Main code here, do whatever...
END 

Task1:
  LED1 = ~LED1
  RETURN 

Task2:
  LED2 = ~LED2
  RETURN 

Task3:
  LED3 = ~LED3
  RETURN 

Task4:
  LED4 = ~LED4
  RETURN 

  

Bean,
To support running tasks scheduled for the same tick, in one tick
you can change
 if taskDelay(0) = 0 then
   on taskId(0) gosub Task0,Task1,Task2,Task3,Task4,Task5,Task6,Task7
   taskDelay(0) = taskInterval(0)
   Reschedule
 endif

into
 do while taskDelay(0) = 0
   on taskId(0) gosub Task0,Task1,Task2,Task3,Task4,Task5,Task6,Task7
   taskDelay(0) = taskInterval(0)
   Reschedule
 loop in subroutine DoSchedule
We then need to set a pending bit for TASKTICK, in case a task is already running
the moment a context switch should take place.

Bean,
Your example works, but is very limited in cycles, so you can only
have very small tasks.

The context switch enables a subroutine to execute directly after the isr
exits and before returning to the mainloop. The way it is set up, this
subroutine can not be interrupted by another task, only by the isr, but the
isr then never does a context switch.
The task may take a considerable longer time than the isr allows.

Please be patient with me Peter... I must get my head around this to implement it properly...

So if you do the context switch, then the task CAN take longer than 1 tasktick ?
If not how could you use more time than the isr would allow ?

If the task CAN take longer than 1 tasktick, then does it keep the next task on-time ?
Let's say we had two task that are at 10 tick intervals, but have a 5 tick offset.
Could both of these tasks take 3 taskticks each time they are run, and still always be exectuted  "on-time" ?
If that is the case, then it makes sense... If not how does the context switch allow longer tasks ?

Bean.

Bean,
If you have an int_period of 217 and no prescaler you only have 217 cycles available
inside the isr. Inside the isr a counter is decremented and when it reaches zero it
does a context switch, allowing a subroutine to run after the isr exits. This counter is
reloaded and decremented inside the isr while the subroutine runs as mainline code.
If the reload value is 100, then you have 100*217 cycles available for the subroutine,
assuming the subroutine must return to not miss the next context switch.
That is how it currently is setup.

I mentioned in an earlier post that timing issues with a task, eg. the subroutine takes
longer than 1 TASKTICK, can be resolved by using a statemachine in that subroutine
so you can make sure the subroutine returns on time. Next time the subroutine runs
it can continue where it was.

Your example of two tasks each lasting for 3 TASKTICKs and 5 ticks apart made me think.
I can change the setup so that when a task is already running when a context switch
should occur, that I decrement the taskDelay(1) by 1. That is sufficient to have taskDelay(1)
set to 2 when the running task returns after 3 TASKTICKs. That is quite a bit better
than the statemachine solution, though that still could be used.

Peter,
 So the interrupt occurs many times within 1 tasktick ? If so then that is where I was getting confused.

Bean.

Yes, the context switch rate is lower than the isr rate.

You know, Peter, I thought I was a reasonably bright guy until I tried following this stuff... wow, very heavy -- but with cool impliations.  So, by "context" to you mean the current task pointer?

Peter,
  I want to ask if every part of every program has to be split into nice little tick-sized subroutines in order to make use of the multi-threading structure you are creating.  It seems that some tasks are well suited to running whenever there is "extra" time between scheduled tasks.  
  For the background UART I finally got working I would like to buffer received data and, when enough bytes have been collected, begin to process it.  I would like to enter this processing subroutine without having to worry about what its longest possible execution time might be and what scheduled tasks it might be preventing from running.  
  Will the multi-threading structure you are developing allow some tasks (at least the designation of one that can be changed during execution) to be run in the slack or "extra" time between the completion of the currently scheduled task and the start of the next scheduled task?

  This seems useful to me.  I hope I am not missing the point!

Peter, Okay now I "get it".
Yeah, that IS pretty cool.
Let me "play" around with the code you posted and I'll investigate how to implement it into SX/B.

Bean.

Not quite.
You have the normal mainloopcode running. This gets interrupted by the isr.
If it is not time for a context switch, the isr exits and the mainloopcode continues.
If it is time for a context switch, the mainloopcode return address is saved and
the TaskSchedule address is placed on the shadow stack.
When the isr exits the subroutine TaskSchedule runs as mainline code.
This calls DoSchedule and there it is decided which task to run.

All this is mainline code. The isr keeps running. When the task returns TaskSchedule waits for the isr
interrupt to restore the context for mainloopcode, or if  RTCC is low enough
then TaskSchedule restores the context for the mainloopcode directly.

Sparks,
If you specify a task rate of 1000, then the task will run every 1msec.
That may be sufficient to pick up a received byte and store it in an array.
Another option would be, to reschedule a task so it runs sooner, and perhaps
only once (task on demand).

Peter,
What are the potential drawbacks of placing code between Main: and Goto Main in this section?

[CODE]Main:
 ' main code here
 goto main[/CODE]
It is my expectation that this section was left over from the use of the SX/B template and that while you intend to have an endless loop there you do not actually intend for user code to reside there.  Is that correct?

Thank you for your patience.  I know you are receiving a lot of questions about this.  :smile:

Sparks,
That is still the place to put your main code.
It is the main code that is interrupted by isr and tasks.
The tasks allow certain code to run without you explicitly
calling this code.

Ahh.!  :smile:

Thank you, Peter.  I really was thinking that your system required every single thing to be broken into tiny little tasks that could be handled by the scheduler.  I like it much, much better now that I understand I can still write big, ugly code for my main program and only use the task scheduler for tasks that I want to run at very specific intervals.

Thank you for your patience with my questions and for the clarification.

I changed the code to adjust for a missed TASKTICK.
Also changed DoSchedule so tasks scheduled to run at the same tick,
are now called after each other without returning to mainloopcode first.
Also added the save and restore of the sx/b variables __PARAM1 to __PARAM5.

Peter,
 I assume it is okay with you if I put this code in the SX/B compiler ?

Bean.

Sure.
You may even (or must) relocate the kernel and list variables,
probably moving them toward the last rambank.
How do you plan to use the variables
index var byte
temp var byte
sumDelay var byte
indexMinus1 var byte
moveup var byte
that I used in the TaskSchedule, DoSchedule and Reschedule routines?
I would hate to loose 5 normal variables,
especially since there are so few of those.

I'll have to figure that all out after I get it implemented. You're right the arrays will be moved to the highest addresses. I hope to preserve the "normal" variable space, that is very dear.

I just didn't want to "rip-off" your code.

Bean.

I understand that.
I managed to relocate two normal variables into kernel(16) array.
If we decide that TASKTICK should be a constant, calculated from interrupt rate
and totalTaskRate (or set by user via interrupt keyword or special keyword), then kTimer var kernel(6)
could be used for moveup.
Then the code only uses 2 normal variables, index and indexMinus1.

Peter,
The SX/B instructions only ever use __PARAM1 .. __PARAM4, so __PARAM5 (aliased address of __PARAMCNT) would not be affected.  __PARAM5 is only used by the programmer when they know that a function or subroutine needs exactly five parameters.

Jon,
I have seen code where _PARAMCNT is used upon entry of a subroutine.
What if the isr interrupts when main code has just entered such a subroutine,
and the isr code itself does a gosub to some subroutine that may take a variable
number of arguments? That would affect _PARAMCNT I think.

Indeed, it would.  If the parameter count is less than 5 then __PARAMCNT is loaded with the number of parameters; if exactly five parameters are used then this register is used for the fifth parameter (the compiler uses the SUB/FUNC declaration to determine which action to take).  The programmer must be aware of the danger of using __PARAMCNT this way; it might be better to pass the address of an array if more than four parameters are required.

If _PARAMCNT is loaded with the number of arguments for any gosub,
then you cannot use gosub in the interrupt section because that will
destroy _PARAMCNT, unless the sub called from isr happens to have
an identical number of parameters.
I also know that most subroutines have a fixed number of parameters
and therefore _PARAMCNT is hardly ever used, but still, this could lead
to some erratic program behaviour, which might not be repeatable,
and therefore almost impossible to debug.

The compiler will not manipulate __PARAMCNT if you specify exactly zero or exactly five parameters in your SUB/FUNC declaration.  To your point, this is rarely the case and using __PARAMCNT/__PARAM5 to pass a value can be dangerous; I don't do it.

The attached version runs (SX48) , generating "RESET" followed by a stream of digits.
'0' for task0, '1' for task1 etc.
Just set pinTX to I/O port of choice and connect via level shifter to pc com port.
Baud 9600,8N1.

There is one issue, task7 never runs. Actually, the task initially at entry7 (=task7) of the
tasklist never runs. Have not figured out yet why that is.
My simulation showed task7 does get to run.

Peter,
 I am sorry to bug you about this.  I know you said that your latest code was for the SX48 but.  I would like to try it on my SX28.  :blush:

  I tried to make the conversion myself by reducing the number of tasks from 8 to 4 with the following changes.

[CODE]DEVICE          SX28, OSCHS1
.
.
.
tasklist var byte(12) '4 tasks supported
taskId var tasklist(0) 'order of task running
taskDelay var tasklist(4) 'delta time list
taskInterval var tasklist(8) 'reload delay values for tasks
.
.
.
put taskId      , 0, 1, 2, 3
put taskInterval,10,13,17,23
put taskDelay   , 1, 1, 1, 1
.
.
.
 for index=1 to 4
   if index=4 then exit
.
.
.
 if index < 4 then
.
.
.
 if moveup < 3 then[/CODE]
 I also tried the inverted serial mode but I always get 12-13 non-text bytes sent whenever I reset the SX28 no matter what serial setting I use.

My questions are as follows.  Is it possible to make your task-switching demo run on an SX28?  If it is, do you mind posting an SX28 version when you have time?
  I hope I am not becoming a pain.  I am just trying to figure this out!

The attached program compiles.
I did NOT test this, but I think it should run.

Yes, yes!  :hop:

  The program is running, Peter.  Now so am I!  I am off to try to make sense of the strange sequence of numbers and dashes slowing filling my terminal window.

  Thank you for providing the demo and for re-providing it in an SX28 version. :smile:

How will this be implemented in the SX/B compiler ???

Sparks,
The sequence is not that strange. If you observe a specific digit, for example 0,
you will notice that there are ten ticks between 0's. The pace is slow enough
to count. This 10 is the supplied interval time in taskDelay array.
The same applies to the other digits (eg. tasks).

[Quoting: "Ibsen"]

How will this be implemented in the SX/B compiler ???

Anyone using the multitasking programs, I have discovered a bug in the SX/B compiler that affects these programs.

Where Peter has aliased the array element bits:

kMisrRunning var kFlag.6
kMisrFinished var kFlag.7
These aliases don't work properly. Actually both get aliased to just kFlag.

The fix is to do this:

kMisrRunningBit  CON 6
kMisrFinishedBit CON 7
Then in the program replace "kMisrRunning" with "kFlag.kMisrRunningBit"
and replace "kMisrFinished" with "kFlag.kMisrFinishedBit"
Bean.

Hi Bean,
Thanks for that info.
I was just debugging the programs using larger delays in the tasks.
The tasks then appear to get stuck (eg. only 1 task keeps running).
I adapted the programs with your suggestion and they seem to run ok now.
I will upload the modified programs shortly.

Here is the sx28 version.

Don't forget to set pinTX to the I/O port you want to use.

As promised, the sx48 version.