OSDev.org

I just ordered a Arduino Uno r3 from tenettech.com.I'll get it soon,but I thought I could build an OS for it.
Main considerations:

• Some code(inijobs) runs in the start of every cycle(500msec) before kernel processing(like code that outputs NTSC signals
  )(max 2,25 msecs)
• Every job(4 max,100 msec each) runs depending on their priority after all inijobsand kernel processing
• A job is a loop,which is like a process
• All jobs,inijobs and kernel processing should be fast.(just 500 msecs on hand.)
• total kernel time every second is 50 msecs
• inijobs time is 50 msecs
• jobs time is 400 msecs
• one cycle is 500 msecs

What's your opinion on it?

While it's a fine idea, I honestly do not see why. IMHO when you're developing some firmware for MCU (no matter AVR, or any other microcontroller) you should focus only at task that MCU has to do.

With only 2KiB if RAM and 32KiB of program space (as ATmega328, running on Arduino Uno r3 provides) there are no much space to waste for OS. And since AVR's program space should be considered as read-only memory (yes, there are facilities to rewrite it, but they're slow and have limited write count), it's not likely you'll load executables at run-time anyway.

I've built a few MCU-based devices (most noteworthy one being IR remote controlled dimmer/switch for lights in my room, which is operating as I type this). There's really no need for multi-threading, most of the logic turns out to be interrupt-driven anyway. I have yet to see a device, where main loop does much more than calling sleep instruction (AVR's equivalent for hlt) repeatedly.

While there are some OS-es available already (FreeRTOS, for example), I've still have not found a reason to use them. I have not even adopted Arduino libraries. Just gcc-avr and avr-libc is all that I need. And even then I sometimes revert to plain AVR assembly.

Low-end microcontrollers like the Arduino are best suited for single task systems. E.g. one Arduino set up to control sprinklers, another Arduino set up to control your blinds, so they usually run single purpose built software that controls the hardware at a very low level to achieve their goal.

Rather than an 'operating system', you could always provide a library or application framework that provides threading, dynamically loading processes (in most cases it'll take up less room to flash the executable code in to ROM, than it would to flash a binary image in to ROM and dynamically load it into RAM), resource management, etc.

Back on topic - try looking at the http://beagleboard.org/.

1GHz ARM processor, modern embedded GPU, 512MB RAM, audio, ethernet, USB, S-Video/DVI-D/HDMI output, etc.. Can run Linux, Windows embedded, or write it all yourself (the hardware is open).