To SHH into your BeagleBone from OS X go to http://beagleboard.org/getting-started#step2 and download the drivers. I recommend to use the links on that web site, when I first did this I used the links provided by the on-board web site of the BeagleBone. That led to old drivers and thus SSH did not really work…
Anyway, after installing the drivers and rebooting your mac you can SSH into the BeagleBone. If there was already a connection any time before you will need to add the new SHA fingerprint to /Users/user/.ssh/known_hosts (where “user” is your user name). Simply open finder, tap CMD+SHIFT+G, paste /Users/user/.ssh/ and open the known_hosts file in an editor. Find the ip address of the BeagleBone (192.168.7.2) and add the new SHA fingerprint right behind it (separated by space). The fingerprint will be provided by the SSH command when it fails due to changed remote identification, so just copy it from there.
My BeagleBone came with Debian 7 installed. To update it I accomplished the following steps:
1. Head over to https://beagleboard.org/latest-images and get the latest image
2. On macOS, install xz, unpack the ter.xz file and flash the SD card you want to use:
brew install xz
xz -d bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img.xz
#find the device name of the SD card
diskutiel -l
#in my case it was /dev/disk2; CHECK THIS FOR YOUR SYSTEM!
#umount the disk
diskutil umountDisk /dev/disk2
#flash the image. This took about 20 minutes on my computer
sudo dd bs=1m if="bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img" of=/dev/disk2
3. Eject the SD card and remove it from your PC. Make sure to power down your BeagleBone and remove all connections (power, ethernet, wires, etc)
4. Insert the micro SD card into the BeagleBone and apply power. It will boot from the SD card, wait for the boot process to finish
5. After SSH’ing into the BeagleBone uncomment the following line in /boot/uEnv.txt
sudo vim /boot/uEnv.txt
---------------------------------------------------------
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
6. Shutdown the BeagleBone and remove the power cable. Before you plug in the power cabe press and hold the boot button (the one near the SD card slot). After plugging it in, wait for the led’s to flash. As soon as you let go the button the led’s should flash in a rhythmic pattern (from left to right and then from right to left and so on).
When the image is written to the eMMC all four led’s will be lit and the BeagleBone will shut down. As soon as all led’s turned off you can remove the SD card. When you boot the next time (without the SD card) you can check if everything worked with
To get to know how to access serial devices I decided to write some simple test code. I connected an Arduino board to the UART1 port of BeagleBone Black as seen here.
Wiring Arduino and BBB
ENABLE UART PORTS ON Jessie
To enable the UART1 port I opened /etc/default/capemgr in vim and added the following line to the bottom:
vim /etc/default/capemgr
----------------------------------------------------
# Options to pass to capemgr
CAPE=BB-UART1,BB-UART2,BB-UART3,BB-UART4
enable uart ports on wheezy
To enable the UART1 port I opened /boot/uEnv.txt in vim and added the following line to the bottom:
vim /boot/uEnv.txt
----------------------------------------------------
##Enable UART ports
cape_enable=capemgr.enable_partno=BB-UART1
So tail gives the following:
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
##Enable UART ports
cape_enable=capemgr.enable_partno=BB-UART1
uuid=0478ef9b-40b8-4b33-b24a-43dbccf19b0b
Communicating through uart
I then wrote some Arduino code which sends 5000 messages to the UART port. On the BB I read the messages using the termios API (see man termios ) and write each message with a tag (time, date) to a file. Currently, everything works fine, but I think if there should arise any issues in terms of performance making the file writing and port reading asynchronously (possibly also using IO interrupts via SIGIO?) should give the whole process more performance.
It’s been a while since I published my first project outline here. I talked to the project mentor, Michael Welling, and he was able to answer my questions related to the project goals. Using the PRUs is a bit oversized, there is no need at all for that. What I will try instead is to configure the UART driver so that he writes input data into a file. That file will be used as log file and can be accessed through the UI.
Did I say UI? Yeah, the last project outline didn’t show that. But a UI is definitively a part of the project and will ease the usage of the program. That way, people with a chronic command-line-phobia will also like to use the serial terminal server.
So what is this about now? Well, there is a UI, probably a web interface, provided by the BeagleBone. This interface will be accessed by a PC and allow the user to access and manage serial devices connected via UART to the board. As you can imagine, there will be something like a middleware needed to connect the web interface to the serial ports. Additionally, all I/O will be logged and will be accessible through the interface.
I created the following component diagrams which show the scope for each stage of the project. I divided it into 3 stages. Stage 1 will be the one which I will definitively implement during GSoC. It includes basic functionality and fulfills the project’s goals. Stage 2 extends the scope and could also fit into the 12 week timeline, depending on my progress with Stage 1. in contrast, Stage 3 will probably be difficult to implement completely during the summer as it introduces a set of extra features which will consume much time to implement. Note that each stage will be divided into several milestones.
stage 1
Basic functionality designed to be extended easily
I payed attention to hide implementation details behind interfaces which allow for easy access, use and extension of single components. I want to make it easier to both include new serial devices (I2C, SPI, etc.) as well as including new features into the terminal server or UI (e.g. see Stage 3).
Features introduced in this stage:
set up serial UART connections through UI
edit baud rate, parity bit
send messages to devices
read current messages from devices
log input for each UART device along with a timestamp in a file
packaging everything into an image (not exactly a feature, but also a goal)
I am still looking for what’s the best solution to connect the terminal server with the client, but probably it would make sense to include Stage 2 which adds an HTML interface:
Stage 2
Expose HTTP interface to clients/network
This basically prepares the project for Stage 3. As pretty much everything can use HTTP interfaces, it makes sense to me to add this interface to the web server. Client applications now also have the option to use the HTTP interface and thus will not need any dependencies to the serial management.
Additional features introduced with this stage:
HTTP interface exposed to the network
Stage 3
More features
Additional features introduced with this stage:
automation rules (e.g. automatically send a mail when an event occurs)
tunneling to interconnect serial devices
pattern matching
upload log to external server/host pc
hexadecimal viewer
These functions are regarded as “stretch goals”. I might be able to implement some parts during the summer, but most of it will probably wait until past GSoC. As I really like these ideas I have also personal interest in implementing them even after GSoC ends, so stay tuned.
I also created a draft which showed how the architecture would look like if I implemented an additional server ( / socket) in C. That server would be responsible for all features introduced with Stage 2 and Stage 3. Yet, that would nearly double the complexity of the project. Using C for the web server means that there are in fact two web servers running: One to provide a backend to the web interface and the other one for tunneling and the automation rules stuff. Note that here we would also need an API which would allow other servers to access our server.. To my mind, if you really need something like this you could use the C-Library within your solution, but for the GSoC project it will make much more sense to just use the web server for all this stuff. Plus, it fits better into the timeline as I’m faster with JavaScript.
Past Stage 3 we can include more serial interfaces like I mentioned before. Due to the HTTP interface, also IoT applications can build up on this project or we can use the C-Library to access serial devices without going through the hassle of using device nodes. Adding a cape to turn the BeagleBone physically into a serial terminal server and including it into the library can be another task.
I guess some of the library functionality already exists inside of other projects out there, I will see if I find something useful. Same applies to the web server component.
If you got to write a driver for the Linux kernel, you basically have two options: Either you compile it directly into the kernel or you use loadable kernel modules (LKM). The latter option has the advantage, as you might already have suggested, to load the driver dynamically during run time. I will focus in this post on some of the things one has to remember when creating a LKM. For a complete description please refer to Derek Molloy’s guide about LKM which has helped me a lot in understanding its concepts and implementation. All his code is also on GitHub.
The following code snippets can be useful in a LKM and give something like a starting point or show you what to remember; I tried to split them into topics so that individual information can be found without searching through a large piece of code.
This is a short summary about how UART works as the serial terminal server project focuses on UART devices. First of all, UART means Universal Asynchronous Receiver Transmitter. This tells us that receiving and transmitting data all happens without a clock.
The protocol
When the UART is idle the output is HIGH. So when there is no data transmitted you will always read HIGH from the UART pins. Then, when a signal is transmitted, the pin is pulled down to LOW to indicate that data is transmitted. This is our start bit. Then we can transmit 8 data bits followed by a stop bit. Its value is HIGH. In total, there are 10bits which are sent in one package. Also note that transmitted values are passed less significant bit first.
In order to read the transmitted data you need to know the baud rate as UART is baud rate based. Transmitter and receiver use the baud rate for synchronization: Having a baud rate of 9600 corresponds to 9600 bits per second. As one package consists of 10 bits we thus receive 960 data bytes per second (or 960 packages per second). For one message, we thus have 1042µs. If we divide this number by 10, we know that one bit takes 104.2µs This timing can now be used to decode each message transmitted via UART.
Let’s look at an example: With a baud rate of 115200 we have 1/115200 = 8.68µs per bit. If we transfer the number 0x03 which is 0b00000011 in binary we get the following time chart:
^
|
|
.........X XXXXXXX XXXX......
HIGH X X X X
X X X X
X X X X
X X X X
X X X X
X X X X
LOW X X X X
XXXX XXXXXXXXXXXXXXXXXXX
|
+--|--|--|--|--|--|--|--|--|--|------>
*idle* start 1 1 0 0 0 0 0 0 end *idle*
bit bit
In reality
When it comes to communication between two micro controllers you have also pay attention to exact timing. If data transmitted is off too much from the specified baud rate you won’t be able to read the message. If you have a 2MHz oscillator (FOSC) and transmit messages using high speed you surely have already seen the formula
FOSC / (16*(SPBRG + 1))
Here, SPBRG is a value saved in the corresponding register which ultimately determines which baud rate is used. With SPBRG=51in the current example we get a baud rate of 9615.38 out of the formula above. So our controller is off by 15.38 bits per second, the amount of error is 0.16%. Of course, you want this error to be as small as possible.
Error detection
If you like to have a parity bit you can reduce the 8 data bits to 7 data bits and use the MSB as parity bit. That way, you can notice one bit errors.
After all, UART is a technology which is existing now for a long time. You won’t get a very large transfer rate but there are still many devices which use this protocol as it is duplex, asynchronous and easy to integrate.
After chatting on IRC with some other students I was able to better understand the Serial Terminal Server project, its goals, requirements and complexity. I think that I’m definitively going to apply for that project, so I ordered a BeagleBone Black now. Since I have no experience with BeagleBone, RaspberryPi and similar boards I think that exploring the BeagleBone Black before starting to code is a good idea. I already thought of some solutions, one of them is shown in the sketch below which involves the PRUs for buffering I/O data. I checked out the BegleScope project from ZeekHuge which also uses the PRUs for buffering, so that might help me in getting some ideas. A slightly different solution I came up with was to use DMA to transfer data from the PRUs (or maybe directly from the UART pins) into the I/O buffer. Yet, this attempt seems to cause people some headaches, as some have already tried it and did not succeed. I will focus for now on using the PRUs along with RPMsg for communication with the A8 and let the PRUs write the buffers.
First architecture draft
Open questions on which I will focus on now are:
How will communication between the two PRUs happen?
Is there a better solution than passing commands through all instances or can we make calls directly to the UART device?
How can multiple UART devices be monitored without loosing inputs?
Is the driver really the right instance to copy the PRUs buffer to the sd card or should this task be done by another instance?
Is there another solution which does not rely on the PRUs?
When talking to ZeekHuge it turned out that it should be possible to reuse and modify some of his code in order to buffer UART I/O. In the days to come I will check out more of his code and explore how to write drivers, how to write code for the PRUs and how to deploy everything so that it’s easy to set up.
As I intend to apply for the PRU or Terminal Server projects mentored by BeagleBoard I now set up my development environment. This involved (finally) installing Linux as dual boot on my Laptop (until now I had it running in VirtualBox) and installing all the required packages and libraries on my fresh installation. I chose to use gcc-arm-linux-gnueabi after some research (alternatives were angstrom and linaro) and qemu as emulator.
After installing everything I just forked the gsoc-application project from GitHub which is a task all applying students have to perform. Here is my repo in case you want to see it: https://github.com/ordsen/gsoc-application
Now I’m going to make a pull request and will eventually get in touch with the community in the days to come.
Just set up my IRC account and hanging around in the beagle-gsoc and scala channels. My nick name is (as always) ordsen. Oddly, my IRC client leaves all joined channels as soon as I minimize it. Should probably make that one work properly.
To log in you can specify your nickname and password in the most IRC clients. To register your nickname follow this guide: https://freenode.net/kb/answer/registration
Just type in the commands shown there into the input line of your IRC client and you should be good to go!
Alright, I spent some time examining all the projects listed below and found my favorite projects. I decided to pay more attention to what I am interested in. Working on things I like makes it always easier for me to learn new skills. Also, I want the project to teach me some new skills instead of just asking me to reproduce stuff I already can do, but also have some parts in it I am familiar with in order to find a starting point. And after all, I checked if the project is mentored by a community I would like to engage with even after GSoC. So here we go:
