USB between PiPico and RaspberryPi

[Trev4G]

I have bCNC on a RPi communicating with grblHAL on a PiPico via usb. This works when bCNC is connected via ttyACM0. However, I want to add data from my own software to the connection. So I wrote a C program to create a pseudo terminal (/dev/pts/2) and interchange data petween ttyACM0 and pts/2. With bCNC connected to the pseudo terminal pts/2. I can open the terminal on bCNC and commands such as '?' & '$$' work fine. When I try to execute a jog or any lengthy G-code command most of the time it is ignored by grblHAL. There is no error code and on the odd occasions when it works it functions correctly.

I have tried a number of different termios settings for the terminals to no avail.

However, configuring grblHAL for serial input and connecting via a USB to TTL convertor module solves the problem and my program transfers data without any problems. grblHAL executing all commands without error. In this case the the terminal used is ttyUSB0 rather than ttyACM0.

I want to avoid using the extra module required by this work round. I am concerned that the use of usb input on the PiPico may have limitations and my software has pushed it over the edge. I would appreciate any thoughts / fixes for this issue.

[terjeio]

Not sure I understand what you have been trying to achieve - is it mixing data from two clients to the single Pico USB port and sending responses back to both?

I am concerned that the use of usb input on the PiPico may have limitations and my software has pushed it over the edge. I would appreciate any thoughts / fixes for this issue.

At least post the C program if you want anybody to come up with suggestions?

[Trev4G]

Not sure I understand what you have been trying to achieve - is it mixing data from two clients to the single Pico USB port and sending responses back to both?

That is the plan but at present, for test purposes, there is only a single client with all data being sent to a log file for debugging.

Program is listing below.

From the header

#define	HYBRID // USB -> USB TTL converter -> UART
				// Otherwise assume USB -> USB
#ifdef HYBRID   
	#define USB_TTY "/dev/ttyUSB0"
#else
	#define USB_TTY "/dev/ttyACM0"
#endif

#define CONTROL_TTY "/dev/tty"

The main function

// Open pseudo tty
   master = posix_openpt(O_RDWR | O_NONBLOCK | O_EXCL);
//    master = posix_openpt(O_RDWR );
   if (master == -1)
   {
       err_Exit("Error - Unable to open pseudo terminal");
   }
   grantpt(master);
   unlockpt(master);
//

// Open USB port
  usb_stream = open(USBport, O_RDWR | O_NOCTTY | O_NDELAY);
    if (usb_stream == -1)
    {
        cerr << "Error - Unable to open"<< USBport << " USB port" << endl;
        exit(EXIT_FAILURE);
    }
    else
    {
        cout << "USB " << USBport << " - opened" << endl;
    }

    Settermios(master, usb_stream);


    cout << "PTY: "<< ptsname(master) << endl;
    cout << " '|' to terminate program" << endl;


////////////////////////////////////////////////////////////////////////
#ifdef DEBUG_FILE
// DEBUG only
    int Dirflag = 0; // shows direction of last data sent 0=unknown 1=from grbl 2=to grbl
    char rx_Dbuf[2]="^";
    char tx_Dbuf[2]="v";

    scriptFd = open("Fmux.log",O_WRONLY | O_CREAT | O_TRUNC,
        S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP |S_IROTH | S_IWOTH);
#endif //DEBUG_FILE


    while (true) /* main loop */
    {
        int n = 1;
        if (read(usb_stream, rx_ubuf, 1) == 1)  // USB IN
        {
            tx_pbuf[0] = rx_ubuf[0];
            write(master, tx_pbuf, 1);
#ifdef DEBUG_FILE
            if (Dirflag != 1)
            {
                Dirflag = 1;
                write(scriptFd, rx_Dbuf, 1);
            }
            write(scriptFd, tx_pbuf, 1);
#endif //DEBUG_FILE
        }
        /* read from the master file descriptor */
        if (read(master, rx_pbuf, 1) == 1)
        {
            tx_ubuf[0] = rx_pbuf[0];
            write(usb_stream, tx_ubuf, 1);

#ifdef DEBUG_FILE
            if (Dirflag != 2)
            {
                Dirflag = 2;
                write(scriptFd, tx_Dbuf, 1);
            }
            write(scriptFd, tx_ubuf, n);
#endif //DEBUG_FILE
         }
        if (read(vt0_filestream, &cntrlBuf, 1) == 1)
        {
            if (cntrlBuf[0] == '|')
            {
                if (Resettermios(master, usb_stream) == -1)
                {
                    exit(EXIT_FAILURE);
                }
                cout << "Normal Program Termination" << endl;         
                return 0;
            }
        }
    }
    Resettermios(master, usb_stream);
    exit(EXIT_FAILURE);
}

[terjeio]

USB is a packet based interface - perhaps try to buffer more characters to improve throughput?
Data coming from the controller are strings terminated by CR+LF so buffering incoming data is fairly easy. Data from the sender is a bit more complicated as this is a mix of strings and single character (real-time) commands. The real-time commands should not be buffered?
And if there are two clients gcode commands should not be possible mix?

FYI I use special packet buffering for outgoing data from the controller for some of the drivers that supports native USB. Some of these requires breaking up the data in 64 byte packets as this is, AFAIK, the USB packet size.

[Trev4G]

Data coming from the grblHAL controller is not an issue. There is no evidence of data loss in this direction. With data going to the controller separating the real time commands and then buffering the other commands is something I have yet to try. However, I have no problem when using USB to a TTL serial converter this suggests there something else going on. The difference between ttyUSB0 and ttyACM0 looks like it may hold the answer. This is where my knowledge fails me and I need help.

And if there are two clients gcode commands should not be possible mix?

Mixing gcodes from two clients can be achieved providing care is taken to manage the two streams. I have linked my program to the software with fifo pipes. Both clients get any data from grblHAL. bCNC will only send commands when it is active. When IDLE status is being recieved my program can send gcode commands. bCNC will update position and show IDLE/RUN/JOG status even though it did not send the gcode responsible for the activity. This is what I was hoping for and in tests earlier today I was able to see this working reliably.

[terjeio]

The difference between ttyUSB0 and ttyACM0 looks like it may hold the answer. This is where my knowledge fails me and I need help.

I have not worked with Linux (Unix) USB ttys - USB was not invented last time I wrote tty code for Unix... Perhaps someone else can help, maybe by asking on a Raspberry Pi forum?

BTW are you using a recent version of the Pico firmware? There was an issue with the DTR signal causing trouble - which is now fixed.

[Trev4G]

Finally got round to buffering traffic from bCNC to grblHAL. To get round the realtime command problem I put everything into a buffer until a launch character is added to the buffer. Defining the launch character as \n ~ ! ? Cntrl-X and anything >=0x7E. Note I do not buffer traffic from grblHAL to bCNC.

The result SUCCESS I can now get grblHAL to execute commands from bCNC without a problem.

I don't think this is a 64 byte packet problem otherwise a direct link avoiding my program would not have worked either. Given everything that has occured it looks much more likely to be a timing issue where gaps between characters are causing the whole command to be ignored. The lack of an error message suggests that delivery of a command fragment is not occuring.