CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Error UART to 115200 baud

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
cvargcal



Joined: 17 Feb 2015
Posts: 134

View user's profile Send private message

Error UART to 115200 baud
PostPosted: Thu Aug 13, 2020 11:00 pm     Reply with quote

Hi,
Someone know why i cannot receive data to 115200?
I bought this module: https://www.aliexpress.com/item/32911363529.html If I use one converter TTL to USB, show without problem. But with this simple code show wrong character.

Quote:
ID=10AÕ‚‰5HID=10PM03M
ID=10AÕ‚i5HID=10U‚iªCID=10U‚iªHID=10A5‚š5
ID=10U‚‰ªH@{FF}


I can see only show the 2 first characters, the correct should be:
ID=10000107,TEP=+28.1¡æ,HUM=000.0%,S=00000001,V=3.38V,SN=026,RSSI=-027dBm{0D}{0A}

I tested all speed, the max where work is with 57600.

Code:
#include <18F26k22.h>
#device PASS_STRINGS = IN_RAM
#device adc=10
#fuses NOPBADEN                                              // PORTB pins are configured as digital I/O on RESET
#fuses BROWNOUT                                              // Reset when brownout detected
#fuses NOHFOFST                                              // High Frequency INTRC waits until stable before clocking CPU
#fuses NOWDT                                                 // No Watch Dog Timer
#fuses PUT                                                   // Power Up Timer
#fuses MCLR                                                  // Master Clear pin enabled
#fuses PROTECT                                               // Code protected from reads
//#fuses PLLEN                                                 // HW PLL enabled    16MH* 4 =64M
#use delay(internal=64MHz)

 //  UARTs
//!/***************************************************************/
#use rs232(baud=115200,bits=8,parity=N,xmit=PIN_B6,rcv=PIN_B7,ERRORS,stream=uart2)   
#use rs232(baud=9600,bits=8,parity=N,xmit=PIN_C6,rcv=PIN_C7,ERRORS,stream=uart1)   
//!/***************************************************************/
#use standard_io(A)
#use standard_io(B)
#use standard_io(c)


#int_RDA                                                 
void RDA_isr1(void) {                                           
}


#int_RDA2                                       
void RDA_isr2(void) {
   
   char bufferByte = getchar(uart2);
   fputc(bufferByte,uart1);
 
}

void main(void){
   fprintf(uart1,"test....");
   enable_interrupts(global);                     // Habilita interrupciones
   enable_interrupts(int_rda);                    // Habilita Interrupción RDA UART1
   enable_interrupts(int_rda2);                   // Habilita Interrupción RDA UART2
   delay_ms(500);
   
   
   fprintf(uart1,"test....");
   while(1);
 
}



This PIC doesn't support high speed?
Ttelmah



Joined: 11 Mar 2010
Posts: 19546

View user's profile Send private message

PostPosted: Fri Aug 14, 2020 1:56 am     Reply with quote

As a comment, use the UART name. Makes absolutely 'sure' you
use the hardware UART,

Also add a receive line to INT_RDA. Problem is you are enabling this
interrupt. If it triggers (UART1 RX is not pulled high), then the code at
this point will hang. Reason is that INT_RDA will be called, and then
can never exit, since you don't read the character. Means the interrupt
cannot be cleared.

Big problem though is the speed difference. Characters are arriving every
1/11520 second, but it takes a mSec to send a character at 9600bps
Code:

#include <18F26k22.h>
#device PASS_STRINGS = IN_RAM
#device adc=10
#fuses NOPBADEN                                              // PORTB pins are configured as digital I/O on RESET
#fuses BROWNOUT                                              // Reset when brownout detected
#fuses NOHFOFST                                              // High Frequency INTRC waits until stable before clocking CPU
#fuses NOWDT                                                 // No Watch Dog Timer
#fuses PUT                                                   // Power Up Timer
#fuses MCLR                                                  // Master Clear pin enabled
#fuses PROTECT                                               // Code protected from reads
//#fuses PLLEN                                                 // HW PLL enabled    16MH* 4 =64M
#use delay(internal=64MHz)

 //  UARTs
