I am having problems getting hardware control (CTS/RTS) to work on the STM32L chip.
Below is how I setup the GPIO lines: void CommPort_SetupCtsRtsLine ( void ) { GPIO_InitTypeDef GPIO_InitStructure;
// Enable GPIO Periph bus clock. RCC_AHBPeriphClockCmd ( RCC_AHBPeriph_GPIOA, ENABLE );
/* Configure USART2 RTS and USART2 Tx as alternate function push-pull */ GPIO_InitStructure.GPIO_Pin = COMM_PORT_RTS_PIN_NAME | USART2_TXD_PIN_NAME; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; GPIO_Init(USART2_PORT_NAME, &GPIO_InitStructure);
/* Configure USART2 CTS and USART2 Rx as input floating */ GPIO_InitStructure.GPIO_Pin = COMM_PORT_CTS_PIN_NAME | USART2_RXD_PIN_NAME; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN; GPIO_Init(USART2_PORT_NAME, &GPIO_InitStructure); }
When I connect to the board using Hyperterminal I don't see any handshaking going on.
I hope that someone can help me with this problem.
Andy meant, that you need a _scope_ to view the RTS/CTS lines...
Actually, sniffer cables with lights (typically LEDs) works pretty well for checking basic RS232 handshake lines. Well, they certainly used to when I was doing such things.
But regardless, you're probably right. Check the IO lines.
They're great for checking static conditions, and can sometimes show that "something" is happening, but no use for observing signals at full speed - you need a scope (or proper serial analyser) for that!
you need a scope (or proper serial analyser) for that!
Wait a sec while I just jaunt back in time, run through all those old developments, where I obviously didn't use the right tools, and demand kit from my employers which they could not provide.
Hardware handshake lines on RS232 tend not to be particularly high speed signals.
Certainly what we used them for, when RS232 was considered high tech, it was LEDs and (if we were lucky) a fakerscope to check the actual data content.
I somethimes think that people are too quick to dismiss the basics to solve basic problems.
"Hardware handshake lines on RS232 tend not to be particularly high speed signals."
Well, I did a project involving high speed Bluetooth lately and I must tell you that when you are dealing with a CPU that is stressing with up to 3 live channels these signals just go mad. It all depends on the host processor and the environment.
Notice I emphasised 'tend'?
Though the OP did not mention it, the chances of him working with a CPU that is stressing with 3 live channels is probably quite unlikely. At his getting started point LEDs are, I suspect, quite sufficient.
I wasn't dismissing them at all!
I use them myself, and have frequently recommended them both here and elsewhere.
eg, www.8052.com/.../165783 "Nobody should be without one of those!"
The most common basic problems are things like the lines not being connected correctly, not connected at all, or "stuck" in the wrong state - and LEDs are certainly great for spotting those kinds of issues.
Although RS232 handshake lines do tend not to be particularly high speed signals, I find they are still generally too fast to be effectively monitored with LEDs and the naked eye. That is where the scope comes in.
But, yes - LEDs first!