Linux termios修改串口读取后的第一个字符()

时间:2021-11-29 21:03:14

My termios setup is modifying the first character read from the serial port using read(). I have a microcontroller talking to a linux box. The microcontroller responds to commands sent from the linux machine. The setup is as follows:

我的termios设置是使用read()修改从串行端口读取的第一个字符。我有一个微控制器与linux盒子交谈。微控制器响应从linux机器发送的命令。设置如下:

  • microcontroller(PIC24F) RS485 port <--> RS485 to USB converter <--> Ubuntu PC.
  • 微控制器(PIC24F)RS485端口< - > RS485转USB转换器< - > Ubuntu PC。

When I run a terminal program such as Cutecom everything works as planned. I send a command character to the PIC and I get a response however when I use my command line program the first character is being modified. Here is my code:

当我运行像Cutecom这样的终端程序时,一切都按计划运行。我向PIC发送一个命令字符然后我得到一个响应,但是当我使用我的命令行程序时,第一个字符正在被修改。这是我的代码:

#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>

#define DEVICE "/dev/ttyUSB0"
#define SPEED B38400 

int main()
{
    struct termios tio; //to hold serial port settings
    struct termios stdio; //so we can accept user input
    struct termios old_stdio; //save the current port settings
    int tty_fd; //file descriptor for serial port
    int res, n, res2, read1, wri;
    char buf[255];
    char buf2[255]; 

    //save the current port settings
    tcgetattr(STDOUT_FILENO,&old_stdio); 

    //setup serial port settings
    bzero(&tio, sizeof(tio));
    tio.c_iflag = 0;
    tio.c_iflag = IGNPAR | IGNBRK | IXOFF;
    tio.c_oflag = 0;
    tio.c_cflag = CS8 | CREAD | CLOCAL; //8n1 see termios.h 
    tio.c_lflag = ICANON;

    //open the serial port
    tty_fd=open(DEVICE, O_RDWR | O_NOCTTY); 

    //set the serial port speed to SPEED
    cfsetospeed(&tio,SPEED); 

    //apply to the serial port the settings made above
    tcsetattr(tty_fd,TCSANOW,&tio); 

    for(n = 5; n > 0; n--)
    {
    printf("Please enter a command: ");
    (void)fgets(buf2, 255, stdin);
    (void)write(tty_fd, buf2, strlen(buf2));                   
    printf("Ok. Waiting for reply.");
    res = read(tty_fd, buf, 255);       
    printf("Read:%d START%d %d %d %d %dFINISH\n",res,buf[0],buf[1],buf[2],buf[3],
    buf[4]);              
    }

    //close the serial port 
    close(tty_fd); 

    //restore the original port settings
    tcsetattr(STDOUT_FILENO,TCSANOW,&old_stdio); 

    return EXIT_SUCCESS; 
}

Here is an example of results I am getting.

这是我得到的结果的一个例子。

  • When the PIC sends "00000\n" the output is: Read: 6 START-16 48 48 48 48FINISH
  • 当PIC发送“00000 \ n”时,输出为:读取:6 START-16 48 48 48 48FINISH

  • When the PIC sends "23456\n" the output is: Read: 6 START-14 51 52 53 54FINISH
  • 当PIC发送“23456 \ n”时,输出为:读:6 START-14 51 52 53 54FINISH

  • When the PIC sends "34567\n" the output is: Read: 6 START-14 52 53 54 55FINISH
  • 当PIC发送“34567 \ n”时,输出为:读取:6 START-14 52 53 54 55FINISH

  • When the PIC sends "45678\n" the output is: Read: 6 START-12 53 54 55 56FINISH
  • 当PIC发送“45678 \ n”时,输出为:读取:6 START-12 53 54 55 56FINISH

  • When the PIC sends "56789\n" the output is: Read: 6 START-12 54 55 56 57FINISH
  • 当PIC发送“56789 \ n”时,输出为:读取:6 START-12 54 55 56 57FINISH

For some reason the first character is getting messed up by some termios setting. It must be the termios settings as the same test inputs above are returned exactly when I run Cutecom. I have read the manual pages over and over, trying all different settings on the input control but no matter what I do cannot shakes this problem.

