1
\$\begingroup\$

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?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Get an MCU with an FPGA section or vice versa. It'll be able to wire pins to pins in a generic, low-latency manner. \$\endgroup\$
    – Reinderien
    Jun 9, 2021 at 18:45
  • 2
    \$\begingroup\$ Or look at the PIC16 CLC section, that can support an FPGA-like pin wiring \$\endgroup\$
    – Reinderien
    Jun 9, 2021 at 18:50
  • \$\begingroup\$ Many thanks @Reinderien - especially good for me to learn that CLC: Configurable Logic Cell exists! \$\endgroup\$
    – sdbbs
    Jun 9, 2021 at 18:59
  • 1
    \$\begingroup\$ Many MCUs, or rather their peripherals could have features that could be used for implementing such a feature from some pin to some other pin, but for any arbitrary pin, it is unlikely. Some ARM MCUs have DMA and bit-banded memory so in theory you might be able to set up an auto-init memory to memory DMA transfer from bit-band memory address for one GPIO input bit to memory address for another GPIO output bit memory address. Or if the timing requirements are not that strict, you could copy the data in a timer tick interrupt which is already executing at say 1000Hz for system timekeeping. \$\endgroup\$
    – Justme
    Jun 9, 2021 at 19:06
  • 1
    \$\begingroup\$ @Justme The PIC families that support peripheral pin select and multi-channel CLC are startlingly flexible - no one will have "any" pin because power buses are reserved, but often everything else is up for grabs. \$\endgroup\$
    – Reinderien
    Jun 9, 2021 at 19:08

2 Answers 2

1
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.