Difference between revisions of "ECE434 Project -Polar Codes"
|Line 1:||Line 1:|
Latest revision as of 07:27, 30 November 2022
Embedded Linux Class by Mark A. Yoder
Team members: Matthew Callahan
I'm using the following template to grade. Each slot is 10 points. 0 = Missing, 5=OK, 10=Wow!
09 Executive Summary 09 Packaging 09 Installation Instructions 09 User Instructions 09 Highlights 09 Theory of Operation 09 Work Breakdown 09 Future Work/Conclusions 09 Hackster.io 09 Demo/Poster 00 Not Late Score: 90/100
The project idea is to use kernel modules to encode signals and then send them out with another linux driver, in this case the UART devices. The project origonally intended to implement Polar codes as the encoding scheme, but due to time constraints was limited to repeat codes.
The UART devices work well and handle normal file I/O without the communicating software needing to handle any of the communication details. The kernel modules work the same way, it is possible to use echo to write to the character device and cat to read from it. To do this, I needed to follow the instructions in the comments of Derek Moloy's post http://derekmolloy.ie/writing-a-linux-kernel-module-part-2-a-character-device/.
I origonally intended to have the kernel modules interface with the UART directly, but that is not possible because the UART devices only accept commands from User space, so the kernel module needs to send its data into user space, which is frowned upon. Instead, the kernel modules accept a message when they are written to and return the processed message (encoded for the encoding module and decoded for the decoded module) when they are read from. I did not get to making the kernel modules thread-safe so being written to from many programs at once is not supported.
I used http://beaglebone.cameon.net/home/serial-ports-uart for the wiring guidelines, https://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer for guidelines on setting up the UART devices, and Derek Molloy's exploring beaglebone chapter 16 for the kernel modules.
This project was a good learning tool to understand how an embedded system can benefit from the linux operating system utilities to make using it easier.
Since this is mostly a project about exploring what linux can do, and the hardware required for the project is two wire, I figured a bare board was sufficient.
1. Download the source files from 
2. Ensure you have the toolchains to compile kernel modules by following the guidance on 
3. connect P9_13 to P8_38 and P9_11 to P8_37
4. Disable the video and audio drivers in /boot/uEnv.txt
5. On the bone in the source folder, run make
6. run setup.sh
7. Setup one uart port to read messages and pipe to the decoder. run
bone$ cat /dev/ttyS4 > /dev/UARTdecode
8. in another terminal write to the encode char device
bone$ echo "Test Message" > /dev/UARTencode
9. pipe the char device to the other uart port
bone$ cat /dev/UARTencode > /dev/ttyS5
10. read the decoded output
bone$ cat /dev/UARTdecode
Theory of Operation
Part of the linux design philosophy is that everything should be a file. Taking this design principle in mind, the encoding kernel is interfaced by a single file that when written to encodes the message sent to it and returns this encoded message on a read. The decoding kernel does the opposite. The UART devices are configured to handle all of the UART handshakes needed, so when they are hooked up appropriately, a message written to one of them can be read from the other. Therefore, the message can be encoded and decoded and transmitted by using linux file transfer tools.
I first had to figure out how to send data out of the board without having to write my own syncronizing method. I therefore spent a while figuring out how to configure the UART devices. I then wrote the kernel modules.
This project could be made more interesting and useful by encoding with a polar code scheme. Additionally, the cabling could be expanded to communicate between two beagles and some software could be written to generate interesting data, like video or a text chat client, that could then be easily configured to use whatever coding scheme is most appropriate. Additionally, changing the device to support longer streams of characters so you could send something like a zip file would be cool. This may require making a block-device instead of a character device.
Embedded Linux Class by Mark A. Yoder