How to receive UART data in interrupt mode

[qwerty]

I need to send and receive 75 bytes of data through each UART channel for 4 channels in 1ms .
I had been using read () in 4 threads for reception, but I am not able do it in 1ms .Can I do in interrupt mode?
how to receive data in interrupt mode can anyone share a code to receive data through interrupt mode?
I am using 600k BAUDRATE, UART CHANNELS 2,5,7,8

[dciliske]

Check your baudrate. 600kbaud = 480kbps = 60kBps = 60 bytes per ms. You can't do it. You need to increase the baudrate or look at some other method of transfer.

[pbreed]

600K baud Start, stop and 8 data bits is 60,000 bytes per second.

So in one ms that is 60 bytes.

75>60 check your math...

The normal OpenSerial driver is interrupt driven, but it s doing a fair bit of work managing
all of the fd, buffer, flow control etc....

You might benifit from writing a direct clean tailored recieve only interrupt or DMA driven system

There are examples of write your own serial drivers in the appnotes for the MOD5270.. the 54415 would be similar...

You can also just override the m_pPutCharFunc function pointer to have function that gets called with each received char and does not of the FD and buffer managment stuff.



To do this:

#include <serinternal.h>

Write your function..

//Called with num = port number starting at 0, not the port FD and the recieved char
//Deal with chars here... will be called in interrupt space so your RTOS function usage is limited to
//to only thoose functions legal in an interrupt read the interrupt section in the programmers guide.
void MyCharFunc(int num, BYTE c )
{

}



Then AFTER you have opened the serial ports with openserial...

UartData[2].m_pPutCharFunc = MyCharFunc;
UartData[5].m_pPutCharFunc = MyCharFunc;
UartData[7].m_pPutCharFunc = MyCharFunc;
UartData[8].m_pPutCharFunc = MyCharFunc;

[qwerty]

can anyone share a UART code using DMA for MOD54415
or the instructions to do so.

[qwerty]

when I am transmitting 16 bytes it takes 1ms at 460800 BAUD RATE
but when I enable reception(reception from another netburner transmitting at same rate )along with transmission the transmission time increases to max of 5ms .
what is the reason for this dependency, how can it be resolved?
can this be solved by using DMA driven system.

[dciliske]

Are you using RS-485 in Half Duplex mode? If you're doing that, I don't know how exactly the throughput would behave.

[qwerty]

For the time being lets consider that I am using wires to short(electrical ) the rx & tx pins

[pbreed]

There is latency in all systems..

On a single RX/TX pair...

460800

Assuming set to 8,n,1 will be 46080 bytes per second or about 46 bytes per msec.

This needs to be queued into and out of the buffer...

How are you measuring the timing?

Are you looking at the output in a scope?

Are you sending the bytes in a single write? Are you using printf what exactly are you doing?

Are you doing this in debug or release mode?

[pbreed]

I did a quick test...
Sending 16 chars out one uart and receiving them on another...
Theoretical best possible time on the wire is 0.347222222 msec
Actual measured time to send and receive is 0.363584 msec
so we lost 16 usec to library overhead.

My test program is below....

#include "predef.h"
#include <stdio.h>
#include <ctype.h>
#include <startnet.h>
#include <autoupdate.h>
#include <dhcpclient.h>
#include <smarttrap.h>
#include <taskmon.h>
#include <serial.h>
#include <pins.h>
#include <hirestimer.h>


extern "C" {
void UserMain(void * pd);
}


const char * AppName="uarttest";

void UserMain(void * pd)
{
InitializeStack();/* Setup the TCP/IP stack buffers etc.. */

GetDHCPAddressIfNecessary();/*Get a DHCP address if needed*/
/*You may want to add a check for the return value from this function*/
/*See the function definition in \nburn\include\dhcpclient.h*/

OSChangePrio(MAIN_PRIO);/* Change our priority from highest to something in the middle */

EnableAutoUpdate();/* Enable the ability to update code over the network */

EnableSmartTraps();/* Enable the smart reporting of traps and faults */

EnableTaskMonitor();/*Enable the Task scan utility */

J2[39].function(PINJ2_39_UART8_RXD);
J2[41].function(PINJ2_41_UART9_RXD);
J2[42].function(PINJ2_42_UART8_TXD);
J2[44].function(PINJ2_44_UART9_TXD);

int fdtx=SimpleOpenSerial(9,+115200*4);
int fdrx=SimpleOpenSerial(8,+115200*4);

HiResTimer* hrt=HiResTimer::getHiResTimer();

static char buffer[40];
hrt->init();
hrt->start();
write(fdtx,"0123456789012345",16);
int nr=0;
int rv=0;
int ntimes=0;

while(nr<16)
{
rv=read(fdrx,buffer+nr,20);
nr+=rv;
ntimes++;
}
hrt->stop();
double v=hrt->readTime();
buffer[nr]=0;
printf("Read %d chars[%s] in %d reads in %g msec \r\n",nr,buffer,ntimes,v*1000.0);

while (1)
{

OSTimeDly(TICKS_PER_SECOND * 1);
}
}

[dciliske]

Follow up question: What version of the NNDK are you running? There was a *nasty* latency bug that was fixed in 2.6.3. If you are running anything prior to 2.6.3, you *need* to update. This issue was due to an undocumented feature in the processor failing to play with the configuration of the hardware.