[sdiy] 1 bit serial stream delay approaches..

[Jean-Pierre Desrochers]

The approach I'd prefer *for now* is the following:
I'd choose a fixed counter lenght that would be
used for the shift registering. Let's say it has a fixed max value of 1024 steps (0-1023).
I'd continuously increment in time its value from 0 to 1023 
then back to 0 and so on..
but each step would be separated by a variable delay from 20usec
to 5msec.
For example:
1024 steps x 20usec = 20msec delay (minimum setable delay)
1024 steps x 5msec. = 5.12 sec. (maximum setable delay)
The delay time is derivated from a DC value from a pot cursor
to an ADC of the PIC.
Whenever an ON or OFF event comes in it writes the event type 
& the actual register counter value (time stamp)
like this:
event_counter = 0;
.
.
.
event_type[event_counter] = ON;
event_time[event_counter] = reg_counter_value;
event_counter++;

and when the reg_counter did a complete cycle
and reach back a preceding event at a specific
reg_counter_value it outputs that event to a pin
(already delayed by the pot delay value)
then it flushes that event from the stacked event list.
It does that until the stacked list is empty.
That's it.
JP



>In the shift-register scenario, to make the most of your available memory 
>you'd want to use a single bit to indicate HIGH.
>Write the input gate state to one bit index, and read it from another, the 
>difference being your delay time.

>Increment both indices and repeat on the next timer interrupt.
>You increase the delay time by increasing the offset to the read index 
>and/or the timer period.

>Did I get that right?

>/m

On 24 Sep 2012, at 16:33, Jean-Pierre Desrochers wrote:

>>
>>The GATE *events* could be like the following:
>> ON....OFF...........ON.OFF............ON.............................OFF...
>> all produced in a short period of time (for example < 500msec.)
>> and delayed of 3 sec for example again.
>> That's why the *shift register* approach should be able to register all 
>> these
>> so called events without missing one.
>> JP