出于某种原因,第一个角色被某些termios设置搞砸了。它必须是termios设置,因为上面相同的测试输入完全在我运行Cutecom时返回。我一遍又一遍地阅读手册页,尝试输入控件上的所有不同设置,但无论我做什么都不能解决这个问题。

For an easy fix I can just shift my data across 1 character but want to avoid doing this.

为了方便修复,我可以将数据移到1个字符上,但是要避免这样做。

Has anyone experienced such a problem or have any idea what to do about it?

有没有人遇到过这样的问题或者有什么想法呢?

Many thanks.

28/3/13 Great suggestion Austin. For those who are interested here are the two outputs:

28/3/13很棒的建议奥斯汀。对于那些感兴趣的人来说,有两个输出:

  • First are the termios settings in my program

    首先是我的程序中的termios设置

    speed 38400 baud; rows 0; columns 0; line = 0; intr = ; quit = ; erase = ; kill = ; eof = ; eol = ; eol2 = ; swtch = ; start = ; stop = ; susp = ; rprnt = ; werase = ; lnext = ; flush = ; min = 0; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

    速度38400波特;第0行;第0列; line = 0; intr =;退出=; erase =; kill =; eof =; eol =; eol2 =; swtch =; start =;停止=; susp =; rprnt =; werase =; lnext =; flush =; min = 0;时间= 0; -parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

  • And the settings that cutecom uses

    以及cutecom使用的设置

    speed 38400 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 60; time = 1; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

    速度38400波特;第0行;第0列; line = 0; intr = ^ C;退出= ^ \; erase = ^?; kill = ^ U; eof = ^ D; eol =; eol2 =; swtch =; start = ^ Q; stop = ^ S; susp = ^ Z; rprnt = ^ R; werase = ^ W; lnext = ^ V; flush = ^ O; min = 60;时间= 1; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr - onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

I am still going through it all and will update the post when I make progress.

我仍然经历这一切,并将在我取得进展时更新帖子。

29/3/13 Still have the same problem. I even found the source code to Cutecom and followed the termios settings they use. Still the problem exists. That first character is corrupted!!!!

