Boarderdude7814 said:
that sounds great. serial control, assuming there already is software to con trol a pic from the serial i wouldn't have to "reinvent the wheel" will that method enable me to trigger multiple outputs at the same time? and can you physicaly hook more that one pic together to get "more outputs"?
Hi again, Nigel addressed (punn intended) the 'more outputs' bit nicely.
To trigger outputs at the same time...well, depends if you want them to 'update' (ie: trigger, toggle, change state, on/off) at
exactly the same time, or whether a small delay (5-50us) is allowed. If they are 'chained', what you would have is just 3 lines, data, clock, and 'strobe'. Configured like this it behaves like one massive shiftregister, who's parallel outputs are a multiple of 8 (if you use 8-bit SR's). The thing with that is, to update/trigger just one of those outputs, you would have to (re)write all the data to that massive SR again, with exactly the same data, apart from the bit you've changed. For 100 outputs (needs 13 8-bit SR's) thats 13 bytes, of which only one bit is changed.
Sounds like a lot of redundancy, but really, in terms of PIC software, thats pretty simple. Have a routine that 'updates' the SR array, it just sends the 13 bytes one after the other...and to change one or more outputs, just XOR one (or many) of the bytes with a 'bit mask' and call the above routine.
The other method, would allow you to 'update' 'bytes' at a time, but not the entire thing at once.
I realise you're talking about triggering fireworks, and timing is the whole point of it, but we're talking latency (from your PC triggering to the output triggering) in terms of microseconds, if you're using serial, maybe a ms or two. And that'll go for both methods. Even if it does, the latency should be fixed, that is, the time between your fireworks whizzing off will be the same, but the delay would be relative to your PC triggering.
Sorry for typing so much, it seems I always have to go into detail, terrible habit I know
I'm not sure what you mean by 'real time', as opposed to 'store and run'. Once programmed, it'll execute its firmware on startup. But your program should be doing nothing until it gets data from the PC, then it does its thang, and goes back to waiting. So I guess, as far as programming concerned, its 'store and run'. But your 'program' runs in 'real time'.
Edit: Wow, I repeated myself a lot there, sorry.
Blueteeth.