[PD] regression testing WAS Re: [psql] object hand-holding
martin.peach at sympatico.ca
Mon Dec 24 20:30:07 CET 2007
Mathieu Bouchard wrote:
> On Mon, 24 Dec 2007, Martin Peach wrote:
>> Mathieu Bouchard wrote:
>>> In most tristate electronics, the third state is WAIT,
>> In digital electronics the third state is high-impedance, that is, it
>> is not driven high or low. However, a device reading a Hi-Z output
>> will itself always output either 0 or 1 and has no way of telling
>> that it is connected to a Hi-Z output,
> No, I'm not talking about the high-impedance state, especially because
> it can't be read easily. The other kind of tristate is at a higher
> level than that and is implemented as "dual-rail" wires: 10 = false,
> 11 = true, 00 or 01 = wait. This is useful for making clockless devices.
OK, but that's not called tristate, and "dual-rail" usually means having
two power supplies (e.g. plus and minus 5V instead of just 5V).
What you are describing is like a two-wire serial setup where the data
on the second wire is only considered valid when the first wire is high.
It's not clockless, in fact the first wire is usually named "Clock".
> Clockless devices are interesting because they can very gradually
> adapt to the "weather": if you remove the heat sink it will
> automatically slow down, and if you dip it in liquid nitrogen it will
> very much accelerate, without any clock, any thermometre, any power
> management device, etc..
The clock frequency is affected by temperature, but it's still a clock.
I guess you're saying that a crystal oscillator is a clock and a RC
oscillator is not, which is a new meaning to me.
Even crystal oscillators are affected by temperature because the crystal
gets bigger as it warms up, if you want a stable frequency you need to
run it in temperature-controlled oven.
> In clockful devices you usually don't have that many WAIT lines, so it
> does not make sense to count them as a 3rd state. Instead, a 8-bit bus
> would have 257 states (2^8 + 1) using 9 wires, and so on, but even
> then they are used as little as possible, and bunch of delays are
> hardcoded and missed deadlines make the CPU crash or do weird things
> (I've *seen* it in a Pd patch once!).
If you have 9 wires you have 512 possible states, so it's wasteful if
256 of them mean the same thing. That may be why the two-wire system is
not much used. Cpus often have a line to indicate if the data on the bus
is valid or not (as well as other lines that indicate what kind of data
it is). And you can add wait states to memory access cycles so the ram
has time to handle the data, which involves using a WAIT line to hold
off the cpu until the time has elapsed.
>> Probably using a watchdog timer is the best way out: if the result
>> isn't in after a reasonable delay, assume it's not going to happen,
>> something like:
> Most of the time, your [delay] is enough, and that's what I meant too.
> Sometimes the problem will also involve 100% CPU spent handling the
> same event, e.g. bang [until] without anything else, and so [delay]
> won't work at all. Sometimes it could be a [delay 0] within the test
> (or component being tested) doing an infinite loop at the same logical
> time instead. Because [delay] can only handle logical times, it won't
> be able to trap it. But I think that those two latter cases are
> relatively rare, and if ever they are not that rare, or that they are
> very inconvenient when they happen, then we might want to use a
> watchdog more like pd's watchdog process.
To be bulletproof you would need to schedule an external interrupt to
kill the process in case of infinite loop. Maybe the pd watchdog could
be adapted to do that? At the moment it doesn't seem to care if I banged
an [until] because the connection to the gui is still functional.
More information about the Pd-list