//!/***************************************************************/
#use rs232(baud=115200,bits=8,parity=N,UART2,ERRORS,stream=uart2)   
#use rs232(baud=9600,bits=8,parity=N,UART1,ERRORS,stream=uart1, TRANSMIT_BUFFER=128)   
//!/***************************************************************/
//Big issue here is the difference in speed.
//Adding the transmit_buffer option, will create an INT_TBE, and handle
//storing the data,

#use standard_io(A)
#use standard_io(B)
#use standard_io(c)


#int_RDA                                                 
void RDA_isr1(void) {   
   int dummy;
   dummy=fgetc(uart1);
   //unless the character is read, the interrupt cannot be cleared
   //processor will then be hung.....                                   
}


#int_RDA2                                       
void RDA_isr2(void) {
   
   char bufferByte = fgetc(uart2);
   //Problem here is characters can arrive every 1/11000th second
   //but the print below takes a mSec. After two characters the
   //output buffer is full, so then things have to hang.....
   fputc(bufferByte,uart1);
 
}

void main(void){
   fprintf(uart1,"test....");
   enable_interrupts(global);                     // Habilita interrupciones
   enable_interrupts(int_rda);                    // Habilita Interrupción RDA UART1
   enable_interrupts(int_rda2);                   // Habilita Interrupción RDA UART2
   delay_ms(500);
   
   fprintf(uart1,"test....");
   while(TRUE) //if you use 'true', gets rid of compiler warning that
   //condition is always true.
      ;
}
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Aug 14, 2020 4:51 am     Reply with quote

just a comment...

If it still randomly fails after Mr. T's reply, consider using a real xtal/2 caps to replace the internal oscillator. Although the internal osc is pretty good (accurate) it may go 'out of spec' when cold or hot or may just be 'marginal'.
There's a reason why all the USBTTL and RTC modules have real xtals. To be accurate and precise you need an xtal.
Have to admit I use the 46K22 all the time without xtal/caps and they've been fine but in the beginning (3 decades ago) you NEEDED xtal/caps for reliable serial communications and timing.
cvargcal



Joined: 17 Feb 2015
Posts: 134

View user's profile Send private message

PostPosted: Fri Aug 14, 2020 10:55 am     Reply with quote

You always show me the light!! thanks!!
I can use the same speed and now it show me exactly how do the TTL to USB... so I only changed the pins name by the uart name, and put the dummy in #int_RDA

Code:


//  UARTs
//!/***************************************************************/
#use rs232(baud=115200,bits=8,parity=N,UART2,ERRORS,stream=uart2)   
#use rs232(baud=115200,bits=8,parity=N,UART1,ERRORS,stream=uart1)   
//!/***************************************************************/



Always I had that question, why use the external crystal if less wire and less component make easy the things.

Once again, thanks.... now i can continue working in my code.


Last edited by cvargcal on Fri Aug 14, 2020 3:13 pm; edited 1 time in total
dyeatman



Joined: 06 Sep 2003
Posts: 1934
Location: Norman, OK

View user's profile Send private message

PostPosted: Fri Aug 14, 2020 10:56 am     Reply with quote

Also, would not recommend using UART1 and UART2 as stream names since
they are reserved names for RS232 setup parameters. Might cause some
unwanted side effects.
_________________
Google and Forum Search are some of your best tools!!!!
temtronic



Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Aug 14, 2020 11:50 am     Reply with quote

followup comment....

stream names should reflect what they're used for
stream=GPSdevice
stream=PClink

The names tell you what the other device is. In the first case a GPS device is attached to the wires, in the second, a connection to a PC.
This can save a LOT of wasted time, when you 'misconnect' the UARTS to the wrong devices...

Jay
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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