[sdiy] 1 bit serial stream delay approaches..

[Tom Wiltshire]

So do it the first way - (A).

Designing a system such that it unnecessarily includes nightmare problems that you then have to (literally) sort out sounds like a definition of lunacy to me.

I understand the potential for an event to finish up going out earlier than another in (B), but I don't see *why* anyone would want such a system, even if they could be bothered to implement it. The original post was looking for a simple way to implement a very long (5 second) shift register with good time resolution. (B) doesn't do that. (A) is much closer in both concept and output to a long shift register clocked with a variable clock.

Tom


On 24 Sep 2012, at 14:01, Olivier Gillet wrote:

>> Sounds to me like you're over-thinking this, unless I'm missing something. I don't see any problem with voltage-control of delay time, either way you implement it.
> 
> It depends on your delay semantics. If at time t, the delay time is
> 500ms, does it mean:
> A/ I should play at time t any event which was registered at t-500ms
> B/ I should play at time t+500ms any incoming event.
> 
> If you follow the A/ approach, it's very easy to keep the event list
> sorted - events are just added in order to it, and this can indeed be
> done with a FIFO. A change in delay time will just rush the flushing
> of the list...
> 
> But if you follow the B/ approach, here is what can happen (assuming
> an initially empty event list):
> - At time t, the delay time is 300ms and an event arrive, it is thus
> scheduled for t+300ms - the event is inserted at the beginning of the
> list
> - At time t+10, the delay time is 200ms and an event arrive, it is
> thus scheduled for t+210ms - the event must be inserted at the
> beginning of the event list.
> - At time t+20, the delay time is 400ms and an event arrive, it is
> thus scheduled for t+420ms - the event must be inserted at the end of
> the event list.
> - At time t+30, the delay time is 100ms and an event arrive, it is
> thus scheduled for t+130ms - the event must be inserted at the
> beginning of the event list
> 
> Since the variation of delays might alter the order of events, you
> might have to insert the event somewhere in the middle of the list,
> which requires O(log n) operations if the event list is kept sorted
> (and not O(n) as stated).
> 
> Olivier