|
|
View previous topic :: View next topic |
Author |
Message |
Guest
|
RS232 ISR problem |
Posted: Mon Mar 14, 2005 10:14 am |
|
|
Hi,
I'm returning to using a PIC again for a test application. I'm using compiler version 2.728 and am having a problem with a comms ISR.
I've effectively got the following code:
#include <16F877.H>
// DDRs
#byte TRISA = 0x85
#byte TRISB = 0x86
#byte TRISC = 0x87
#byte TRISD = 0x88
#byte TRISE = 0x89
// Port registers
#byte PORTA = 0x05
#byte PORTB = 0x06
#byte PORTC = 0x07
#byte PORTD = 0x08
#byte PORTE = 0x09
#fuses HS,NOWDT,NOPROTECT
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#define CSTX ('?')
#define CETX ('!')
#define BUFFER_SIZE 32
byte rx_buffer[BUFFER_SIZE];
byte rx_index;
byte rx_message_in;
void main(void)
{
InitPorts();
enable_interrupts(global);
enable_interrupts(int_rda);
rx_index = 0;
rx_message_in = 0;
while(1)
{
output_high( PIN_E1 );
output_low( PIN_E1 );
if( rx_message_in )
{
rx_message_in = 0;
}
}
}
#int_rda
void serial_isr(void)
{
byte inchar;
inchar = getc();
switch(inchar)
{
case CSTX :
rx_index = 0;
break;
case CETX:
rx_message_in = 1;
break;
default:
rx_buffer[rx_index] = inchar;
rx_index = (rx_index + 1) % BUFFER_SIZE;
break;
}
}
void InitPorts(void)
{
TRISA = 0x00;
TRISB = 0xC0;
TRISC = 0xC0;
TRISD = 0x00;
TRISE = 0x00;
PORTA = 0x00;
PORTB = 0x00;
PORTC = 0x00;
PORTD = 0x00;
PORTE = 0x00;
}
This is just test code to obtain a string under interrupt and to set a flag once the ETX char is obtained.
Now, if I only perform the TRISA and PORTA actions, everything works fine and I can rx chars under interrupt ok.
As soon as I set TRIS for ports B/C, I start to get frame errors in the comms.
I've checked the SFRs and everything looks to be ok but clearly something is amiss.
I've even tried repeating the "#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)" declaration at the end of initialising the ports but that didn't work either.
I'm running the code on an advanced transdata parallel ICD so I suspect that TRIS operations either upset the ICD..or the comms I/O...or both.
As I can't see what CCS does with the port for the comms, it's hard to know what might be wrong.
Anyone help, please? And don't just say, 'upgrade your compiler' (unless, of course, it IS a bug in the compiler).
Regards,
Dan |
|
|
Ttelmah Guest
|
|
Posted: Mon Mar 14, 2005 10:44 am |
|
|
If you are going to set TRIS for a port, add the specification #use fast_io(x) where 'x' is the port letter. This is necessary to tell CCS to leave the TRIS register alone.
There was a bug with the ICD core from Microchip for the 877 chip, which applies to any ICD unit, that uses their core in this version (most ICD's use the MicroChip core), which required the TRIS settings for the comms to differ from those in the data sheet. On units affected, the TRIS bits have to be 10, not 11. This caused me no end of hassles in the past...
Add 'NOLVP' to your fuses. Though it probably should not apply with the ICD, if this is enabled, RB3 is the serial programming pin, and can cause problems...
Best Wishes |
|
|
Guest
|
|
Posted: Tue Mar 15, 2005 2:07 am |
|
|
Hi,
Thanks for the quick reply. Initially, I thought you'd cracked it but it still will not work properly. The code is now:
#include <16F877.H>
#use fast_io(B)
#use fast_io(C)
#fuses HS,NOWDT,NOPROTECT,NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#define CSTX ('?')
#define CETX ('!')
#define BUFFER_SIZE 32
byte rx_buffer[BUFFER_SIZE];
byte rx_index;
byte rx_message_in;
void main(void)
{
SET_TRIS_B( 0xFF ); // not 0xC0 due to ICD bug
SET_TRIS_C( 0xFF );
enable_interrupts(global);
enable_interrupts(int_rda);
rx_index = 0;
rx_message_in = 0;
while(1)
{
output_high(PIN_E1);
output_low(PIN_E1);
}
}
#int_rda
void serial_isr(void)
{
byte inchar;
inchar = getc();
switch(inchar)
{
case CSTX :
rx_index = 0;
break;
case CETX:
rx_message_in = 1;
break;
default:
rx_buffer[rx_index] = inchar;
rx_index = (rx_index + 1) % BUFFER_SIZE;
break;
}
}
Now, if I set both TRISB and TRISC to 0xFF respectively, as shown, then the comms works ok.
If I set them to 0xC0 and 0x80 respectively, it doesn't work.
If I set them to 0xC0 and 0xC0 respectively, it doesn't work.
I even tried 0x80 and 0xC0 respectively and it still doesn't work.
The only other thing I can think of is an intermittant fault somewhere but it's too consistent for that, IMO.
Also, I had thought it might be a problem with WinXP and the advanced transdata IDE because the programming front end gets so far with counting up the locations flashed but then appears to hang (the window isn't updated)...before resuming normally when I suspect it's programmed everything. If I check the program memory, all the code is there. Besides, again, it seems too consistent to be this. i.e. if I swap back to working code, it always works.
Also, if I set TRISC to 0xFF, it has changed to 0xBF following me break pointing on rx of the '?' in the isr.
If I set TRISC to 0xC0 and TRISB to 0xFF, it doesn't work. When I check TRISC, the port is set to 0x80 anyway.
If I set TRISC to 0xBF and TRISB to 0xFF, it works.
It's a strange one. Oh well, that's embedded systems for you.
Cheers,
Dan |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Tue Mar 15, 2005 8:52 am |
|
|
Following is a piece of text posted by PCM programmer in the
Old Forum at October 22, 2000 at 17:23:31:
Quote: |
Posted by PCM programmer (209.85.139.111) on October 22, 2000 at 17:23:31:
I found a problem with the compiler. It fails with
vs. 2.693, and vs. 2.727 (and probably a lot of others).
I had a local variable in my #int_rda function, called "temp".
The compiler assigned this variable to the same address as
several other locals in other functions.
...............
...............
|
In those days I remember a lot of interminables discusions regarding the
UART dedicated pins and TRISC overlaping that were solved after.
For your sanity I strongly recommend try to get a new and more stable
version.
Best wishes,
Humberto |
|
|
|
|
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
|