29/3/13仍然有同样的问题。我甚至找到了Cutecom的源代码,并遵循他们使用的termios设置。问题仍然存在。第一个角色已损坏!!!!

  • Here are the Termios settings from my program. Cannot set flush for some reason.

    以下是我的程序中的Termios设置。由于某种原因无法设置刷新。

    speed 38400 baud; rows 0; columns 0; line = 0; intr = ^?; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ; min = 60; time = 1; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

    速度38400波特;第0行;第0列; line = 0; intr = ^?;退出= ^ \; erase = ^ H; kill = ^ U; eof = ^ D; eol =; eol2 =; swtch =; start = ^ Q; stop = ^ S; susp = ^ Z; rprnt = ^ R; werase = ^ W; lnext = ^ V; flush =; min = 60;时间= 1; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr - onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

  • And my new code:

    我的新代码:

    #include <stdlib.h>
    #include <stdio.h>
    #include <unistd.h>
    #include <fcntl.h>
    #include <termios.h>
    #include <sys/ioctl.h>
    
    #define DEVICE "/dev/ttyUSB0"
    #define SPEED B38400 
    
    int main()
    {
    struct termios tio; //to hold serial port settings
    struct termios stdio; //so we can accept user input
        struct termios old_stdio; //save the current port settings
        int tty_fd; //file descriptor for serial port
        int retval, res, n, res2, read1, wri;
        char buf[255];
        char buf2[255]; 
    
    
        tty_fd = open(DEVICE, O_RDWR | O_NDELAY);
        if(tty_fd < 0)
        {
            perror(DEVICE);
            exit(-1);
        }
        printf("Init 1 complete.\n");
    
        tcflush(tty_fd, TCIOFLUSH);
    
        int f = fcntl(tty_fd, F_GETFL, 0);
        fcntl(tty_fd, F_SETFL, f & ~O_NDELAY);
    
        retval = tcgetattr(tty_fd, &old_stdio);
        if(retval != 0)
        {
            perror(DEVICE);
            exit(-1);
        }
        printf("Init 2 complete.\n");
    
        struct termios newtio;
        retval = tcgetattr(tty_fd, &newtio);
        if(retval != 0)
        {
            perror(DEVICE);
            exit(-1);
        }
        printf("Init 3 complete.\n");
    
        cfsetospeed(&newtio, SPEED);
        cfsetispeed(&newtio, SPEED);
    
        newtio.c_cflag = (newtio.c_cflag & ~CSIZE) | CS8;
        newtio.c_cflag |= CLOCAL | CREAD;
        newtio.c_cflag &= ~(PARENB | PARODD);
        newtio.c_cflag &= ~CRTSCTS;
        newtio.c_cflag &= ~CSTOPB;
    
        newtio.c_iflag = IGNBRK;
        newtio.c_iflag &= ~(IXON | IXOFF | IXANY);
    
        newtio.c_lflag = 0;
    
        newtio.c_oflag = 0;
    
        newtio.c_cc[VTIME] = 1;
        newtio.c_cc[VMIN] = 60;
        newtio.c_cc[VINTR] = 127; 
        newtio.c_cc[VQUIT] = 28;
        newtio.c_cc[VERASE] = 8;
        newtio.c_cc[VKILL] =  21;
        newtio.c_cc[VEOF] = 4;
        newtio.c_cc[VSTOP] = 19;
        newtio.c_cc[VSTART] = 17;
        newtio.c_cc[VSUSP] = 26;
        newtio.c_cc[VREPRINT] = 18;
        newtio.c_cc[VFLSH] = 15;
        newtio.c_cc[VWERASE] = 23;
        newtio.c_cc[VLNEXT] = 22;
    
    
        retval = tcsetattr(tty_fd, TCSANOW, &newtio);
        if(retval != 0)
        {
            perror(DEVICE);
            exit(-1);
        }
        printf("Init 4 complete.\n");
    
        int mcs = 0;
        ioctl(tty_fd, TIOCMGET, &mcs);
        mcs |= TIOCM_RTS;
        ioctl(tty_fd, TIOCMSET, &mcs);
    
        retval = tcgetattr(tty_fd, &newtio);
        if(retval != 0)
        {
            perror(DEVICE);
            exit(-1);
        }
        printf("Init 5 complete.\n");
    
        newtio.c_cflag &= ~CRTSCTS;
    
        retval = tcsetattr(tty_fd, TCSANOW, &newtio);
        if(retval != 0)
        {
            perror(DEVICE);
            exit(-1);
        }
        printf("Init 6 complete.\n");
    
    
        for(n = 5; n > 0; n--)
        {
        printf("Please enter a command: ");
        (void)fgets(buf2, 255, stdin);
        (void)write(tty_fd, buf2, strlen(buf2));
        printf("Ok. Waiting for reply\n");
        res = read(tty_fd, buf, 255);       
        printf("Read:%d START%d %d %d %d %dFINISH\n",res,buf[0],buf[1],buf[2], buf[3],
        buf[4]);              
        }
    
        //restore the original port settings
        tcsetattr(tty_fd, TCSANOW, &old_stdio); 
    
        close(tty_fd);
    
        return EXIT_SUCCESS; //return all good
    }
    

I am totally lost as to what can be done or where I should take it from here.

我完全迷失了可以做什么或者我应该从哪里开始。

2 个解决方案

#1


2  

I can't see anything obviously wrong with a quick scan of your code. You may want to consider moving to unsigned char buf[] if you're expecting to work with 8 bit values.

快速扫描您的代码,我看不出任何明显错误。如果您希望使用8位值,可能需要考虑转移到unsigned char buf []。

Since you have a working program in Cutecom, you can use their termios settings as a reference to debug your own program.

由于您在Cutecom中有一个工作程序,您可以使用他们的termios设置作为调试您自己的程序的参考。

With Cutecom running on /dev/ttyUSB0, run the following command in another terminal to dump the tty settings:

