MCU GPIO input pin state copying/buffering as another pin output in real-time?

Question

I was wondering about the following: generally, in MCUs, are there typically facilities for "real-time" copying/buffering an input pin's state to another (output) pin?

Typically, I would set up, say:

• GPIO port A pin 0 (GPIOA0) as input
• GPIO port B pin 0 (GPIOB0) as output
• set up an interrupt on any bit transition read on GPIOA0
• in the interrupt handler, do (Arduino-like pseudocode)

void isr_transition_gpioa0(void)
{
  int a0value = digitalRead(GPIOA0); 
  digitalWrite( GPIOB0, a0value );
}

In effect, the signal output on GPIOB0, is a buffered (and slightly delayed) version of the digital signal brought to the input pin GPIOA0; or in other words, the output copy is a buffered copy of the input signal.

My thinking was: in principle, if one wanted buffering like this, it could also be done by a hardware standalone buffer/repeater -- if such was present on the MCU, it would probably be possible to set up a register, to say: ok, map pin GPIOA0 to input of buffer A, and map output of buffer A on pin GPIOB0; then this buffering would be performed in "real-time" (disregarding latency in the buffer itself), and in parallel with whatever the CPU of the MCU does (so no chances of delaying a transition because the ISR was delayed/preempted). And then, whenever you "break" this link on a register level, the "copying" stops, so this facility could also act as a signal "gate".

However, looking at either Atmel or STMicro, I could not find anything specific about this kind of a setup -- so it is likely that such a facility is simply not present on MCUs.

But, taking the slight chance that the facility might be there, I just lack the correct terminology to look it up - is there anything like this on any brand of MCUs?

Answer 1

are there typically facilities for "real-time" copying/buffering an input pin's state to another (output) pin?

Depends on your latency constraints. The order of magnitude (ms, us, ns) will determine which category of technology is available to you at which price point.

But vaguely, "yes".

This is also highly dependent on your configurability needs. Will you need to swap out/rewire pins in runtime, in compile time, or never? If never, the obvious answer is to disconnect the output wire from the MCU and short it to your input.

For reconfigurable (runtime or otherwise) razor-thin latency you'll probably want to give up on a microcontroller altogether and use an FPGA instead. They're powerful enough that it's a near-guarantee you'll be able to reimplement whatever you were doing on an MCU in (pick your poison - VHDL/Verilog).

PICking (sorry) on the PIC16(L)F1773/6 because I've wrangled with it recently, it's a microcontroller that has a Configurable Logic Cell section that smells vaguely like an FPGA and has wiring to some of the other modules, like capture. Refer to figure 36-12 - the CLC has a propagation delay limited mainly by the slew rate of the output pin, which is on the order of 15-70 ns depending on circuit conditions. The CLC inputs and outputs are themselves multiplexed through the peripheral pin select module, and can connect pins on any of the ports.

Sacrificing some configurability for narrower latency, just use a high-speed, dedicated multiplexer external to your controller. If you need "multiple lines to multiple lines", rather than a single multiplexer you'll need a crosspoint switch.

Answer 2

Your proposal has very little use in practical implementation. Coming from industrial world of PLC it would translate as:

  int a0value = digitalRead(GPIOA0); 
  digitalWrite( GPIOB0, a0value );

At each main sweep cycle you do read peripheral inputs and you copy them into temporary buffer a0value, at the very next moment you do copy temporary output values a0value to peripheral outputs, then you process the whole program. This is sometimes called IOP cycle (Input,Output,Process), other possibilities are possible as IPO or OIP (which are the same, since the last is the beginning of the first)

But there is an exception for those inputs and outputs that have to be processed in the interrupt. You read input in the interrupt, compute and then write to temp value and directly to peripheral output.

Pros:

• The input values are snapshots and they don't change while computing. Obtaining different logic values of the same pin during computing, could be very problematic, if you process a truth table of logic values combination by combination, or doing some sequencer where the conditions of logical state has to be fulfilled.
• The peripheral access (read of pins) adds more processing delay, rather than reading from memory.