Note that what I said was,

"I'd suggest you consider a 74HC147 priority encoder IC if you don't want to encode the ten inputs in firmware."

How he goes about implementing this device can be any one of many ways. Quite frankly, I have no idea whether these are even still availble, but, it would probably be both better and easier if he implemented such logic, if not in firmware, then in programmable logic, which would allow itself to be tailored to his needs.

At this moment, we don't know whether the relay closure is short (~20 ms or less) or quite long (~200 ms or more). This appears to be a human-actuated input, however, so I'd suspect it will not be very short. Nevertheless, since he has few interrupts and, relative to that, many (10) inputs, until it is known how long the pulse is and how fast the MCU is, it's not possible to proceed without risking a missed input. Moreover, unless there's an acknowledge signal that hasn't been discussed, which will negate an input, once it's been received and acknowledged, it's not possible to make sense of multiple inputs ov variable persistence anyway.

Normally, based on my last time in hospital, a call button in a hospital requires that a nurse or other attendant acknowledge the "call" signal by negating it at the bedside. I would easily believe that nursing homes operate on more or less the same basis.

I agree that 10 separate inputs to the MCU are a much sounder approach than simply attaching a priority encoder such as the '147. However, the '147 alone would not be sufficient to implement a solution, as it has no gate strobe, as does the '148, so an input detector (e.g. HC133) would be necessary in any case to generate an interrupt, and some means would have to be provided to negate an input, once registered. Further, once sensed, the input should be blocked with yet another signal from the MCU, so that the inputs should probably come in through 4093 Schmidt-trigger NAND gates rather than 40106's. Since the application is apparently cost-sensitive, I'd say that the priority encoder approach would be too costly. However, it should be examined for its benefits, as it reduces ten inputs to four, and those four are then useable in a table lookup that very nicely fits the two-step control model:

a. examine inputs
b. take appropriate action

As there are ten inputs, there's no really simple way to get to a four bit value for any of the ten inputs, though everything from there would seem quite simple. He can, of course, read and transfer two of the inputs to DPH and put the remaining two in A and then MOVC A,@A+DPTR to retrieve a value from code space, but, since the input combinations are in the entire range 0000000000b to 1111111111b, that would demand a 1KB table in ROM, wouldn't it? Consequently, a more involved scheme will have to be used.

Now, I suspect, though there's no basis in fact for this assumption, that the transmitter closes that relay, and it persists in that state until the acknowledge is pressed at the bedside. The priority encoder alone would mask all but the "highest" priority input once it becomes active. However, input masking is not necessarily the only problem that would occur with this priority encoder approach.

The message intended by my mention priority encoder is that it is possible to reduce those ten bits to four. Naturally, since this is a human-activated event, it can easily be processed 100x in the MCU without any consequence.

I'll have to wait for more detail before I can recommend something readily implementable.

RE