使用Cutecom在/ dev / ttyUSB0上运行,在另一个终端中运行以下命令以转储tty设置:

stty -a -F /dev/ttyUSB0

Do the same when running your program and look for differences between the two configurations. Try setting up the terminal settings in your program to exactly match those reported for Cutecom.

在运行程序时执行相同操作并查找两种配置之间的差异。尝试在程序中设置终端设置,使其与Cutecom报告的设置完全匹配。

Update:

Since fixing the termios settings hasn't resolved the issue, here are some further things to try. I'd hazard a guess that there is a timing problem somewhere. When typing on the Cutecom console, you're sending 1 character at a time to your device with many milliseconds between characters. When using your program, a complete buffer of characters will be sent after you enter a command, with the characters being sent back-to-back as fast as the driver allows. Maybe your PIC program can't handle the timing of the data stream, or expects two stop bits for example instead of one, resulting in some weird return codes.

由于修复termios设置尚未解决问题,因此可以尝试以下一些方法。我猜测某个地方有时间问题。在Cutecom控制台上键入时,您一次向设备发送1个字符,字符之间的间隔为毫秒。使用程序时,输入命令后将发送完整的字符缓冲区,字符将以驱动程序允许的速度背靠背发送。也许你的PIC程序无法处理数据流的时序,或者预期两个停止位而不是一个,导致一些奇怪的返回码。

Probably the best place to start is back at the source. Get hold of an oscilloscope or logic analyzer and verify that the data being sent by the PIC is in fact correct. You'll have to understand the bit level waveforms, allowing for start and stop bits. Compare the waveforms for both Cutecom and your program. If using a logic analyzer ensure the clock used is some high multiple of your baud rate. eg a 32 multiplier.

可能最好的起点是从源头回来。掌握示波器或逻辑分析仪,确认PIC发送的数据实际上是正确的。您必须了解位级波形,允许启动和停止位。比较Cutecom和您的程序的波形。如果使用逻辑分析仪,请确保使用的时钟是波特率的高倍。例如32乘法器。

Another way to debug is by using strace to verify that the characters returned by the driver are in fact incorrect and that's it's not a problem with your program. Using strace, you'll be able to see the raw reads/writes of your program and what is returned by the kernel. Use strace -o ~/tmp/strace_output.txt -ttt -xx your_program to dump all the system calls while your program is running. Sometimes, just the process of stracing a program will slow it down enough to show timing errors. You could compare the timing of the read/writes with an strace of Cutecom. Just for testing, you could add your own write() function which sends a string but delays a small amount between each character.

另一种调试方法是使用strace来验证驱动程序返回的字符实际上是不正确的,这对您的程序来说不是问题。使用strace,您将能够看到程序的原始读/写以及内核返回的内容。使用strace -o~ / tmp / strace_output.txt -ttt -xx your_program在程序运行时转储所有系统调用。有时候,只需要对程序进行处理就会使其慢下来以显示计时错误。您可以将读/写的时间与Cutecom的时间进行比较。仅用于测试,您可以添加自己的write()函数,该函数发送字符串但在每个字符之间延迟少量。

#2


0  

I finally worked it out. This is what fixed it:

我终于解决了。这是修正它的原因:

  • (void)write(tty_fd, buf2, 1);
  • (void)write(tty_fd,buf2,1);

Problem is fixed but not 100% sure as to why it was doing what it was. The problem was my program appending a \n to the micro controller write. When I did the strace on both Cutecom and my program this I found that Cutecom writes '1' only whereas my program would write "1\n". I just didn't think it through enough because when using Cutecom to send a character you type for example 1 in the user prompt and then hit enter. On the PIC side my program looks like this:

问题是固定的,但不是100%肯定它为什么做它是什么。问题是我的程序将一个\ n附加到微控制器写入。当我对Cutecom和我的程序进行了分析时,我发现Cutecom只写'1'而我的程序会写“1 \ n”。我只是没有想到这一点,因为当使用Cutecom发送你在用户提示中键入例如1的字符然后点击回车。在PIC方面,我的程序看起来像这样:

