A single port RS485 or modified RS232 could do this. data rate is low compared to time available. PC knows which modules are free and could do total task by master control. Initially ALL are free. PC assigns task(s) to module(s) PC is now able to periodically ask modules which have tasks if they are finished yet. This can happen fast enough that there is minimal delay compared with the length of the tasks but infrequently enough that the PC largely free for other tasks. Declare all modules free Forever Do stuff On 100 millisecond IRQ or whatever Do routine below Loop On IRQ etc If new task available Assign task to known free PIC Endif For all known busy PICs Request result If result provided Process result. Declare related PIC free Else Task not finished - ignore (could be busy reply or no reply) Endif Next End You could ask all PICs for explicit status occasionally to ensure you don't lose track of PICs which think hey are free when you think that they are busy. The above saves collision arbitration. PICs only ever talk when spoken to. Buy me a Pepsi and I'll happily push ideas on this around on paper with you. Lesee - 20 Byte pkg @ 19200 baud = 20*10/19200= 0.0104 second About 10 in whole of 100 ms. Status requesting can be single bytes with 1 byte answer so most of time its very quick. Average data rate is MUCH lower than this. As long as PICs have fixed addresses PC can keep track of additions easily. This can be address straps on a board or eerom set or whatever. If all are IDless at startup then some initial address assignment protocol with address contention may be needed but this need not continue for the main task as each can be given a unique ID. Say there are 20 max PICs & PC polls for 1 new PIC every 0.1s say so it picks up a new addition within 2s. This could be quicker. A full PC controlled poll can be done with 1 byte out, 1 byte back and about 1 byte delay between. Getting PC into realtime serial handling may be hardest part - having a master twixt line and PC may be useful - cheap still though. 20 slaves x 3 bytes /19200 = 0.03s for total update. eg o/g 5 Address 1 Report / I have a message for you 2 Spare i/c 5 Address 1 Free / Data ready 2 No error correction here. 1 word messages can be > 8 bits, especially if their is a PIC master handling the line. regards Russell McMahon _____________________________ What can one man* do? Help the hungry at no cost to yourself! at http://www.thehungersite.com/ (* - or woman, child or internet enabled intelligent entity :-)) From other worlds: www.changingourworld.com www.easttimor.com www.sudan.com >I've a job to look at that requires several, possibly a dozen, >modules to hang off a PC com port. The PC holds 20-byte >packets, which are complete messages in themselves. It >has to look for a module that's not busy and send it a packet. >The PIC in the module performs a small calculation and then >returns the result back to the PC. BUT before it returns the result >it has to wait maybe several seconds before doing so. This >is because another external device has to do something the >module will refer to. This means I can't perform the whole >operation in sequence with each module before moving on to >the next. > >In other words, 10 packets may be thrown out to 10 modules but >each module will take an indeterminate time to return the result >to the PC. A new packet might be available to send to this free >module immediately, but if there isn't then this module will have >to be ear-marked as free for the next available packet > >Each module can be assigned an ID number as part of the >packet so the PC will recognise where a returned result came >from. All of the modules will be together physically as plug-ins >on a motherboard, which has one short cable to the PC > >1:1 comms between a PIC and a PC I can manage, but what >would be the most efficient way of fanning out a PC port to >several devices ? I'm looking at either 19k or even 56k but >speed isn't critical, particularly with such small finite packets. >What I'd like to know is more about how to create a system >that can be polled for an available module. Modules may be >added or removed so the system has to be somewhat flexible. >There can be no inter-connectivity between modules. Cost is >especially critical - I'm stumping up for the prototype !!! But >it's a shared venture and I daresay I'll be re-imbursed one day > >Which protocol would be most suitable ? > >What glue could I use between the PICs and the PC to indicate >that a module is busy and/or is ready to send its result ? > >Is there a way to poll, for example, a Busy pin or would the PC >have to re-communicate with each module to find out if it's still >busy or free for a new packet > >TIA >__________________________________________ >Even if you're on the right track, you'll get run over if you >just sit there > >-- >http://www.piclist.com hint: The PICList is archived three different >ways. See http://www.piclist.com/#archives for details. > > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.