| View previous topic :: View next topic |
| Author |
Message |
spilz
Joined: 30 Jan 2012
Posts: 220
|
| [SOLVED] PIC18F66J94 COM pins and INT_RDA issue |
 Posted: Fri Jun 12, 2020 7:55 am |
 |
|
hello,
I'm working on a project with a new pic for me : PIC18F66J94
i have some strange issue with pins RG0, RG1, RG2 and RG3 which are respectively COM4, COM5, COM6 and COM7 (I think my issue is related to this "COM" relation between then)
I want to use RG0 and RG1 for a serial communication, and RG2 and RG3 as output level (like controling a LED).
so I have this in my code :
| Code: | // PINS ESP32
#define ESP_GPIO0_PIN PIN_G2
#define ESP_RST_PIN PIN_G3
#define ESP_TX PIN_G0
#define ESP_RX PIN_G1
// UART ESP
#pin_select U1TX = ESP_TX
#pin_select U1RX = ESP_RX
#use rs232(baud=115200,parity=N,xmit=ESP_TX,rcv=ESP_RX,bits=8,stream=RS232_ESP) |
and add in main() :
| Code: | | setup_lcd(LCD_DISABLED); |
and
| Code: | enable_interrupts(INT_RDA); // esp
enable_interrupts(GLOBAL); |
then
| Code: | output_float(ESP_GPIO0_PIN);
output_low(ESP_RST_PIN);
delay_ms(500);
output_high(ESP_RST_PIN);
delay_ms(200); |
and I dont know why, but it looks like sometime controling PIN_G2 and PIN_G3 as output affect RDA interrupt (no more data received).
if I change
| Code: | #define ESP_GPIO0_PIN PIN_G2
#define ESP_RST_PIN PIN_G3 |
by
| Code: | #define ESP_GPIO0_PIN PIN_E0
#define ESP_RST_PIN PIN_E1 |
(RE0 and RE1 are juste near RG0)
no more issue !!!
is there a like between RG0, RG1, RG2, RG3 ? and if yes is there a way to "break" it ? and how ?
(the thing is the PCB was already producted so I wanted to solve it by software (and learn new things  ) instead of change the desugn and pay for new production :(
thanks in advance for your help
regards
Last edited by spilz on Sat Jun 13, 2020 6:16 am; edited 1 time in total |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19589
|
|
| Posted: Fri Jun 12, 2020 9:59 am |
|
|
No, your issue is you will not get an INT_RDAx, until you use a hardware
UART.
Read the sticky at the top of the forum, and map one of the UARTs onto
these pins with #PIN_SELECT.
Then use this UART (again the sticky shows how to use the UART name
to do this). You will then get the INT for the UART you have used.
Currently you are setting up a software UART, so no interrupt. |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Fri Jun 12, 2020 10:09 am |
|
|
Thanks Ttelmah for your quick reply
It’s not what I did with | Quote: | // UART ESP
#pin_select U1TX = ESP_TX
#pin_select U1RX = ESP_RX |
? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19589
|
|
| Posted: Fri Jun 12, 2020 10:17 am |
|
|
Yes, but you then need to use UART1, instead of using the pins....
| Code: |
// UART ESP
#pin_select U1TX = ESP_TX
#pin_select U1RX = ESP_RX
#use rs232(baud=115200,parity=N,UART1,bits=8,stream=RS232_ESP)
|
This tells it to connect to the hardware UART, rather than to the pins.
It does depend on the compiler version. On some compiler and some
chips the compiler will detect that you have already made the
assignment, but most don't. (Actually I think it only works where there
is only one PPS UART).
This is why the sequence should always be:
Setup the PPS, and then connect to the physical UART not the pins.
The 'COM' usage is for the LCD controller. So long as these are not
enabled by this, shouldn't matter. |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Sat Jun 13, 2020 4:38 am |
|
|
hello
thanks, I changed it, it doesn't solve the issue :(
It looks like sometime it works fine, and other time interrupt is like disabled.
what can generate this kind of issue ?? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9269
Location: Greensville,Ontario
|
|
| Posted: Sat Jun 13, 2020 4:42 am |
|
|
dozens of 'things'...
1st one I can think of is not having 'errors' in the use rs232( ...options....)
you need to post a small, compilable program that we can see, download and test.
Jay |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Sat Jun 13, 2020 4:49 am |
|
|
thanks, I will add it, i totally forgot it :(
lets see if it solve it.
I try to write a small code with this issue, but as it's not all the time, I still don't find the good one which is reproducible.
What kind of error / issue adding ERRORS prevent ?
a parity error ? I mean, a received error (parity, etc) can stop the uart (not just lost a data) ? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9269
Location: Greensville,Ontario
|
|
| Posted: Sat Jun 13, 2020 6:02 am |
|
|
| if you don't read the HW UART buffer fast enough, it'll 'overrun' and hang. say the other device sends 6 characters to the PIC in a 'stream',you need to read them to clear the buffer. |
|
|
spilz
Joined: 30 Jan 2012
Posts: 220
|
|
| Posted: Sat Jun 13, 2020 6:16 am |
|
|
that seems to solve everything :D:D:D
thanks a lot for your help |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19589
|
|
| Posted: Sat Jun 13, 2020 7:38 am |
|
|
I think perhaps we may have to do a 'sticky':
"Always add ERRORS'. 
Basically, on the PIC, if an overrun error or framing error occurs, the receive
part of the UART will be disabled till this is cleared. Adding 'ERRORS', makes
the compiler add automatic error clearing code to the getc.
So the rule is:
When using the hardware UART, you really must always use 'ERRORS',
unless you are implementing your own error handling routines. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
