sergiotarxz/nuttx
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

arch/arm/src/stm32 and configs/stm32f4discovery: Some feeble attempts to communicate with the BT860. Not much progress yet.

Browse Source
This commit is contained in:
Gregory Nutt 2018-04-16 15:24:17 -06:00
parent 5fc2f7a36c
commit 603efe6fb5
4 changed files with 53 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
arch/arm/src/stm32/stm32_hciuart.c
View File

@ -319,8 +319,8 @@ static int hciuart_dma_nextrx(const struct hciuart_config_s *config);
#endif
static uint16_t hciuart_rxinuse(const struct hciuart_config_s *config);
static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config);
static inline void hciuart_rxflow_disable(const struct hciuart_config_s *config);
static void hciuart_rxflow_enable(const struct hciuart_config_s *config);
static void hciuart_rxflow_disable(const struct hciuart_config_s *config);
static ssize_t hciuart_copytorxbuffer(const struct hciuart_config_s *config);
static ssize_t hciuart_copyfromrxbuffer(const struct hciuart_config_s *config,
uint8_t *dest, size_t destlen);
@ -941,11 +941,13 @@ static uint16_t hciuart_rxinuse(const struct hciuart_config_s *config)
* Name: hciuart_rxflow_enable
*
* Description:
* Enable software Rx flow control.
* Enable software Rx flow control, i.e., clear the RTS output. This will
* be seen as CTS on the other end of the cable and the HCI UART device
* must stop sending data.
*
****************************************************************************/
static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config)
static void hciuart_rxflow_enable(const struct hciuart_config_s *config)
{
#ifdef CONFIG_STM32_HCIUART_SW_RXFLOW
struct hciuart_state_s *state;
@ -963,7 +965,7 @@ static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config)
{
wlinfo("Enable RTS flow control\n");
stm32_gpiowrite(config->rts_gpio, true);
stm32_gpiowrite(config->rts_gpio, false);
state->rxflow = true;
}
}
@ -974,11 +976,13 @@ static inline void hciuart_rxflow_enable(const struct hciuart_config_s *config)
* Name: hciuart_rxflow_disable
*
* Description:
* Enable software Rx flow control.
* Disable software Rx flow control, i.e., set the RTS output. This will
* be seen as CTS on the other end of the cable and the HCI UART device
* can resume sending data.
*
****************************************************************************/
static inline void hciuart_rxflow_disable(const struct hciuart_config_s *config)
static void hciuart_rxflow_disable(const struct hciuart_config_s *config)
{
#ifdef CONFIG_STM32_HCIUART_SW_RXFLOW
struct hciuart_state_s *state;
@ -994,7 +998,7 @@ static inline void hciuart_rxflow_disable(const struct hciuart_config_s *config)
{
wlinfo("Disable RTS flow control\n");
stm32_gpiowrite(config->rts_gpio, false);
stm32_gpiowrite(config->rts_gpio, true);
state->rxflow = false;
}
}
@ -1575,9 +1579,15 @@ static int hciuart_configure(const struct hciuart_config_s *config)
* have broken HW based RTS behavior (they assert nRTS after every byte
* received) Enable this setting workaround this issue by using software
* based management of RTS.
*
* Convert the RTS alternate function pin to a push-pull output with
* initial output value of zero, i.e., rx flow control enabled. The HCI
* UART device should not send data until we assert RTS.
*/
pinset = (config & ~GPIO_MODE_MASK) | GPIO_OUTPUT;
regval = GPIO_MODE_MASK | GPIO_PUPD_MASK | GPIO_OPENDRAIN |
GPIO_OUTPUT_SET | GPIO_EXTI;
pinset = (config & ~regval) | GPIO_OUTPUT;
#endif
stm32_configgpio(pinset);
@ -1650,6 +1660,9 @@ static int hciuart_configure(const struct hciuart_config_s *config)
(void *)config, true);
#endif
/* Disable Rx flow control, i.e, assert RTS. */
hciuart_rxflow_disable(config);
return OK;
}

20
configs/stm32f4discovery/README.txt
View File

@ -1203,6 +1203,26 @@ Configuration Sub-directories
changed by modifying the disambiguation definitions in
configs/stm32f4discovery/include/board.h
I have been testing with the DVK_BT960_SA board via J10 as follows:
DVK_BT860-SA J10 STM32F4 Discovery P1
pin 1 GND P1 pin 49
pin 2 Module_RTS_O USART3_CTS PB13, P1 pin 37
pin 3 N/C
pin 4 Module_RX_I USART3_TXD PB10, P1 pin 34
pin 5 Module_TX_O USART3_RX PB11, P1 pin 35
pin 6 Module_CTS_I USART3_RTS PB14, P1 pin 38
3. Due to conflicts, USART3 many not be used if Ethernet is enabled with
the STM32F4DIS-BB base board:
PB-11 conflicts with Ethernet TXEN
PB-13 conflicts with Ethernet TXD1
If you need to use the HCI uart with Ethernet, then you will need to
configure a new U[S]ART and/or modify the pin selections in
include/board.h.
ipv6:
----
This is another version of the NuttShell configuration for the

1
configs/stm32f4discovery/hciuart/defconfig
View File

@ -1,6 +1,7 @@
# CONFIG_ARCH_FPU is not set
# CONFIG_MMCSD_MMCSUPPORT is not set
# CONFIG_MMCSD_SPI is not set
# CONFIG_NET_ETHERNET is not set
# CONFIG_NET_IPv4 is not set
# CONFIG_NSH_ARGCAT is not set
# CONFIG_NSH_CMDOPT_HEXDUMP is not set

10
configs/stm32f4discovery/include/board.h
View File

@ -265,6 +265,16 @@
*
* Used in pseudoterm configuration and also with the BT860 HCI UART.
* RTS/CTS Flow control support is needed by the HCI UART.
*
* There are conflicts with the STM32F4DIS-BB Ethernet in this configuration
* when Ethernet is enabled:
*
* PB-11 conflicts with Ethernet TXEN
* PB-13 conflicts with Ethernet TXD1
*
* UART3 TXD and RXD are available on CON4 PD8 and PD8 of the STM32F4DIS-BB,
* respectively, but not CTS or RTS. For now we assume that Ethernet is not
* enabled if USART3 is used in a configuration with the STM32F4DIS-BB.
*/
#define GPIO_USART3_TX GPIO_USART3_TX_1 /* PB10, P1 pin 34 (also MP45DT02 CLK_IN) */