solarwind wrote: > : 1 byte. Start of packet. 0xAA. Pointless. All nodes should know where the start of packets are, else you will have other problems anyway. A signature byte doesn't guarantee start of packet unless you guarantee it can never occur in the rest of the packet. This can be done if necessary, usually by using a escape byte. I wouldn't do that here though. > : the 8 bit polynomial checksum 8 bits is very small for the size packets you are talking about. It may be good enough for your purposes if you don't really expect errors, which might be applicable in your case. > If the node has no data to send, it will pass > the token to the next node in the bus, which is it's own ID + 1. What happens when there is no node at this address or it went down or doesn't respond for some other reason? Somewhere you need to have a timeout that allows recovering from dead node that has the token. In your kind of peer to peer network, it gets very tricky deciding how to recover. Things get somewhat easier if you have a single bus master that interrogates the slaves in turn and handles the timeouts. You also need to think about timeouts when a ACK is not received. Think carefully about what happens when the ACK itself is lost. The receiving node got the command, executed it, and sent the ACK. The transmitting node has to assume the receiver never got the command. Most likely it will resend after a timeout, but you have to think carefully about what the receiving node might do if it receives two separate valid commands. A sequence number is the usual way around this, but there are other strategies. This is a bit of a aside, but you should go read the RFC for TCP. I know you're not trying to implement TCP, but it is a quite readable document that deals with a lot of the same issues you have created for yourself. You will see that people have thought about and solved these problems long before you were born. > The packets shall be examined as CPU time permits. > > One question to you all though: since this type of network requires > the constant examining of packets, I assume it takes a lot of CPU > time. Not really. The bigger problem with small systems like PICs is the buffer space to hold packets. The checksum forces storing the whole packet before acting on any of it. You may want to limit the maximum packet size for this reason alone. For example, you have pretty much made it impossible for a 16F or lower to participate in this protocol. However, the cycles for validating and interpreting a packet are pretty minimal. Think how many cycles you have per bus byte. At 115.2Kbaud each byte takes 87uS. That's 434 instruction cycles per byte assuming a 20MHz PIC, and it takes a few bytes at least for a packet. Even with short packets you have a couple of 1000 instructions to spend. The packet processing overhead will be a tiny fraction of that. Of course it may take more to perform the command itself, but that is up to how you define the commands. > If I have other things to do, how do I create "tasks" so that > the real tasks such as getting data from sensors, turning off the > lights, and so on is done on a high priority basis? You don't need priorities, since you've got plenty of CPU time to go around. A simple round robin task manager should be just fine for this. Each task does whatever it can do immediately, then calls TASK_YIELD to let all other tasks run once. When a task is waiting on a external event, it sits in a loop checking the event and calling TASK_YIELD until the event condition occurs. Take a look at my QQQ_TASK.ASPIC template source module. It implements just such a simple task manager for a PIC 18. I've used it a bunch of times when it is convenient to have several independent threads each doing a simple task. This kind of firmware architecture is often useful when dealing with asynchronous input streams. Input streams usually need some sort of state machine to interpret them. A conventional state machine is cumbersome, but a task written such that the PC becomes the state variable often makes the code work out nicely. It's often a very useful abstraction to have the input processing code appear to go and get the next input byte even though the input byte comes in when it comes in. A task is a easy way to get this abstraction. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist