|
|
View previous topic :: View next topic |
Author |
Message |
maxrate
Joined: 01 Jan 2007 Posts: 38 Location: Mississauga, Ontario, Canada
|
Garbage serial characters |
Posted: Tue Jun 11, 2024 4:55 pm |
|
|
Hello - I know garbage characters have been addressed in the past. Perhaps I'm not having much success with searching today.
I have a small red dev board (ebay/Aliexpress) PIC-DIP40. Has 5 buttons, LED's, DS18B820, XTAL, DB9 RS232, LCD header, 2.54mm pitch IO pin breakout header, USB power, 40 pin ZIP socket.
Using a PIC18F46K22 (my go to chip, as I have lot's of them).
Program repeats text over and over again, sending to hardware UART 1 (c6/c7 hardwired on dev board to DB9) Also, repeats same text over and over on hardware UART 2 (d6/d7) - needs external TTL to USB serial modules.
PORT1 - No issues with text flying across the DB9 to my Windows computer running TeraTerm.
PORT2 - Garbage/Noise on approx 5% of the characters, usually grouped together.
I've tried multiple modules, pull-up/pull-down resistors/etc. I find different modules give different levels of 'noise'.
Both streams are going to same PC - tried many different USB<>TTL devices. -Varying levels of noise-
Any suggestions?
MAIN.C
Code: | #include <main.h>
#INT_TIMER0
void TIMER0_isr(void)
{
}
#INT_TIMER1
void TIMER1_isr(void)
{
}
#INT_EXT
void EXT_isr(void) // Interrupt #1 = PIN B0 on the PIC18F46K22 40 pin DIP chip
{
}
#INT_RDA
void RDA_isr(void)
{
}
#INT_RDA2
void RDA2_isr(void)
{
}
void main()
{
port_b_pullups(0xFF);
setup_adc_ports(sAN5, VSS_VDD);
setup_adc(ADC_CLOCK_INTERNAL | ADC_TAD_MUL_20);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_4); //32.7 ms overflow
setup_timer_1(T1_INTERNAL|T1_DIV_BY_8); //65.5 ms overflow
enable_interrupts(INT_TIMER0);
enable_interrupts(INT_TIMER1);
enable_interrupts(INT_EXT);
enable_interrupts(INT_RDA);
enable_interrupts(INT_RDA2);
enable_interrupts(GLOBAL);
while(TRUE)
{
fprintf(PORT2,"The quick brown fox jumps over the lazy dog. ");
delay_ms(30);
fprintf(PORT1,"The quick brown fox jumps over the lazy dog. ");
delay_ms(30);
}
}
|
MAIN.H
Code: | #include <18F46K22.h>
#device ADC=8
#FUSES NOWDT //No Watch Dog Timer
#use delay(crystal=32MHz)
#use STANDARD_IO( B )
#define TX1 PIN_C6
#define RX1 PIN_C7
#define LED_D0 PIN_D0
#define TX2 PIN_D6
#define RX2 PIN_D7
#define BATTERY PIN_E0
#use rs232(baud=115200,parity=N,xmit=TX1,rcv=RX1,bits=8,stream=PORT1)
#use rs232(baud=115200,parity=N,xmit=TX2,rcv=TX2,bits=8,stream=PORT2)
#define LED PIN_D0
#define DELAY 200
|
|
|
|
maxrate
Joined: 01 Jan 2007 Posts: 38 Location: Mississauga, Ontario, Canada
|
|
Posted: Tue Jun 11, 2024 4:58 pm |
|
|
Neglected to mention, when I rid the code of all the interrupts/etc, things run well. What I'm specifically puzzled about is why only PORT2 giving the trouble and not PORT1... |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Wed Jun 12, 2024 1:38 am |
|
|
One warning. You must _NEVER_ have an iINT_RDA (or RDA2), enabled,
that does not read the received character in it. Doing so will cause UART
problems if a character is seen. Do not do this.....
However the reason for your problem, is that you are not using the UART
for PORT2. Your chip does not have PPS. So UART2 is on pins B6 & B7.
Your second stream is setup as a _software_ UART. Won't generate RDA2,
and transmission is all done by software timing. The timer interrupts will
therefore interfere with the bit timing. Result corrupted characters.
You must learn to use the pins that the hardware supports. Even on PPS
chips, there are restrictions on what devices can go where and you must
always refer to the data sheet when making your connections.
You could probably get it to work by using the DISABLE_INTS option
in your setup for PORT2, but you will still have problems in the future
if you want to receive on this port.
Fix your hardware and use the hardware pins for UART2. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Jun 12, 2024 4:56 am |
|
|
hmm, I'm pretty sure it's the ICSP that's on B6,B7 with the 2nd UART on D6,D7 but need to check the datasheet...AFTER I make coffee.
Neighbour woke me up at 5:30 today AND my PC can't see the router or printer again..even though I have internet access...
some days I'd like to go back to the PIC16C84 ! |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Wed Jun 12, 2024 5:51 am |
|
|
maxrate wrote: | Neglected to mention, when I rid the code of all the interrupts/etc, things run well. What I'm specifically puzzled about is why only PORT2 giving the trouble and not PORT1... |
You have configured PORT2 to use the same TX pin for both transmit and receive. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
maxrate
Joined: 01 Jan 2007 Posts: 38 Location: Mississauga, Ontario, Canada
|
|
Posted: Wed Jun 12, 2024 5:58 am |
|
|
Hi there Ttelmah and Temtronic
Egg on my face! I was convinced I was using the hardware UARTS. I certainly checked out the datasheet before hand - I've seem to have made two errors: Got my "B's and D's" crossed in my mind - oops. Also, I used the CCS wizard to generate the code and I made a terrible assumption that it would populate the values correctly based off the MCU selection given the values for the first UART were spot on. Data sheet was referenced before I launched the wizard to determine hardware UART1 and UART2 pins, also used to determine what pin the first interrupt was (RB0 in the case of the PIC18F46K22) as evidenced in the comments for INT0 interrupt routine.
Ttelmah, Temtronic, PCM Programmer and a few others - always great of you to offer assistance.
I am aware about the mandatory catching of characters on the input side of things. I note that when I remove the timer interrupt code things clear up. I thought it was behaving as a software uart, but was 'certain' I was using hardware.
Many thanks!!! Not triple checking wasted everyone's time - many apologies.
-Shaun |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
|
Posted: Wed Jun 12, 2024 7:25 am |
|
|
FWIW, using UART1 and UART2 specifies the hardware pins and
simplifies the RS232 setup (Nov 2021 man page 193-194).
Since bits and parity are at defaults this reduces the declarations to:
#use rs232(UART1, baud=115200,stream=PORT1)
#use rs232(UART2, baud=115200,stream=PORT2) _________________ Google and Forum Search are some of your best tools!!!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Wed Jun 12, 2024 8:12 am |
|
|
Though one should really also add 'ERRORS', otherwise if you get an
error condition the UART can hang.... |
|
|
maxrate
Joined: 01 Jan 2007 Posts: 38 Location: Mississauga, Ontario, Canada
|
|
Posted: Wed Jun 12, 2024 11:23 am |
|
|
Thanks all for the tips. Excellent! |
|
|
dyeatman
Joined: 06 Sep 2003 Posts: 1934 Location: Norman, OK
|
|
Posted: Wed Jun 12, 2024 12:36 pm |
|
|
Ttelmah, I always use ERRORS so I don't know why I left it off.
Thanks for the catch!
#use rs232(UART1, baud=115200,stream=PORT1, ERRORS)
#use rs232(UART2, baud=115200,stream=PORT2, ERRORS) _________________ Google and Forum Search are some of your best tools!!!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19539
|
|
Posted: Thu Jun 13, 2024 1:05 am |
|
|
Well said.
It really is 'sticky' status. On PIC12/16/18, if using a hardware UART,
you should always have ERRORS in the UART definition, unless you are
adding your own error handling. On the UART, errors must be handled....
It changes on the PIC24/30/33, where really you really need to use an error
interrupt.
It is easy to miss it. Personally I wish that CCS would change the default
so that it normally adds the error handler, and have instead a 'NOERRORS'
setting to turn this off. Would avoid quite a few problems. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|