Using Rockpis i am implementing Uart(serial communication), made a configuration of 9600bps baudrate then transfering the data, other end using Docklight software capturing the data. Here the time gap between two packets it is of 17Milliseconds at baudrate is 9600bps, is it possible to reduce that 17milliseconds to 10 milliseconds.
Data transfer over UART
sorry, i think the question is not clear, can you explain further?
Hi Jack,
Thank you for your reply 
We are transmitting large data over Rock Pi S UART. other end we are using Docklight software to receive the data. We noticed that packets split with a delay of 17miliseconds at 9600 baud rate. We are expecting less than 10milisecons instead of 17milisecond.
UART configuration - 9600 baud rate and NONE parity
Attached screenshot for your reference.
Diagram1 - wiring diagram
Diagram 2 - Application running, printing data which we transferred over UART
Diagram 3 - Received data with delay
Can you share the source code you wrote to test the uart?
Also, did you turn the Pi S in performance mode, ie the CPU is running at 1.3GHz.
No, we have not turned to performance mode. We are running sample code without any changes. let us know if anything to change and test.
Please find the below sample source code which we used to test.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h> //Header file for sleep(). man 3 sleep for details.
#include <pthread.h>
#include <fcntl.h> /* File Control Definitions */
#include <termios.h>/* POSIX Terminal Control Definitions*/
#include <sys/ioctl.h>
#include <string.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/select.h>
#include <sys/socket.h>
#include <time.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
int main()
{
struct termios o;
int fd1;
fd1=open("/dev/ttyS2", O_RDWR | O_NOCTTY | O_SYNC); if(fd1==1)
printf("\n Error! in openning ttyS1\n");
else
printf("ttyS1 Opened Successfully\n");
// Trying to set correct options here
tcgetattr(fd1,&o);
cfsetispeed(&o,B9600);
cfsetospeed(&o,B9600);
o.c_cflag &= ~ PARENB;
// o.c_cflag &= ~ PARODD;
o.c_cflag &= ~CSTOPB;o.c_cflag &= ~CSIZE;o.c_cflag |= CS8;
o.c_cflag &= ~CRTSCTS;
o.c_cflag |= CREAD | CLOCAL;
o.c_iflag &= ~(IXON | IXOFF | IXANY );
o.c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL );
o.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
o.c_oflag&=~OPOST;
o.c_cc[VMIN] = 1; //to prevent delay in read();
o.c_cc[VTIME] =1;
tcsetattr(fd1, TCSANOW, &o);
tcflush(fd1, TCIFLUSH);
int i=0,j=0;
char data_tx_buf[3000]={0};
for(i=0;i<1000;i++)
{
data_tx_buf[i]=i;
}
write(fd1,data_tx_buf,200);
for(j=0;j<200;j++)
printf("%d",j);
}
Hi Jack, Any update on this?
Can you set the cpu to performance mode and test again?
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
performance powersave
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
try this:
echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorHi Jack,
We tried changing scaling_governor to Performance mode but its not working. So we have changed to Userspace mode and changed frequency to maximum. But UART issue still exist.
Hi Team, Any solution for this
We are currently investigating this issue. We will get back to you later.
Dear Team,
Thanks for the response.
We tested your sample code on /dev/ttyS0 and /dev/ttyS2 on our ROCK S and a logic analyzer. We did not see the massive delay between data streams. Please check if you are using the latest system image for your ROCK S, and if you can reproduce this issue on other receiving devices.
Hi team,
We have generated custom build root and using the same in Rock Pi S module
Can you try our system image to verify this is not a hardware issue? Currently we are unable to provide support for custom images.