onsdag 5. mai 2021 kl. 22:29:50 UTC+2 skrev Jan Mercl: > On Wed, May 5, 2021 at 6:56 PM Øyvind Teig <oyvin...@teigfam.net> wrote: > > > hiPri is a disconnect message of a smoke detetector. loPri is a fire > alarm. If the disconnect hiPri is activated before (1 sec to 1 ns) or > simulatenously (same polling of "hw pins") as the alarm loPri there should > be no alarm being sent to the fire department. > > I think that if the correctness of some code depends on the ordering > of external/random events within a single nanosecond or less then it's > IMO probably never correct code. > > I started my professional life as a HW designer. (18yo college > drop-out, only later migrated to writing SW.) What is quoted above is > called a hazard[0]. The specifications of ICs have specifications > about how much time must separate changes in inputs of a, for example, > 7400 NAND gate for its output to be the negation of the boolean > product of its inputs. Otherwise the output is allowed to be > undefined. Not even just zero or one, but any (voltage) value in > between might occur. In combination with the maximum time allowed for > the gate to change and settle its output the specs allow for (at those > times tedious, pencil and paper) calculation of propagation delays in > complex circuits and detecting any hazards. Because hazards cause > chaotic behavior that is seldomly intended or welcome, usually it's > not correct/acceptable. > > Your "logic circuit" depicted above has a hazard. It should not be > deployed until it is redesigned to be robust, ie. hazard-free. >
Of course all this apply. I guess I need to relate to them when (oops.. if) I make a test case in xC for xCORE. I was thinking about actually waiting in hi and low for two hw pins that I can exercise simultaneously or or not, from another set of pins. The xCORE polls the pins and presents them to tasks. Plus, I assume I could just try to send hi and low on channels. Each task will run on their own logical core, and the cycles run in round robin, like one for each core at a time. But in any case I (think I) know is that the xC [[ordered]] select with is interpreted once, for both (all) guards of the select, when the select is entered. I will try to write more below all the other comments. Øyvind > [0]: https://en.wikipedia.org/wiki/Hazard_(logic) > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/56e12192-3fcd-45ff-b45b-2ff423675b4bn%40googlegroups.com.