while(1)
{
    WATCHDOG();

    if(flag == 1)
    {
        char *start = str2;
        RS485_TXEN1();
        indicator = UART1_getch(); //get character sent from PC
        switch(indicator)
        {
            case '1' :                       
                    UART1_putstr("00000\n");
                    DAC_Write( DAC_CH_2, 4095);
                    break;
            case '2' :                      
                    UART1_putstr("23456\n");
                    DAC_Write( DAC_CH_2, 0);
                    break;
            case '3' :
                    UART1_putstr("34567\n");
                    break;
            case '4' :                       
                    UART1_putstr("45678\n");
                    break;
            case '\n' :
                    UART1_putch('\n');
                    break;
            default  :         
                    UART1_putstr("56789\n");                  
                    break;
        }
        RS485_RXEN1();
        flag = 0;
    }
} 

When a character arrives on the UART RX an interrupt is generated. I set "flag" in this interrupt service routine and then service the received command in main(). Not sure how the first character was being modified like it was but looks like there was some overwriting or write interrupt occurring due to "case '\n' :".

当字符到达UART RX时,会产生中断。我在此中断服务程序中设置“flag”,然后在main()中处理接收到的命令。不确定第一个字符是如何被修改的,但看起来由于“case'\ n':”而发生了一些覆盖或写入中断。

Simple fix in the end and even learnt some valuable lessons working with a Linux system and debugging. Thanks to everyone that offered suggestions. To anybody wanting to get a start on interfacing a linux box and micro controller the above codes might be helpful in getting you started.

最后简单修复,甚至学习了一些使用Linux系统和调试的宝贵经验。感谢所有提出建议的人。对于任何想要开始连接linux盒子和微控制器的人来说,上面的代码可能对你有所帮助。

#1


2  

I can't see anything obviously wrong with a quick scan of your code. You may want to consider moving to unsigned char buf[] if you're expecting to work with 8 bit values.

快速扫描您的代码,我看不出任何明显错误。如果您希望使用8位值,可能需要考虑转移到unsigned char buf []。

Since you have a working program in Cutecom, you can use their termios settings as a reference to debug your own program.

由于您在Cutecom中有一个工作程序,您可以使用他们的termios设置作为调试您自己的程序的参考。

With Cutecom running on /dev/ttyUSB0, run the following command in another terminal to dump the tty settings:

使用Cutecom在/ dev / ttyUSB0上运行,在另一个终端中运行以下命令以转储tty设置:

stty -a -F /dev/ttyUSB0

Do the same when running your program and look for differences between the two configurations. Try setting up the terminal settings in your program to exactly match those reported for Cutecom.

在运行程序时执行相同操作并查找两种配置之间的差异。尝试在程序中设置终端设置,使其与Cutecom报告的设置完全匹配。

Update:

Since fixing the termios settings hasn't resolved the issue, here are some further things to try. I'd hazard a guess that there is a timing problem somewhere. When typing on the Cutecom console, you're sending 1 character at a time to your device with many milliseconds between characters. When using your program, a complete buffer of characters will be sent after you enter a command, with the characters being sent back-to-back as fast as the driver allows. Maybe your PIC program can't handle the timing of the data stream, or expects two stop bits for example instead of one, resulting in some weird return codes.

由于修复termios设置尚未解决问题,因此可以尝试以下一些方法。我猜测某个地方有时间问题。在Cutecom控制台上键入时,您一次向设备发送1个字符,字符之间的间隔为毫秒。使用程序时,输入命令后将发送完整的字符缓冲区,字符将以驱动程序允许的速度背靠背发送。也许你的PIC程序无法处理数据流的时序,或者预期两个停止位而不是一个,导致一些奇怪的返回码。

Probably the best place to start is back at the source. Get hold of an oscilloscope or logic analyzer and verify that the data being sent by the PIC is in fact correct. You'll have to understand the bit level waveforms, allowing for start and stop bits. Compare the waveforms for both Cutecom and your program. If using a logic analyzer ensure the clock used is some high multiple of your baud rate. eg a 32 multiplier.

