route (overlap) gpio to another without wiring

[rudi ;-)]

hi guys

the esp32 gives new surprises every day, so I dare ask the question:

since we know we can "swap" pins in ESP8266 ( U0TXD<==>U0RTS(MTDO) , U0RXD<==>U0CTS(MTCK) )
by

Code: Select all

#define FUNC_U0CTS    4
#define FUNC_U0RTS    4

PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTCK_U, FUNC_U0CTS);//CONFIG MTCK PIN FUNC TO U0CTS
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDO_U, FUNC_U0RTS);//CONFIG MTDO PIN FUNC TO U0RTS
SET_PERI_REG_MASK(0x3ff00028 , BIT2);//SWAP PIN : U0TXD<==>U0RTS(MTDO) , U0RXD<==>U0CTS(MTCK)

i wounder me, we can do similar things in esp32?
( gpio0, gpio's..)

we have an example, that we config gpio as output and an other as input with ISR on it by falling edge example.
can we route the ouput gpio physical to the input gpio that we need not to wiring the 2 pins?

only a theoretical question

best wishes
rudi

[ESP_Sprite]

A GPIO pin can only accept an output value from one peripheral signal. However, you can have multiple peripherals looking at the input value for that pin. If you for example would like the Tx of your uart to be used as the input for a pulse counter, you could happily wire the output of the uart to the same pin as the input of the pulse counter.

[clarkster]

A GPIO pin can only accept an output value from one peripheral signal. However, you can have multiple peripherals looking at the input value for that pin. If you for example would like the Tx of your uart to be used as the input for a pulse counter, yoDou could happily wire the output of the uart to the same pin as the input of the pulse counter.

Let me see if I understand what @ESP_Sprite said:

When you connect a peripherals output signal to a GPIO, the GPIO cannot also be an input to another peripheral.

However, multiply input signals to different peripherals can be connected to a GPIO.

Examples:

You cannot internally connect a RMT output to a PCNT input. If you want to do this you must use two GPIO pins and externally wire them together. If I am wrong, would someone please show me how to do this?

You could internally connect a RMT input, along with a PCNT input to a single GPIO pin.

[WiFive]

https://esp32.com/viewtopic.php?f=13&t=4253

[meowsqueak]

You cannot internally connect a RMT output to a PCNT input. If you want to do this you must use two GPIO pins and externally wire them together.

Actually you only need one GPIO to do this, with no external wiring required. Set up a GPIO as both the RMT output and the PCNT input. I do this here:

https://github.com/DavidAntliff/esp32-f ... ain.c#L206

This code also contains an example of routing an incoming signal on one GPIO to an onboard LED driven by another GPIO. See lines 102 and 149.

[clarkster]

Actually you only need one GPIO to do this, with no external wiring required. Set up a GPIO as both the RMT output and the PCNT input. I do this here:

https://github.com/DavidAntliff/esp32-f ... ain.c#L206

Hi meow

I can't get it to work. Here is what I am doing:

1. I am starting with the pcnt example (esp-idf/examples/peripherals/gpio/main/gpio_example_main.c)
2. I make one change. I change line 52 to be

Code: Select all

#define PCNT_INPUT_SIG_IO   18

This causes PCNT_INPUT_SIG_IO and LEDC_OUTPUT_IO to be the same GPIO number. That means the pcnt pulse input and the ledc output are the same GPIO. As far as I can tell, this is exactly what you are doing. But it doesn't work here. The counter stays at zero indicating the PCNT is not seeing the LEDC output.

I haven't yet tried your program because I am not exactly sure how to use it.

Another question:

What is the value in using SIG_IN_FUNC228_IDX in your lines 102 and 149. If I understand the code correctly it is internally bridging two GPIO together. This technique cannot be used to connect together

1. an RMT output,
2. a PCNT input, and
3. a single GPIO output.

It could connect an RMT and a PCNT if both the RMT and the PCNT were connected to different GPIO. So it does not reduce the number of IO. All it does it prevent having to install an external jumper between the two GPIO.

Do I have a full understanding of what is happening?

[meowsqueak]

I don't have time at the moment to fully explain my code, however to answer your questions as best I can:

I haven't specifically tried connecting the PCNT input to the LEDC output, however based on my understanding of the I/O mux / GPIO matrix, it should be possible via a "connecting" GPIO. I suggest putting a scope on the GPIO pin and make sure that the LEDC is driving it properly. You shouldn't need two GPIOs and a jumper, but as I say I haven't tried this exact configuration myself so maybe there's something about it that makes this impossible. Also make sure you haven't set the PCNT into a mode where it needs a control signal asserted to "enable" the counter.

My code does require an enable on PCNT, and it's provided by RMT via the single GPIO. This allows the counter to count for a precise period of time without CPU involvement. To use my program, you just connect an external clock signal to CONFIG_FREQ_SIGNAL_GPIO (set in make menuconfig) and it will simply measure the frequency every 10 seconds and display the value on the console.

SIG_IN_FUNC228_IDX is a "spare" internal matrix channel that I use to connect the incoming frequency signal to the GPIO that drives the fixed LED on my board - that way the incoming clock drives the LED and makes it flash at the same rate - handy for visual feedback. This is completely separate to the RMT->PCNT thing.

[kjames]

Hello, my apologies if this is a dated topic, or not exactly related to what I am asking, but I have been looking into this frequency count example, which may be useful for a project I'm working on:

https://github.com/DavidAntliff/esp32-freqcount-example

I'm a bit new to developing using the ESP32, but at first look, this example looks like it may suit my needs for detecting the state or frequency on (4) possible GPIOs. I am trying to detect the possible states of ON, OFF, 1 Hz, 2 Hz, and 5 Hz for regular single color LEDs.

I don't completely understand how this example works just yet as I have only got it to work on one GPIO to detect the state of a blinking LED and everything seemed to work OK.

My question; is it possible to expand this code to work with detecting multiple GPIOs, (4 in my case) and if so, can it be expanded to work with multiple GPIOs without extensive changes?

Any insight into this is much appreciated!

[meowsqueak]

As you're probably aware already, that example just looks at a single signal incoming on a single GPI.

The main constraint is the size of the RMT buffers - as the GPI is sampled, a new value is added to the RMT buffer. The size of the buffer required is therefore related to the required sample rate, which in turn is constrained by the real signal's bandwidth. For example, if you wish to catch a 100kHz on/off square wave, then you'll need to sample at least twice per cycle, so you'll need RMT to sample at a minimum of 200kHz. If you check and clear the buffer fast enough, you can keep it small, otherwise you'll need the buffers to be of suitable size to hold all the samples between checks.

There are limited buffers available, and they are of a limited size. There are also a limited number of RMT input channels (8 I think?).

So in theory you can have four instances of my driver running on four different GPIs, writing into four different RMT buffers, but whether this makes sense will depend a lot on your application needs.

Can you give some technical requirements for your project? How often do you need to sample each of the four inputs? How often can you check and clear the buffers? The RMT clock scaling doesn't go particularly slowly, so slower rates end up using very large buffers.

[kjames]

Thanks very much for the additional info about your example.

The project requires constant monitoring of the possible GPIO states (constant ON, OFF, & 1Hz up to 5Hz) and the states of the four LEDs being monitored could change at any given time. Given the slow rates, perhaps this example may not make the most sense?

I am just now getting into the requirements (which are not completely defined), but I think that capturing the data every 10 seconds (more or less) should suffice. As I am now in the beginning stages, my goal is to somehow understand the best way to capture the four LED states...