|
|
View previous topic :: View next topic |
Author |
Message |
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
Ideas on speeding up RS 232 communications |
Posted: Fri Jan 30, 2004 9:37 pm |
|
|
Hi,
I would like to have some suggestions on speeding up communications..
At present I am using a switch statement in the USART receive interrupt , the switch statement consists of the various commands ( in the form of single alphabets ), each alphabet performs a certain task...
for example...
switch (cmd)
{
case 'A':
// Performs some task here
// sends out a character to PC signifying end of task
break;
case 'B':
break;
}
Are there any other faster and more professional ways than the one above...
cheers
arun |
|
|
Ttelmah Guest
|
Re: Ideas on speeding up RS 232 communications |
Posted: Sat Jan 31, 2004 4:26 am |
|
|
arunb wrote: | Hi,
I would like to have some suggestions on speeding up communications..
At present I am using a switch statement in the USART receive interrupt , the switch statement consists of the various commands ( in the form of single alphabets ), each alphabet performs a certain task...
for example...
switch (cmd)
{
case 'A':
// Performs some task here
// sends out a character to PC signifying end of task
break;
case 'B':
break;
}
Are there any other faster and more professional ways than the one above...
cheers
arun |
Really, it depends on the 'nature' of your commands, and where the speed problem lays.
The problem with the approach you have, is that the system sits doing nothing else, while sending the reply. However for 'single character' outputs and responses, this approach will give the lowest latency (the time between the character being received, and the reply starting).
Generally, it is far better to buffer _all_ communications (both send and receive). Then the main loop, sits waiting for a character to appear in the incoming buffer, goes through a similar 'parsing' tree to deal with this. The replies are sent using an output buffer, which transfers data to the UART, as needed (using interrupt driven transmission). So something like:
Code: |
#define BUFSIZE (16)
//Must be a binary multiple size.
#define TOBUFF(val,buff,count,ip,op) buff[ip]=val;\
ip=(++ip)&(BUFSIZE-1);\
++count
#define FROMBUFF(val,buff,count,ip,op) val=buff[op];\
op = (++op)&(BUFSIZE-1);\
--count
#define ISEMPTY(val,buff,count,ip,op) (count==0)
int8 TXBUFF[BUFSIZE];
int8 RXBUFF[BUFSIZE];
int8 RXcount=0,TXcount=0,RXIP=0,RXOP=0,TXIP=0,TXOP=0;
#bit CREN=0x18.4
#bit OERR=0x18.1
#bit TXIE=0x8C.4
#int_TBE
void TBE_isr(void) {
//transmit data if any is waiting
if (ISEMPTY(TXout,TXBUFF,TXcount,TXIP,TXOP)) {
disable_interrupts(INT_TBE);
}
else {
FROMBUFF(TXout,TXBUFF,TXcount,TXIP,TXOP);
}
}
#int_RDA
void RDA_isr(void) {
//Receive data
TOBUFF(RCREG,RXBUFF,RXcount,RXIP,RXOP);
if (OERR) {
CREN=0;
CREN=1;
}
}
void put_RS232(int8 val) {
int1 flag;
flag = TXIE;
disable_interrupts(INT_TBE);
TOBUFF(val,TXBUFF,TXcount,TXIP,TXOP);
if (!flag) {
FROMBUFF(TXout,TXBUFF,TXcount,TXIP,TXOP);
}
enable_interrupts(INT_TBE);
}
|
Then in your main code, you can at quite 'loose' intervals, simply execute:
Code: |
if (!ISEMPTY(RCREG,RXBUFF,RXcount,RXIP,RXOP)) {
//Here there is some serial data
//Use the same sort of switch statement, but instead of 'getc',
//use:
val=FROMBUFF(RCREG,RXBUFF,RXcount,RXIP,RXOP);
//send your replies with:
printf(put_RS232,"String to send %d",val);
}
|
The key difference, is that provided you don't overflow the buffers (protection for this, can be coded in if needed), you can be receiving commands, even while replying to the last one....
Best Wishes |
|
|
|
|
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
|