可能最好的起点是从源头回来。掌握示波器或逻辑分析仪,确认PIC发送的数据实际上是正确的。您必须了解位级波形,允许启动和停止位。比较Cutecom和您的程序的波形。如果使用逻辑分析仪,请确保使用的时钟是波特率的高倍。例如32乘法器。

Another way to debug is by using strace to verify that the characters returned by the driver are in fact incorrect and that's it's not a problem with your program. Using strace, you'll be able to see the raw reads/writes of your program and what is returned by the kernel. Use strace -o ~/tmp/strace_output.txt -ttt -xx your_program to dump all the system calls while your program is running. Sometimes, just the process of stracing a program will slow it down enough to show timing errors. You could compare the timing of the read/writes with an strace of Cutecom. Just for testing, you could add your own write() function which sends a string but delays a small amount between each character.

另一种调试方法是使用strace来验证驱动程序返回的字符实际上是不正确的,这对您的程序来说不是问题。使用strace,您将能够看到程序的原始读/写以及内核返回的内容。使用strace -o~ / tmp / strace_output.txt -ttt -xx your_program在程序运行时转储所有系统调用。有时候,只需要对程序进行处理就会使其慢下来以显示计时错误。您可以将读/写的时间与Cutecom的时间进行比较。仅用于测试,您可以添加自己的write()函数,该函数发送字符串但在每个字符之间延迟少量。

#2


0  

I finally worked it out. This is what fixed it:

我终于解决了。这是修正它的原因:

  • (void)write(tty_fd, buf2, 1);
  • (void)write(tty_fd,buf2,1);

Problem is fixed but not 100% sure as to why it was doing what it was. The problem was my program appending a \n to the micro controller write. When I did the strace on both Cutecom and my program this I found that Cutecom writes '1' only whereas my program would write "1\n". I just didn't think it through enough because when using Cutecom to send a character you type for example 1 in the user prompt and then hit enter. On the PIC side my program looks like this:

问题是固定的,但不是100%肯定它为什么做它是什么。问题是我的程序将一个\ n附加到微控制器写入。当我对Cutecom和我的程序进行了分析时,我发现Cutecom只写'1'而我的程序会写“1 \ n”。我只是没有想到这一点,因为当使用Cutecom发送你在用户提示中键入例如1的字符然后点击回车。在PIC方面,我的程序看起来像这样:

while(1)
{
    WATCHDOG();

    if(flag == 1)
    {
        char *start = str2;
        RS485_TXEN1();
        indicator = UART1_getch(); //get character sent from PC
        switch(indicator)
        {
            case '1' :                       
                    UART1_putstr("00000\n");
                    DAC_Write( DAC_CH_2, 4095);
                    break;
            case '2' :                      
                    UART1_putstr("23456\n");
                    DAC_Write( DAC_CH_2, 0);
                    break;
            case '3' :
                    UART1_putstr("34567\n");
                    break;
            case '4' :                       
                    UART1_putstr("45678\n");
                    break;
            case '\n' :
                    UART1_putch('\n');
                    break;
            default  :         
                    UART1_putstr("56789\n");                  
                    break;
        }
        RS485_RXEN1();
        flag = 0;
    }
} 

When a character arrives on the UART RX an interrupt is generated. I set "flag" in this interrupt service routine and then service the received command in main(). Not sure how the first character was being modified like it was but looks like there was some overwriting or write interrupt occurring due to "case '\n' :".

当字符到达UART RX时,会产生中断。我在此中断服务程序中设置“flag”,然后在main()中处理接收到的命令。不确定第一个字符是如何被修改的,但看起来由于“case'\ n':”而发生了一些覆盖或写入中断。

Simple fix in the end and even learnt some valuable lessons working with a Linux system and debugging. Thanks to everyone that offered suggestions. To anybody wanting to get a start on interfacing a linux box and micro controller the above codes might be helpful in getting you started.

最后简单修复,甚至学习了一些使用Linux系统和调试的宝贵经验。感谢所有提出建议的人。对于任何想要开始连接linux盒子和微控制器的人来说,上面的代码可能对你有所帮助。