PIC32 Async Communication with Putty - Page 1
Forum section: electronics / beginners

author: Teun
author_rank: Regular Contributor
timestamp: July 09, 2021, 07:08:42 pm
content: Hi Guys,I'm trying to (re)educate myself a bit on PIC32 MCU's. I was following THE book on it (Exploring the PIC32 - Di Jasio).Now I have everything set up but I cannot get Putty to show the output of the MCU. I can see data being sent to the MCU from putty on the scope. But the other way around it doesn't work. I have established that CTS isn't being pulled low.So the question is, if the PC or USB-Serial adapter should be able to pull CTS low? Or is this handled by Putty? In short what makes CTS go low so the handshake can be established?I have just followed the standard day 9 exercise of the book. And I'm pretty sure the code is correct.

author: esepecesito
author_rank: Regular Contributor
timestamp: July 09, 2021, 07:21:50 pm
content: CTS is a signal from Modem to Terminal. According to standard, will be read by the computer.Search in putty for an option about flow/control. Typically you have RTS/CTS as hardware and XON/XOFF as software. Select NONE, and the whole CTS/RTS signals will be ignored.Look here:https://documentation.help/PuTTY/config-serial-flow.htmlHope it helps

author: Teun
author_rank: Regular Contributor
timestamp: July 10, 2021, 08:50:55 am
content: I did that. Flowcontrol is on CTS/RTS and my program actually uses the CTS/RTS lines. Since CTS is an input to the MCU I expect it to be driven from the computer side. But it never turns low. So I was hoping someone could tell me more about how it is driven etc.I have tried a lot of settings in putty already but nothing seems to help. So I was wondering if someone else might have done exercise 9 from the book with putty and got it working.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 10, 2021, 09:25:40 am
content: Don't use RS232 hardware flow control unless it's an absolute must (i.e., having to talk to some ancient devices requiring this). No one bothers to implement it any longer so most USB adapters don't support it, and those that do may be buggy due to being untested. Also many MCU UART implementations do not have any kind of support for flow control so buffering and signaling is up to you to implement.Real flow control is also just not hardware signaling, it really complicates the full design; i.e., how to buffer data, what to do with it. Often in embedded it's just easier to consume the data than storing it into a buffer to be consumed later, and if you are out of memory, then you have failed anyway, asking the source to wait before sending more isn't usually helpful.Serial port (RS232 or logic level) is nowadays mostly used with assumption of both sides being able, by design, to consume the data at the same rate it's generated, completely removing the need of flow control and associated data storage problems. If you can, do this and forget about flow control. This also eases your learning journey because there is no handshaking, the link is always open and Just Works^tm when you connect the cable, so you can focus on finding the reason why the PIC UART peripheral fails to generate bits on TX pin.

author: Teun
author_rank: Regular Contributor
timestamp: July 10, 2021, 09:39:21 am
content: But... If I really wanted to I should probably look for a more reliable USB to Serial adapter is what you are saying?The thing is, I thought I got this stuff working a few years back in school with putty. Probably different adapter though. I intend to move towards USB eventually but since I'm not a hero at Embedded Systems, I'm just trying out the simpler stuff first. Even though it's old doesn't mean its not worth understanding how it works.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 10, 2021, 09:49:39 am
content: The question is, what are you going to actually do?If it is just a learning experience for developing electronics, forget about standard UART flow control because it's something used in new design in maybe 1990's. I have never designed or built a microcontroller device which uses CTS/RTS flow control, and probably never have to.UART without CTS/RTS is simpler to understand and use for a beginner so start here. Any USB adapter works. Native non-USB UARTs are exceedingly rare in modern computers. Also ignore RS232 signal levels and use just logic level adapters to reduce number of parts and possible mistakes.

author: esepecesito
author_rank: Regular Contributor
timestamp: July 10, 2021, 11:47:42 am
content: If you insist in using HW flow control, what you see, I and others discourage, again CTS is driven by the modem (in this case the microcontroller).The terminal (in this case your computer) says "I need to send data" by setting RTS. CTS is the response; means "I, the modem, am ready to send data, go ahead".So the computer sets RTS, the microcontroller, when ready, the CTS. Do not expect to go the way around, becauseif implemented at all, as stated by Teunit wont.Just one hint more: the levels of the RS232 signals may be confusing. 1 is 5v at the controller side, but -15 at cable side. But the control signals 0 is asserted and 1 deasserted. Look here:https://en.wikipedia.org/wiki/RS-232#RTS,_CTS,_and_RTR

author: Teun
author_rank: Regular Contributor
timestamp: July 10, 2021, 12:49:25 pm
content: Ok this is literally from the book except for the LEDsCode:#define CTS _RF12 // Clear To Send, input#define RTS _RF13 // Request To Send, output#define TRTS TRISFbits.TRISF13 // TRIS Control for RTS pin#define BRATE 42 // 115.200 Baud (BREGH = 1)#define U_ENABLE 0x8008 // enable, BREGH=1, 1 stopbit, no parity bit#define U_TX 0x0400 // enable TX, clear all flagsvoid initU2(void){U2BRG = BRATE; // init baudrate generatorU2MODE = U_ENABLE; // init UART moduleU2STA = U_TX; // enable transmitterTRTS = 0; // make RTS pin outputRTS = 1; // set RTS default status} // initU2int putU2( int c){while(CTS); // wait for !CTS, clear to sendwhile(U2STAbits.UTXBF); // wait while TX buffer fullU2TXREG = c;return c;} // putU2char getU2(void){RTS = 0; // assert request to send !RTSwhile(!U2STAbits.URXDA); // wait for new char to arriveRTS = 1;return U2RXREG; // read char from receive bufer} // getU2main(){// INIT PORTSTRISA = 0xffff; // PORTA as inputsPORTBCLR = 0xffff; // Clear port BTRISB = 0x0000; // PORTB pin 0..15 as output// GLOBAL VARIABLESchar c;// 1. init the UART2 Serial portinitU2();// 2. promptputU2('>');// 3. main loopwhile(1){/*if( RTS==1 ){ LED1 = 1; LED2 = 0;}else {LED1 = 0; LED2 = 1;}if( CTS==1 ){ LED3 = 1; LED4 = 0;}else {LED3 = 0; LED4 = 1;}*///3.1 wait for a characterc = getU2();//3.2 echo character to terminalputU2(c);} // main loop} // mainSo I assumed CTS was an input to the MCU and would be driven by the PC.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 10, 2021, 01:36:36 pm
content: Well obviously it gets stuck in while(CTS) unless the CTS signaling is definitely working correctly*, and this is one of the most likely culprits. Start by removing this check.*) for this to work, you need a 20-year old native RS232 UART port, or a very high quality advanced USB adapter, need to connect the CTS line through the MAX232 or similar level translator properly, need to configure adapter drivers / PuTTY properly, and so on. Just too many things to go wrong.I also dislike the idea of first example being an "echo" thing because it requires both TX and RX side to work correctly in order to do anything visible. Instead, I suggest you implement a printing function and use it to print "Hello World!". On a typical UART implementation (but depends on the micro, I have never used a PIC32!), the steps to get this far usually are:* Set the UART peripheral's config and baud rate registers,* Configure the UART TX pin as output (connected to the correct peripheral, if that needs to be done separately)* Enable the UART peripheralThen,For each character in string,* Poll for a "transmit register empty" / similar status bit from the UART status register* Write the byte in UART data registerOscillosscope is great to have as you do because then you can see if anything happens on the line. Having baud rate wrong is a very common mistake to make and in an unlucky case you won't see anything, not even garbage on the computer screen, but scope easily reveals the actual baudrate.