Difference between revisions of "ECE434 Project -Polar Codes"

From eLinux.org
Jump to: navigation, search
(Created page with "PT PT {{YoderHead}} Team members: Matthew Callahan == Grading Template == I'm using the following templa...")
 
m
 
(15 intermediate revisions by one other user not shown)
Line 1: Line 1:
[[Category:ECE497 |PT]]
+
[[Category:ECE434Fall2020 |Pp]]
[[Category:ECE434Fall2020 |PT]]
 
 
{{YoderHead}}
 
{{YoderHead}}
  
Line 26: Line 25:
  
 
== Executive Summary ==
 
== Executive Summary ==
The Idea of the project is to generate a kernel module that has two files. The first file encodes what is written to it using a polar code or an LDPC code and outputs through a gpio pin. The other file responds with a decoding of the input from another gpio pin using the same algorithm.
+
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.  
Give two sentence intro to the project.
 
  
Give two sentences telling what works.
+
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/.
 +
[[File:Kernel_module_read_fix.png]]
  
Give two sentences telling what isn't working.
+
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.  
  
End with a two sentence conclusion.
+
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.
  
The sentence count is approximate and only to give an idea of the expected length.
+
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.
  
 
== Packaging ==
 
== Packaging ==
If you have hardware, consider [http://cpprojects.blogspot.com/2013/07/small-build-big-execuition.html Small Build, Big Execuition] for ideas on the final packaging.
+
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.
 
 
 
== Installation Instructions ==
 
== Installation Instructions ==
 +
 
 +
1. Download the source files from [https://github.com/mbcallahan/ECE434EncodingProject]
 +
 +
2. Ensure you have the toolchains to compile kernel modules by following the guidance on [https://elinux.org/EBC_Exercise_26_Device_Drivers#Cloning_Source_and_Compiling]
  
Give step by step instructions on how to install your project. 
+
3. connect P9_13 to P8_38 and P9_11 to P8_37
  
* Include your [https://github.com/ github] path as a link like this to the read-only git site:  [https://github.com/MarkAYoder/gitLearn https://github.com/MarkAYoder/gitLearn].
+
4. Disable the video and audio drivers in /boot/uEnv.txt
* Be sure your README.md is includes an up-to-date and clear description of your project so that someone who comes across you git repository can quickly learn what you did and how they can reproduce it.
 
* Include a Makefile for your code if using C.
 
* Include any additional packages installed via '''apt'''.  Include '''install.sh''' and '''setup.sh''' files.
 
* Include kernel mods.
 
* If there is extra hardware needed, include links to where it can be obtained.
 
  
== User Instructions ==
+
5. On the bone in the source folder, run make
Once the modules are enabled, if the gpio lines are tied together then writing to the first file should then allow you to read back the same data from the other file.
 
  
== Highlights ==
+
6. run setup.sh
 +
==User Instructions==
  
Here is where you brag about what your project can do.
+
7. Setup one uart port to read messages and pipe to the decoder.
 +
run
 +
bone$ cat /dev/ttyS4 > /dev/UARTdecode 
  
Include a [http://www.youtube.com/ YouTube] demo the audio description.
 
  
== Theory of Operation ==
+
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
  
Give a high level overview of the structure of your software. Are you using GStreamer?  Show a diagram of the pipeline. Are you running multiple tasks?  Show what they do and how they interact.
+
10. read the decoded output
 +
  bone$ cat /dev/UARTdecode
  
== Work Breakdown ==
 
  
List the major tasks in your project and who did what.
+
== 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.
  
Also list here what doesn't work yet and when you think it will be finished and who is finishing it.
+
== Work Breakdown ==
 +
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.
  
 
== Future Work ==
 
== Future Work ==
 +
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.
  
Suggest addition things that could be done with this project.
 
 
== Conclusions ==
 
 
Give some concluding thoughts about the project. Suggest some future additions that could make it even more interesting.
 
  
 
{{YoderFoot}}
 
{{YoderFoot}}

Latest revision as of 08:27, 30 November 2022

thumb‎ Embedded Linux Class by Mark A. Yoder


Team members: Matthew Callahan

Grading Template

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

Executive Summary

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/. Kernel module read fix.png

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.

Packaging

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.

Installation Instructions

1. Download the source files from [1]

2. Ensure you have the toolchains to compile kernel modules by following the guidance on [2]

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

User Instructions

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.

Work Breakdown

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.

Future Work

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.




thumb‎ Embedded Linux Class by Mark A. Yoder