Simplest programm does not work- UART PIC
Moderator: Benj
-
- Posts: 24
- Joined: Wed Apr 29, 2015 4:49 pm
- Has thanked: 5 times
- Been thanked: 5 times
- Contact:
Simplest programm does not work- UART PIC
Since a few days I am having serious trouble with communicating via serial interface between terminal and a PIC. I am using the eb006v9 with a 20MHz crystal, newest Flowcode 6 Version, Pickit 3 and a pic18f46k22. Everything seems to work fine instead of rs232 communication. To isolate the problem, I wrote a very simple program which just echoes back rx data and even that does not work. I am sending "a b c d e f g" and getting back random chars and timeouts... I provide the program and some screenshots below. Please help I am getting really frustrated since i lost the whole weekend on that. Any help will be mostly appreciated. What am I doing wrong?
- Attachments
-
- hterm.png
- send an received data
- (173.73 KiB) Downloaded 1540 times
-
- DS1Z_QuickPrint1.png
- physical signal from terminal
- (42.79 KiB) Downloaded 3573 times
-
- Flowcode1.fcfx
- program
- (6.14 KiB) Downloaded 259 times
-
- Matrix Staff
- Posts: 9520
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
- Contact:
Re: Simplest programm does not work- UART PIC
Hi Beertree,
What I can suggest is drop the baud rate to a lower value e.g 19200
Then just send an uppercase U
All the mark to space ratio should be the same so you can see how out the waveform is.
Also you could do a 1 second test just to make sure osc is running at the expected frequency.
Martin
What I can suggest is drop the baud rate to a lower value e.g 19200
Then just send an uppercase U
All the mark to space ratio should be the same so you can see how out the waveform is.
Also you could do a 1 second test just to make sure osc is running at the expected frequency.
Martin
Martin
-
- Posts: 24
- Joined: Wed Apr 29, 2015 4:49 pm
- Has thanked: 5 times
- Been thanked: 5 times
- Contact:
Re: Simplest programm does not work- UART PIC
Hello Martin,
Thanks for your fast reply. At 19200 things seem working fine. I attached both, the hterm screenshot and the transient reading again. Maximum I can use is 57600 baud. The it doesnot function anymore. I also give you the reading of the one second check. I think the timing is accurate. Where else can the problem at 115200 baudrate come from? All my cables are shielded and I use the well known ftdi usb converting chipset (I checked other converters, too). Maximum I can use is 57600 baud.
Thanks for your fast reply. At 19200 things seem working fine. I attached both, the hterm screenshot and the transient reading again. Maximum I can use is 57600 baud. The it doesnot function anymore. I also give you the reading of the one second check. I think the timing is accurate. Where else can the problem at 115200 baudrate come from? All my cables are shielded and I use the well known ftdi usb converting chipset (I checked other converters, too). Maximum I can use is 57600 baud.
- Attachments
-
- DS1Z_QuickPrint4.png
- one second
- (42.47 KiB) Downloaded 3556 times
-
- DS1Z_QuickPrint2.png
- 0x55 (U)
- (35.68 KiB) Downloaded 3556 times
-
- hterm.png
- Terminal programm
- (159.07 KiB) Downloaded 1523 times
-
- Matrix Staff
- Posts: 9520
- Joined: Sat May 05, 2007 2:27 pm
- Location: Northamptonshire, UK
- Has thanked: 2585 times
- Been thanked: 3815 times
- Contact:
Re: Simplest programm does not work- UART PIC
Your welcome.
I would say the problem is the accuracy of UART at the required baud rate.
I have just checked with an old version of flowcode (V4) and that shows accuracy of 1.36%
That along with capacitance of leads plus the baud rate limitation of UART to RS232 could be why you are facing these issues?
A suggestion I could make is to reduce one of the variables is use a 12MHz crystal, set clock speed to 48MHz and enable PLL
Setting clock in Flowcode V4 for 48MHz reduced error to 0.16% which is miles better.
Note: Percentage given is what is calculated By RS232 component within V4 and not measured on hardware.
But still not sure if it will work because of the other variables described above.
You can check the baud rate by measuring a bit width (Using upper case U)on the scope
Then use 1/bit width
For e.g. if bit width is 52uS then baud = 1/52E-6 = 19230
So you could get the scope to accurately measure bit with by using cursors, then determine how out the actual baud rate is.
Martin
I would say the problem is the accuracy of UART at the required baud rate.
I have just checked with an old version of flowcode (V4) and that shows accuracy of 1.36%
That along with capacitance of leads plus the baud rate limitation of UART to RS232 could be why you are facing these issues?
A suggestion I could make is to reduce one of the variables is use a 12MHz crystal, set clock speed to 48MHz and enable PLL
Setting clock in Flowcode V4 for 48MHz reduced error to 0.16% which is miles better.
Note: Percentage given is what is calculated By RS232 component within V4 and not measured on hardware.
But still not sure if it will work because of the other variables described above.
You can check the baud rate by measuring a bit width (Using upper case U)on the scope
Then use 1/bit width
For e.g. if bit width is 52uS then baud = 1/52E-6 = 19230
So you could get the scope to accurately measure bit with by using cursors, then determine how out the actual baud rate is.
Martin
Martin
-
- Posts: 24
- Joined: Wed Apr 29, 2015 4:49 pm
- Has thanked: 5 times
- Been thanked: 5 times
- Contact:
Re: Simplest programm does not work- UART PIC
Thank you again! . Thank you for your hints, I will try to figure it out, when there is time again within the next days.
-
- Posts: 24
- Joined: Wed Apr 29, 2015 4:49 pm
- Has thanked: 5 times
- Been thanked: 5 times
- Contact:
Re: Simplest programm does not work- UART PIC
A bit late, but I want to let others to know, that I were not able to solve the problem with a other crystal and reduced the baud rate. Meanwhile I have another project with the ftdi-chip nearby the processor, which works fine at 115kbaud. I guess, the problem was the hardware design of the eb006 board, combined with the cablelength of the ftdi convertercable.