No Google for you!

For the past few years I have been specializing in Google driven development. Its exciting!! I've never had to read a software programming book ever since! It is simple. You should try it too!

Copy! - Once you enter the key words in your requirement in google, you get a list of possible solutions to your problem. You then move your mouse over the first link and click the left button.

Copy(Ctrl-C) anything between flower braces and the sentence before that.

Paste!! - Alt-Tab, Ctrl-V

Comment!!! - within /* .... */ replace the first three '...' with your search words. The fourth '.' is all the punctuation you will need!

Checkin!!! :)

This is maintenance/rewrite friendly too as the guy after you will need just your keywords and the process flow document for GDD!!!

Semaphores

Implemented semaphores. Each semaphore holds a list of tasks that are waiting on it. You can create one with an initial value N. N is the number of tasks that can concurrently access it. It gets decremented every time a task calls a semaphore. If N is already 0 when a task requests a lock on it, the task has to be suspended. Tested with two tasks. Need to test that more.

Implementing threads should be easy. Something about last words comes to mind :)! In switching a task, you have to switch a whole task out and put the new one in. For threads, you don't have to swap out the context of a task, just the PC and a much faster timer for each thread in the process. So the process TCB struct has to change to accomodate threads.

Finally getting a feel for what a scheduler should look like! It is a state machine duh! Now as far as implementing state machines go, I have no idea :).

Round Robin

Writing your own scheduler can be illuminating :). I realized that it is one thing to conceptually "understand" the algorithms involved and entirely another to come up with your own source from scratch. Trouble is *other* things get in the way.

1. Debugging debugging debugging. How are you going to test your code on bare metal? A simulator can be a life saver here. I'm working on a hand wired C501 dev board using SDCC and JSIM.

2. Target Architecture -
Maintaining stack integrity. How is the stack pointer incremented? Can it address all of memory? Probably not. Is the high byte/word pushed before or after the low one during a function call? How big is your stack anyway?
I mean do you have to swap the stack to RAM too during a context switch?

Registers - How many registers do you have to push? The one I'm working with has 32 general purpose ones. Only bank '0' (zero) is used most of the time.
Timer - Mine has 3. What mode to use? How fast is the context switch? what is the %time slice per process?
Can you get by with setjmp and longjmp? I saw lightweight threading support added using just setjmp and longjmp.

3. Organizing code - Since you are pretty much juggling around with stacks, I got burnt breaking up my code into functions. So I'm exclusively relying on 'C' style macros for any semblance of organization. Its hairy to say the least. The actual data structures and algorithms are pretty simple.

Just in case you were wondering mine is a round robin scheduler. The code is here.