I'm trying a variety of things out with input pins and customized timers on the STM32F0. All timer functions are alternate functions on the pins and therefore you cannot use the user button (PC13 on the NUCLEO) as it doesn't have any timer in its alternate functions.
So, the question is: Can you (in the software) "simulate" a GPIO pin input going high? This would make writing code easier as you won't have to hook up the NUCLEO test board, header wires, etc. I was thinking of manually toggling bits in GPIO's IDR register but it's read-only. And the BSRR register only affects outputs. Is there a way to achieve this?
ST should have put the User Button on a different pin with more functions...
Thanks!
2 Answers 2
Use the internal pullup and pulldown resistors.
As long as a pin has nothing connected to it, and it's an input pin, setting the corresponding bits in GPIOx_PUPDR
will activate pullup or pulldown resistors, directly affecting the pin state. It will not only simulate the pin going high or low, but the voltage will actually appear on the pin. The current might be too weak to drive anything else, but the pin state would change. It should work even when the pin has an alternate input function, like the external trigger or capture input of a timer.
For example, setting PA12
(TIM1
external trigger) to high
GPIOA->PUPDR=(GPIOA->PUPDR & ~(3 << (2 * 12))) | (1 << 2 * 12);
Setting the same pin to low
GPIOA->PUPDR=(GPIOA->PUPDR & ~(3 << (2 * 12))) | (2 << 2 * 12);
Can you simulate a GPIO input on STM32F0?
That is the wrong problem to solve. The real question is:
Can you simulate a GPIO input?
Yes you can. You can make a different execution environment. For example, run the software on your pc, or create mock objects and peripherals and run on target.
This is part software testing, for example with Test Driven Development.
Practical:
On any embedded platform registers are defined in a header file. For ST, these are structures defined and mapped to peripherals in stm32f0xx.h
. You can create a modified header file for your test environment where these structures do not map to peripherals, but to memory. This way you can simulate everything by a test you can write.
-
\$\begingroup\$ I don't think this is a valid approach to test how the timer peripherals react on changing inputs. You'd have to simulate all the behavior of the peripheral as well, which tends to get ugly pretty quickly. \$\endgroup\$Arsenal– Arsenal2018年11月05日 08:57:24 +00:00Commented Nov 5, 2018 at 8:57
-
\$\begingroup\$ @Arsenal It's not simulating if your testing the hardware. If you want to test the timer inputs, use the pin as output, the alternate function inputs should still work then. Otherwise use the EGR register, change the timer polarity setting, or externally jump the input to another pin. \$\endgroup\$Jeroen3– Jeroen32018年11月05日 09:33:39 +00:00Commented Nov 5, 2018 at 9:33
-
1\$\begingroup\$ I think your comment answers the question better than your answer. At least how I understand the question. \$\endgroup\$Arsenal– Arsenal2018年11月05日 09:40:32 +00:00Commented Nov 5, 2018 at 9:40
-
\$\begingroup\$ @Jeroen3 use the pin as output, the alternate function inputs should still work then is this documented somewhere? \$\endgroup\$followed Monica to Codidact– followed Monica to Codidact2018年11月05日 11:56:30 +00:00Commented Nov 5, 2018 at 11:56
-
\$\begingroup\$ @berendi RM0091 Figure 16. Basic structure of an I/O port bit \$\endgroup\$Jeroen3– Jeroen32018年11月05日 12:55:21 +00:00Commented Nov 5, 2018 at 12:55
ETR
. How do I test it, when the hardware is not yet there? \$\endgroup\$