I have interrupt driven SPI putting bytes into Q1

Task1 blocks on Q1 and gobbles the bytes, eventually putting bytes in Q2. There
will be far fewer bytes sent to Q2 than Q1 but there is some atoi() kinds of
things in the process.

Task 2 blocks on Q2 and takes the ASCII strings and packs them into Q3 which has
multiple packet sized blocks of around 512 bytes. I suppose this could be done
in Task1 but having a separate task seems cleaner even if it wastes a little RAM
for Q2.

Task 3 blocks on Q3, grabs the packets and sends them on their way via uIP.
Other than ARP traffic, uIP will not be receiving packets for the application.

uIP looks at some kind of startup flag and decides that if there is a passive
connection (via uip_listen()) that this is the destination for the packets. If
there is no passive connection, it makes an active connection to a known host (a
LaserJet in this case) and sends the packets there.

There is also an unrelated 'flash the heartbeat LED' task.

The questions are about priorities.

1) What would be a reasonable assignment of task priorities? Right now I have
Task1 as lowest, Task2 next, Task3 and then the LED task highest. Does that
seem about right?

2) What should be the priority of uip AppCall()?

I have the project working up to the point of starting work on the uIP part. I
have experience with uIP and I will use the LPC2106 demo code as a start.

Thanks
Richard