Serial Terminal Server and PRU project

Hello everyone,

my name is Giorgio Gross (Nick: ordsen). I’m a second year undergraduate studying computer sciences in Germany. I’m new to embedded systems but I aim to hear more lectures on this topic and regard GSoC as a possibility to dive in even deeper. That’s one of the reasons I would like to work with you. I have been using mainly Java, C#, JS, PHP and C, although I learned many new skills in C during the current term. I published some of my projects on GitHub. Both the „PRUs to offload processing of raw data from on-board Peripherals“ and the „BeagleBone-based Serial Terminal Server“ projects catched my attention. I intend to apply for the latter as it is my favorite.

I created a pull request at the gsoc-application repo and checked the file type of the compiled binary. My terminal tells me it is compiled for 32Bit ARM CPUs, I also tested it with qemu but I would be glad if someone reviews it and tells me if there is something missing. I also set up a blog which I will use to summarize my thoughts about the GSoC project as time permits. Regarding the Serial Terminal project I have the following thoughts and questions:

1) Initially I had some problems understanding the task for the Serial Terminal Server project. maciejjo had some valuable input on IRC for me which helped me to outline the basic Idea and goals of the project. During my first research I found Minicom to be worth investigating for establishing the connection to the BB, although there might be more appropriate tools. The project description states that connecting to the BB will happen through SSH. As far as I know, telnet is used to connect to serial terminal server, so why change to SSH?

2) I found that the major part of the project will be to transfer incoming commands/messages from the PC to the devices connected via UART and vice versa. This task is expanded by adding a buffer for past I/O. Thinking about that, I have some concerns regarding Linux’ process scheduling policy. The buffering will need to be done by a user process which has yet to be implemented, right? So if we preempt that process, I/O inputs might be missed. If we don’t, no other process may execute. Please correct me if I’m wrong. That said, developing the software will certainly be possible without additional hardware, but in order to use the BB productively the cape hardware will be mandatory. The cape would then have an own memory and read from/write to the UART pins as an independent unit. To develop a solution without additional hardware I will hook up my Arduino to the UART pins for testing. As the Arduino uses 5V I will bring them down to 3.3V (as stated in the project description) by using a voltage divider circuit. A micro SD card will then be used as I/O buffer.

3) The project also involves linux kernel programming, but I can’t see where this is needed. Managing the UART ports, incoming connections and the buffer should be able in user space, depending on the scheduling policy as written above. So, is only the kernel allowed to change the UART pins (so that’s why we would need kernel programming?) or what am I missing here? I could think of needing to add something to the kernel when developing the cape, though.

Thanks in advance

Hi again,
I was able to answer some of my own questions, so just to update my last mail with my latest thoughts:

I found more software which would enable talking to devices connected via UART. So my questions labeled with “1)” and "2)“ are now answered (in fact I misunderstood how users interact with those devices). Software like GNU screen, Minicom, tty or cu already provide a usable solution to manage UART devices. As the set up as a serial terminal server should be "easy to use and deploy“ changes I can currently think of are the integration of commands wich will simplify (or enable automatic?) connection to connected devices. Added functionality would also help interfacing a certain device and start buffering I/O. Moreover, calls for managing the buffer and other settings will also ease the usage of the software.

For testing, connecting my Arduino is not necessary as connecting to another UART port or using a simple USB to UART bridge on my PC will be sufficient and make testing easier.

In order to buffer I/O I still have the same question regarding programmed I/O (which might cause data read readable on one of the UARTs to be missed). Possible solutions I am thinking of are:

1: using DMA for writing I/O input directly to the destination. Researching this attempt was not really fruitful. There are people who tried this already and were not able to do it, I will investigate this further.

2: using the PRU for writing I/O input to memory. This could be used to write into DDR memory where a first buffer is placed. Then there just needs to scheduled a process which will copy the buffer content e.g. to the sd card. Though, also DMA could be used for this task.

3: modifying the UART driver to write to the destination. Issues will be the write speed of the memory and how to address the memory properly from a drivers point of view. I will also research this one further but your input is appreciated. Alternatively, trying to write to DDR memory and proceed like I proposed in the previous attempt seems to be another option.

I also removed “PRU” from the topic as this is now all about the terminal project.

If you have some ideas or annotations please let me know.