Can the RX and TX pins be used as GPIO?

Title explains my question :stuck_out_tongue:
If so, how do I change their state?

I believe the short answer is no. Haven’t looked at the code but they are usually normal GPIO so it sounds soooo possible

I wasn’t sure if they were TX/RX-only pins coming out of the SMT32 or just regular bit banged GPIO pins. I went to have a look at the serial lib, but I didn’t quite understand it:

   * USRAT_peripheral (USART1-USART2; not using others)
   * clock control register (APB1ENR or APB1ENR)
   * clock enable bit value (RCC_APB2Periph_USART1 or RCC_APB2Periph_USART2)
   * interrupt number (USART1_IRQn or USART2_IRQn)
   * TX pin
   * RX pin
   * GPIO Remap (RCC_APB2Periph_USART2 or GPIO_Remap_None )
   * <tx_buffer pointer> used internally and does not appear below
   * <rx_buffer pointer> used internally and does not appear below
  { USART2, &RCC->APB1ENR, RCC_APB1Periph_USART2, USART2_IRQn, TX, RX, GPIO_Remap_None },

It mentions it does some remapping, so does that mean I can’t use them as regular GPIO anymore?

Hi @henriquepss

The TX and RX pins are on STM32 pins PA2 and PA3 and are general purpose IO. But the serial code assumes that it has complete access to them and does not make any allowance for users to take control over them. When used for serial as in the Spark core, there is a hardware USART connected to them. There is no bit-banged serial on the core at this time. There is also a pull-request on Github to add a third serial port using two of the existing GPIO pins as RX/TX again with another hardware USART.

So I think you could use them as general purpose IO if you build firmware locally and remove the USART code that connects to them. I am not sure how hard that would be, but it is theoretically possible.


There’s a 2nd serial that I tested halfway. The docs are ready but waiting for someone to verify and ensure all is good for release to the public.


Got it, thanks. Don’t want to lose the web IDE flexibility, so I’ll just rule those out.