I don't know what you mean by "UWB" (use standard or common abbreviations, no I'm not going to look it up, it's your job to explain), but many many micros have 10 bit A/Ds and SPI hardware. Even without the SPI hardware, SPI is simple to do in firmware by controlling the I/O lines directly.
In the Microchip line, there is a wide spectrum that meet these requirements. A low end PIC 16 can be small, cheap, and very low power. A fast dsPIC33 can run up to 40 MIPS but of course will use more power. There are various PIC 18 and PIC 24 in between.
What you need to explain is how fast you need to sample the 10 bit A/D and what the micro needs to do to these 10 bit values before passing them on via SPI.
This "answer" is more of a comment because too much important information is lacking. It can be turned into a answer if you cooperate and answer the specific questions asked, not what you feel like answering or or you think is important. As it stands, this question is too vague to be reasonably answered and should be closed. People will come by and close it as they encounter it. When 5 close votes are cast, it's over. The clock is ticking. You may have only minutes to a few hours. Do what I said exactly as I said quickly and you may get your answer. Ignore it and not cooperate and you'll be sent home without a cookie.
Added:
You have now added that the A/D sample rate is 500 kHz and that this raw A/D data is to be passed on via SPI. Since the A/D is 10 bits, this is apparently where you got the 5 Mb/s SPI data requirement from.
This is doable, but will require a reasonably high end micro. The limiting factor is the 10 bit A/D at 500 kHz sample rate. That's quite fast for a micro, so that limits the available options. Another thing to consider is that there is more to SPI than just sending the bits. Bytes may need to be transferred in chunks with chip select asserted and de-asserted per chunk. For example, how will this 10 bit data be packed into 8 bit bytes, or will it at all?
The main operating loop of the firmware will be quite simple. You probably set up the A/D to do automatic periodic conversions and interrupt every 2µs with a new value. Now you've got most of 2µs to send it out the SPI. If the device really can just accept a stream of bits, then it might be easier to do the SPI in firmware. Most SPI hardware wants to send 8 or 16 bits at a time. You'd have to buffer bits and send a 16 bit word 5 out of every 8 interrupts. It might be easier to just send 10 bits each interrupt in firmware.
Sending SPI bits in firmware if you only need to control clock and data out is pretty easy. Per bit, you have to:
- Write bit value to data line.
- Raise clock
- Lower clock
It would make sense to unroll this loop with preprocessor logic or something. A PIC 24H can run at up to 40 MIPS, so you have 80 instructions per interrupt. Obviously you can't use 8 instructions to send each bit. If you can do it in 6 it should work. There is some overhead to get into and out of each interrupt, so you might make the whole thing a polling loop waiting for the A/D, but then the processor can't do anything else. I'd probably try to cram this into the A/D interrupt routine using every possible trick so that at least a few forground cycles are left over for background tasks like knowing when to stop, etc.
Check out the Microchip PIC 24H line. I think most if not all have A/Ds that can do 500 kbit/s, and they can all run at least up to 40 MIPS. The new E series is even faster, but I'm not sure how real that is yet.
At the risk of sounding like a broken record...
PSoC5 is your answer! (It's amazing how many times PSoC is the answer)
The PSoC5 MCU has an ARM Cortex M3 core, and a bunch of other brilliant features that practically no other MCU has. Unlike other MCUs, setting up the peripherals is as fun as eating ice cream, and you can even create your own in Verilog! The IDE is pretty good, and totally free.
The Development Kit is great, and full of features and comes with the programmer, which you can use for your future projects. It's not too expensive.
Best Answer
There are two main types of multitasking operating systems, preemptive and cooperative. Both allow multiple tasks to be defined in the system, the difference is how the task switching works. Of course with a single core-processor only one task is actually running at a time.
Both types of multitasking OS's require a separate stack for each task. So this implies two things: first, that the processor allows stacks to be placed anywhere in RAM and therefore has instructions to move the stack pointer (SP) around -- i.e. there is no special purpose hardware stack like there is on the low-end PIC's. This leaves out the PIC10, 12 and 16 series.
You can write an OS almost entirely in C, but the task switcher, where the SP gets move around has to be in assembly. At various times I've written task switchers for the PIC24, PIC32, 8051, and 80x86. The guts are all quite different depending on the architecture of the processor.
The second requirement is that there is enough RAM to provide for multiple stacks. Usually one would like at least a couple hundred bytes for a stack; but even at just 128 bytes per task, eight stacks is going to require 1K bytes of RAM -- you don't have to allocate the same size stack for each task though. Remember you need enough stack to handle the current task, and any calls to its nested subroutines, but also stack space for an interrupt call since you never know when one is going to occur.
There are fairly simple methods to determine how much stack you are using for each task; for example you can initialize all of the stacks to a particular value, say 0x55, and run the system for a while and then stop and examine memory.
You don't say what kind of PIC's you want to use. Most PIC24's and PIC32's will have plenty of room to run a multitasking OS; the PIC18 (the only 8-bit PIC to have stacks in RAM) has a maximum RAM size of 4K. So that's pretty iffy.
With cooperative multitasking (the simpler of the two), task switching is only done when the task "gives up" its control back to the OS. This happens whenever the task needs to call an OS routine to perform some function which it will wait for, such as an I/O request or timer call. This makes it easier for the OS to switch stacks, since it is not necessary to save all of the registers and state information, the SP can just be switched to another task (if there are no other tasks ready to run, an idle stack is given control). If the current task doesn't need to make an OS call but has been running for a while, it needs to give up control voluntarily to keep the system responsive.
The problem with cooperative multitasking is if the task never gives up control, it can hog the system. Only it and any interrupt routines that happen to be given control can run, so the OS will seem to lock up. This is the "cooperative" aspect of these systems. If a watchdog timer is implemented that is only reset when a task switch is performed, then it is possible to catch these errant tasks.
Windows 3.1 and earlier were cooperative operative systems, which is partly why their performance wasn't so great.
Preemptive multitasking is more difficult to implement. Here, tasks are not required to give up control manually, but instead each task can be given a maximum amount of time to run (say 10 ms), and then a task switch is performed to the next runable task if there is one. This requires arbitrarily stopping a task, saving all of the state information, and then switching the SP to another task and starting it. This makes the task switcher more complicated, requires more stack, and slows the system down a little bit.
For both cooperative and preemptive multitasking, interrupts can occur at any time which will temporarily preempt the running task.
As supercat points out in a comment, one advantage cooperative multitasking has is it is easier to share resources (e.g. hardware like a multi-channel ADC or software like modifying a linked list). Sometimes two tasks want access to the same resource at the same time. With preemptive scheduling, it would be possible for the OS to switch tasks in the middle of one task using a resource. So locks are necessary to prevent another task from coming in and accessing the same resource. With cooperative multitasking, this not necessary because the task controls when it will release it self back to the OS.