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