http://www.elinux.org/api.php?action=feedcontributions&user=Yoder&feedformat=atomeLinux.org - User contributions [en]2013-06-19T07:34:02ZUser contributionsMediaWiki 1.22alphahttp://www.elinux.org/ECE497_Tips_and_TricksECE497 Tips and Tricks2013-06-18T16:24:35Z<p>Yoder: Added pico DLP instructions</p>
<hr />
<div>[[Category:ECE497 |Tips]]<br />
{{YoderHead}}<br />
<br />
Some useful tips and tricks for Linux and the Beagleboard.<br />
<br />
== Interesting Links ==<br />
<br />
Since we are working with the open source community, you need to know where the action is. Here are some useful links to what's happening in the Beagle community.<br />
<br />
* [http://groups.google.com/group/beagleboard/browse_thread/thread/c5a631c6582119b8 State of the Beagle 2011], learn about the Beagle's past, present and future.<br />
* [http://BeagleBoard.org BeagleBoard.org], the starting point for all thing Beagle.<br />
* [http://groups.google.com/group/beagleboard Beagle Discussion Group], lot's of good information here, but you'll have to dig a bit. Subscribe and follow the discussion.<br />
* [http://beagleboard.blogspot.com/ blogspot], see what is being said about the Beagle.<br />
* [http://elinux.org/BeagleBoard eLinux], this is where this page is being hosted. It's about embedded Linux in general, not just the BeagleBoard.<br />
* [http://free-electrons.com/blog/beagle-labs/ Free Electrons Beagle Board Training], some good labs about what makes embedded Linux run.<br />
* [https://gforge.ti.com/gf/project/tiesr/ TI Embedded Speech Recognizer] (TIesr) is a fixed-point recognizer written in C++ and C. <br />
* [http://code.google.com/soc/ Google Summer of Code]. BeagleBoard is an accepted organization.<br />
* [http://www.makelinux.net/kernel_map Linux Kernel Map]<br />
* [http://processors.wiki.ti.com/index.php/Category:OMAP35x Texas Instruments Embedded Processors Wiki]<br />
<br />
== Linux ==<br />
<br />
[http://freeengineer.org/learnUNIXin10minutes.html Learn UNIX in 10 Minutes] is a quick overview of the most commonly used Linux commands.<br />
<br />
[http://lifehacker.com/5935869/top-10-tools-that-are-better-in-the-command-line?utm_campaign=socialflow_lifehacker_twitter&utm_source=lifehacker_twitter&utm_medium=socialflow Top 10 Tools] is a nice summary of 10 of the most useful Linux commands.<br />
<br />
=== Quick Tips ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Tip<br />
! Description<br />
|-<br />
| <br />
beagle$ '''gnome-open'''<br />
| Open a file or directory using the default program<br />
|-<br />
| Give the IP address a name<br />
| Inside /etc/hosts add a line of the form <IP address> <alias> this will allow you to refer to the host by name.<br />
|-<br />
| Built-in GUI for gdb<br />
| If you invoke gdb with the command line argument -tui, it will show a built-in GUI<br />
|-<br />
| <br />
beagle$ '''ntpdate ntp.org'''<br />
beagle$ '''rm /etc/localtime'''<br />
beagle$ '''ln -s /usr/share/zoneinfo/America/New_York /etc/localtime'''<br />
<br />
| This will go to a '''n'''etwork '''t'''ime '''p'''rotocol server and get the current time and set the Beagle to it and set the local time zone. [http://derekmolloy.ie/automatically-setting-the-beaglebone-black-time-using-ntp/]<br />
|-<br />
|<br />
beagle$ '''mount -t debugfs debugfs /sys/kernel/debug/'''<br />
beagle$ '''cd /sys/kernel/debug'''<br />
beagle$ '''ls'''<br />
| Kernel Debug Info<br />
|}<br />
<br />
=== Connecting to RHIT wifi ===<br />
<br />
There is a discussion in the [https://groups.google.com/forum/?fromgroups=#!topic/beaglebone/9PEUmcsLXLU Beagle Google Group] about getting wireless working with the bone.<br />
<br />
Use these settings for connecting to the Rose-Hulman wireless network:<br />
<br />
* '''SSID:''' RHIT-1X<br />
* '''Security:''' WPA & WPA2 Enterprise<br />
* Leave "anonymous identity" blank <br />
* '''CA Certificate''': (None)<br />
* '''PEAP version''': Version 0<br />
* '''Inner authentication''': MSCHAPv2<br />
* Use your Rose username and password<br />
<br />
=== bash ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Tip<br />
! Description<br />
|-<br />
| Ctrl-r<br />
| Reverse incremental search<br />
|-<br />
| Ctrl-g<br />
| Abort command<br />
|-<br />
| Esc-.<br />
| Insert last argument from last command<br />
|}<br />
<br />
=== ssh ===<br />
<br />
==== Suspending ssh ====<br />
<br />
Most programs can be suspended by typing <code>^z</code> (Ctrl-z). If you have an '''ssh''' connection to another machine you can suspend it by entering <code>~^z</code>. You can resume the connection by entering ''fg''.<br />
<br />
==== ssh and X-windows ====<br />
<br />
When using ssh between to X-windows systems try<br />
<br />
host$ '''ssh -CX root@beagle'''<br />
<br />
The -X set the DISPLAY variable on the remote machine so you can open windows from the beagle on your host machine. <br />
<br />
The -C compressed the data over the link. Good for slow connections.<br />
<br />
==== vnc ====<br />
<br />
You can run a vnc server on the Beagle. Install it with:<br />
beagle$ '''opkg update'''<br />
beagle$ '''opkg install x11vnc'''<br />
Install a password with<br />
beagle$ '''x11vnc -storepasswd'''<br />
Run it on the Beagle with<br />
beagle$ '''x11vnc -display :0 -ssl -usepw -forever -q &'''<br />
On your host, connect to it with:<br />
host$ '''vinagre'''<br />
or '''Applications:Internet:Remote Desktop Viewer'''<br />
<br />
==== Authorizing ssh ====<br />
<br />
'''ssh''' and '''scp''' can be set up for automatic authorization so you don't have to enter your password when using these commands. Here's how to do it.<br />
First let's see what's already there:<br />
<br />
* On your Beagle run<br />
<br />
beagle$ '''ls ~/.ssh'''<br />
<br />
'''~/.ssh''' may not exist, if not, it will be created. If it's there, check the files in it.<br />
<br />
* On your host computer run<br />
<br />
host$ '''ssh-copy-id root@beagle'''<br />
<br />
It was ask for you beagle password and then copy the needed files to it.<br />
<br />
* Back on the beagle to see what has changed:<br />
<br />
host$ '''ssh -CX root@beagle'''<br />
beagle$ '''ls ~/.ssh'''<br />
<br />
The ssh command shouldn't ask for a password. What new files appeared?<br />
<br />
==== ssh configuration ====<br />
<br />
Here's a nice tip so you don't have to remember who to login as on the beagle. On your host, put the following in '''~/.ssh/config'''.<br />
<br />
Host beagle<br />
User root<br />
UserKnownHostsFile /dev/null<br />
StrictHostKeyChecking no<br />
<br />
Before you had to<br />
host$ ssh -CX root@beagle<br />
<br />
Now you can just<br />
host$ ssh -CX beagle<br />
<br />
=== Mounting dfs/afs ===<br />
<br />
You can set up your Linux box to directly mount your afs and dfs files. The [http://lug.rose-hulman.edu/wiki/Main_Page Rose-Hulman Linux Users' Group] has a nice [http://lug.rose-hulman.edu/wiki/HOWTO_Use_sshfs_to_mount_AFS/DFS_home page] with the details .<br />
<br />
After installing <code>sshfs</code> I added the following to my <code>/etc/fstab</code> file:<br />
<pre><br />
sshfs#username@dfs.Rose-hulman.edu:/DFS/MyDocs/username /home/username/MyDocs fuse user,noauto,uid=1000,gid=1000 0 0<br />
sshfs#username@dfs.rose-hulman.edu:/DFS/Users/Y/username /home/username/dfs-home fuse user,noauto,uid=1000,gid=1000 0 0<br />
sshfs#username@afs.rose-hulman.edu: /home/username/afs-home fuse user,noauto,uid=1000,gid=1000 0 0<br />
</pre><br />
You'll have to replace <code>username</code> with your login name. Then create the mount points:<br />
<br />
host$ '''cd ~'''<br />
host$ '''mkdir MyDocs'''<br />
host$ '''mkdir dfs-home'''<br />
host$ '''mkdir afs-home'''<br />
<br />
Now you can mount your files by using:<br />
<br />
host$ '''cd ~'''<br />
host$ '''mount dfs-home'''<br />
host$ '''cd dfs-home'''<br />
host$ '''ls'''<br />
<br />
You should now see your dfs files. You can unmount using:<br />
<br />
host$ '''cd ~'''<br />
host$ '''sudo umount dfs-home'''<br />
<br />
=== debugfs ===<br />
<br />
'''debugfs''' looks like a handy way to look into the kernel. These notes are based on the example [https://groups.google.com/forum/#!msg/beagleboard/bGZcCHwHwrI/CXHJ0WOBpV0J here].<br />
<br />
beagle$ '''cd /'''<br />
beagle$ '''mkdir debugfs'''<br />
beagle$ '''mount -t debugfs none debugfs'''<br />
<br />
Then explore...<br />
<br />
bone$ '''cd debugfs; ls -F'''<br />
asoc/ gpio mmc0/ pm_debug/ sched_features vram<br />
bdi/ hid/ musb/ regdump testmode wakeup_sources<br />
clock/ memblock/ omap_mux/ regulator/ usb/<br />
<br />
beagle$ ''' cd debugfs; ls -F'''<br />
asoc/ clock/ hid/ omapdss/ sched_features usb/<br />
bdi/ gpio mmc0/ pm_debug/ tracing/ vram<br />
<br />
=== Tool chain work flows ===<br />
<br />
[http://www.angstrom-distribution.org/some-usefull-workflow-blogs Here] is a link to a list of workflows for various tool chains.<br />
<br />
=== Installing more applications ===<br />
==== On the Beagle ====<br />
<br />
On the Beagle under Angstrom you use '''opkg''' to manage packages. Start with<br />
<br />
beagle$ '''opkg update'''<br />
<br />
This updated the local database with the current version information. Then<br />
<br />
beagle$ '''opkg list > /tmp/list'''<br />
beagle$ '''less /tmp/list'''<br />
<br />
will list all the available packages. You can also search here [1] to see what packages are available.<br />
<br />
[1] [http://www.angstrom-distribution.org/repo/ www.angstrom-distribution.org/repo/]<br />
<br />
==== On the host ====<br />
There are tree command that I use for managing packages.<br />
<br />
; dpkg<br />
: is used for listing what packages are installed.<br />
; synaptic<br />
: is a GUI-based package manager. I used it to discover new packages to install.<br />
; apt-get<br />
: is used to install and update packages.<br />
<br />
For example, let's suppose you run '''make menuconfig''' and the error message says<br />
*** Install ncurses (ncurses-devel) and try again.<br />
<br />
Let's see what's installed.<br />
host$ '''dpkg -l > /tmp/list'''<br />
host$ '''grep curses /tmp/list'''<br />
ii libncurses5 5.7+20090803-2ubuntu3 shared libraries for terminal handling<br />
ii libncursesw5 5.7+20090803-2ubuntu3 shared libraries for terminal handling (wide<br />
ii mtr-tiny 0.75-2build1 Full screen ncurses traceroute tool<br />
ii ncurses-base 5.7+20090803-2ubuntu3 basic terminal type definitions<br />
ii ncurses-bin 5.7+20090803-2ubuntu3 terminal-related programs and man pages<br />
<br />
Hmmm... there's something related to ncurses installed, but the error says something about ncurses-devel. Let's fire up synaptic<br />
host$ '''synaptic &'''<br />
Enter '''ncurses-devel''' in the search field.<br />
[[File:Screenshot-Synaptic Package Manager .png | 500px]]<br />
<br />
The green dot in the '''S''' column says the package is installed. '''libncurses5-dev''' isn't installed. Install it with:<br />
host$ '''sudo apt-get install libncurses5-dev'''<br />
<br />
And now your make should work.<br />
<br />
=== byobu - A Screen Manager ===<br />
<br />
For years Unix has had <code>screen</code> which is a screen manager. ''byobu'' is wrapper for screen that puts a nice face on it. You can run byobu on your host computer and on the Beagle. With byobu you can start a long running program (bitbake for example) in one terminal and detach from the terminal and the program will keeping running in the background. Using byobu you can later attach to the program (possibly from another terminal) and see how the program is progressing.<br />
<br />
Install byobu on your host with:<br />
<br />
host$ '''sudo apt-get update'''<br />
host$ '''sudo apt-get install byobu'''<br />
<br />
It's a bit harder on the Beagle.<br />
beagle$ '''opkg update'''<br />
beagle$ '''opkg install screen'''<br />
Go to [https://launchpad.net/byobu/+download here] and download the latest version to your Beagle.<br />
beagle$ '''tar zxvf byobu_*.orig.tar.gz''' <br />
beagle$ '''cd byobu*''' and follow the instructions in INSTALL. I had to hack one file.<br />
beagle$ '''gedit /usr/local/lib/byobu/.constants'''. <br />
<br />
Change the last two lines to:<br />
<br />
# command -v gsed >/dev/null && export SED="gsed" || export SED="sed"<br />
# command -v greadlink >/dev/null && export READLINK="greadlink" || export READLINK="readlink"<br />
export SED="sed"<br />
export READLINK="readlink"<br />
<br />
Now you can run it.<br />
<br />
beagle$ '''byobu'''<br />
<br />
You'll see a command prompt. You'll also see some status information on the bottom two lines. Type Ctrl-A ? for help. Type Ctrl-A Ctrl-D to detach from the session. Running byobu again will reattach you to the session. Try running byobu in two windows at the same time. You should see the same session in both.<br />
<br />
Hmmm.... I had to reinstall and it doesn't seem to be working now.<br />
<br />
=== Finding what opkg installed ===<br />
<br />
Once you've run opkg, how do you know what's been installed? Take a look in '''/var/lib/opkg/info''' or '''/usr/lib/opkg/info'''. The files that end in .list contain a list of what's been installed.<br />
<br />
=== Backing up an SD card with dd ===<br />
<br />
Here's the command I use to backup an SD card. I use '''System:Administration:Disk Utility''' to figure out the path to the card. In this case it's ''/dev/sdc''<br />
<br />
host$ '''sudo time dd if=''/dev/sdc'' of=FIE2011.img bs=4M count=1000'''<br />
host$ '''sudo chown yoder:yoder FIE2011.img'''<br />
host$ '''md5sum FIE2011.img > FIE2011.img.md5'''<br />
host$ '''bzip2 -k FIE2011.img'''<br />
<br />
It takes about 5 minutes to dd a 4G card, 1.2 minutes for md5 and bzip2 takes about 23 minutes.<br />
<br />
It looks like the 7z compression is becoming popular. Use it via<br />
host$ ''' 7za a FIE2011.img.7z IFE2011.img<br />
<br />
It took 16 minutes. The file size is 454M compared to 628M. Wow, faster and smaller.<br />
<br />
=== CSSE's Linux reference page ===<br />
<br />
CSSE332, Operating Systems, has a nice page of Linux resources [http://www.rose-hulman.edu/class/csse/csse332/current/Resources/ here].<br />
<br />
=== Local Ubuntu Update Mirror ===<br />
<br />
Darryl Mouck in CSSE has passed this on...<br />
<br />
We host a local mirror for all ubuntu updates. This is from the current distro back to hardy; it hosts every distro that ubuntu currently supports.<br />
<br />
In order to get your system to point to our mirror, please copy and paste this rather lengthy command into a terminal:<br />
<br />
host$ '''sudo cp /etc/apt/sources.list{,.old} && \<br />
sudo sh -c '\<br />
'''. /etc/lsb-release &&'''<br />
'''echo "'''<br />
'''deb http://ftp.csse.rose-hulman.edu/ubuntu $DISTRIB_CODENAME main restricted universe multiverse'''<br />
'''deb http://ftp.csse.rose-hulman.edu/ubuntu $DISTRIB_CODENAME-updates main restricted universe multiverse'''<br />
'''deb http://ftp.csse.rose-hulman.edu/ubuntu $DISTRIB_CODENAME-security main restricted universe multiverse'''<br />
'''" > /etc/apt/sources.list' && sudo apt-get update'''<br />
<br />
The text and further instructions are available [http://csse.rose-hulman.edu/news-mainmenu-2/27-linux-distros/102-ubuntu here].<br />
<br />
The script makes a backup of the updates file and replaces it with links to our mirror. The $DISTRIB_CODENAME is replaced by whatever distro you are running (eg. lucid, maverick, natty etc.). I wish I could take credit for it, but it was a joint effort with Mike McLeish :-)<br />
<br />
=== Using pico DLP with BBB ===<br />
<br />
Put this in uEnv.txt to use the BBB with a pico DLP.<br />
optargs=video=HDMI-A-1:640x480@60<br />
<br />
=== More tips ===<br />
<br />
[http://www.gigamegablog.com/2012/01/29/beaglebone-linux-101-configuring-angstrom-linux/ GigaMegaBlog] has some nice tips for the BeagleBone, many of which apply to the -xM.<br />
<br />
== Windows ==<br />
<br />
Most of the work is done under Linux; however there are some handy Windows-based tools.<br />
<br />
=== Serial Port ===<br />
<br />
[http://www.vandyke.com/products/securecrt/ SecureCRT] is a good program that gives you both access to a serial port and is also an ssh client. Rose has a license for [http://www.rose-hulman.edu/tsc/software/documentation/applications/securecrt-secureFX/installation/ SecureCRT].<br />
<br />
[http://www.tucows.com/preview/195282 Tera Term] also gives you access to the serial port and it's free.<br />
<br />
=== Notepad++ ===<br />
<br />
[http://notepad-plus-plus.org/ Notepad++] is a nice text editor for Windows.<br />
<br />
== Set up on the BeagleBoard ==<br />
<br />
=== Setup stuff on github ===<br />
If you've cloned the course github site ([EBC Exercise 05 Getting Exercise Support Materials]]) you will find set up things in '''exercises/setup'''. '''install.sh''' is a list of various things I to to a fresh SD card to 'move in'. For example, the bone will mount a filesystem on the host computer if it's connected via USB. You can turn this off and have the eithernet over USB run at boot time with:<br />
<br />
# Turn off storage gadget, turn on network at boot time.<br />
cd /lib/systemd/system/basic.target.wants<br />
rm storage-gadget-init.service<br />
ln -s ../network-gadget-init.service .<br />
<br />
=== Accessing the Beagle via the Serial Port ===<br />
<br />
During boot up the Beagle logs various messages on the serial port. You can see these messages by:<br />
<br />
* See what USB/tty devices are already attached to your host<br />
host$ '''ls /dev/ttyU*'''<br />
* Attach a serial to USB converter to your host computer and the Beagle's serial port.<br />
* See what new USB/tty devices appeared<br />
host$ '''ls /dev/ttyU*'''<br />
* On my host, '''/dev/ttyUSB1''' appeared. On the host computer run<br />
<br />
host$ '''byobu /dev/ttyUSB''1'' 115200'''<br />
where '''ttyUSB1''' is what appeared when you plugged in your converter.<br />
<br />
You are now talking to your Beagle's serial port. Login quickly. There appears to be a bug that makes garbage appear on your screen if you wait too long. Try<br />
beagle$ '''shutdown -r now'''<br />
<br />
You will see the shutdown messages, followed by the U-boot messages. After a 3 second (or so) delay you will see the kernel booting.<br />
<br />
'''Tip 1''': Ctrl-a H will cause the data on the serial port to be logged. See<br />
host$ '''man byobu'''<br />
for help.<br />
<br />
'''Tip 2''': <F6> will disconnect from the session. You can reconnect later.<br />
<br />
=== Installing Ubuntu ===<br />
<br />
I've installed 2 different versions of Ubuntu on my SD cards. Each of my SD cards is 4GB, and this is just large enough to hold the Ubuntu images.<br />
<br />
I followed the instructions from [http://elinux.org/BeagleBoardUbuntu#Maverick_10.10 here] and [http://elinux.org/BeagleBoardUbuntu#Maverick_10.10_2 here].<br />
<br />
The first link references a Ubuntu wiki which details how to install a netbook edition of Ubuntu on ARM/OMAP processor-based systems. It is not beagle-specific. This image runs a little slowly, but not much slower than the [http://elinux.org/ECE497_Lab01_Installing_Angstrom_on_Your_Beagle_%28precompiled%29#From_beagleboard-validation.s3.amazonaws.com SPEd image].<br />
<br />
The second link references instructions for installing another image. This image is very minimal, and doesn't have a gui. There are instructions for installing a gui, which I did, with good success. As far as I can tell, even with the gui, this is the fastest image so far.<br />
<br />
=== Installing Always Innovating's Super Jumbo ===<br />
<br />
[http://www.alwaysinnovating.com/home/index.htm Always Innovating] works with branded products and services companies that are looking to deliver great touch devices as part of their offerings. They have published a free SD card image for the BeagleBoard that runs Angstrom, Android, Ubuntu, and ChromiumOS. [http://www.alwaysinnovating.com/beagleboard/ Here's] a video showing what it can do.<br />
<br />
I've put a copy of the compressed image on my DFS site. Feal free to play with it. [http://www.alwaysinnovating.com/wiki/index.php/Beagleboard Here's] a wiki that shows how to switch between OS's on the fly.<br />
<br />
=== Resizing an SD card partition via the Beagle ===<br />
<br />
The following is a slick way to boot the Beagle so it isn't using the SD, then repartition the SD card. It came from [http://groups.google.com/group/beagleboard/browse_thread/thread/3be77bc54feb08a6/b792e092e3c48989?lnk=gst&q=resize+partition#b792e092e3c48989]<br />
<br />
Jason Kridner says ...<br />
I got a related question from Mark about how to perform the partition <br />
resizing, so I figured I'd address that here. I don't believe you'd <br />
be able to resize a mounted partition and that this operation would <br />
require another file system to mount. Because this image does not <br />
have the ramdisk, I downloaded the one used being shipped with the xM <br />
boards today [http://www.google.com/url?sa=D&q=http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/ramdisk.gz]. <br />
<br />
beagle$ '''wget http://www.google.com/url?sa=D&q=http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/ramdisk.gz'''<br />
Connecting to beagleboard-validation.s3.amazonaws.com (72.21.214.39:80) <br />
ramdisk.gz 100% |*******************************| 19492k 00:00:00 ETA <br />
beagle$ '''cp ramdisk.gz /media/mmcblk0p1/''' <br />
beagle$ '''shutdown -r now''' <br />
<br />
I halted the board during reboot and did: <br />
<br />
OMAP3 beagleboard.org # '''mmc rescan 0''' <br />
OMAP3 beagleboard.org # '''run loaduimage''' <br />
Loading file "/boot/uImage" from mmc device 0:2 (xxa2) <br />
3194256 bytes read <br />
OMAP3 beagleboard.org # '''run loadramdisk''' <br />
reading ramdisk.gz <br />
19960110 bytes read <br />
OMAP3 beagleboard.org # '''run ramboot''' <br />
<br />
I allowed it to boot and did: <br />
<br />
beagle$ '''umount /dev/mmcblk0p1'''<br />
beagle$ '''umount /dev/mmcblk0p2'''<br />
beagle$ '''fdisk /dev/mmcblk0'''<br />
Command (m for help): '''p''' <br />
Disk /dev/mmcblk0: 3965 MB, 3965190144 bytes <br />
255 heads, 63 sectors/track, 482 cylinders <br />
Units = cylinders of 16065 * 512 = 8225280 bytes <br />
Sector size (logical/physical): 512 bytes / 512 bytes <br />
Disk identifier: 0x00000000 <br />
Device Boot Start End Blocks Id System <br />
/dev/mmcblk0p1 * 1 15 120456 c W95 FAT32 (LBA) <br />
/dev/mmcblk0p2 16 444 3445942+ 83 Linux <br />
Command (m for help): '''d''' <br />
Partition number (1-4): '''2''' <br />
Command (m for help): '''n''' <br />
Command action <br />
e extended <br />
p primary partition (1-4) <br />
'''p''' <br />
Partition number (1-4): '''2''' <br />
First cylinder (16-482, default 16):<br />
<br />
Using default value 16 <br />
Last cylinder, +cylinders or +size{K,M,G} (16-482, default 482):<br />
<br />
Using default value 482 <br />
Command (m for help): '''w''' <br />
The partition table has been altered! <br />
Calling ioctl() to re-read partition table. <br />
Syncing disks. <br />
beagle$ '''umount /dev/mmcblk0p2''' <br />
beagle$ '''resize2fs /dev/mmcblk0p2''' <br />
resize2fs 1.41.9 (22-Aug-2009) <br />
Resizing the filesystem on /dev/mmcblk0p2 to 937794 (4k) blocks. <br />
The filesystem on /dev/mmcblk0p2 is now 937794 blocks long. <br />
beagle$ '''shutdown -r now''' <br />
<br />
I then waited for the reboot. That was all there was to it. <br />
Going the other way would require performing the resize operation <br />
first and specifying the size. <br />
<br />
Anyone care to automate this and submit this to Angstrom?<br />
<br />
=== Sharing Laptop Internet Connection with BeagleBoard ===<br />
Two options: One uses Ubuntu's GUI network connections manager, the other requires modifying things yourself.<br />
<br />
==== Option 1 - Using Ubuntu Network Connections GUI ====<br />
<br />
# In Ubuntu, go to System -> Preferences -> Network Connections<br />
# On the 'Wired' tab, select 'Auto eth0' and click 'Edit' (Note: name may be other than 'eth0'. If nothing exists in this list, then make sure there is '''not''' an entry starting with 'auto eth0' in your /etc/network/interfaces file; such an entry prevents Network Manager from managing that interface.)<br />
# Click the 'IPv4 Settings' tab and change 'Method' to 'Shared to other computers'<br />
# Click apply<br />
# Restart Ubuntu<br />
# Connect the BeagleBoard to the laptop with the crossover Ethernet cable<br />
# Boot the BeagleBoard - if Ubuntu was already running and the Ethernet cable was already plugged in, the BeagleBoard should automatically get assigned an IP address and you should be able to access the Internet on the BeagleBoard via the laptop's wireless connection<br />
<br />
==== Option 2 - Modifying Things Yourself (DHCP Server) ====<br />
<br />
This will setup a DHCP server on the host machine that will listen to the Ethernet port and assign an IP address to the BeagleBoard when it is connected with an Ethernet crossover cable. The host machine will then act as a router using NAT to send packets out the wifi interface.<br /><br />
A number of steps were taken from the [https://help.ubuntu.com/community/Internet/ConnectionSharing Ubuntu Community Documentation].<br /><br />
Notes:<br />
* 'eth0' will refer to the internal interface (connected to the BeagleBoard) and 'wlan0' will refer to the external interface (connected to the Internet). Your interface names may differ.<br />
* A number of configuration files are changed. It's a good idea to save a backup copy of these before modifying them.<br />
<br />
On the host machine, configure eth0 for a static IP:<br />
<br />
host$ '''sudo ifconfig eth0 192.168.1.13'''<br />
<br />
If you don't want to configure this after every boot, add an entry to /etc/network/interfaces with the following:<br />
<pre><br />
auto eth0<br />
address 192.168.1.13<br />
netmask 255.255.255.0<br />
network 192.168.1.0<br />
broadcast 192.168.1.255 <br />
</pre><br />
<br />
On the host machine, configure the IP tables to use NAT translation for routing packets:<br />
<br />
host$ '''sudo iptables -A FORWARD -o wlan0 -i eth0 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT'''<br />
host$ '''sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT'''<br />
host$ '''sudo iptables -A POSTROUTING -t nat -j MASQUERADE'''<br />
<br />
To avoid having to setup the IP tables after every boot, save the IP tables<br />
<br />
host$ '''sudo iptables-save | sudo tee /etc/iptables.sav'''<br />
<br />
And add the following command to /etc/rc.local (or other appropriate file for your distribution) to be run at boot<br />
<pre>iptables-restore < /etc/iptables.sav</pre><br />
<br />
IP forwarding needs to be enabled:<br />
<br />
host$ '''sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"'''<br />
<br />
To make sure this is set after rebooting, add these lines to /etc/sysctl.conf:<br />
<pre><br />
net.ipv4.conf.default.forwarding=1<br />
net.ipv4.conf.all.forwarding=1<br />
</pre><br />
<br />
Install the DHCP server software<br />
<br />
host$ '''sudo apt-get install dhcp3-server'''<br />
<br />
And edit the configuration file /etc/dhcp3/dhcpd.conf (comment out any already existing lines other than "ddns-update-style none;")<br />
<pre><br />
#Added for DHCP with BeagleBoard<br />
default-lease-time 600;<br />
max-lease-time 7200;<br />
option subnet-mask 255.255.255.0;<br />
option broadcast-address 192.168.1.255;<br />
option routers 192.168.1.13; #<--This must match the IP address you statically set for eth0<br />
option domain-name-servers 137.112.4.196,137.112.5.28,137.112.12.11; #<--Rose-Hulman's DNS servers (according to my laptop, at least)<br />
option domain-name "rose-hulman.edu";<br />
<br />
subnet 192.168.1.0 netmask 255.255.255.0 {<br />
range 192.168.1.14 192.168.1.14; #<--You can specify a larger range; I used this to force my BeagleBoard to always have the same IP so I could add an entry for that IP in /etc/hosts<br />
}<br />
</pre><br />
You may need to edit /etc/default/dhcp3-server to specify the interface for the DHCP server<br />
<pre>INTERFACES="eth0"</pre><br />
Then restart the DHCP server service<br />
<br />
host$ '''sudo service dhcp3-server restart'''<br />
<br />
You may need to reboot your host machine, and it may be necessary to run the command above to restart the DHCP server every time you boot (I'm not sure if it starts appropriately at boot).<br />
<br />
Now connect the BeagleBoard to the host machine with a crossover Ethernet cable and boot the Beagle. After booting, run 'ifconfig' to see if the Beagle was assigned an IP address. If it does not have an IP address, try running the command 'dhclient usb0'.<br />
<br />
Once the Beagle does have an IP address, try<br />
<br />
beagle$ '''ping -c 3 -W 10 www.google.com'''<br />
<br />
to test if the setup is working correctly. If it complains about a bad name, the DNS servers are incorrect; try pinging a specific IP such as 8.8.8.8 to see if packets get through (though unless you want to rely on all IP addresses, you will need to get some DNS servers that work).<br />
<br />
==== Option 3 - Manual Routing, Static Beagle IP ====<br />
<br />
This will setup the routing on Ubuntu (sending all eth0 traffic out wlan0). It will then set a static IP address on the BeagleBoard (so you can stick an entry for your BeagleBoard in /etc/hosts for convenience). The key difference from Option 2 is that the DHCP server in that option supplied the BeagleBoard with DNS servers. In this option, we add a script that gives the BeagleBoard some static DNS server addresses every time it boots.<br />
<br />
First, follow through the steps in Option 2 right up until it starts talking about installing the DHCP server. Instead of installing the DHCP server, do the following.<br />
<br />
On your BeagleBoard, add the following entry to <code>/etc/network/interfaces</code> (comment out any pre-existing entries regarding 'usb0')<br />
<pre><br />
auto usb0<br />
iface usb0 inet static<br />
address 192.168.1.14 # This is the static IP address of your choice<br />
netmask 255.255.255.0<br />
network 192.168.1.0<br />
gateway 192.168.1.13 # This must match the static IP address you assigned to eth0 on your host machine<br />
</pre><br />
After booting, the BeagleBoard is now configured with a static IP address and knows the gateway for all its traffic is the address of your host machine. The last thing to do is to make sure your BeagleBoard knows what DNS servers to use. This information is stored in the <code>/etc/resolv.conf</code> file. You could add it manually every time after boot, but we'll make a script to do it at boot instead.<br />
<br />
On your BeagleBoard, navigate to the /etc/rc5.d/ directory. In this directory, create a file named <code>S99<name></code> where <code><name></code> can be anything you prefer. My file was named <code>S99SetRoseHulmanNameServers</code>. Add the following inside that file:<br />
<pre><br />
#! /bin/sh<br />
echo "nameserver 137.112.4.196" >> /etc/resolv.conf # These three IP addresses are the Rose-Hulman DNS servers<br />
echo "nameserver 137.112.5.28" >> /etc/resolv.conf # Replace them with whatever DNS servers you are using<br />
echo "nameserver 137.112.12.11" >> /etc/resolv.conf<br />
</pre><br />
That should be it. Assuming all cables are connected properly and you have a WiFi connection on the host machine, after booting the BeagleBoard should have a usable Internet connection.<br />
<br />
=== Using u-boot to specify a MAC address at boot ===<br />
The BeagleBoard has a problem where Linux will randomly select a MAC address at boot. In order to get around this, [http://blog.galemin.com/tag/random-mac-address/ one blogger] provides a patch to enable a kernel command line parameter to set a MAC address. Below is one way to apply, your mileage may vary.<br />
<br />
# Make sure your kernel compiles and boots.<br />
# Grab the patch, and open it with gedit<br />
# Open .../git/drivers/net/usb/smsc95xx.c<br />
# Go to line 64-ish, and look for a place to insert the first code with plus signs preceding each line. Remove the plus signs.<br />
# Go to 656-ish, and repeat for the other block of code.<br />
# Save and re-compile.<br />
# Install the new kernel as normal.<br />
# Edit the kernel command line. There are two ways to do this:<br />
## Edit the uBoot source and recompile <br />
### Go to u-boot, and edit ../include/configs/omap3_beagle.h<br />
### Change mmcargs, nandargs, and ramargs to include a parameter for "ethaddr=...", where ... is your MAC address.<br />
### Save, close, recompile.<br />
### Install the new u-boot as normal.<br />
## Edit the boot.scr file<br />
### See [[ECE497 Modifying Kernel Command Line Parameters| Modifying Kernel Command Line Parameters]]<br />
# Register your MAC Address via any method that works, and enjoy reduced-hassle internet access on your Beagle.<br />
# Optionally, Update opkg.<br />
<br />
=== Rename an External Storage Device ===<br />
<br />
I ran out of space on my Linux (Ubuntu) partition, so I opted to do all my development on an external hard drive. This works just fine, except that the drive is labeled "Expansion Drive" and the space in there causes problems in some of the setup scripts. It is possible to add an entry in /etc/fstab that mounts the device with a certain name, but this is very cumbersome, for many reasons. Instead, I used this [1] very helpful guide to change the label on my external drive.<br />
<br />
[1] [http://help.ubuntu.com/community/RenameUSBDrive help.ubuntu.com/community/RenameUSBDrive]<br />
<br />
<br />
<br />
=== Setup a USB Wireless Device on Beagle ===<br />
<br />
([http://embeddedgeeks.wordpress.com/2012/01/03/belkin-micro-wifi-usb-dongle-on-the-beagleboard/ Here] are instructions on setting up a Belkin USB dongle.)<br />
<br />
The device I used to setup a wireless connection on the Beagle Board was the Linksys Compact Wireless-G USB Network Adapter with SpeedBooster.<br />
<br />
I first opened the wpa_supplicant.conf file to setup my networks:<br />
<br />
beagle$ '''cd /etc'''<br />
beagle$ '''gedit wpa_supplicant.conf &'''<br />
<br />
This file is filled with numerous examples of possible wireless configurations for you to basically fill in. After looking at the examples, I scrolled down to the bottom of the page and set up two networks: one for home and one for school. Here are examples of my setup networks:<br />
<pre><br />
#Home Network<br />
network={<br />
ssid="YourHomeNetworkName"<br />
psk="YourHomeNetworkPassword"<br />
}<br />
<br />
#School Network<br />
network={<br />
ssid="RHIT-1X"<br />
proto=WPA<br />
key_mgmt=WPA-EAP<br />
pairwise=CCMP<br />
group=TKIP<br />
eap=PEAP<br />
phase1="peapver=0 peaplabel=0"<br />
phase2="auth=MSCHAPV2"<br />
scan_ssid=1<br />
identity="YourSchoolUsername"<br />
password="YourSchoolPassword"<br />
}<br />
</pre><br />
For the network examples above,the quotation marks actually belong there but replace the Your.... areas with your corresponding information. No <space> before the first quotation mark.When finished editing save and exit this file.<br />
The information for the RHIT school network was found here:[http://lug.rose-hulman.edu/wiki/RHIT-1X RHLUG] <br />
<br />
Now you must specify that this is the file to use for the wireless device:<br />
<br />
beagle$ '''cd network'''<br />
beagle$ '''gedit interfaces &'''<br />
<br />
This file will display all of the different types of Internet connections you have setup.<br />
To use the wpa_supplicant.conf file, scroll down to around line 42 of the code and uncomment the configuration for wpasupplicant. After doing this make sure all of the above lines mentioning anything about wlan0 are commented out. Return back to where it says "iface wlan0 inet dhcp" that you uncommented around line 42.<br />
Add "auto wlan0" above this line, make sure the line "wpa-conf /etc/wpa_supplicant.conf" is uncommented below the iface line, and change the wpa-driver line below that line to wext. So after all of that the code in this file for the wireless device should be the following:<br />
<pre><br />
auto wlan0 <br />
iface wlan0 inet dhcp<br />
wpa-conf /etc/wpa_supplicant.conf<br />
wpa-driver wext<br />
</pre><br />
NOTE: the auto wlan0 command in this file means that this device will load at boot time. You can take the time in here now to comment out any interfaces you don't use like auto usb0 to make these devices not load at boot time, which will increase the speed at which you boot up.<br />
Save and exit this file<br />
<br />
Once you have finished this you can either restart the Beagle Board or:<br />
<br />
beagle$ '''cd'''<br />
beagle$ '''/etc/init.d/networking restart'''<br />
<br />
I've found that a lot of the time the interface doesn't receive an IP address when it boots up. If you run ifconfig in the terminal you should see your wireless device connected to a network. If it is connected but no IP address I do the following:<br />
<br />
beagle$ '''ifdown wlan0'''<br />
# it will report messages here and then<br />
beagle$ '''ifup wlan0'''<br />
# more messages and it should report connecting and having an IP address<br />
<br />
This ifdown ifup method has worked every time for me so far but if anyone can find a way to prevent having to do this almost every time please feel free to edit this<br />
<br />
== Development tips for bitbake and oe ==<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=70&Itemid=89 Gumstix Development Tips] appears to have some good ideas that can apply to the Beagle too.<br />
<br />
=== Point to a given git snapshot ===<br />
<br />
The original SD card image came from [http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/list.html here]. The file [http://beagleboard-validation.s3.amazonaws.com/deploy/201008201549/sd/ec2build.sh ec2buld.sh] shows how the image was build. There are a couple of interesting things in this file. <br />
<br />
Line 564 shows an additional git repository was used.<br />
<br />
host$ '''cd sources/openembedded'''<br />
host$ '''git remote add myrepo git://gitorious.org/~Jadon/angstrom/jadon-openembedded.git'''<br />
host$ '''git remote update'''<br />
<br />
Run this git command to get access to this repository. (It took about 2 minutes at 6:20am.) Line 21 shows the hash tag for the build.<br />
<br />
ANGSTROM_REPO_ID=24805033b1205acc35f8b4d75cc42f8b9c2a1b38<br />
<br />
If we pull from this tag we will have the same files as were used to generate the SD image. So do the following<br />
<br />
host$ '''git checkout 24805033b1205acc35f8b4d75cc42f8b9c2a1b38'''<br />
<br />
This takes about 10 seconds.<br />
<br />
== Fixing Problems ==<br />
<br />
=== Kernel Boot Problems ===<br />
<br />
[http://processors.wiki.ti.com/index.php/Kernel_-_Common_Problems_Booting_Linux Here] is a link with some suggestions of what to do if your kernel isn't booting properly.<br />
<br />
=== Serial port garbage ===<br />
<br />
If you are having trouble with garbage on the console, this might help. Sometimes the serial port times out. Most of the time it just generates some junk which can be cleared with CTRL-U or backspace. However, if it happens at the login prompt then getty thinks the terminal is 7-bit with parity (rather than 8-bit raw). If this happens and you continue to login the whole session appears to be scrambled - if you press CTRL-D you can login again provided you don't stop typing... :] <br />
I have simply added the following two lines to root's <code>.profile</code>: <br />
<pre><br />
stty -parenb -parodd cs8 -inpck -istrip <br />
echo 0 > /sys/class/tty/ttyS2/device/sleep_timeout<br />
</pre><br />
A better fix would probably be to just add the second line to a rc.d startup script somewhere.<br />
<br />
This suggestion came from this [http://groups.google.com/group/beagleboard/browse_thread/thread/d23c15e3c9fcb8fc posting].<br />
<br />
=== Turning off gpe ===<br />
The following worked last year, but doesn't seem to work now.<br />
<br />
Running above will write on top of what Angstrom is doing. You can turn off the display manager by using:<br />
<pre><br />
/etc/init.d/gpe-dm stop<br />
</pre><br />
Replace <code>stop</code> with <code>start</code> if you want to run it again.<br />
<br />
== Details of making your own MLO ==<br />
<br />
[http://www.embedded-bits.co.uk/2011/beagleboardxmjtaghardwar/ Hardware Environment for a BeagleBoard XM with JTAG]<br />
<br />
[http://www.embedded-bits.co.uk/2011/beagleboardxmjtagsoftware/ Software Environment for a BeagleBoard XM with JTAG]<br />
<br />
[http://www.embedded-bits.co.uk/2011/writeanmlo/ This] might make a good lab.<br />
<br />
== Getting help from a news group == <br />
<br />
[http://groups.google.com/group/beagleboard/msg/db315d63de2a522a Here's] a nice tip on what to do before posting a question to a news group.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/BeagleBoard_Education_WorkshopsBeagleBoard Education Workshops2013-06-18T15:23:13Z<p>Yoder: /* 2013 SPEN Workshop */ Added</p>
<hr />
<div>[[Category:ECE497 |W]]<br />
[[Category:BeagleBoard]]<br />
[[Category:Workshops]]<br />
[[Category:Education]]<br />
{{YoderHead}}<br />
<br />
== 2013 SPEN Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Moving Beyond the DSP and Teaching 32-bit Embedded Processors Using the BeagleBone<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| <br />
|-<br />
| '''Date:''' <br />
| 13-Aug-2013<br />
|-<br />
| '''Link'''<br />
| [http://dspe2013.engr.scu.edu/ 2013 Digital Signal Processing & Signal Processing Education Workshop]<br />
|}<br />
<br />
=== Abstract:===<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. This 2.5-hour, hands-on workshop presents ideas on how to use the BeagleBone Black ([http://www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded media processing using Open Source resources. The BeagleBone is 1) more powerful and has more I/O than a [http://www.raspberrypi.org/ Raspberry Pi], 2) is as easy to use as an [http://www.arduino.cc/ Arduino] and 3) has a thriving [http://beagleboard.org/Community/Forums Open Source Software community]. <br />
<br />
The workshop activities will include 1) several demonstrations of what the Beagle can do, 2) discussions of what topics to include in an embedded Linux class and 3) several hands-on exercises to get participants familiar with using the Beagle using [http://beagleboard.org/Support/BoneScript BoneScript] and Linux commands.<br />
<br />
Participants will receive a BeagleBone Black.<br />
<br />
=== Pre Workshop ===<br />
<br />
=== Labs ===<br />
<br />
[[ASEE 2013 Workshop | Afternoon labs]]<br />
<br />
=== Post Workshop ===<br />
<br />
== 2013 ASEE Workshop ==<br />
{|<br />
| '''Title:''' <br />
| U216·WORKSHOP: BeagleBone - A Hands-on Workshop<br />
|-<br />
| '''Presentors:''' <br />
| Dr. Steven F Barrett P.E., Jason Kridner, Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Atlanta, Omni CNN Center Hotel, Omni - Chestnut<br />
|-<br />
| '''Date:''' <br />
| 23-June-2013<br />
|-<br />
| '''Link'''<br />
| [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE site]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Ticketed event: $25.00 advanced registration and $35.00 on site registration'''<br />
<br />
BeagleBone is a low cost, open hardware computer first introduced in November 2011 by BeagleBoard.org, a community of developers sponsored by Texas Instruments. BeagleBone hosts a powerful 32-bit, super-scalar ARM Cortex A8 processor operating at 720 MHz. Yet it is small enough to fit in an Altoids mint tin box. The "Bone'' may be used in a wide variety of projects from middle school science fair projects to senior design projects to first prototypes of very complex systems. Novice users may access the power of the Bone through the user-friendly Bonescript environment. Seasoned users may take full advantage of the Bone's power using the underlying Linux-based operating system, a host of feature extension boards (Capes) and a wide variety of open source libraries. This hands on workshop provides an introduction to this powerful computer and has been designed for a wide variety of users including the first time novice through the seasoned embedded system design professional. <br />
<br />
Workshop participants will receive a BeagleBone board and also a BeagleBone book courtesy of BeagleBoard.org and Morgan and Claypool Publishers. This workshop is subsidized by Texas Instruments (TI).<br />
<br />
=== Pre Workshop ===<br />
<br />
=== Labs ===<br />
<br />
[[ASEE 2013 Workshop | Afternoon labs]]<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Engibous Summit Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on BeagleBone<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Dallas<br />
|-<br />
| '''Date:''' <br />
| 30-July-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.ti.com/corp/docs/landing/universityprogram/prize.htm Engibous Summit]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
???<br />
<br />
=== Pre Workshop ===<br />
<br />
You will be mailed some information about the workshop and some things for you to do before arriving.<br />
<br />
--Mark<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Chandigarh Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/73-chitkara-school-of-engineering-a-technology Chitkara School of Engineering & Technology] - Chandigarh, India<br />
|-<br />
| '''Date:''' <br />
| 18-20 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Beagleboard is a low-cost open-source embedded system development platform. It is based on Texas Instruments DM3730 processor, which includes an on-chip ARM Cortex-A8 processor core, a Texas Instruments C6x DSP core, and a host of peripherals. Beagleboard is a single board computer, which provides adequate performance to run Linux software, yet has a power consumption lower than 2W. A large number of embedded applications have been developed on Beagleboard ([http://www.beagleboard.org www.beagleboard.org]) Module A provides a gentle introduction to the subject of Embedded Linux, Linux Systems Programming and Linux Kernel Programming. The intention of Module B is to provide a hands-on exposure to running Embedded Linux operating system on the Beagleboard and develop system software on the Beagleboard.<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Hyderabad Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Three-day workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/69-c-dac-hyderabad C-DAC Hyderabad] - Hyderabad, India<br />
|-<br />
| '''Date:''' <br />
| 14-16 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Linux, which is an “open source” operating system and enjoys considerable popularity on general-purpose computers, is becoming popular in the embedded world also. Different versions and variants of Linux are now available on embedded platforms. In this workshop, the intention is to provide a hands-on introduction to concepts of Linux Systems/Kernel Programming and Embedded Linux<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Bangalore Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 6-day modular workshop on Embedded Linux<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/68-cambridge-institute-of-technology Cambridge Institute of Technology] - Bangalore, India<br />
|-<br />
| '''Date:''' <br />
| 11-13 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Module A''' provides an overview of basic concepts of Linux, Linux Systems Programming, Linux Kernel Programming, and Embedded Systems. Module A will also include an introduction to Beagleboard, an open-source, low-cost, low-power embedded system development platform. '''Module A''' will be conducted jointly by a team of experts from industry and academia. In '''Module B''', aspects of Embedded Linux on Beagleboard will be explored in greater depth. Module B will be conducted by Prof. Mark A. Yoder of Rose-Hulman Institute of Technology, USA.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2011 FIE Workshop - Cancelled ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Holiday Inn Salon F, Rapid City, South Dakota<br />
|-<br />
| '''Date:''' <br />
| Wednesday, October 12, 2011, 2:30 p.m. - 5:30 p.m<br />
|-<br />
| '''Link'''<br />
| [http://fie-conference.org/fie2011/] [http://fie-conference.org/fie2011/Pages/workshops.htm#SCRL6]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
The goal of this hands-on tutorial is to present ideas on how to use Texas Instrument’s DM 3730-based BeagleBoard xM ([www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded processing using Open Source resources. The DM 3730 is a dual core processor with an ARM Cortex-a8 core and a TI ‘c64x DSP core. The BeagleBoard is Open Source hardware that has sold over 30,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
<br />
The BeagleBoard has many uses in the classroom. This workshop will show some of those uses and present some of the challenges in teaching with Open Source.<br />
<br />
The workshop activities will include:<br />
<br />
* several hands-on exercises to get participants familiar with using the Beagle, and how it differs from a traditional 8- or 16-bit microcomputer.<br />
* several demonstrations of what the Beagle can do, such as streaming video and programming its DSP and discussions of what topics to include in an embedded/DSP class including dealing with open source comminutes.<br />
* This workshop is targeted to those who are teaching embedded processors or DSP hardware. Some Linux background would be helpful, but not required. Those with little or no Linux experience will be paired with those with more experience.<br />
<br />
=== Post Workshop ===<br />
<br />
Even though the workshop has been cancelled, you can still do the exercises. Here ([[Getting a Workshop SD Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
Here ([[EBC Embedded Beagle Class Topics]]) is a list of topics I cover in my class. If you have questions, please email me.<br />
<br />
== 2011 IEEE ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| How 32-bit Embedded Processors Change the Focus in Teaching DSP Hardware<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Monday May 23rd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/registration]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 20,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
After the introduction, this workshop will complement the Sunday afternoon tutorial “From DSP Chips to Embedded Processors for Teaching Digital Signal Processing”. The Sunday workshop examples focus on programming the ‘C64 DSP on the OMAP3530. This workshop will focus on using Open Source software for media processing (such as GStreamer, OpenCV, etc.) and using the OMAP display subsystem for handling video. <br />
The workshop activities will include:<br />
# Several hands-on exercises to get participants familiar with using the Beagle, (same as tutorial)<br />
# Several demonstrations of what the Beagle can do using Open Source software, including using the display subsystem, recognizing speech, computer vision<br />
# Discussions of what topics to include in an embedded Linux class.<br />
No BeagleBoards will given out.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Monty Hayes<br />
|Georgia Tech, Professor, Atlanta, GA and<br />
Chung-Ang University Distinguished Foreign Professor, Seoul, Korea<br />
|I have no linux experience, have taught courses on DSP chips before<br />
|I would like to develop an undergraduate course using the Beagleboard to teach DSP.<br />
|-<br />
|Oleg Muratov<br />
|University of Trento, Itay<br />
|I am a PhD student and I have limited Linux experience.<br />
|I am planning to give a course to undergraduate students on DSP probably using some hardware.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[VideoThru Lab]]<br />
<br />
=== Post Workshop ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE ICASSP Tutorial ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Sunday May 22nd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/tutorials/tutorial-5]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 16,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. Our students need to see that the days of the single DSP chip are almost over and they need to be prepared for working with DSPs embedded with other processors.<br />
The OMAP3530 processor contains both an ARM Cortex-A9 processor and a ‘C6400 DSP and it and chips like it are being used in products today. <br />
The workshop activities include:<br />
# hands-on exercises to get participants familiar with using the Beagle,<br />
# demonstrations of what the Beagle can do, including streaming video and synthesizing speech and<br />
# discussions of what topics to include in an embedded Linux class.<br />
Participants will receive a BeagleBoard and course materials.<br />
<br />
=== Pre Tutorial ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Matt Gately<br />
|University of Oklahoma, Norman, OK, USA<br />
|I am a PhD student and I use Linux in my research. <br />
|I would love to someday teach a DSP course using embedded systems such as FPGA or microcontroller boards. <br />
<br />
<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[AudioThru Lab]]<br />
<br />
=== Post Tutorial ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE SPEd (Signal Processing Society 14th DSP Workshop & 6th SPEd Workshop) ==<br />
{|<br />
| '''Title:''' <br />
| Moving Beyond the DSP and Teaching 32-bit Embedded Processors Using the BeagleBoard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Enchantment Resort, Sedona, Arizona<br />
|-<br />
| '''Date:''' <br />
| Thursday 6 January, 2011 Time: 14:00 - 17:30<br />
|-<br />
| '''Link'''<br />
| [http://enpub.fulton.asu.edu/ivu/Workshops/DSPE2011/training.html#TI2]<br />
|}<br />
<br />
=== Abstract ===<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. This 3-hour, hands-on workshop presents ideas on how to use TI’s OMAP 3530-based BeagleBoard ([www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded media processing using Open Source resources. The OMAP3530 processor contains both an ARM Cortex-A9 processor and a ‘C6400 DSP. The BeagleBoard is Open Source hardware that has sold over 20,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community. The 3-hour workshop activities will include 1) several demonstrations of what the Beagle can do, including streaming video and synthesizing speech, 2) Discussions of what topics to include in an embedded Linux class and 3) Several hands-on exercises to get participants familiar with using the Beagle. Participants will receive a Beagleboard. <br />
<br />
=== Post Workshop ===<br />
Here are some things you might want to do now that the workshop is over. <br />
<br />
Here are instructions on how to create the SD card that was used in the workshop.<br />
* Go here ([[ECE597_Getting_your_Beagle_running_(precompiled)#From_beagleboard-validation.s3.amazonaws.com]]) to download and install the base image for the Beagle. This will install the kernel and all the files needed to run many of the demos.<br />
* Download [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopFiles.zip this zip file] to get the extra files used in the workshop. Copy it to your BeagleBoard and unzip it there. This file contains the '''VideoThru''', '''c6run_target''', '''hello.c''' and '''helloBeagle.c''' files.<br />
* Download the workshop pptx [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopPPTX.zip here].<br />
<br />
=== Pre Workshop === <br />
If you are an overachiever (not required) go here ([[ECE497 Lab13 Using the DSP via c6run]]) to learn how to install the ARM and DSP development tools on your Linux system (Ubuntu 10.4 LTS is required). If you don't have Ubuntu installed, go [http://processors.wiki.ti.com/index.php/How_to_Build_a_Ubuntu_Linux_host_under_VirtualBox here] to learn how to install it in a virtual machine under windows.<br />
<br />
These installs are not required for the workshop; however editing the the table below ''is''.<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program www.ti.com/university helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
| Steve Chadwick<br />
| Embry-Riddle Aeronautical University, Prescott, AZ <br />
| Very new to DSP and hoping develop sufficient depth to teach it next academic year. <br />
| Interests: Pretty much everything in science. <br />
|-<br />
| Mark Wickert<br />
| University of Colorado, Colorado Springs, CO, USA<br />
| I have played on and off with Linux for about 10 years, never done any real-time DSP under this OS however.<br />
| I regularly teach DSP and related courses. I am using the C6713 today, but ready to move forward. I recently started playing with ARM processors (not the BeagleBoard until now).<br />
|-<br />
| Shane Cotter<br />
| Union College, Schenectady, NY<br />
| I have taught DSP courses. I have used Unix/Linux in the past but not for real-time DSP.<br />
| The Beagleboard seems like a great platform and I'm interested in learning about it and its potential uses in courses.<br />
|-<br />
| Jake Gunther<br />
| Utah State University<br />
| I have taught DSP and communication systems for over ten years.<br />
| I want to move from a simulation-based teaching approach to a real-time approach.<br />
|}<br />
<br />
== 2010 ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 32-bit Embedded Linux-based Signal Processing – Hands on Workshop<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| ICASSP 2010, Dallas, Texas<br />
|-<br />
| '''Date:''' <br />
| Monday, March 15 2010, 13:30 - 17:00<br />
|}<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:20%" | email<br />
! style="width:40%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| [http://www.rose-hulman.edu/~yoder]<br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|David V. Anderson<br />
|Georgia Institute of Technology<br />
|<br />
|Teaching DSP using BeagleBoard as a real-time platform.<br />
|-<br />
|Andres Kwasinski<br />
|Rochester Institute of Technology<br />
|[http://people.rit.edu/axkeec/]<br />
|Teaching DSP to Computer Engineers using real-world platforms.<br />
|-<br />
|Roger West<br />
|Utah State University<br />
|<br />
|Teaching DSP to ECE students using real-time platforms.<br />
|}<br />
<br />
=== Labs ===<br />
Here is a list of the hands on exercises we will be doing in the 2010 workshop. Many have suggestions for additional homework that you can do once you are back home and have a network connection.<br />
<br />
# [[2010 ICASSP Lab 1 Wiring_and_Running the Beagle]]<br />
# [[2010 ICASSP Lab 2 The Boot Sequence]]<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/BeagleBoard_Education_WorkshopsBeagleBoard Education Workshops2013-06-18T15:04:48Z<p>Yoder: Added Abstract</p>
<hr />
<div>[[Category:ECE497 |W]]<br />
[[Category:BeagleBoard]]<br />
[[Category:Workshops]]<br />
[[Category:Education]]<br />
{{YoderHead}}<br />
<br />
== 2013 ASEE Workshop ==<br />
{|<br />
| '''Title:''' <br />
| U216·WORKSHOP: BeagleBone - A Hands-on Workshop<br />
|-<br />
| '''Presentors:''' <br />
| Dr. Steven F Barrett P.E., Jason Kridner, Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Atlanta, Omni CNN Center Hotel, Omni - Chestnut<br />
|-<br />
| '''Date:''' <br />
| 23-June-2013<br />
|-<br />
| '''Link'''<br />
| [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE site]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Ticketed event: $25.00 advanced registration and $35.00 on site registration'''<br />
<br />
BeagleBone is a low cost, open hardware computer first introduced in November 2011 by BeagleBoard.org, a community of developers sponsored by Texas Instruments. BeagleBone hosts a powerful 32-bit, super-scalar ARM Cortex A8 processor operating at 720 MHz. Yet it is small enough to fit in an Altoids mint tin box. The "Bone'' may be used in a wide variety of projects from middle school science fair projects to senior design projects to first prototypes of very complex systems. Novice users may access the power of the Bone through the user-friendly Bonescript environment. Seasoned users may take full advantage of the Bone's power using the underlying Linux-based operating system, a host of feature extension boards (Capes) and a wide variety of open source libraries. This hands on workshop provides an introduction to this powerful computer and has been designed for a wide variety of users including the first time novice through the seasoned embedded system design professional. <br />
<br />
Workshop participants will receive a BeagleBone board and also a BeagleBone book courtesy of BeagleBoard.org and Morgan and Claypool Publishers. This workshop is subsidized by Texas Instruments (TI).<br />
<br />
=== Pre Workshop ===<br />
<br />
=== Labs ===<br />
<br />
[[ASEE 2013 Workshop | Afternoon labs]]<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Engibous Summit Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on BeagleBone<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Dallas<br />
|-<br />
| '''Date:''' <br />
| 30-July-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.ti.com/corp/docs/landing/universityprogram/prize.htm Engibous Summit]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
???<br />
<br />
=== Pre Workshop ===<br />
<br />
You will be mailed some information about the workshop and some things for you to do before arriving.<br />
<br />
--Mark<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Chandigarh Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/73-chitkara-school-of-engineering-a-technology Chitkara School of Engineering & Technology] - Chandigarh, India<br />
|-<br />
| '''Date:''' <br />
| 18-20 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Beagleboard is a low-cost open-source embedded system development platform. It is based on Texas Instruments DM3730 processor, which includes an on-chip ARM Cortex-A8 processor core, a Texas Instruments C6x DSP core, and a host of peripherals. Beagleboard is a single board computer, which provides adequate performance to run Linux software, yet has a power consumption lower than 2W. A large number of embedded applications have been developed on Beagleboard ([http://www.beagleboard.org www.beagleboard.org]) Module A provides a gentle introduction to the subject of Embedded Linux, Linux Systems Programming and Linux Kernel Programming. The intention of Module B is to provide a hands-on exposure to running Embedded Linux operating system on the Beagleboard and develop system software on the Beagleboard.<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Hyderabad Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Three-day workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/69-c-dac-hyderabad C-DAC Hyderabad] - Hyderabad, India<br />
|-<br />
| '''Date:''' <br />
| 14-16 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Linux, which is an “open source” operating system and enjoys considerable popularity on general-purpose computers, is becoming popular in the embedded world also. Different versions and variants of Linux are now available on embedded platforms. In this workshop, the intention is to provide a hands-on introduction to concepts of Linux Systems/Kernel Programming and Embedded Linux<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Bangalore Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 6-day modular workshop on Embedded Linux<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/68-cambridge-institute-of-technology Cambridge Institute of Technology] - Bangalore, India<br />
|-<br />
| '''Date:''' <br />
| 11-13 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Module A''' provides an overview of basic concepts of Linux, Linux Systems Programming, Linux Kernel Programming, and Embedded Systems. Module A will also include an introduction to Beagleboard, an open-source, low-cost, low-power embedded system development platform. '''Module A''' will be conducted jointly by a team of experts from industry and academia. In '''Module B''', aspects of Embedded Linux on Beagleboard will be explored in greater depth. Module B will be conducted by Prof. Mark A. Yoder of Rose-Hulman Institute of Technology, USA.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2011 FIE Workshop - Cancelled ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Holiday Inn Salon F, Rapid City, South Dakota<br />
|-<br />
| '''Date:''' <br />
| Wednesday, October 12, 2011, 2:30 p.m. - 5:30 p.m<br />
|-<br />
| '''Link'''<br />
| [http://fie-conference.org/fie2011/] [http://fie-conference.org/fie2011/Pages/workshops.htm#SCRL6]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
The goal of this hands-on tutorial is to present ideas on how to use Texas Instrument’s DM 3730-based BeagleBoard xM ([www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded processing using Open Source resources. The DM 3730 is a dual core processor with an ARM Cortex-a8 core and a TI ‘c64x DSP core. The BeagleBoard is Open Source hardware that has sold over 30,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
<br />
The BeagleBoard has many uses in the classroom. This workshop will show some of those uses and present some of the challenges in teaching with Open Source.<br />
<br />
The workshop activities will include:<br />
<br />
* several hands-on exercises to get participants familiar with using the Beagle, and how it differs from a traditional 8- or 16-bit microcomputer.<br />
* several demonstrations of what the Beagle can do, such as streaming video and programming its DSP and discussions of what topics to include in an embedded/DSP class including dealing with open source comminutes.<br />
* This workshop is targeted to those who are teaching embedded processors or DSP hardware. Some Linux background would be helpful, but not required. Those with little or no Linux experience will be paired with those with more experience.<br />
<br />
=== Post Workshop ===<br />
<br />
Even though the workshop has been cancelled, you can still do the exercises. Here ([[Getting a Workshop SD Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
Here ([[EBC Embedded Beagle Class Topics]]) is a list of topics I cover in my class. If you have questions, please email me.<br />
<br />
== 2011 IEEE ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| How 32-bit Embedded Processors Change the Focus in Teaching DSP Hardware<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Monday May 23rd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/registration]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 20,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
After the introduction, this workshop will complement the Sunday afternoon tutorial “From DSP Chips to Embedded Processors for Teaching Digital Signal Processing”. The Sunday workshop examples focus on programming the ‘C64 DSP on the OMAP3530. This workshop will focus on using Open Source software for media processing (such as GStreamer, OpenCV, etc.) and using the OMAP display subsystem for handling video. <br />
The workshop activities will include:<br />
# Several hands-on exercises to get participants familiar with using the Beagle, (same as tutorial)<br />
# Several demonstrations of what the Beagle can do using Open Source software, including using the display subsystem, recognizing speech, computer vision<br />
# Discussions of what topics to include in an embedded Linux class.<br />
No BeagleBoards will given out.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Monty Hayes<br />
|Georgia Tech, Professor, Atlanta, GA and<br />
Chung-Ang University Distinguished Foreign Professor, Seoul, Korea<br />
|I have no linux experience, have taught courses on DSP chips before<br />
|I would like to develop an undergraduate course using the Beagleboard to teach DSP.<br />
|-<br />
|Oleg Muratov<br />
|University of Trento, Itay<br />
|I am a PhD student and I have limited Linux experience.<br />
|I am planning to give a course to undergraduate students on DSP probably using some hardware.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[VideoThru Lab]]<br />
<br />
=== Post Workshop ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE ICASSP Tutorial ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Sunday May 22nd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/tutorials/tutorial-5]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 16,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. Our students need to see that the days of the single DSP chip are almost over and they need to be prepared for working with DSPs embedded with other processors.<br />
The OMAP3530 processor contains both an ARM Cortex-A9 processor and a ‘C6400 DSP and it and chips like it are being used in products today. <br />
The workshop activities include:<br />
# hands-on exercises to get participants familiar with using the Beagle,<br />
# demonstrations of what the Beagle can do, including streaming video and synthesizing speech and<br />
# discussions of what topics to include in an embedded Linux class.<br />
Participants will receive a BeagleBoard and course materials.<br />
<br />
=== Pre Tutorial ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Matt Gately<br />
|University of Oklahoma, Norman, OK, USA<br />
|I am a PhD student and I use Linux in my research. <br />
|I would love to someday teach a DSP course using embedded systems such as FPGA or microcontroller boards. <br />
<br />
<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[AudioThru Lab]]<br />
<br />
=== Post Tutorial ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE SPEd (Signal Processing Society 14th DSP Workshop & 6th SPEd Workshop) ==<br />
{|<br />
| '''Title:''' <br />
| Moving Beyond the DSP and Teaching 32-bit Embedded Processors Using the BeagleBoard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Enchantment Resort, Sedona, Arizona<br />
|-<br />
| '''Date:''' <br />
| Thursday 6 January, 2011 Time: 14:00 - 17:30<br />
|-<br />
| '''Link'''<br />
| [http://enpub.fulton.asu.edu/ivu/Workshops/DSPE2011/training.html#TI2]<br />
|}<br />
<br />
=== Abstract ===<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. This 3-hour, hands-on workshop presents ideas on how to use TI’s OMAP 3530-based BeagleBoard ([www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded media processing using Open Source resources. The OMAP3530 processor contains both an ARM Cortex-A9 processor and a ‘C6400 DSP. The BeagleBoard is Open Source hardware that has sold over 20,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community. The 3-hour workshop activities will include 1) several demonstrations of what the Beagle can do, including streaming video and synthesizing speech, 2) Discussions of what topics to include in an embedded Linux class and 3) Several hands-on exercises to get participants familiar with using the Beagle. Participants will receive a Beagleboard. <br />
<br />
=== Post Workshop ===<br />
Here are some things you might want to do now that the workshop is over. <br />
<br />
Here are instructions on how to create the SD card that was used in the workshop.<br />
* Go here ([[ECE597_Getting_your_Beagle_running_(precompiled)#From_beagleboard-validation.s3.amazonaws.com]]) to download and install the base image for the Beagle. This will install the kernel and all the files needed to run many of the demos.<br />
* Download [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopFiles.zip this zip file] to get the extra files used in the workshop. Copy it to your BeagleBoard and unzip it there. This file contains the '''VideoThru''', '''c6run_target''', '''hello.c''' and '''helloBeagle.c''' files.<br />
* Download the workshop pptx [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopPPTX.zip here].<br />
<br />
=== Pre Workshop === <br />
If you are an overachiever (not required) go here ([[ECE497 Lab13 Using the DSP via c6run]]) to learn how to install the ARM and DSP development tools on your Linux system (Ubuntu 10.4 LTS is required). If you don't have Ubuntu installed, go [http://processors.wiki.ti.com/index.php/How_to_Build_a_Ubuntu_Linux_host_under_VirtualBox here] to learn how to install it in a virtual machine under windows.<br />
<br />
These installs are not required for the workshop; however editing the the table below ''is''.<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program www.ti.com/university helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
| Steve Chadwick<br />
| Embry-Riddle Aeronautical University, Prescott, AZ <br />
| Very new to DSP and hoping develop sufficient depth to teach it next academic year. <br />
| Interests: Pretty much everything in science. <br />
|-<br />
| Mark Wickert<br />
| University of Colorado, Colorado Springs, CO, USA<br />
| I have played on and off with Linux for about 10 years, never done any real-time DSP under this OS however.<br />
| I regularly teach DSP and related courses. I am using the C6713 today, but ready to move forward. I recently started playing with ARM processors (not the BeagleBoard until now).<br />
|-<br />
| Shane Cotter<br />
| Union College, Schenectady, NY<br />
| I have taught DSP courses. I have used Unix/Linux in the past but not for real-time DSP.<br />
| The Beagleboard seems like a great platform and I'm interested in learning about it and its potential uses in courses.<br />
|-<br />
| Jake Gunther<br />
| Utah State University<br />
| I have taught DSP and communication systems for over ten years.<br />
| I want to move from a simulation-based teaching approach to a real-time approach.<br />
|}<br />
<br />
== 2010 ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 32-bit Embedded Linux-based Signal Processing – Hands on Workshop<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| ICASSP 2010, Dallas, Texas<br />
|-<br />
| '''Date:''' <br />
| Monday, March 15 2010, 13:30 - 17:00<br />
|}<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:20%" | email<br />
! style="width:40%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| [http://www.rose-hulman.edu/~yoder]<br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|David V. Anderson<br />
|Georgia Institute of Technology<br />
|<br />
|Teaching DSP using BeagleBoard as a real-time platform.<br />
|-<br />
|Andres Kwasinski<br />
|Rochester Institute of Technology<br />
|[http://people.rit.edu/axkeec/]<br />
|Teaching DSP to Computer Engineers using real-world platforms.<br />
|-<br />
|Roger West<br />
|Utah State University<br />
|<br />
|Teaching DSP to ECE students using real-time platforms.<br />
|}<br />
<br />
=== Labs ===<br />
Here is a list of the hands on exercises we will be doing in the 2010 workshop. Many have suggestions for additional homework that you can do once you are back home and have a network connection.<br />
<br />
# [[2010 ICASSP Lab 1 Wiring_and_Running the Beagle]]<br />
# [[2010 ICASSP Lab 2 The Boot Sequence]]<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-17T16:19:36Z<p>Yoder: </p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button? Hit '''Ctrl-C''' to quit button.sh.<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input and print it on the same line.<br />
bone$ '''cd'''<br />
bone$ '''nano ainOut.sh'''<br />
<br />
cd /sys/devices/ocp.2/helper.14<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
bone$ '''chmod +x ainOut.sh'''<br />
bone$ '''./ainOut.sh'''<br />
Use '''Ctrl-C''' to quit ainOut.sh<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
We have to run a couple of commands to make the PWM interface appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS'''<br />
bone$ '''cd /sys/devices/ocp.2/pwm_test_P9_21.14'''<br />
bone$ '''ls'''<br />
driver duty modalias period polarity power run subsystem uevent<br />
<br />
The units are in ns.<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period'''<br />
bone$ '''echo 250000000 > duty'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
== Other Languages ==<br />
Out-of-the-box the bone can run<br />
* C<br />
* C++<br />
* bash<br />
* perl<br />
* python<br />
* Javascript<br />
<br />
Here's a simple C example<br />
<br />
bone$ '''cd'''<br />
bone$ '''nano hello.c'''<br />
'''#include <stdio.h>'''<br />
'''main ()'''<br />
'''{'''<br />
''' printf("hello, world\n");'''<br />
'''}'''<br />
<br />
bone$ '''cc hello.c'''<br />
bone$ '''./a.out'''<br />
hello, world<br />
<br />
Try your favorite language.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-17T16:15:06Z<p>Yoder: /* Other Languages */ Added hello, world</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button? Hit '''Ctrl-C''' to quit button.sh.<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input and print it on the same line.<br />
bone$ '''cd'''<br />
bone$ '''nano ainOut.sh'''<br />
<br />
cd /sys/devices/ocp.2/helper.14<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
bone$ '''chmod +x ainOut.sh'''<br />
bone$ '''./ainOut.sh'''<br />
Use '''Ctrl-C''' to quit ainOut.sh<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
We have to run a couple of commands to make the PWM interface appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS'''<br />
bone$ '''cd /sys/devices/ocp.2/pwm_test_P9_21.14'''<br />
bone$ '''ls'''<br />
driver duty modalias period polarity power run subsystem uevent<br />
<br />
The units are in ns.<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period'''<br />
bone$ '''echo 250000000 > duty'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
== Other Languages ==<br />
Out-of-the-box the bone can run<br />
* C<br />
* C++<br />
* bash<br />
* perl<br />
* python<br />
* Javascript<br />
<br />
Here's a simple C example<br />
<br />
bone$ '''cd'''<br />
bone$ '''nano'''<br />
'''#include <stdio.h>'''<br />
'''main ()'''<br />
'''{'''<br />
''' printf("hello, world\n");'''<br />
'''}'''<br />
<br />
bone$ '''cc hello.c'''<br />
bone$ '''./a.out'''<br />
hello, world<br />
<br />
Try your favorite language.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-17T16:10:06Z<p>Yoder: /* Other Languages */ Added</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button? Hit '''Ctrl-C''' to quit button.sh.<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input and print it on the same line.<br />
bone$ '''cd'''<br />
bone$ '''nano ainOut.sh'''<br />
<br />
cd /sys/devices/ocp.2/helper.14<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
bone$ '''chmod +x ainOut.sh'''<br />
bone$ '''./ainOut.sh'''<br />
Use '''Ctrl-C''' to quit ainOut.sh<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
We have to run a couple of commands to make the PWM interface appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS'''<br />
bone$ '''cd /sys/devices/ocp.2/pwm_test_P9_21.14'''<br />
bone$ '''ls'''<br />
driver duty modalias period polarity power run subsystem uevent<br />
<br />
The units are in ns.<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period'''<br />
bone$ '''echo 250000000 > duty'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
== Other Languages ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-17T16:08:21Z<p>Yoder: /* Pulse Width Modulation */ Updated instructions</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button? Hit '''Ctrl-C''' to quit button.sh.<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input and print it on the same line.<br />
bone$ '''cd'''<br />
bone$ '''nano ainOut.sh'''<br />
<br />
cd /sys/devices/ocp.2/helper.14<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
bone$ '''chmod +x ainOut.sh'''<br />
bone$ '''./ainOut.sh'''<br />
Use '''Ctrl-C''' to quit ainOut.sh<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
We have to run a couple of commands to make the PWM interface appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS'''<br />
bone$ '''cd /sys/devices/ocp.2/pwm_test_P9_21.14'''<br />
bone$ '''ls'''<br />
driver duty modalias period polarity power run subsystem uevent<br />
<br />
The units are in ns.<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period'''<br />
bone$ '''echo 250000000 > duty'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:59:56Z<p>Yoder: </p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button? Hit '''Ctrl-C''' to quit button.sh.<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input and print it on the same line.<br />
bone$ '''cd'''<br />
bone$ '''nano ainOut.sh'''<br />
<br />
cd /sys/devices/ocp.2/helper.14<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
bone$ '''chmod +x ainOut.sh'''<br />
bone$ '''./ainOut.sh'''<br />
Use '''Ctrl-C''' to quit ainOut.sh<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:54:35Z<p>Yoder: /* Reading a switch */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button? Hit '''Ctrl-C''' to quit button.sh.<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:47:19Z<p>Yoder: /* Analog In */ Moved to AIN0</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired up P9_39 for AIN0 in the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
bone$ '''cat AIN0'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN0<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:45:07Z<p>Yoder: </p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in the table below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different place. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:40:16Z<p>Yoder: /* Reading a switch */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''cd''' (Go back home)<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:28:00Z<p>Yoder: /* Blinking an External LED via gpio */ Removed unexport</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off.<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:26:35Z<p>Yoder: /* Blinking an External LED via gpio */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
Your LED should be on!<br />
bone$ '''echo 0 > value'''<br />
Now it's off. When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''ls'''<br />
export gpio60 gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport<br />
bone$ '''echo 60 > unexport'''<br />
bone$ '''ls'''<br />
export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:25:47Z<p>Yoder: /* Blinking an External LED via gpio */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
bone$ '''echo 0 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''ls'''<br />
export gpio60 gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport<br />
bone$ '''echo 60 > unexport'''<br />
bone$ '''ls'''<br />
export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:21:46Z<p>Yoder: /* Blinking a USR LED */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
(The "'''@'''" after the name means it's a link.) See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:18:28Z<p>Yoder: Cleaning up</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
Another easy way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. Here we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you can easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
The "'''/'''" after the name means it's a directory. Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-14T16:14:09Z<p>Yoder: /* Warm Up */ Moved play to play.txt</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play.txt'''.<br />
<br />
bone$ '''nano play.txt'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play.txt<br />
bone$ '''cat play.txt'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here.txt'''<br />
bone$ '''cat here.txt'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here.txt play.txt<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/EBC_Exercise_01_Start_HereEBC Exercise 01 Start Here2013-06-11T17:47:40Z<p>Yoder: </p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
<br />
== Overview ==<br />
<br />
There are four major things that need to be done to have the BeagleBoard ready to run for class:<br />
# Get your Beagle Hardware together<br />
# Update the OS on your Beagle<br />
# Set up a host computer, running Linux for code development<br />
# Clone the course git repository on both the Beagle and the host<br />
<br />
== The Hardware ==<br />
<br />
Here's the hardware you will need and where you get it.<br />
<br />
=== You may have, or will have to buy ===<br />
<br />
We are using the [http://beagleboard.org/Getting%20Started BeagleBone Black] this year. Since it's only $45 I'll have you buy your your own. There's a few other things you will need to get before the first day of class.<br />
* BeagleBone Black. See [http://beagleboard.org/ http://beagleboard.org/] for suggestions of where to buy the Black.<br />
* USB keyboard and mouse<br />
* HDMI display<br />
* At least three 4G micro SD cards. I suggest you have 3 or 4 cards since it's easy to mess up one and it takes some 10 minutes to reload it.<br />
* micro SD card reader/writer<br />
* Powered USB hub, at least 4 ports. The Black has only one USB so this will allow you to plug in the keyboard, mouse, web cam, etc.<br />
<br />
==== Books ====<br />
* [http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839 Embedded Linux Primer] The bookstore will have this.<br />
* [http://www.morganclaypool.com/doi/abs/10.2200/S00500ED1V01Y201304DCS041 Bad to the Bone] Don't by this yet, I think I can get you a free copy.<br />
<br />
=== What you buy from the Instrument Room ===<br />
* Proto Plate with full sized breadboard<br />
* various input devices, sensors, displays, etc.<br />
<br />
=== What you borrow from the Instrument Room ===<br />
* 5V power supply<br />
* micro HDMI to HDMI adapter. [http://www.monoprice.com/products/product.asp?c_id=104&cp_id=10419&cs_id=1041913&p_id=7703&seq=1&format=2 Monoprice]<br />
* FTDI USB to Serial Adapter. Must be 3.3V version. [https://www.sparkfun.com/products/9717 Sparkfun]<br />
<br />
== Updating the Beagle OS ==<br />
<br />
Once you have all your hardware together go ahead and [http://beagleboard.org/Getting%20Started explore the Bone]. It should work right out of the box. After you have explored a while, update the image on the Bone so you are running the most current image. Go to [[EBC Exercise 03 Installing a Beagle OS]] to learn how to flash your SD card with a fresh OS.<br />
<br />
== The Linux host computer ==<br />
<br />
The above will get you ready for about the first 4 weeks of class. Around week 5 we'll start looking at the kernel and will need to cross compile. Once we start moving into Kernel development we will need a host computer. Since we are doing Linux development, it's generally agree the host should be running Linux. I suggest you run [http://www.ubuntu.com Ubuntu 12.04 (LTS)]. The Rose Linux Users Group [http://lug.rose-hulman.edu/wiki/Main_Page LUG] has instructions on where to get a local copy so you don't have to download some 700M.<br />
<br />
There are three options as to how to run Linux.<br />
# Native install ([http://www.ubuntu.com/download])<br />
# Install in a virtual machine. I've been running [[EBC Exercise 06 Notes on VirtualBox | Virtual Box]] recently and it seems to work find. You can also try [[EBC Exercise 07 Notes on Installing Ubuntu in VMware Player | VMware Player]].<br />
# Run in the cloud<br />
<br />
The Ubuntu site gives good instructions for a native install. I've had good success with running both VMware and Virtual Box, though my installation instructions are a bit dated. (Feel free to update them if they need it.)<br />
<br />
I've been testing out the "Cloud" approach and it looks like it will work too. If you want to try the cloud, let me known and I'll ask CSSE to set up a machine for you.<br />
<br />
=== Kernel Development ===<br />
<br />
Once you have Linux running somewhere, you need to install the kernel development tools. Go to [[EBC Exercise 08 Installing Development Tools]] to see all the steps you need. Once set up, go back to [[EBC Exercise 05 Getting Exercise Support Materials]] to clone the class repository on your host.<br />
<br />
Now that you have all these pieces in place you are ready to work with a very power embedded processor.<br />
<br />
== The class git repository ==<br />
<br />
Once you have an up to date OS running on your Beagle, go to [[EBC Exercise 05 Getting Exercise Support Materials]] to learn how to clone the class git repository. Once cloned it's a single command to get the latest materials on your Beagle (or host computer for that matter).<br />
<br />
{{YoderHead}}</div>Yoderhttp://www.elinux.org/EBC_Exercise_01_Start_HereEBC Exercise 01 Start Here2013-06-11T17:46:47Z<p>Yoder: /* What you buy from the Instrument Room */ Added borrow section</p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
<br />
== Overview ==<br />
<br />
There are four major things that need to be done to have the BeagleBoard ready to run for class:<br />
# Get your Beagle Hardware together<br />
# Update the OS on your Beagle<br />
# Set up a host computer, running Linux for code development<br />
# Clone the course git repository on both the Beagle and the host<br />
<br />
== The Hardware ==<br />
<br />
Here's the hardware you will need and where you get it.<br />
<br />
=== You may have, or will have to buy ===<br />
<br />
We are using the [http://beagleboard.org/Getting%20Started BeagleBone Black] this year. Since it's only $45 I'll have you buy your your own. There's a few other things you will need to get before the first day of class.<br />
* BeagleBone Black. See [http://beagleboard.org/ http://beagleboard.org/] for suggestions of where to buy the Black.<br />
* USB keyboard and mouse<br />
* HDMI display<br />
* At least three 4G micro SD cardz. I suggest you have 3 or 4 cards since it's easy to mess up one and it takes some 10 minutes to reload it.<br />
* micro SD card reader/writer<br />
* Powered USB hub, at least 4 ports. The Black has only one USB so this will allow you to plug in the keyboard, mouse, web cam, etc.<br />
<br />
Books<br />
* [http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839 Embedded Linux Primer] The bookstore will have this.<br />
* [http://www.morganclaypool.com/doi/abs/10.2200/S00500ED1V01Y201304DCS041 Bad to the Bone] Don't by this yet, I think I can get you a free copy.<br />
<br />
=== What you buy from the Instrument Room ===<br />
* Proto Plate with full sized breadboard<br />
* various input devices, sensors, displays, etc.<br />
<br />
=== What you borrow from the Instrument Room ===<br />
* 5V power supply<br />
* micro HDMI to HDMI adapter. [http://www.monoprice.com/products/product.asp?c_id=104&cp_id=10419&cs_id=1041913&p_id=7703&seq=1&format=2 Monoprice]<br />
* FTDI USB to Serial Adapter. Must be 3.3V version. [https://www.sparkfun.com/products/9717 Sparkfun]<br />
<br />
== Updating the Beagle OS ==<br />
<br />
Once you have all your hardware together go ahead and [http://beagleboard.org/Getting%20Started explore the Bone]. It should work right out of the box. After you have explored a while, update the image on the Bone so you are running the most current image. Go to [[EBC Exercise 03 Installing a Beagle OS]] to learn how to flash your SD card with a fresh OS.<br />
<br />
== The Linux host computer ==<br />
<br />
The above will get you ready for about the first 4 weeks of class. Around week 5 we'll start looking at the kernel and will need to cross compile. Once we start moving into Kernel development we will need a host computer. Since we are doing Linux development, it's generally agree the host should be running Linux. I suggest you run [http://www.ubuntu.com Ubuntu 12.04 (LTS)]. The Rose Linux Users Group [http://lug.rose-hulman.edu/wiki/Main_Page LUG] has instructions on where to get a local copy so you don't have to download some 700M.<br />
<br />
There are three options as to how to run Linux.<br />
# Native install ([http://www.ubuntu.com/download])<br />
# Install in a virtual machine. I've been running [[EBC Exercise 06 Notes on VirtualBox | Virtual Box]] recently and it seems to work find. You can also try [[EBC Exercise 07 Notes on Installing Ubuntu in VMware Player | VMware Player]].<br />
# Run in the cloud<br />
<br />
The Ubuntu site gives good instructions for a native install. I've had good success with running both VMware and Virtual Box, though my installation instructions are a bit dated. (Feel free to update them if they need it.)<br />
<br />
I've been testing out the "Cloud" approach and it looks like it will work too. If you want to try the cloud, let me known and I'll ask CSSE to set up a machine for you.<br />
<br />
=== Kernel Development ===<br />
<br />
Once you have Linux running somewhere, you need to install the kernel development tools. Go to [[EBC Exercise 08 Installing Development Tools]] to see all the steps you need. Once set up, go back to [[EBC Exercise 05 Getting Exercise Support Materials]] to clone the class repository on your host.<br />
<br />
Now that you have all these pieces in place you are ready to work with a very power embedded processor.<br />
<br />
== The class git repository ==<br />
<br />
Once you have an up to date OS running on your Beagle, go to [[EBC Exercise 05 Getting Exercise Support Materials]] to learn how to clone the class git repository. Once cloned it's a single command to get the latest materials on your Beagle (or host computer for that matter).<br />
<br />
{{YoderHead}}</div>Yoderhttp://www.elinux.org/BeagleBoard_Education_WorkshopsBeagleBoard Education Workshops2013-06-11T17:44:38Z<p>Yoder: Updated price</p>
<hr />
<div>[[Category:ECE497 |W]]<br />
[[Category:BeagleBoard]]<br />
[[Category:Workshops]]<br />
[[Category:Education]]<br />
{{YoderHead}}<br />
<br />
== 2013 ASEE Workshop ==<br />
{|<br />
| '''Title:''' <br />
| U216·WORKSHOP: BeagleBone - A Hands-on Workshop<br />
|-<br />
| '''Presentors:''' <br />
| Dr. Steven F Barrett P.E., Jason Kridner, Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Atlanta, Omni CNN Center Hotel, Omni - Chestnut<br />
|-<br />
| '''Date:''' <br />
| 23-June-2013<br />
|-<br />
| '''Link'''<br />
| [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE site]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Ticketed event: $25.00 advanced registration and $35.00 on site registration'''<br />
<br />
BeagleBone is a low cost, open hardware computer first introduced in November 2011 by BeagleBoard.org, a community of developers sponsored by Texas Instruments. BeagleBone hosts a powerful 32-bit, super-scalar ARM Cortex A8 processor operating at 720 MHz. Yet it is small enough to fit in an Altoids mint tin box. The "Bone'' may be used in a wide variety of projects from middle school science fair projects to senior design projects to first prototypes of very complex systems. Novice users may access the power of the Bone through the user-friendly Bonescript environment. Seasoned users may take full advantage of the Bone's power using the underlying Linux-based operating system, a host of feature extension boards (Capes) and a wide variety of open source libraries. This hands on workshop provides an introduction to this powerful computer and has been designed for a wide variety of users including the first time novice through the seasoned embedded system design professional. <br />
<br />
Workshop participants will receive a BeagleBone board and also a BeagleBone book courtesy of BeagleBoard.org and Morgan and Claypool Publishers. This workshop is subsidized by Texas Instruments (TI).<br />
<br />
=== Pre Workshop ===<br />
<br />
=== Labs ===<br />
<br />
[[ASEE 2013 Workshop | Afternoon labs]]<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Engibous Summit Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on BeagleBone<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Dallas<br />
|-<br />
| '''Date:''' <br />
| 30-July-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.ti.com/corp/docs/landing/universityprogram/prize.htm Engibous Summit]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
???<br />
<br />
=== Pre Workshop ===<br />
<br />
You will be mailed some information about the workshop and some things for you to do before arriving.<br />
<br />
--Mark<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Chandigarh Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/73-chitkara-school-of-engineering-a-technology Chitkara School of Engineering & Technology] - Chandigarh, India<br />
|-<br />
| '''Date:''' <br />
| 18-20 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Beagleboard is a low-cost open-source embedded system development platform. It is based on Texas Instruments DM3730 processor, which includes an on-chip ARM Cortex-A8 processor core, a Texas Instruments C6x DSP core, and a host of peripherals. Beagleboard is a single board computer, which provides adequate performance to run Linux software, yet has a power consumption lower than 2W. A large number of embedded applications have been developed on Beagleboard ([http://www.beagleboard.org www.beagleboard.org]) Module A provides a gentle introduction to the subject of Embedded Linux, Linux Systems Programming and Linux Kernel Programming. The intention of Module B is to provide a hands-on exposure to running Embedded Linux operating system on the Beagleboard and develop system software on the Beagleboard.<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Hyderabad Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Three-day workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/69-c-dac-hyderabad C-DAC Hyderabad] - Hyderabad, India<br />
|-<br />
| '''Date:''' <br />
| 14-16 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Linux, which is an “open source” operating system and enjoys considerable popularity on general-purpose computers, is becoming popular in the embedded world also. Different versions and variants of Linux are now available on embedded platforms. In this workshop, the intention is to provide a hands-on introduction to concepts of Linux Systems/Kernel Programming and Embedded Linux<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Bangalore Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 6-day modular workshop on Embedded Linux<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/68-cambridge-institute-of-technology Cambridge Institute of Technology] - Bangalore, India<br />
|-<br />
| '''Date:''' <br />
| 11-13 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Module A''' provides an overview of basic concepts of Linux, Linux Systems Programming, Linux Kernel Programming, and Embedded Systems. Module A will also include an introduction to Beagleboard, an open-source, low-cost, low-power embedded system development platform. '''Module A''' will be conducted jointly by a team of experts from industry and academia. In '''Module B''', aspects of Embedded Linux on Beagleboard will be explored in greater depth. Module B will be conducted by Prof. Mark A. Yoder of Rose-Hulman Institute of Technology, USA.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2011 FIE Workshop - Cancelled ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Holiday Inn Salon F, Rapid City, South Dakota<br />
|-<br />
| '''Date:''' <br />
| Wednesday, October 12, 2011, 2:30 p.m. - 5:30 p.m<br />
|-<br />
| '''Link'''<br />
| [http://fie-conference.org/fie2011/] [http://fie-conference.org/fie2011/Pages/workshops.htm#SCRL6]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
The goal of this hands-on tutorial is to present ideas on how to use Texas Instrument’s DM 3730-based BeagleBoard xM ([www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded processing using Open Source resources. The DM 3730 is a dual core processor with an ARM Cortex-a8 core and a TI ‘c64x DSP core. The BeagleBoard is Open Source hardware that has sold over 30,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
<br />
The BeagleBoard has many uses in the classroom. This workshop will show some of those uses and present some of the challenges in teaching with Open Source.<br />
<br />
The workshop activities will include:<br />
<br />
* several hands-on exercises to get participants familiar with using the Beagle, and how it differs from a traditional 8- or 16-bit microcomputer.<br />
* several demonstrations of what the Beagle can do, such as streaming video and programming its DSP and discussions of what topics to include in an embedded/DSP class including dealing with open source comminutes.<br />
* This workshop is targeted to those who are teaching embedded processors or DSP hardware. Some Linux background would be helpful, but not required. Those with little or no Linux experience will be paired with those with more experience.<br />
<br />
=== Post Workshop ===<br />
<br />
Even though the workshop has been cancelled, you can still do the exercises. Here ([[Getting a Workshop SD Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
Here ([[EBC Embedded Beagle Class Topics]]) is a list of topics I cover in my class. If you have questions, please email me.<br />
<br />
== 2011 IEEE ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| How 32-bit Embedded Processors Change the Focus in Teaching DSP Hardware<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Monday May 23rd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/registration]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 20,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
After the introduction, this workshop will complement the Sunday afternoon tutorial “From DSP Chips to Embedded Processors for Teaching Digital Signal Processing”. The Sunday workshop examples focus on programming the ‘C64 DSP on the OMAP3530. This workshop will focus on using Open Source software for media processing (such as GStreamer, OpenCV, etc.) and using the OMAP display subsystem for handling video. <br />
The workshop activities will include:<br />
# Several hands-on exercises to get participants familiar with using the Beagle, (same as tutorial)<br />
# Several demonstrations of what the Beagle can do using Open Source software, including using the display subsystem, recognizing speech, computer vision<br />
# Discussions of what topics to include in an embedded Linux class.<br />
No BeagleBoards will given out.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Monty Hayes<br />
|Georgia Tech, Professor, Atlanta, GA and<br />
Chung-Ang University Distinguished Foreign Professor, Seoul, Korea<br />
|I have no linux experience, have taught courses on DSP chips before<br />
|I would like to develop an undergraduate course using the Beagleboard to teach DSP.<br />
|-<br />
|Oleg Muratov<br />
|University of Trento, Itay<br />
|I am a PhD student and I have limited Linux experience.<br />
|I am planning to give a course to undergraduate students on DSP probably using some hardware.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[VideoThru Lab]]<br />
<br />
=== Post Workshop ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE ICASSP Tutorial ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Sunday May 22nd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/tutorials/tutorial-5]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 16,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. Our students need to see that the days of the single DSP chip are almost over and they need to be prepared for working with DSPs embedded with other processors.<br />
The OMAP3530 processor contains both an ARM Cortex-A9 processor and a ‘C6400 DSP and it and chips like it are being used in products today. <br />
The workshop activities include:<br />
# hands-on exercises to get participants familiar with using the Beagle,<br />
# demonstrations of what the Beagle can do, including streaming video and synthesizing speech and<br />
# discussions of what topics to include in an embedded Linux class.<br />
Participants will receive a BeagleBoard and course materials.<br />
<br />
=== Pre Tutorial ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Matt Gately<br />
|University of Oklahoma, Norman, OK, USA<br />
|I am a PhD student and I use Linux in my research. <br />
|I would love to someday teach a DSP course using embedded systems such as FPGA or microcontroller boards. <br />
<br />
<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[AudioThru Lab]]<br />
<br />
=== Post Tutorial ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE SPEd (Signal Processing Society 14th DSP Workshop & 6th SPEd Workshop) ==<br />
{|<br />
| '''Title:''' <br />
| Moving Beyond the DSP and Teaching 32-bit Embedded Processors Using the BeagleBoard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Enchantment Resort, Sedona, Arizona<br />
|-<br />
| '''Date:''' <br />
| Thursday 6 January, 2011 Time: 14:00 - 17:30<br />
|}<br />
<br />
=== Post Workshop ===<br />
Here are some things you might want to do now that the workshop is over. <br />
<br />
Here are instructions on how to create the SD card that was used in the workshop.<br />
* Go here ([[ECE597_Getting_your_Beagle_running_(precompiled)#From_beagleboard-validation.s3.amazonaws.com]]) to download and install the base image for the Beagle. This will install the kernel and all the files needed to run many of the demos.<br />
* Download [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopFiles.zip this zip file] to get the extra files used in the workshop. Copy it to your BeagleBoard and unzip it there. This file contains the '''VideoThru''', '''c6run_target''', '''hello.c''' and '''helloBeagle.c''' files.<br />
* Download the workshop pptx [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopPPTX.zip here].<br />
<br />
=== Pre Workshop === <br />
If you are an overachiever (not required) go here ([[ECE497 Lab13 Using the DSP via c6run]]) to learn how to install the ARM and DSP development tools on your Linux system (Ubuntu 10.4 LTS is required). If you don't have Ubuntu installed, go [http://processors.wiki.ti.com/index.php/How_to_Build_a_Ubuntu_Linux_host_under_VirtualBox here] to learn how to install it in a virtual machine under windows.<br />
<br />
These installs are not required for the workshop; however editing the the table below ''is''.<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program www.ti.com/university helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
| Steve Chadwick<br />
| Embry-Riddle Aeronautical University, Prescott, AZ <br />
| Very new to DSP and hoping develop sufficient depth to teach it next academic year. <br />
| Interests: Pretty much everything in science. <br />
|-<br />
| Mark Wickert<br />
| University of Colorado, Colorado Springs, CO, USA<br />
| I have played on and off with Linux for about 10 years, never done any real-time DSP under this OS however.<br />
| I regularly teach DSP and related courses. I am using the C6713 today, but ready to move forward. I recently started playing with ARM processors (not the BeagleBoard until now).<br />
|-<br />
| Shane Cotter<br />
| Union College, Schenectady, NY<br />
| I have taught DSP courses. I have used Unix/Linux in the past but not for real-time DSP.<br />
| The Beagleboard seems like a great platform and I'm interested in learning about it and its potential uses in courses.<br />
|-<br />
| Jake Gunther<br />
| Utah State University<br />
| I have taught DSP and communication systems for over ten years.<br />
| I want to move from a simulation-based teaching approach to a real-time approach.<br />
|}<br />
<br />
== 2010 ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 32-bit Embedded Linux-based Signal Processing – Hands on Workshop<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| ICASSP 2010, Dallas, Texas<br />
|-<br />
| '''Date:''' <br />
| Monday, March 15 2010, 13:30 - 17:00<br />
|}<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:20%" | email<br />
! style="width:40%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| [http://www.rose-hulman.edu/~yoder]<br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|David V. Anderson<br />
|Georgia Institute of Technology<br />
|<br />
|Teaching DSP using BeagleBoard as a real-time platform.<br />
|-<br />
|Andres Kwasinski<br />
|Rochester Institute of Technology<br />
|[http://people.rit.edu/axkeec/]<br />
|Teaching DSP to Computer Engineers using real-world platforms.<br />
|-<br />
|Roger West<br />
|Utah State University<br />
|<br />
|Teaching DSP to ECE students using real-time platforms.<br />
|}<br />
<br />
=== Labs ===<br />
Here is a list of the hands on exercises we will be doing in the 2010 workshop. Many have suggestions for additional homework that you can do once you are back home and have a network connection.<br />
<br />
# [[2010 ICASSP Lab 1 Wiring_and_Running the Beagle]]<br />
# [[2010 ICASSP Lab 2 The Boot Sequence]]<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/BeagleBoard_Education_WorkshopsBeagleBoard Education Workshops2013-06-11T17:43:33Z<p>Yoder: /* Labs */</p>
<hr />
<div>[[Category:ECE497 |W]]<br />
[[Category:BeagleBoard]]<br />
[[Category:Workshops]]<br />
[[Category:Education]]<br />
{{YoderHead}}<br />
<br />
== 2013 ASEE Workshop ==<br />
{|<br />
| '''Title:''' <br />
| U216·WORKSHOP: BeagleBone - A Hands-on Workshop<br />
|-<br />
| '''Presentors:''' <br />
| Dr. Steven F Barrett P.E., Jason Kridner, Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Atlanta, Omni CNN Center Hotel, Omni - Chestnut<br />
|-<br />
| '''Date:''' <br />
| 23-June-2013<br />
|-<br />
| '''Link'''<br />
| [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE site]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Ticketed event: $100.00 advanced registration and $110.00 on site registration'''<br />
<br />
BeagleBone is a low cost, open hardware computer first introduced in November 2011 by BeagleBoard.org, a community of developers sponsored by Texas Instruments. BeagleBone hosts a powerful 32-bit, super-scalar ARM Cortex A8 processor operating at 720 MHz. Yet it is small enough to fit in an Altoids mint tin box. The "Bone'' may be used in a wide variety of projects from middle school science fair projects to senior design projects to first prototypes of very complex systems. Novice users may access the power of the Bone through the user-friendly Bonescript environment. Seasoned users may take full advantage of the Bone's power using the underlying Linux-based operating system, a host of feature extension boards (Capes) and a wide variety of open source libraries. This hands on workshop provides an introduction to this powerful computer and has been designed for a wide variety of users including the first time novice through the seasoned embedded system design professional. <br />
<br />
Workshop participants will receive a BeagleBone board and also a BeagleBone book courtesy of BeagleBoard.org and Morgan and Claypool Publishers. This workshop is subsidized by Texas Instruments (TI). <br />
<br />
=== Pre Workshop ===<br />
<br />
=== Labs ===<br />
<br />
[[ASEE 2013 Workshop | Afternoon labs]]<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Engibous Summit Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on BeagleBone<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Dallas<br />
|-<br />
| '''Date:''' <br />
| 30-July-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.ti.com/corp/docs/landing/universityprogram/prize.htm Engibous Summit]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
???<br />
<br />
=== Pre Workshop ===<br />
<br />
You will be mailed some information about the workshop and some things for you to do before arriving.<br />
<br />
--Mark<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Chandigarh Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Hands-on workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/73-chitkara-school-of-engineering-a-technology Chitkara School of Engineering & Technology] - Chandigarh, India<br />
|-<br />
| '''Date:''' <br />
| 18-20 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/128-hands-on-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Beagleboard is a low-cost open-source embedded system development platform. It is based on Texas Instruments DM3730 processor, which includes an on-chip ARM Cortex-A8 processor core, a Texas Instruments C6x DSP core, and a host of peripherals. Beagleboard is a single board computer, which provides adequate performance to run Linux software, yet has a power consumption lower than 2W. A large number of embedded applications have been developed on Beagleboard ([http://www.beagleboard.org www.beagleboard.org]) Module A provides a gentle introduction to the subject of Embedded Linux, Linux Systems Programming and Linux Kernel Programming. The intention of Module B is to provide a hands-on exposure to running Embedded Linux operating system on the Beagleboard and develop system software on the Beagleboard.<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Hyderabad Workshop ==<br />
{|<br />
| '''Title:''' <br />
| Three-day workshop on Embedded Linux on Beagleboard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/69-c-dac-hyderabad C-DAC Hyderabad] - Hyderabad, India<br />
|-<br />
| '''Date:''' <br />
| 14-16 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard http://www.uniti.in/events/details/123-three-day-workshop-on-embedded-linux-on-beagleboard]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
Linux, which is an “open source” operating system and enjoys considerable popularity on general-purpose computers, is becoming popular in the embedded world also. Different versions and variants of Linux are now available on embedded platforms. In this workshop, the intention is to provide a hands-on introduction to concepts of Linux Systems/Kernel Programming and Embedded Linux<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2012 Bangalore Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 6-day modular workshop on Embedded Linux<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| [http://www.uniti.in/events/venueevents/68-cambridge-institute-of-technology Cambridge Institute of Technology] - Bangalore, India<br />
|-<br />
| '''Date:''' <br />
| 11-13 June-2012<br />
|-<br />
| '''Link'''<br />
| [http://www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux www.uniti.in/events/details/122-6-day-modular-workshop-on-embedded-linux]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
'''Module A''' provides an overview of basic concepts of Linux, Linux Systems Programming, Linux Kernel Programming, and Embedded Systems. Module A will also include an introduction to Beagleboard, an open-source, low-cost, low-power embedded system development platform. '''Module A''' will be conducted jointly by a team of experts from industry and academia. In '''Module B''', aspects of Embedded Linux on Beagleboard will be explored in greater depth. Module B will be conducted by Prof. Mark A. Yoder of Rose-Hulman Institute of Technology, USA.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]].<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
=== Post Workshop ===<br />
<br />
== 2011 FIE Workshop - Cancelled ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Holiday Inn Salon F, Rapid City, South Dakota<br />
|-<br />
| '''Date:''' <br />
| Wednesday, October 12, 2011, 2:30 p.m. - 5:30 p.m<br />
|-<br />
| '''Link'''<br />
| [http://fie-conference.org/fie2011/] [http://fie-conference.org/fie2011/Pages/workshops.htm#SCRL6]<br />
|}<br />
<br />
=== Abstract:===<br />
<br />
The goal of this hands-on tutorial is to present ideas on how to use Texas Instrument’s DM 3730-based BeagleBoard xM ([www.BeagleBoard.org www.BeagleBoard.org]) for teaching embedded processing using Open Source resources. The DM 3730 is a dual core processor with an ARM Cortex-a8 core and a TI ‘c64x DSP core. The BeagleBoard is Open Source hardware that has sold over 30,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
<br />
The BeagleBoard has many uses in the classroom. This workshop will show some of those uses and present some of the challenges in teaching with Open Source.<br />
<br />
The workshop activities will include:<br />
<br />
* several hands-on exercises to get participants familiar with using the Beagle, and how it differs from a traditional 8- or 16-bit microcomputer.<br />
* several demonstrations of what the Beagle can do, such as streaming video and programming its DSP and discussions of what topics to include in an embedded/DSP class including dealing with open source comminutes.<br />
* This workshop is targeted to those who are teaching embedded processors or DSP hardware. Some Linux background would be helpful, but not required. Those with little or no Linux experience will be paired with those with more experience.<br />
<br />
=== Post Workshop ===<br />
<br />
Even though the workshop has been cancelled, you can still do the exercises. Here ([[Getting a Workshop SD Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
Here ([[EBC Embedded Beagle Class Topics]]) is a list of topics I cover in my class. If you have questions, please email me.<br />
<br />
== 2011 IEEE ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| How 32-bit Embedded Processors Change the Focus in Teaching DSP Hardware<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Monday May 23rd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/registration]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 20,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
After the introduction, this workshop will complement the Sunday afternoon tutorial “From DSP Chips to Embedded Processors for Teaching Digital Signal Processing”. The Sunday workshop examples focus on programming the ‘C64 DSP on the OMAP3530. This workshop will focus on using Open Source software for media processing (such as GStreamer, OpenCV, etc.) and using the OMAP display subsystem for handling video. <br />
The workshop activities will include:<br />
# Several hands-on exercises to get participants familiar with using the Beagle, (same as tutorial)<br />
# Several demonstrations of what the Beagle can do using Open Source software, including using the display subsystem, recognizing speech, computer vision<br />
# Discussions of what topics to include in an embedded Linux class.<br />
No BeagleBoards will given out.<br />
<br />
=== Pre Workshop ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Monty Hayes<br />
|Georgia Tech, Professor, Atlanta, GA and<br />
Chung-Ang University Distinguished Foreign Professor, Seoul, Korea<br />
|I have no linux experience, have taught courses on DSP chips before<br />
|I would like to develop an undergraduate course using the Beagleboard to teach DSP.<br />
|-<br />
|Oleg Muratov<br />
|University of Trento, Itay<br />
|I am a PhD student and I have limited Linux experience.<br />
|I am planning to give a course to undergraduate students on DSP probably using some hardware.<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[VideoThru Lab]]<br />
<br />
=== Post Workshop ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE ICASSP Tutorial ==<br />
{|<br />
| '''Title:''' <br />
| From DSP Chips to Embedded Processors for Teaching Digital Signal Processing<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Prague, Czech Republic<br />
|-<br />
| '''Date:''' <br />
| Sunday May 22nd, 2011, Afternoon<br />
|-<br />
| '''Link'''<br />
| [http://www.icassp2011.com/en/tutorials/tutorial-5]<br />
|}<br />
<br />
=== Abstract:===<br />
This hands-on tutorial presents ideas on how to use TI’s OMAP 3530-based BeagleBoard (www.BeagleBoard.org) for teaching embedded media processing using Open Source resources. The BeagleBoard is Open Source hardware that has sold over 16,000 units since its introduction less than 2 years ago and has a thriving Open Source Software community.<br />
Today’s media handling embedded processors have come a long way from the limited performance of 8- or 16-bit embedded processors or the limited functionality of a dedicated DSP chip. Our students need to see that the days of the single DSP chip are almost over and they need to be prepared for working with DSPs embedded with other processors.<br />
The OMAP3530 processor contains both an ARM Cortex-A9 processor and a ‘C6400 DSP and it and chips like it are being used in products today. <br />
The workshop activities include:<br />
# hands-on exercises to get participants familiar with using the Beagle,<br />
# demonstrations of what the Beagle can do, including streaming video and synthesizing speech and<br />
# discussions of what topics to include in an embedded Linux class.<br />
Participants will receive a BeagleBoard and course materials.<br />
<br />
=== Pre Tutorial ===<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle [[ECE497 - 32-bit Embedded Linux, Rose-Hulman]]. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program [http://www.ti.com/university www.ti.com/university] helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
|Melani Plett<br />
|Seattle Pacific University,<br />
Seattle, Washington, USA<br />
|I teach an undergraduate signals and systems course. I have no Linux experience, though I did use Unix years ago.<br />
|I am thinking of generating a technical elective follow-on class to illustrate the signals and systems concepts on the Beagleboard.<br />
|-<br />
|Matt Gately<br />
|University of Oklahoma, Norman, OK, USA<br />
|I am a PhD student and I use Linux in my research. <br />
|I would love to someday teach a DSP course using embedded systems such as FPGA or microcontroller boards. <br />
<br />
<br />
|}<br />
<br />
=== Labs ===<br />
<br />
Here's an additional handout that didn't make it in time for the printers.<br />
<br />
[[AudioThru Lab]]<br />
<br />
=== Post Tutorial ===<br />
<br />
Here ([[Getting_a_Workshop_SD_Image]]) are instructions on how to put the tutorial image on your SD card.<br />
<br />
== 2011 IEEE SPEd (Signal Processing Society 14th DSP Workshop & 6th SPEd Workshop) ==<br />
{|<br />
| '''Title:''' <br />
| Moving Beyond the DSP and Teaching 32-bit Embedded Processors Using the BeagleBoard<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| Enchantment Resort, Sedona, Arizona<br />
|-<br />
| '''Date:''' <br />
| Thursday 6 January, 2011 Time: 14:00 - 17:30<br />
|}<br />
<br />
=== Post Workshop ===<br />
Here are some things you might want to do now that the workshop is over. <br />
<br />
Here are instructions on how to create the SD card that was used in the workshop.<br />
* Go here ([[ECE597_Getting_your_Beagle_running_(precompiled)#From_beagleboard-validation.s3.amazonaws.com]]) to download and install the base image for the Beagle. This will install the kernel and all the files needed to run many of the demos.<br />
* Download [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopFiles.zip this zip file] to get the extra files used in the workshop. Copy it to your BeagleBoard and unzip it there. This file contains the '''VideoThru''', '''c6run_target''', '''hello.c''' and '''helloBeagle.c''' files.<br />
* Download the workshop pptx [http://www.rose-hulman.edu/~yoder/Beagle/SPEd2011WorkshopPPTX.zip here].<br />
<br />
=== Pre Workshop === <br />
If you are an overachiever (not required) go here ([[ECE497 Lab13 Using the DSP via c6run]]) to learn how to install the ARM and DSP development tools on your Linux system (Ubuntu 10.4 LTS is required). If you don't have Ubuntu installed, go [http://processors.wiki.ti.com/index.php/How_to_Build_a_Ubuntu_Linux_host_under_VirtualBox here] to learn how to install it in a virtual machine under windows.<br />
<br />
These installs are not required for the workshop; however editing the the table below ''is''.<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list. You will have to create an eLinux account before you can edit the page.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:30%" | Linux/DSP Background<br />
! style="width:30%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| I've been using various flavors of Unix/Linux since the late '70s, but there is always more to learn.<br />
I've taught a 'C6713 based DSP class years ago. <br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|Cathy Wicks<br />
|Texas Instruments, University Program Manager<br />
|I am a HUGE fan of Beagleboard and very interested to develop a community of teachers using it. <br />
|Our Program www.ti.com/university helps academics use TI Hardware, Software and Chips in their projects and curriculum. <br />
|-<br />
| Steve Chadwick<br />
| Embry-Riddle Aeronautical University, Prescott, AZ <br />
| Very new to DSP and hoping develop sufficient depth to teach it next academic year. <br />
| Interests: Pretty much everything in science. <br />
|-<br />
| Mark Wickert<br />
| University of Colorado, Colorado Springs, CO, USA<br />
| I have played on and off with Linux for about 10 years, never done any real-time DSP under this OS however.<br />
| I regularly teach DSP and related courses. I am using the C6713 today, but ready to move forward. I recently started playing with ARM processors (not the BeagleBoard until now).<br />
|-<br />
| Shane Cotter<br />
| Union College, Schenectady, NY<br />
| I have taught DSP courses. I have used Unix/Linux in the past but not for real-time DSP.<br />
| The Beagleboard seems like a great platform and I'm interested in learning about it and its potential uses in courses.<br />
|-<br />
| Jake Gunther<br />
| Utah State University<br />
| I have taught DSP and communication systems for over ten years.<br />
| I want to move from a simulation-based teaching approach to a real-time approach.<br />
|}<br />
<br />
== 2010 ICASSP Workshop ==<br />
{|<br />
| '''Title:''' <br />
| 32-bit Embedded Linux-based Signal Processing – Hands on Workshop<br />
|-<br />
| '''Presentor:''' <br />
| Mark A. Yoder<br />
|-<br />
| '''Location:''' <br />
| ICASSP 2010, Dallas, Texas<br />
|-<br />
| '''Date:''' <br />
| Monday, March 15 2010, 13:30 - 17:00<br />
|}<br />
<br />
The purpose of this page is to give you practice editing a wiki and to start building a community of BeagleBoard Educators. Click on the '''edit''' tab above and add your name to the list.<br />
<br />
--Mark<br />
<br />
{|<br />
! style="width:20%" | Name<br />
! style="width:20%" | School/Company<br />
! style="width:20%" | email<br />
! style="width:40%" | Interests<br />
|-<br />
| Mark A. Yoder<br />
| Rose-Hulman Institute of Technology, <br />
Terre Haute, Indiana, USA<br />
| [http://www.rose-hulman.edu/~yoder]<br />
| I teach 32-bit embedded with the Beagle. DSP is appearing everywhere now. The BeagleBoard is a great environment to teach DSP.<br />
|-<br />
|David V. Anderson<br />
|Georgia Institute of Technology<br />
|<br />
|Teaching DSP using BeagleBoard as a real-time platform.<br />
|-<br />
|Andres Kwasinski<br />
|Rochester Institute of Technology<br />
|[http://people.rit.edu/axkeec/]<br />
|Teaching DSP to Computer Engineers using real-world platforms.<br />
|-<br />
|Roger West<br />
|Utah State University<br />
|<br />
|Teaching DSP to ECE students using real-time platforms.<br />
|}<br />
<br />
=== Labs ===<br />
Here is a list of the hands on exercises we will be doing in the 2010 workshop. Many have suggestions for additional homework that you can do once you are back home and have a network connection.<br />
<br />
# [[2010 ICASSP Lab 1 Wiring_and_Running the Beagle]]<br />
# [[2010 ICASSP Lab 2 The Boot Sequence]]<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-11T13:58:44Z<p>Yoder: /* Analog In */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]<br />
do <br />
tr '\n' '\r' < AIN6<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-11T13:45:31Z<p>Yoder: /* Reading a switch */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano button.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x button.sh''' (This makes button.sh executable)<br />
bone$ '''./button.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. Can you flash the LED? How fast? Make the LED read the switch.<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]; do <br />
tr '\n' '\r' < AIN5<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-11T13:37:17Z<p>Yoder: /* Blinking an External LED via gpio */ Added ls in gpio60</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''ls'''<br />
active_low direction edge power subsystem uevent value<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano flash.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value > gpio60/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x flash.sh''' (This makes flash.sh executable)<br />
bone$ '''./flash.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. How fast can you flash the LED?<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]; do <br />
tr '\n' '\r' < AIN5<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T20:38:22Z<p>Yoder: /* Pulse Width Modulation */ Updated</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano flash.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value > gpio60/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x flash.sh''' (This makes flash.sh executable)<br />
bone$ '''./flash.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. How fast can you flash the LED?<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]; do <br />
tr '\n' '\r' < AIN5<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
(Note: The pwm interface seems to changing. Some of this may not apply in the future.)<br />
<br />
The Bone has a PWM interface at <code>/sys/class/pwm/</code>. You can see what's there by:<br />
<br />
bone$ '''cd /sys/class/pwm'''<br />
bone$ '''ls -F'''<br />
export unexport<br />
Hmmm, there isn't much there. We have to run a command to make something appear. Try<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo am33xx_pwm > $SLOTS'''<br />
bone$ '''ls -F'''<br />
export pwmchip0@ pwmchip2@ pwmchip3@ pwmchip5@ pwmchip7@ unexport<br />
Now we need to run another command to say which pwm pin we want to use. I'm using P9_21.<br />
bone$ '''echo bone_pwm_P9_21 > $SLOTS<br />
Now you can export a pwm much list you export a gpio port<br />
bone$ '''echo 1 > export'''<br />
bone$ '''cd pwm1'''<br />
bone$ '''ls -F'''<br />
device@ duty_ns period_ns polarity power/ run subsystem@ uevent<br />
Try a 1Hz frequency with a 25% duty cycle<br />
bone$ '''echo 1000000000 > period_ns'''<br />
bone$ '''echo 250000000 > duty_ns'''<br />
bone$ '''echo 1 > run'''<br />
<br />
Connect the LED from and watch it flash. Try changing the frequency and duty cycle. You may have to set the duty cycle to 0 to change the frequency. Can you guess why?<br />
<br />
=== Challenge ===<br />
Combine the analog in and the PWM by having the pot control the frequency or the duty cycle of the LED.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T20:27:02Z<p>Yoder: </p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano flash.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value > gpio60/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x flash.sh''' (This makes flash.sh executable)<br />
bone$ '''./flash.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. How fast can you flash the LED?<br />
<br />
== Analog In ==<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:P9PWMs.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
You've already wired these up for the AM lab. You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later I'll explain what you did if you are interested.<br />
<br />
bone$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
bone$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, let's explore.<br />
<br />
bone$ '''cd /sys/devices/ocp.2/helper.14'''<br />
bone$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
bone$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
You can use the following script to continuously read the input.<br />
while [ 1 ]; do <br />
tr '\n' '\r' < AIN5<br />
done<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T19:04:39Z<p>Yoder: /* Reading a switch */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''echo in > direction'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano flash.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value > gpio60/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x flash.sh''' (This makes flash.sh executable)<br />
bone$ '''./flash.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. How fast can you flash the LED?<br />
<br />
== Analog In ==<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T18:39:10Z<p>Yoder: /* Reading a Switch */</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. In the AM lab you wired a switch to P9_42, which from the table above is '''gpio_7'''. <br />
<br />
Based on what you saw above.<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''echo 7 > export'''<br />
bone$ '''cd gpio7'''<br />
bone$ '''ls'''<br />
bone$ '''cat value'''<br />
0<br />
Now hold the button down and try again.<br />
bone$ '''cat value'''<br />
1<br />
Once you have the switch and LED working use '''nano''' and put the following in a file.<br />
bone$ '''nano flash.sh'''<br />
#!/bin/bash<br />
cd /sys/class/gpio<br />
while [ 1 ]<br />
do<br />
cat gpio7/value > gpio60/value<br />
sleep 0.25<br />
done<br />
Quit nano and run<br />
bone$ '''chmod +x flash.sh''' (This makes flash.sh executable)<br />
bone$ '''./flash.sh'''<br />
What happens when you push the button?<br />
<br />
Now experiment around. How fast can you flash the LED?<br />
<br />
== Analog In ==<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T18:29:55Z<p>Yoder: /* Blinking an LED */ Initial page</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
=== Blinking a USR LED ===<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
=== Blinking an External LED via gpio ===<br />
<br />
In the AM lab we wired an LED to the P9_12 General Purpose IO (gpio) port and controlled it via BoneScript. Here we'll control it via a shell command. First we need to figure out which gpio pin P9_12 is attached to. The following figure shows it attached to gpio_60.<br />
<br />
[[File:P9PWMs.jpg | 600px]]<br />
<br />
Here's how you turn it on<br />
<br />
bone$ '''cd /sys/class/gpio'''<br />
bone$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
bone$ '''echo 60 > export'''<br />
bone$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
bone$ '''cd gpio60'''<br />
bone$ '''echo out > direction'''<br />
bone$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
bone$ '''cd ..'''<br />
bone$ '''echo 60 > unexport'''<br />
<br />
== Reading a Switch ==<br />
<br />
== Analog In ==<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/File:P9PWMs.jpgFile:P9PWMs.jpg2013-06-10T18:19:49Z<p>Yoder: </p>
<hr />
<div></div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T18:09:37Z<p>Yoder: /* Blinking an LED */ Initial page</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
=== gpio via the Shell Command Line and sysfs ===<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this:<br />
bone$ '''cd /sys'''<br />
bone$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. <br />
<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
bone$ '''cd /sys/class/leds'''<br />
bone$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
bone$ '''cd beagleboard\:\:usr0'''<br />
bone$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
bone$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
bone$ '''echo none > trigger'''<br />
bone$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
bone$ '''echo 1 > brightness'''<br />
bone$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
bone$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
bone$ '''echo timer > trigger'''<br />
bone$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
bone$ '''echo 100 > delay_on'''<br />
bone$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
== Reading a Switch ==<br />
<br />
== Analog In ==<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T18:03:33Z<p>Yoder: /* Warm Up */ Initial page</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
At this point you need to learn a few simple Linux commands for creating and displaying files. Once you know these commands it's easy to turn an LED on and off.<br />
<br />
First, let's edit a file using the '''nano''' editor. Nano is a simple editor that easy to learn. This will edit (and create) the file '''play'''.<br />
<br />
bone$ '''nano play'''<br />
<br />
Add a couple of lines of text to the file, it doesn't really matter what and then Exit. You can list the files in the current directory with '''ls''' and show the contents of a file with '''cat'''.<br />
bone$ '''ls'''<br />
Desktop play<br />
bone$ '''cat play'''<br />
A couple of lines<br />
of text.<br />
<br />
Use '''echo''' to print a line of text.<br />
bone$ '''echo This is a line of text'''<br />
This is a line of text<br />
<br />
Here's a powerful operator. You can take the output of any command and redirect it to a file with '''>'''.<br />
<br />
bone$ '''echo This is a line of text > here'''<br />
bone$ '''cat here'''<br />
This is a line of text<br />
<br />
We are almost there. Use '''cd''' to change directories. '''/''' is the top level directory.<br />
bone$ '''cd /'''<br />
bone$ '''ls'''<br />
bin dev home lost+found mnt run sys usr<br />
boot etc lib media proc sbin tmp var<br />
<br />
If you ever get lost, '''cd''' alone takes you home.<br />
bone$ '''cd'''<br />
gone$ '''ls'''<br />
Desktop here play<br />
<br />
Now you are ready to flash an LED.<br />
<br />
== Blinking an LED ==<br />
<br />
== Reading a Switch ==<br />
<br />
== Analog In ==<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ASEE_2013_WorkshopASEE 2013 Workshop2013-06-10T17:48:32Z<p>Yoder: Initial Page</p>
<hr />
<div>[[Category:ECE497 |Workshop]]<br />
{{YoderHead}}<br />
Here are the labs for the afternoon Linux part of the [http://www.asee.org/public/conferences/20/registration/view_session?session_id=2420 ASEE 2013 Workshop]<br />
<br />
== Warm Up ==<br />
[[File:PuTTYconfiguration.jpg|thumbnail]]<br />
Before we can interact with LEDs and switches we need to learn some simple Linux commands. <br />
# On your host computer, running Windows, start up '''puTTY'''. <br />
# If you get a ''Security Warning'', click '''Run'''.<br />
# Enter '''192.167.7.2''' in the '''Host Name''' field and click '''Open'''<br />
# Login as '''root''' with no password.<br />
# Enter '''ls''' to list what files you have. You shouldn't see much.<br />
[[File:PuTTYloging.jpg|thumbnail]]<br />
<br />
<br />
== Blinking an LED ==<br />
<br />
== Reading a Switch ==<br />
<br />
== Analog In ==<br />
<br />
== Pulse Width Modulation ==<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/File:PuTTYloging.jpgFile:PuTTYloging.jpg2013-06-10T17:35:29Z<p>Yoder: </p>
<hr />
<div></div>Yoderhttp://www.elinux.org/File:PuTTYconfiguration.jpgFile:PuTTYconfiguration.jpg2013-06-10T17:22:14Z<p>Yoder: </p>
<hr />
<div></div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-07T18:31:22Z<p>Yoder: /* Installation Instructions 3.8 Kernel */ Updated to use setup.sh</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.8}}<br />
All of these instructions are meant for the BeagleBone running version 3.8 of the kernel with device tree. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/linux-dev/KERNEL</code><br />
<br />
Start by updating the course materials. ([[EBC Exercise 05 Getting Exercise Support Materials]])<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/exercises/LEDstring/driver'''<br />
host$ '''git pull'''<br />
host$ '''./patch.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the file <code>lpd8806.c</code> into the <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code> directory, make the kernel, and then scp the files to the bone. (Look in the Makefile and update the address for you Beagle.)<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd exercises/LEDstring'''<br />
bone$ '''git pull'''<br />
bone$ '''./setup.sh'''<br />
<br />
This will make the correct device tree overlay to set the pin muxxes for spi0 and insert the kernel module. You only have to do this once per booting the beagle.<br />
<br />
Now test it with<br />
bone$ '''make tree'''<br />
bone$ '''./tree 3 60000 20000'''<br />
<br />
This will display a sequence of LEDs running up and down the string.<br />
<br />
== User Instructions 3.2 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== User Instructions 3.8 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find a folder inside <code>/sys/firmware</code> called <code>lpd8806</code>.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 18 (D12/SPI0_D1) and 22 (A13/SPI0_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:HeaderP9.jpg|800px]]<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127 0" > rgb'''<br />
<br />
You should see LED '''0''' (closest to the bone) light up bright white. You can also do something like the following to turn LED ''x'' red.<br />
<br />
bone$ '''echo "127 0 0 ''x''" > rgb'''<br />
<br />
The driver keeps an internal state of the string and shifts it out to update the string. (The shifting is so fast you won't see it.) You can see the state of the string with:<br />
<br />
bone$ '''cat data'''<br />
<br />
You can change the internal state without updating the string by suppressing the 'return' on the echo.<br />
<br />
bone$ '''echo -n 0 50 0 10 > rgb"<br />
<br />
=== References ===<br />
* [http://hipstercircuits.com/enable-spi-with-device-tree-on-beaglebone-black-copy-paste/ Enable SPI with device tree on BeagleBone Black] shows how to set the pin muxing for SPI1.<br />
* [http://blog.inbedded.net/blog/categories/device-tree/ BeagleBone Black and LCD = fun] showed how to set the pin mux for SPI0.<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/EBC_Exercise_01_Start_HereEBC Exercise 01 Start Here2013-06-07T18:27:46Z<p>Yoder: Added links to where to get items</p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
<br />
== Overview ==<br />
<br />
There are four major things that need to be done to have the BeagleBoard ready to run for class:<br />
# Get your Beagle Hardware together<br />
# Update the OS on your Beagle<br />
# Set up a host computer, running Linux for code development<br />
# Clone the course git repository on both the Beagle and the host<br />
<br />
== The Hardware ==<br />
<br />
Here's the hardware you will need and where you get it.<br />
<br />
=== You may have, or will have to buy ===<br />
<br />
We are using the [http://beagleboard.org/Getting%20Started BeagleBone Black] this year. Since it's only $45 I'll have you buy your your own. There's a few other things you will need to get before the first day of class.<br />
* BeagleBone Black. See [http://beagleboard.org/ http://beagleboard.org/] for suggestions of where to buy the Black.<br />
* USB keyboard and mouse<br />
* HDMI display<br />
* At least three 4G micro SD cardz. I suggest you have 3 or 4 cards since it's easy to mess up one and it takes some 10 minutes to reload it.<br />
* micro SD card reader/writer<br />
* Powered USB hub, at least 4 ports. The Black has only one USB so this will allow you to plug in the keyboard, mouse, web cam, etc.<br />
<br />
Books<br />
* [http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839 Embedded Linux Primer] The bookstore will have this.<br />
* [http://www.morganclaypool.com/doi/abs/10.2200/S00500ED1V01Y201304DCS041 Bad to the Bone] Don't by this yet, I think I can get you a free copy.<br />
<br />
=== What you buy from the Instrument Room ===<br />
<br />
* 5V power supply<br />
* micro HDMI to HDMI adapter. [http://www.monoprice.com/products/product.asp?c_id=104&cp_id=10419&cs_id=1041913&p_id=7703&seq=1&format=2 Monoprice]<br />
* FTDI USB to Serial Adapter. Must be 3.3V version. [https://www.sparkfun.com/products/9717 Sparkfun]<br />
* Proto Plate with full sized breadboard<br />
* various input devices, sensors, displays, etc.<br />
<br />
== Updating the Beagle OS ==<br />
<br />
Once you have all your hardware together go ahead and [http://beagleboard.org/Getting%20Started explore the Bone]. It should work right out of the box. After you have explored a while, update the image on the Bone so you are running the most current image. Go to [[EBC Exercise 03 Installing a Beagle OS]] to learn how to flash your SD card with a fresh OS.<br />
<br />
== The Linux host computer ==<br />
<br />
The above will get you ready for about the first 4 weeks of class. Around week 5 we'll start looking at the kernel and will need to cross compile. Once we start moving into Kernel development we will need a host computer. Since we are doing Linux development, it's generally agree the host should be running Linux. I suggest you run [http://www.ubuntu.com Ubuntu 12.04 (LTS)]. The Rose Linux Users Group [http://lug.rose-hulman.edu/wiki/Main_Page LUG] has instructions on where to get a local copy so you don't have to download some 700M.<br />
<br />
There are three options as to how to run Linux.<br />
# Native install ([http://www.ubuntu.com/download])<br />
# Install in a virtual machine. I've been running [[EBC Exercise 06 Notes on VirtualBox | Virtual Box]] recently and it seems to work find. You can also try [[EBC Exercise 07 Notes on Installing Ubuntu in VMware Player | VMware Player]].<br />
# Run in the cloud<br />
<br />
The Ubuntu site gives good instructions for a native install. I've had good success with running both VMware and Virtual Box, though my installation instructions are a bit dated. (Feel free to update them if they need it.)<br />
<br />
I've been testing out the "Cloud" approach and it looks like it will work too. If you want to try the cloud, let me known and I'll ask CSSE to set up a machine for you.<br />
<br />
=== Kernel Development ===<br />
<br />
Once you have Linux running somewhere, you need to install the kernel development tools. Go to [[EBC Exercise 08 Installing Development Tools]] to see all the steps you need. Once set up, go back to [[EBC Exercise 05 Getting Exercise Support Materials]] to clone the class repository on your host.<br />
<br />
Now that you have all these pieces in place you are ready to work with a very power embedded processor.<br />
<br />
== The class git repository ==<br />
<br />
Once you have an up to date OS running on your Beagle, go to [[EBC Exercise 05 Getting Exercise Support Materials]] to learn how to clone the class git repository. Once cloned it's a single command to get the latest materials on your Beagle (or host computer for that matter).<br />
<br />
{{YoderHead}}</div>Yoderhttp://www.elinux.org/EBC_Exercise_01_Start_HereEBC Exercise 01 Start Here2013-06-07T18:03:25Z<p>Yoder: Added micro HDMI adapter and FTDI USB to Serial Adaptoer</p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
<br />
== Overview ==<br />
<br />
There are four major things that need to be done to have the BeagleBoard ready to run for class:<br />
# Get your Beagle Hardware together<br />
# Update the OS on your Beagle<br />
# Set up a host computer, running Linux for code development<br />
# Clone the course git repository on both the Beagle and the host<br />
<br />
== The Hardware ==<br />
<br />
Here's the hardware you will need and where you get it.<br />
<br />
=== You may have, or will have to buy ===<br />
<br />
We are using the [http://beagleboard.org/Getting%20Started BeagleBone Black] this year. Since it's only $45 I'll have you buy your your own. There's a few other things you will need to get before the first day of class.<br />
* BeagleBone Black. See [http://beagleboard.org/ http://beagleboard.org/] for suggestions of where to buy the Black.<br />
* USB keyboard and mouse<br />
* HDMI display<br />
* At least three 4G micro SD cardz. I suggest you have 3 or 4 cards since it's easy to mess up one and it takes some 10 minutes to reload it.<br />
* micro SD card reader/writer<br />
* Powered USB hub, at least 4 ports. The Black has only one USB so this will allow you to plug in the keyboard, mouse, web cam, etc.<br />
<br />
Books<br />
* [http://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839 Embedded Linux Primer] The bookstore will have this.<br />
* [http://www.morganclaypool.com/doi/abs/10.2200/S00500ED1V01Y201304DCS041 Bad to the Bone] Don't by this yet, I think I can get you a free copy.<br />
<br />
=== What you buy from the Instrument Room ===<br />
<br />
* 5V power supply<br />
* micro HDMI to HDMI adapter<br />
* FTDI USB to Serial Adapter. Must be 3.3V version<br />
* Proto Plate with full sized breadboard<br />
* various input devices, sensors, displays, etc.<br />
<br />
== Updating the Beagle OS ==<br />
<br />
Once you have all your hardware together go ahead and [http://beagleboard.org/Getting%20Started explore the Bone]. It should work right out of the box. After you have explored a while, update the image on the Bone so you are running the most current image. Go to [[EBC Exercise 03 Installing a Beagle OS]] to learn how to flash your SD card with a fresh OS.<br />
<br />
== The Linux host computer ==<br />
<br />
The above will get you ready for about the first 4 weeks of class. Around week 5 we'll start looking at the kernel and will need to cross compile. Once we start moving into Kernel development we will need a host computer. Since we are doing Linux development, it's generally agree the host should be running Linux. I suggest you run [http://www.ubuntu.com Ubuntu 12.04 (LTS)]. The Rose Linux Users Group [http://lug.rose-hulman.edu/wiki/Main_Page LUG] has instructions on where to get a local copy so you don't have to download some 700M.<br />
<br />
There are three options as to how to run Linux.<br />
# Native install ([http://www.ubuntu.com/download])<br />
# Install in a virtual machine. I've been running [[EBC Exercise 06 Notes on VirtualBox | Virtual Box]] recently and it seems to work find. You can also try [[EBC Exercise 07 Notes on Installing Ubuntu in VMware Player | VMware Player]].<br />
# Run in the cloud<br />
<br />
The Ubuntu site gives good instructions for a native install. I've had good success with running both VMware and Virtual Box, though my installation instructions are a bit dated. (Feel free to update them if they need it.)<br />
<br />
I've been testing out the "Cloud" approach and it looks like it will work too. If you want to try the cloud, let me known and I'll ask CSSE to set up a machine for you.<br />
<br />
=== Kernel Development ===<br />
<br />
Once you have Linux running somewhere, you need to install the kernel development tools. Go to [[EBC Exercise 08 Installing Development Tools]] to see all the steps you need. Once set up, go back to [[EBC Exercise 05 Getting Exercise Support Materials]] to clone the class repository on your host.<br />
<br />
Now that you have all these pieces in place you are ready to work with a very power embedded processor.<br />
<br />
== The class git repository ==<br />
<br />
Once you have an up to date OS running on your Beagle, go to [[EBC Exercise 05 Getting Exercise Support Materials]] to learn how to clone the class git repository. Once cloned it's a single command to get the latest materials on your Beagle (or host computer for that matter).<br />
<br />
{{YoderHead}}</div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-07T17:21:39Z<p>Yoder: Switched setup.sh to patch.sh</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.8}}<br />
All of these instructions are meant for the BeagleBone running version 3.8 of the kernel with device tree. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/linux-dev/KERNEL</code><br />
<br />
Start by updating the course materials. ([[EBC Exercise 05 Getting Exercise Support Materials]])<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/exercises/LEDstring/driver'''<br />
host$ '''git pull'''<br />
host$ '''./patch.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the file <code>lpd8806.c</code> into the <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code> directory, make the kernel, and then scp the files to the bone. (Look in the Makefile and update the address for you Beagle.)<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd exercises/LEDstring/driver'''<br />
bone$ '''git pull'''<br />
bone$ '''make dt'''<br />
<br />
This will make the correct device tree overlay to set the pin muxxes for spi0. You only have to do this once per booting the beagle. Next:<br />
<br />
bone$ '''cd /lib/modules/3.8.13''' (or whatever path is correct for you system.)<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/lpd8806.ko:</code> (This didn't work for me.)<br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''cd /lib/modules/3.8.13-bone19/kernel/drivers/char/'''<br />
bone$ '''insmod lpd8806'''<br />
<br />
Now test it with<br />
bone$ '''cd ~/exercises/LEDstring'''<br />
bone$ '''make tree'''<br />
bone$ '''./tree 3 60000 20000'''<br />
<br />
This will display a sequence of LEDs running up and down the string.<br />
<br />
== User Instructions 3.2 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== User Instructions 3.8 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find a folder inside <code>/sys/firmware</code> called <code>lpd8806</code>.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 18 (D12/SPI0_D1) and 22 (A13/SPI0_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:HeaderP9.jpg|800px]]<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127 0" > rgb'''<br />
<br />
You should see LED '''0''' (closest to the bone) light up bright white. You can also do something like the following to turn LED ''x'' red.<br />
<br />
bone$ '''echo "127 0 0 ''x''" > rgb'''<br />
<br />
The driver keeps an internal state of the string and shifts it out to update the string. (The shifting is so fast you won't see it.) You can see the state of the string with:<br />
<br />
bone$ '''cat data'''<br />
<br />
You can change the internal state without updating the string by suppressing the 'return' on the echo.<br />
<br />
bone$ '''echo -n 0 50 0 10 > rgb"<br />
<br />
=== References ===<br />
* [http://hipstercircuits.com/enable-spi-with-device-tree-on-beaglebone-black-copy-paste/ Enable SPI with device tree on BeagleBone Black] shows how to set the pin muxing for SPI1.<br />
* [http://blog.inbedded.net/blog/categories/device-tree/ BeagleBone Black and LCD = fun] showed how to set the pin mux for SPI0.<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/EBC_Exercise_10a_Analog_InEBC Exercise 10a Analog In2013-06-06T19:14:03Z<p>Yoder: /* Analog in */</p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
== Analog in ==<br />
{{EBC3.8}}This page is for the Bone (Black or White) running the 3.8 Kernel. See [[EBC_Exercise_10_Flashing_an_LED_-_xM_WhiteBone]] for the White Bone or xM running 3.2.<br />
<br />
(This is based on [https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/AIN/beagleboard/-ClhIXxtOds/rranYdwhS88J BeagleBone Black Analog Input].)<br />
<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 below. How many do you find?<br />
<br />
[[File:HeaderP9.jpg|800px]]<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
The photo below shows a small potentiometer wired to the bone. One end goes to the analog ground (pin 34), the other analog 1.8V (pin 32). The wiper is attached to '''AIN5''' which is pin 36.<br />
<br />
[[File:Bone gpio.JPG|300px]]<br />
[[File:BoneGPIO.png|300px]]<br />
<br />
You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later we'll explain what you did.<br />
<br />
beagle$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
beagle$ '''PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins'''<br />
beagle$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, but where do they appear. Try using the '''find''' command.<br />
<br />
beagle$ '''find /sys -name "*AIN"'''<br />
./devices/ocp.2/helper.14/AIN0<br />
./devices/ocp.2/helper.14/AIN1<br />
./devices/ocp.2/helper.14/AIN2<br />
./devices/ocp.2/helper.14/AIN3<br />
./devices/ocp.2/helper.14/AIN4<br />
./devices/ocp.2/helper.14/AIN5<br />
./devices/ocp.2/helper.14/AIN6<br />
./devices/ocp.2/helper.14/AIN7<br />
<br />
You paths may be slightly different. Now explore.<br />
<br />
beagle$ '''cd /sys/devices/ocp.2/helper.14'''<br />
beagle$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
beagle$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
=== Challenge ===<br />
Rewrite the scripts from before to read an AIN pin and continuously display it's value.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/EBC_Exercise_10_Flashing_an_LEDEBC Exercise 10 Flashing an LED2013-06-06T19:09:12Z<p>Yoder: /* Analog in */ Moved to it's own page</p>
<hr />
<div>[[Category:EmbeddedBeagleClass]]<br />
[[Category:ECE497]]<br />
{{YoderHead}}<br />
{{EBC3.8}}This page is for the Bone (Black or White) running the 3.8 Kernel. See [[EBC_Exercise_10_Flashing_an_LED_-_xM_WhiteBone]] for the White Bone or xM running 3.2.<br />
<br />
The [http://en.wikipedia.org/wiki/Hello_world_program "Hello World"] program is the traditional first program for many classes. Flashing an LED is the embedded equivalent. Here we will explore a few ways to flash and LED on the Beagle and explore General Purpose I/O (gpio) along the way. These calls will be done from the command line of the Beagle, so there is no need for the host computer.<br />
<br />
== gpio via the Shell Command Line and sysfs ==<br />
<br />
('''Note''': Draw the new diagrams with [http://engineersofthecorn.blogspot.com/2012/06/fritzing-part-for-beaglebone.html this].)<br />
<br />
The easiest way to do general purpose I/O (gpio) on the Beagle is through a terminal window and a shell prompt. In Linux, almost everything is treated as a file, even things that aren't files. In our class we'll use a virtual file system called '''sysfs'''. sysfs exposes the drivers for the hardware so you get easily use them.<br />
<br />
Try this, open a terminal and type:<br />
<br />
beagle$ '''cd /sys'''<br />
beagle$ '''ls -F'''<br />
block/ bus/ class/ dev/ devices/ firmware/ fs/ kernel/ module/ power/<br />
<br />
Here we see several directories that represent hardware we can control. Explore a bit and see what you find.<br />
<br />
Now try:<br />
<br />
beagle$ '''cd /sys/class'''<br />
beagle$ '''ls -F'''<br />
backlight/ firmware/ lcd/ mtd/ scsi_disk/ ubi/<br />
bdi/ gpio/ leds/ net/ scsi_host/ udc/<br />
block/ graphics/ mbox/ power_supply/ sound/ uio/<br />
bluetooth/ hwmon/ mdio_bus/ regulator/ spi_master/ usbmon/<br />
bsg/ i2c-adapter/ mem/ rfkill/ spidev/ vc/<br />
dma/ i2c-dev/ misc/ rtc/ thermal/ vtconsole/<br />
drm/ input/ mmc_host/ scsi_device/ tty/ watchdog/<br />
<br />
Explore some. What do you find? In '''graphics''' you will see the frame buffer supported by the processor. In '''sound''' you'll see the [http://www.alsa-project.org/main/index.php/Main_Page alsa] sound devices.<br />
<br />
== Flashing the user LEDs ==<br />
<br />
The Beagle Black has four user LEDS, '''user0''' - '''user3''', that you can control. Try this:<br />
<br />
beagle$ '''cd /sys/class/leds'''<br />
beagle$ '''ls -F'''<br />
beaglebone:green:usr0 beaglebone:green:usr2<br />
beaglebone:green:usr1 beaglebone:green:usr3<br />
<br />
Here you see the directories for controlling each of the usr LEDs. By default, usr0 flashes a heartbeat pattern and usr1 flashes when the micro SD card is accessed. Let's control usr0.<br />
<br />
beagle$ '''cd beagleboard\:\:usr0'''<br />
beagle$ '''ls -F'''<br />
brightness device@ max_brightness power/ subsystem@ trigger uevent<br />
<br />
See what's in '''brightness''', '''max_brightness''' and '''trigger''' by using the <code>cat</code> command. For example:<br />
<br />
beagle$ '''cat trigger'''<br />
none nand-disk mmc0 timer oneshot [heartbeat] backlight gpio cpu0 default-on transient<br />
<br />
This shows trigger can have many values. The present value is '''heartbeat'''. Check the LED, is it beating? You can stop the heartbeat via:<br />
<br />
beagle$ '''echo none > trigger'''<br />
beagle$ '''cat trigger'''<br />
[none] nand-disk mmc0 timer oneshot heartbeat backlight gpio cpu0 default-on transient <br />
<br />
Did it stop beating? You can now turn it on and off with:<br />
<br />
beagle$ '''echo 1 > brightness'''<br />
beagle$ '''echo 0 > brightness'''<br />
<br />
Is it responding correctly?<br />
<br />
The Bone has more trigger options. Try:<br />
<br />
beagle$ '''cat trigger'''<br />
[none] mmc0 timer heartbeat backlight gpio default-on <br />
beagle$ '''echo timer > trigger'''<br />
beagle$ '''ls -F'''<br />
brightness delay_on max_brightness subsystem@ uevent<br />
delay_off device@ power/ trigger<br />
beagle$ '''echo 100 > delay_on'''<br />
beagle$ '''echo 900 > delay_off'''<br />
<br />
What does this do?<br />
<br />
== Adding your own LED ==<br />
<br />
It's not hard to use the gpio pins to control your own LED. All you need is an LED and a 220&Omega; resistor. Here's a picture of how it's wired. We are just doing the LED at the top of the breadboard for now.<br />
<br />
[[File:Bone gpio.JPG|300px]]<br />
[[File:BoneGPIO.png|300px]]<br />
<br />
So how do you know where to connect it? The BeagleBone [https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true System Reference Manual] has the details. Figure 45 on page 74 shows:<br />
<br />
[[File:BlackHeaders.jpg]]<br />
<br />
There at two expansion headers, P8 and P9. Look at the bottom of the left header and you'll see it's labeled '''P9'''. Table 11 on page 78 shows the pinout for P9.<br />
<br />
[[File:HeaderP9.jpg|800px]]<br />
<br />
On the first photo above you can see that pin 1 (Ground) is wired to the '''-''' bus and pin 3 (3.3V) is wired to the '''+''' bus. The 220&Omega; resistor is wired to the '''-''' bus and the other end is attached to the negative lead of the LED. The positive lead is attached to pin 12 which, as shown in Table 11, is attached to '''gpio1_28'''. The gpio pins are in banks of 32 each, so to find the gpio number to use on the Beagle, use 1*32+28='''60'''. Here's how you turn it on<br />
<br />
beagle$ '''cd /sys/class/gpio'''<br />
beagle$ '''ls -F'''<br />
export gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Presently no gpio pins are visible. You need to tell it which pin to export<br />
<br />
beagle$ '''echo 60 > export'''<br />
beagle$ '''ls -F'''<br />
export gpio60@ gpiochip0@ gpiochip32@ gpiochip64@ gpiochip96@ unexport<br />
<br />
Notice '''gpio60''' has appeared. All we need to do is tell it which direction and then turn it on.<br />
<br />
beagle$ '''cd gpio60'''<br />
beagle$ '''echo out > direction'''<br />
beagle$ '''echo 1 > value'''<br />
<br />
Your LED should be on! When you are done you can unexport the pin and it will disappear.<br />
beagle$ '''cd ..'''<br />
beagle$ '''echo 60 > unexport'''<br />
<br />
== Reading a switch ==<br />
<br />
Now that you have an LED working, wiring in a switch is easy. The picture above shows a push button switch wired in at the bottom of the P9 header. Attach the '''+''' bus to one pole on the switch with a wire. The other end of the switch is attached to pin 42 which is '''gpio0_7'''. <br />
<br />
Based on what you saw above, show how to read the switch.<br />
<br />
Once you have the switch and LED working you can use the following scripts to play with them.<br />
<br />
beagle$ '''cd ~/exercises/gpio'''<br />
beagle$ '''./togglegpio.sh 60 0.1'''<br />
<br />
The LED should be blinking on and off.<br />
<br />
beagle$ '''./readgpio.sh 7'''<br />
<br />
Push the pushbutton and see what happens.<br />
<br />
How can this work without a pulldown resistor? It turns out the Bone has an internal pulldown (and up) resistor that can be software enabled. We'll discuss how when we cover device trees.<br />
<br />
=== Challenge ===<br />
<br />
* Can you modify the scripts above to read the switch and turn the LED on and off?<br />
<br />
== Assignment: gpio from the shell ==<br />
<br />
=== <span style="color:green;">Measuring a gpio pin on an Oscilloscope</span> ===<br />
<br />
Get an oscilloscope so you can measure the output of your gpio pins. Run<br />
beagle$ '''./togglegpio.sh 60 0.1'''<br />
<br />
and answer the following questions about gpio measurements.<br />
<br />
# What's the min and max voltage? <br />
# What period is it? <br />
# How close is it to 100ms? <br />
# Why do they differ?<br />
# Run '''htop''' and see how much processor you are using.<br />
# Try different values for the sleep time (2nd argument). What's the shortest period you can get? Make a table of the values you try and the corresponding period and processor usage.<br />
# How stable is the period? <br />
# Try launching something like '''mplayer'''. How stable is the period?<br />
# Try cleaning up togglegpio.sh and removing unneeded lines. Does it impact the period?<br />
# togglegpio uses bash (first line in file). Try using sh. Is the period shorter?<br />
# What's the shortest period you can get?<br />
<br />
=== Toggling the LEDs ===<br />
<br />
Modify togglegpio.sh (call it toggleLED) to toggle the on-board LEDs. Can you get the LED to appear to dim by changing the duty cycle of the toggling?<br />
<br />
=== Count the User Button Presses ===<br />
<br />
Write a shell script that displays a count of the number of times the Button has been pressed.<br />
<br />
=== Copy gpio 7 to gpio 60===<br />
<br />
Write a shell script that copies the value of gpio pin 7 (your switch) to gpio pin 60 (Your LED). How much CPU time does it take? What's the delay from the time the input changes until the output changes? How constant is the delay?<br />
<br />
You may need to get a function generator and set it to a square wave (0 to 3.3V) and attach it to pin 7 and attached an oscilloscope to pin 60.<br />
<br />
== Resources ==<br />
<br />
# [http://wh1t3s.com/2009/05/14/reading-beagleboard-gpio/ Here] is wh1ts article on flashing an LED. It is referenced in the '''readgpio''' file that comes on the Beagle.<br />
# [http://blog.makezine.com/archive/2009/02/blinking-leds-with-the-beagle-board.html?CMP=OTC-0D6B48984890 This] Make magazine article has a few more details.<br />
# [http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/GPIO#Getting_access_to_a_GPIO Here] in a gpio reference for Linux in general. It includes sample 'C' code for flashing at 1 Hz.<br />
# [https://groups.google.com/forum/?hl=en#!msg/beagleboard/20rM-r8C2YY/hVZiN2ahI8YJ Here] is a posting in the Beagle Google group about gpio.<br />
# [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/gpio.txt;h=36af58eba136bac198ea3b1f33f34236be9ce5df;hb=HEAD Here] is some information about gpio from the kernel point of view.<br />
# [http://wiki.gumstix.org/index.php?title=GPIO_Event_Driver Here] is some info on a GPIO Event Driver<br />
# [https://www.ridgerun.com/developer/wiki/index.php/How_to_use_GPIO_signals Here] is info on how to set '''edge''' to falling and poll() the pin.<br />
# [http://www.kernel.org/doc/Documentation/gpio.txt Here] is the kernel Documentation on gpio.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/EBC_Exercise_10a_Analog_InEBC Exercise 10a Analog In2013-06-06T19:08:40Z<p>Yoder: Initial Page</p>
<hr />
<div>[[Category:ECE497]]<br />
{{YoderHead}}<br />
== Analog in ==<br />
<br />
(This is based on [https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/AIN/beagleboard/-ClhIXxtOds/rranYdwhS88J this].)<br />
<br />
The bone has eight Analog Inputs. Several are exposed on P9. They are labeled '''AIN''' in table 11 above. How many do you find?<br />
<br />
The AIN pins are sampled at 12 bits and 100k samples per second. The input voltage is between 0 and 1.8V. Fortunately, both voltages are available on P9.<br />
<br />
The photo above shows a small potentiometer wired to the bone. One end goes to the analog ground (pin 34), the other analog 1.8V (pin 32). The wiper is attached to '''AIN5''' which is pin 36.<br />
<br />
You interact with the analog in much like the gpio, but it appears in a different. We have to run a command before the AIN interface appears. Just run them now, later we'll explain what you did.<br />
<br />
beagle$ '''SLOTS=/sys/devices/bone_capemgr.*/slots'''<br />
beagle$ '''PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins'''<br />
beagle$ '''echo cape-bone-iio > $SLOTS'''<br />
<br />
You can now access the analog interface, but where do they appear. Try using the '''find''' command.<br />
<br />
beagle$ '''find /sys -name "*AIN"'''<br />
./devices/ocp.2/helper.14/AIN0<br />
./devices/ocp.2/helper.14/AIN1<br />
./devices/ocp.2/helper.14/AIN2<br />
./devices/ocp.2/helper.14/AIN3<br />
./devices/ocp.2/helper.14/AIN4<br />
./devices/ocp.2/helper.14/AIN5<br />
./devices/ocp.2/helper.14/AIN6<br />
./devices/ocp.2/helper.14/AIN7<br />
<br />
You paths may be slightly different. Now explore.<br />
<br />
beagle$ '''cd /sys/devices/ocp.2/helper.14'''<br />
beagle$ '''ls -F'''<br />
AIN0 AIN2 AIN4 AIN6 driver@ power/ uevent<br />
AIN1 AIN3 AIN5 AIN7 modalias subsystem@<br />
<br />
There are the various analog inputs, but watch out. This interface starts numbering at '''1''' and Table 11 starts at '''0''', so to read AIN5 you need to look at '''AIN6'''!<br />
<br />
beagle$ '''cat AIN6'''<br />
1185<br />
<br />
Change the pot and rerun '''cat'''. What's the min and max value you get? Is it 12 bits?<br />
<br />
=== Challenge ===<br />
Rewrite the scripts from before to read an AIN pin and continuously display it's value.<br />
<br />
{{YoderFoot}}</div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-06T18:56:21Z<p>Yoder: /* User Instructions 3.8 Kernel */ Added References</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the BeagleBone running version 3.8 of the kernel with device tree. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/linux-dev/KERNEL</code><br />
<br />
Start by updating the course materials. ([[EBC Exercise 05 Getting Exercise Support Materials]])<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/exercises/LEDstring/driver'''<br />
host$ '''git pull'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the file <code>lpd8806.c</code> into the <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code> directory, make the kernel, and then scp the files to the bone. (Look in the Makefile and update the address for you Beagle.)<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd exercises/LEDstring/driver'''<br />
bone$ '''git pull'''<br />
bone$ '''make dt'''<br />
<br />
This will make the correct device tree overlay to set the pin muxxes for spi0. You only have to do this once per booting the beagle. Next:<br />
<br />
bone$ '''cd /lib/modules/3.8.13''' (or whatever path is correct for you system.)<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/lpd8806.ko:</code> (This didn't work for me.)<br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''cd /lib/modules/3.8.13-bone19/kernel/drivers/char/'''<br />
bone$ '''insmod lpd8806'''<br />
<br />
Now test it with<br />
bone$ '''cd ~/exercises/LEDstring'''<br />
bone$ '''make tree'''<br />
bone$ '''./tree 3 60000 20000'''<br />
<br />
This will display a sequence of LEDs running up and down the string.<br />
<br />
== User Instructions 3.2 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== User Instructions 3.8 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find a folder inside <code>/sys/firmware</code> called <code>lpd8806</code>.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 18 (D12/SPI0_D1) and 22 (A13/SPI0_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:HeaderP9.jpg|800px]]<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127 0" > rgb'''<br />
<br />
You should see LED '''0''' (closest to the bone) light up bright white. You can also do something like the following to turn LED ''x'' red.<br />
<br />
bone$ '''echo "127 0 0 ''x''" > rgb'''<br />
<br />
The driver keeps an internal state of the string and shifts it out to update the string. (The shifting is so fast you won't see it.) You can see the state of the string with:<br />
<br />
bone$ '''cat data'''<br />
<br />
You can change the internal state without updating the string by suppressing the 'return' on the echo.<br />
<br />
bone$ '''echo -n 0 50 0 10 > rgb"<br />
<br />
=== References ===<br />
* [http://hipstercircuits.com/enable-spi-with-device-tree-on-beaglebone-black-copy-paste/ Enable SPI with device tree on BeagleBone Black] shows how to set the pin muxing for SPI1.<br />
* [http://blog.inbedded.net/blog/categories/device-tree/ BeagleBone Black and LCD = fun] showed how to set the pin mux for SPI0.<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-06T18:52:54Z<p>Yoder: /* User Instructions 3.8 Kernel */ Initial content</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the BeagleBone running version 3.8 of the kernel with device tree. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/linux-dev/KERNEL</code><br />
<br />
Start by updating the course materials. ([[EBC Exercise 05 Getting Exercise Support Materials]])<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/exercises/LEDstring/driver'''<br />
host$ '''git pull'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the file <code>lpd8806.c</code> into the <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code> directory, make the kernel, and then scp the files to the bone. (Look in the Makefile and update the address for you Beagle.)<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd exercises/LEDstring/driver'''<br />
bone$ '''git pull'''<br />
bone$ '''make dt'''<br />
<br />
This will make the correct device tree overlay to set the pin muxxes for spi0. You only have to do this once per booting the beagle. Next:<br />
<br />
bone$ '''cd /lib/modules/3.8.13''' (or whatever path is correct for you system.)<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/lpd8806.ko:</code> (This didn't work for me.)<br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''cd /lib/modules/3.8.13-bone19/kernel/drivers/char/'''<br />
bone$ '''insmod lpd8806'''<br />
<br />
Now test it with<br />
bone$ '''cd ~/exercises/LEDstring'''<br />
bone$ '''make tree'''<br />
bone$ '''./tree 3 60000 20000'''<br />
<br />
This will display a sequence of LEDs running up and down the string.<br />
<br />
== User Instructions 3.2 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== User Instructions 3.8 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find a folder inside <code>/sys/firmware</code> called <code>lpd8806</code>.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 18 (D12/SPI0_D1) and 22 (A13/SPI0_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:HeaderP9.jpg|800px]]<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127 0" > rgb'''<br />
<br />
You should see LED '''0''' (closest to the bone) light up bright white. You can also do something like the following to turn LED ''x'' red.<br />
<br />
bone$ '''echo "127 0 0 ''x''" > rgb'''<br />
<br />
The driver keeps an internal state of the string and shifts it out to update the string. (The shifting is so fast you won't see it.) You can see the state of the string with:<br />
<br />
bone$ '''cat data'''<br />
<br />
You can change the internal state without updating the string by suppressing the 'return' on the echo.<br />
<br />
bone$ '''echo -n 0 50 0 10 > rgb"<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-06T18:38:24Z<p>Yoder: /* User Instructions */ Added 3.8 Kernel instructions</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the BeagleBone running version 3.8 of the kernel with device tree. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/linux-dev/KERNEL</code><br />
<br />
Start by updating the course materials. ([[EBC Exercise 05 Getting Exercise Support Materials]])<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/exercises/LEDstring/driver'''<br />
host$ '''git pull'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the file <code>lpd8806.c</code> into the <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code> directory, make the kernel, and then scp the files to the bone. (Look in the Makefile and update the address for you Beagle.)<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd exercises/LEDstring/driver'''<br />
bone$ '''git pull'''<br />
bone$ '''make dt'''<br />
<br />
This will make the correct device tree overlay to set the pin muxxes for spi0. You only have to do this once per booting the beagle. Next:<br />
<br />
bone$ '''cd /lib/modules/3.8.13''' (or whatever path is correct for you system.)<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/lpd8806.ko:</code> (This didn't work for me.)<br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''cd /lib/modules/3.8.13-bone19/kernel/drivers/char/'''<br />
bone$ '''insmod lpd8806'''<br />
<br />
Now test it with<br />
bone$ '''cd ~/exercises/LEDstring'''<br />
bone$ '''make tree'''<br />
bone$ '''./tree 3 60000 20000'''<br />
<br />
This will display a sequence of LEDs running up and down the string.<br />
<br />
== User Instructions 3.2 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== User Instructions 3.8 Kernel ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-06T18:35:20Z<p>Yoder: /* Installation Instructions 3.8 Kernel */ Initial version</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the BeagleBone running version 3.8 of the kernel with device tree. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/linux-dev/KERNEL</code><br />
<br />
Start by updating the course materials. ([[EBC Exercise 05 Getting Exercise Support Materials]])<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/exercises/LEDstring/driver'''<br />
host$ '''git pull'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the file <code>lpd8806.c</code> into the <code>~/BeagleBoard/linux-dev/KERNEL/driver/char</code> directory, make the kernel, and then scp the files to the bone. (Look in the Makefile and update the address for you Beagle.)<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd exercises/LEDstring/driver'''<br />
bone$ '''git pull'''<br />
bone$ '''make dt'''<br />
<br />
This will make the correct device tree overlay to set the pin muxxes for spi0. You only have to do this once per booting the beagle. Next:<br />
<br />
bone$ '''cd /lib/modules/3.8.13''' (or whatever path is correct for you system.)<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/lpd8806.ko:</code> (This didn't work for me.)<br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''cd /lib/modules/3.8.13-bone19/kernel/drivers/char/'''<br />
bone$ '''insmod lpd8806'''<br />
<br />
Now test it with<br />
bone$ '''cd ~/exercises/LEDstring'''<br />
bone$ '''make tree'''<br />
bone$ '''./tree 3 60000 20000'''<br />
<br />
This will display a sequence of LEDs running up and down the string.<br />
<br />
== User Instructions ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-06T18:22:40Z<p>Yoder: /* Installation Instructions */ Added 3.8 Kernel section</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions 3.2 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== Installation Instructions 3.8 Kernel ==<br />
{{EBC3.2}}<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== User Instructions ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/Adafruit:_Rotary_EncoderAdafruit: Rotary Encoder2013-06-05T19:43:07Z<p>Yoder: Removed Grading</p>
<hr />
<div>[[Category:ECE497]]<br />
[[Category:Adafruit]]<br />
<br />
[[File:Adafruit_Rotary_Encoder.jpg|thumb|Adafruit's Rotary Encoder]]<br />
<br />
==Overview==<br />
<br />
[http://adafru.it/377 Adafruit's Rotary Encoder] is a device that detects rotation. As it rotates, it sends pulses on two pins. By comparing the signals, the direction of rotation can be determined. There are 24 pulses per rotation. The device also acts as a pushbutton switch.<br />
<br />
==Inputs and Outputs==<br />
<br />
The device has five pins - three on one side and two on the other. The side with three pins is for the encoder and is ordered (from left to right) signal A, ground, and signal B. The side with two pins is for the pushbutton switch. The signal pins require the use of pullup resistors, and the switch should use either a pullup or pulldown resistor. More information can be found on the [http://adafru.it/377 product page] or on the [http://www.adafruit.com/datasheets/pec11.pdf datasheet].<br />
<br />
==Bone Usage==<br />
<br />
The pins on the device can be difficult to use with a bread board, so it may be useful to solder the device to a perfboard and add connectors. [[File:Adafruit_Rotary_Encoder_With_Connectors.jpg|thumb|Rotary encoder with connectors added]]<br />
<br />
<blockquote style="color:red">How do you configure the pullups?</blockquote>.<br />
<br />
The two signal pins and one of the pushbutton pins can be hooked up directly to any of the GPIO ports on the BeagleBone. The pins should then be configured as pullups for the signal pins and either pullup or pulldown for the switch pin. The remaining pins can be hooked up to GND and +3,3v. The example below uses GPIO1_6 for signal A, GPIO1_15 for signal B, and GPIO1_16 for the pushbutton switch. [[File:Adafruit_Rotary_Encoder_in_BeagleBone.jpg|thumb|Rotary encoder hooked up to the BeagleBone]]<br />
<br />
To configure the pull-up resistor, write 0x0037 to the pin's OMAP mux file (in /sys/kernel/debug/omap_mux). For example, the code below writes 0x0037 into /sys/kernel/debug/omap_mux/gpmc_ad6 for the B signal pin. Writing a value of 0x0027 to the file will configure it to use a pull-down resistor.<br />
<br />
<span style="color:red">Show the specific command that does the right. A beginner would have trouble with your instructions.</span><br />
<br />
The C code below demonstrates how to use the encoder with the BeagleBone.<br />
<br />
<pre><br />
/*<br />
<br />
Port Congiguration:<br />
-Encoder A: GPIO1_6 - Header P8, pin 3 - GPIO 38<br />
-Encoder B: GPIO1_15 - Header P8, pin 15 - GPIO 47<br />
-Encoder GND: Header P8, pin 1<br />
<br />
-Pushbutton Switch: GPIO1_16 - Header P9, pin 15 - GPIO 48<br />
-Pusshbuton Switch V+: Header P9, pin 3<br />
<br />
This program keeps track of an encoder. CW rotation will<br />
increment the ticks, and CCW will decrement it. The current<br />
number of ticks is printed when the button is pressed.<br />
<br />
The files gpio.h and gpio.c consist of the GPIO methods copied<br />
directly from:<br />
https://www.ridgerun.com/developer/wiki/index.php/Gpio-int-test.c<br />
<br />
*/<br />
<br />
#include "gpio.h"<br />
#include <signal.h><br />
#include <poll.h><br />
#include <stdio.h><br />
#include <string.h><br />
#include <unistd.h><br />
#include <stdlib.h><br />
<br />
#define OMAP_DIR "/sys/kernel/debug/omap_mux"<br />
<br />
int running = 1;<br />
<br />
// Quit when ^C is pressed<br />
void signal_handler(int sig)<br />
{<br />
printf("\n");<br />
running = 0;<br />
}<br />
<br />
int main(int argc, char* argv[])<br />
{<br />
// Polling variables<br />
int rc;<br />
struct pollfd fdset[3];<br />
int nfds = 3;<br />
int len;<br />
char* buf[MAX_BUF];<br />
<br />
// Keeps track of encoder ticks.<br />
int ticks = 0;<br />
<br />
// Variables used to store GPIO values<br />
unsigned int enc_a_val;<br />
unsigned int enc_b_val;<br />
unsigned int sw_val;<br />
<br />
// Handle Ctrl^C<br />
signal(SIGINT, signal_handler);<br />
<br />
// Configure the pins to use internal pull-down resistors<br />
FILE *mux_ptr;<br />
char pullup_str[10];<br />
char pulldown_str[10];<br />
strcpy(pullup_str, "0x0037");<br />
strcpy(pulldown_str, "0x0027");<br />
<br />
// Configure pull-up for the A signal<br />
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_ad6", "rb+")) == NULL)<br />
{<br />
printf("Failed to open gpmc_ad6. Quitting.\n");<br />
exit(1);<br />
}<br />
else<br />
{<br />
fwrite(&pullup_str, sizeof(char), 6, mux_ptr);<br />
fclose(mux_ptr);<br />
}<br />
<br />
// Configure pull-up for the B signal<br />
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_ad15", "rb+")) == NULL)<br />
{<br />
printf("Failed to open gpmc_ad15. Quitting.\n");<br />
exit(1);<br />
}<br />
else<br />
{<br />
fwrite(&pullup_str, sizeof(char), 6, mux_ptr);<br />
fclose(mux_ptr);<br />
}<br />
<br />
// Configure pull-down for the switch<br />
if ((mux_ptr = fopen(OMAP_DIR "/gpmc_a0", "rb+")) == NULL)<br />
{<br />
printf("Failed to open gpmc_a0. Quitting.\n");<br />
exit(1);<br />
}<br />
else<br />
{<br />
fwrite(&pulldown_str, sizeof(char), 6, mux_ptr);<br />
fclose(mux_ptr);<br />
}<br />
<br />
// Set up GPIO pins<br />
unsigned int gpio_a = 38;<br />
unsigned int gpio_b = 47;<br />
unsigned int gpio_sw = 48;<br />
<br />
int enc_a_fd;<br />
int enc_b_fd;<br />
int enc_sw_fd;<br />
<br />
printf("Exporting a... %d\n", gpio_export(gpio_a));<br />
printf("Exporting b... %d\n", gpio_export(gpio_b));<br />
printf("Exporting sw... %d\n", gpio_export(gpio_sw));<br />
<br />
printf("Setting a direction... %d\n", gpio_set_dir(gpio_a, 0));<br />
printf("Setting b direction... %d\n", gpio_set_dir(gpio_b, 0));<br />
printf("Setting sw direction... %d\n", gpio_set_dir(gpio_sw, 0));<br />
<br />
// Interrupts<br />
printf("setting edge a... %d\n", gpio_set_edge(gpio_a, "rising"));<br />
printf("setting edge sw... %d\n", gpio_set_edge(gpio_sw, "rising"));<br />
<br />
// Open the file for the encoder A signal<br />
enc_a_fd = gpio_fd_open(gpio_a);<br />
enc_sw_fd = gpio_fd_open(gpio_sw);<br />
<br />
// Main loop<br />
while (running == 1)<br />
{<br />
memset((void*)fdset, 0, sizeof(fdset));<br />
<br />
fdset[0].fd = STDIN_FILENO;<br />
fdset[0].events = POLLIN;<br />
<br />
fdset[1].fd = enc_a_fd;<br />
fdset[1].events = POLLPRI;<br />
<br />
fdset[2].fd = enc_sw_fd;<br />
fdset[2].events = POLLPRI;<br />
<br />
rc = poll(fdset, nfds, -1);<br />
<br />
<br />
if (rc < 0)<br />
{<br />
// printf("poll() failed.\n");<br />
}<br />
<br />
if (rc == 0)<br />
{<br />
// printf(".");<br />
}<br />
<br />
if (fdset[0].revents & POLLIN)<br />
{<br />
(void) read(fdset[0].fd, buf, 1);<br />
}<br />
<br />
// Encoder click<br />
if (fdset[1].revents & POLLPRI)<br />
{<br />
lseek(fdset[1].fd, 0, SEEK_SET);<br />
len = read(fdset[1].fd, buf, MAX_BUF);<br />
<br />
enc_a_val = atoi((const char*) buf);<br />
gpio_get_value(gpio_b, &enc_b_val);<br />
<br />
if (enc_a_val == 1) // rising edge<br />
{<br />
if (enc_b_val == 0) ticks--;<br />
else ticks++;<br />
}<br />
<br />
}<br />
<br />
// Button press - print the current number of encoder ticks<br />
if (fdset[2].revents & POLLPRI)<br />
{<br />
lseek(fdset[2].fd, 0, SEEK_SET);<br />
len = read(fdset[2].fd, buf, MAX_BUF);<br />
<br />
// Very simple debouncing<br />
usleep(5000);<br />
gpio_get_value(gpio_sw, &sw_val);<br />
if (sw_val == 1)<br />
{<br />
printf("Ticks: %d\n", ticks);<br />
}<br />
}<br />
<br />
}<br />
<br />
gpio_fd_close(enc_a_fd);<br />
<br />
return 0;<br />
}<br />
<br />
</pre><br />
<br />
The full code can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].<br />
<br />
==Interfacing with node.js==<br />
<br />
Interfacing it with node.js is relatively straight-forward. The code is shwon below, and can be found in [https://github.com/jtlobdell/Adafruit_Rotary_Encoder_BeagleBone John Lobdell's Git repository].<br />
<br />
rotary_encoder.js:<br />
<pre><br />
// From Getting Started With node.js and socket.io <br />
// http://codehenge.net/blog/2011/12/getting-started-with-node-js-and-socket-io-v0-7-part-2/<br />
"use strict";<br />
<br />
var http = require('http'),<br />
url = require('url'),<br />
fs = require('fs'),<br />
exec = require('child_process').exec,<br />
server,<br />
connectCount = 0; // Number of connections to server<br />
<br />
server = http.createServer(function (req, res) {<br />
// server code<br />
var path = url.parse(req.url).pathname;<br />
console.log("path: " + path);<br />
switch (path) {<br />
case '/':<br />
res.writeHead(200, {'Content-Type': 'text/html'});<br />
res.write('<h1>John Lobdell - Mini Project 4</h1>Try<ul><li><a href="/rotary_encoder.html">Rotary Encoder</a></li></ul>');<br />
<br />
res.end();<br />
break;<br />
<br />
default: // This is so all the files will be sent.<br />
fs.readFile(__dirname + path, function (err, data) {<br />
if (err) {return send404(res); }<br />
// console.log("path2: " + path);<br />
res.write(data, 'utf8');<br />
res.end();<br />
});<br />
break;<br />
<br />
}<br />
});<br />
<br />
var send404 = function (res) {<br />
res.writeHead(404);<br />
res.write('404');<br />
res.end();<br />
};<br />
<br />
server.listen(8081);<br />
<br />
// socket.io, I choose you<br />
var io = require('socket.io').listen(server);<br />
io.set('log level', 2);<br />
<br />
// on a 'connection' event<br />
io.sockets.on('connection', function (socket) {<br />
var frameCount = 0; // Counts the frames from arecord<br />
var lastFrame = 0; // Last frame sent to browser<br />
console.log("Connection " + socket.id + " accepted.");<br />
// console.log("socket: " + socket);<br />
<br />
// now that we have our connected 'socket' object, we can <br />
// define its event handlers<br />
<br />
// Make sure gpio 38, 47, and 48 are available.<br />
exec("echo 38 > /sys/class/gpio/export");<br />
exec("echo 47 > /sys/class/gpio/export");<br />
exec("echo 48 > /sys/class/gpio/export");<br />
<br />
// Configure pullup/pulldown resistors<br />
exec("echo 0x0037 > /sys/kernel/debug/omap_mux/gpmc_ad6"); // Pullup for encoder A<br />
exec("echo 0x0037 > /sys/kernel/debug/omap_mux/gpmc_ad15"); // Pullup for encoder B<br />
exec("echo 0x0027 > /sys/kernel/debug/omap_mux/gpmc_a0"); // Pulldown for the switch<br />
<br />
// Handle disconnects<br />
socket.on('disconnect', function () {<br />
console.log("Connection " + socket.id + " terminated.");<br />
connectCount--;<br />
if(connectCount === 0) {<br />
}<br />
console.log("connectCount = " + connectCount);<br />
});<br />
<br />
// Periodically send data<br />
var push_interval = 20;<br />
function push_data() {<br />
// Send encoder A status<br />
var gpioPath = "/sys/class/gpio/gpio38/value";<br />
fs.readFile(gpioPath, 'base64', function (err, data) {<br />
if (err) throw err;<br />
socket.emit('enc_a', data);<br />
});<br />
<br />
// Send encoder B status<br />
gpioPath = "/sys/class/gpio/gpio47/value";<br />
fs.readFile(gpioPath, 'base64', function (err, data) {<br />
if (err) throw err;<br />
socket.emit('enc_b', data);<br />
});<br />
<br />
<br />
// Send encoder switch status<br />
gpioPath = "/sys/class/gpio/gpio48/value";<br />
fs.readFile(gpioPath, 'base64', function (err, data) {<br />
if (err) throw err;<br />
socket.emit('enc_sw', data);<br />
});<br />
<br />
setTimeout(push_data, push_interval);<br />
}<br />
push_data();<br />
<br />
connectCount++;<br />
console.log("connectCount = " + connectCount);<br />
});<br />
<br />
</pre><br />
<br />
rotary_encoder.html:<br />
<pre><br />
<!doctype html><br />
<html><br />
<head><br />
<title>Rotary Encoder Demo</title><br />
<br />
<script src="/json.js"></script> <!-- for ie --><br />
<script src="/socket.io/socket.io.js"></script><br />
<br />
<link href="layout.css" rel="stylesheet" type="text/css"><br />
<script src="jquery.js"></script><br />
<script src="jquery.flot.js"></script><br />
<script src="jquery.flot.navigate.js"></script><br />
</head><br />
<body><br />
<h1>Rotary Encoder Demo <a href="http://Rose-Hulman.edu" target="_blank"><br />
<img src="RoseLogo96.png" width=200 style="float:right"></a></h1><br />
<button id="connect" onClick='connect()'/>Connect</button><br />
<button id="disconnect" onClick='disconnect()'>Disconnect</button><br />
<!-- <button id="send" onClick='send()'/>Send Message</button> --><br />
<table><br />
<tr><br />
<td><div id="plotTop" style="width:550px;height:150px;"></div><br />
<center>samples</center></td><br />
</tr><br />
<tr><br />
<td><div id="plotBot" style="width:550px;height:150px;"></div><br />
<center>samples<center></td><br />
</tr><br />
</table><br />
<br />
<br /><br />
<br /><br />
<br />
<a href="http://beagleboard.org" target="_blank"><br />
<img src="beagle-hd-logo.gif" width=200 align="right"></a><br />
<div><p id="status">Waiting for input</p></div><br />
<div><p id="ticks"></p></div><br />
<a href="http://www.ti.com/sitara" target="_blank"><br />
<img src="hdr_ti_logo.gif" width=200 align="right"></a><br />
By <i>John Lobdell</i><br />
<br /><br />
<br />
<script><br />
<br />
var socket;<br />
var firstconnect = true,<br />
fs = 8000,<br />
Ts = 1/fs*1000,<br />
samples = 100,<br />
plotTop,<br />
enc_a = [], ienc_a = 0,<br />
enc_b = [], ienc_b = 0,<br />
sw_data = [], isw_data = 0,<br />
gpio_enc_a = 38,<br />
gpio_enc_b = 47,<br />
gpio_sw = 48;<br />
<br />
enc_a[samples] = 0;<br />
enc_b[samples] = 0;<br />
sw_data[samples] = 0;<br />
<br />
function connect() {<br />
if(firstconnect) {<br />
socket = io.connect(null);<br />
<br />
socket.on('message', function(data)<br />
{ status_update("Received: message");});<br />
socket.on('connect', function()<br />
{ status_update("Connected to Server"); });<br />
socket.on('disconnect', function()<br />
{ status_update("Disconnected from Server"); });<br />
socket.on('reconnect', function()<br />
{ status_update("Reconnected to Server"); });<br />
socket.on('reconnecting', function( nextRetry )<br />
{ status_update("Reconnecting in " + nextRetry/1000 + " s"); });<br />
socket.on('reconnect_failed', function()<br />
{ message("Reconnect Failed"); });<br />
<br />
socket.on('enc_a', enca);<br />
socket.on('enc_b', encb);<br />
socket.on('enc_sw', encsw);<br />
socket.on('set_ticks', setTicks);<br />
<br />
firstconnect = false;<br />
<br />
}<br />
else {<br />
socket.socket.reconnect();<br />
}<br />
}<br />
<br />
function disconnect() {<br />
socket.disconnect();<br />
}<br />
<br />
// When new data arrives, convert it and plot it.<br />
function enca(data) {<br />
// status_update("enc_a " + data);<br />
data = atob(data);<br />
enc_a[ienc_a] = [ienc_a, data];<br />
ienc_a++;<br />
if (ienc_a >= samples) {<br />
ienc_a = 0;<br />
enc_a = [];<br />
}<br />
plotTop.setData([ enc_a, enc_b ]);<br />
plotTop.draw();<br />
}<br />
<br />
function encb(data) {<br />
// status_update("enc_b " + data);<br />
data = atob(data);<br />
enc_b[ienc_b] = [ienc_b, data];<br />
ienc_b++;<br />
if (ienc_b >= samples) {<br />
ienc_b = 0;<br />
enc_b = [];<br />
}<br />
plotTop.setData([ enc_a, enc_b ]);<br />
plotTop.draw();<br />
}<br />
<br />
function encsw(data) {<br />
// status_update("encsw " + data);<br />
data = atob(data);<br />
sw_data[isw_data] = [isw_data, data];<br />
isw_data++;<br />
if (isw_data >= samples) {<br />
isw_data = 0;<br />
sw_data = [];<br />
}<br />
plotBot.setData([ sw_data ]);<br />
plotBot.draw();<br />
}<br />
<br />
function status_update(txt){<br />
document.getElementById('status').innerHTML = txt;<br />
}<br />
<br />
function setTicks(numTicks){<br />
document.getElementById('ticks').innerHTML = "Ticks: " + numTicks;<br />
}<br />
<br />
connect();<br />
<br />
$(function () {<br />
<br />
function initPlotData() {<br />
// zip the generated y values with the x values<br />
var result = [];<br />
for (var i = 0; i <= samples; i++)<br />
result[i] = [i, 0];<br />
return result;<br />
}<br />
<br />
// setup plot<br />
var optionsTop = {<br />
series: { <br />
shadowSize: 0, // drawing is faster without shadows<br />
points: { show: false},<br />
lines: { show: true, lineWidth: 5},<br />
}, <br />
yaxis: { min: 0, max: 2, <br />
zoomRange: [10, 256], panRange: [-128, 128] },<br />
xaxis: { show: true, <br />
zoomRange: [10, 100], panRange: [0, 100] },<br />
legend: { position: "sw" },<br />
zoom: { interactive: true, amount: 1.1 },<br />
pan: { interactive: true }<br />
};<br />
plotTop = $.plot($("#plotTop"), <br />
[ <br />
{ data: initPlotData(), <br />
label: "Encoder A" },<br />
{ data: initPlotData(),<br />
label: "Encoder B" }<br />
],<br />
optionsTop);<br />
<br />
var optionsBot = {<br />
series: {<br />
shadowSize: 0, // drawing is faster without shadows<br />
points: { show: false},<br />
lines: { show: true, lineWidth: 5},<br />
color: 2<br />
},<br />
yaxis: { min: 0, max: 2,<br />
zoomRange: [10, 256], panRange: [-128, 128] },<br />
xaxis: { show: true,<br />
zoomRange: [10, 100], panRange: [0, 100] },<br />
legend: { position: "sw" },<br />
zoom: { interactive: true, amount: 1.1 },<br />
pan: { interactive: true }<br />
};<br />
plotBot = $.plot($("#plotBot"),<br />
[<br />
{ data: initPlotData(),<br />
label: "Encoder Switch"}<br />
],<br />
optionsBot);<br />
});<br />
</script><br />
<br />
</body><br />
</html><br />
</pre></div>Yoderhttp://www.elinux.org/ECE497_SPI_ProjectECE497 SPI Project2013-06-05T18:27:10Z<p>Yoder: Added ECE497 category</p>
<hr />
<div>[[Category:ECE497Fall2012 |Project]]<br />
[[Category:ECE497 |Ada]]<br />
Team members: [[user:Richarsm|Sean Richardson]], [[user:larmorgs|Greg Larmore]]<br />
<br />
== Executive Summary ==<br />
<br />
For this project we wanted to further improve documentation available for sysfs kernel drivers with the Beagle Bone. To do this we have interfaced an [http://adafruit.com/products/306 LED light strand] by Adafruit with a sysfs kernel driver utilizing SPI. In doing so we have created an easy to use interface to the light strand while also maximizing data throughput.<br />
<br />
== Good Websites ==<br />
<br />
[http://elinux.org/BeagleBoard/SPI BeagleBoard and SPI]<br />
<br />
[http://www.xml.com/ldd/chapter/book/ O'Reilly Book on Linux Device Drivers]<br />
<br />
[http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/samples/kobject/kset-example.c Kset example for sysfs driver]<br />
<br />
[http://elk.informatik.fh-augsburg.de/pub/elinux/ngw100-docs/AVR32743/spi/spi_example.c Example SPI device driver]<br />
<br />
[http://www.jumpnowtek.com/index.php?option=com_content&view=article&id=57&Itemid=62 Another example SPI device driver]<br />
<br />
== More Good Websites ==<br />
<br />
[http://www.loadyourself.com/linux/sample-linux-driver/ Example Kernel Driver (ioctl, no sysfs)]<br />
<br />
[http://www.freesoftwaremagazine.com/articles/drivers_linux Kernel Driver Tutorial (no sysfs/ioctl)]<br />
<br />
== Installation Instructions ==<br />
<br />
All of these instructions are meant for the A6A BeagleBone running version 3.2.25+ of the kernel. Scripts and Makefiles expect that the kernel be located at <code>~/BeagleBoard/kernel/kernel</code><br />
<br />
Start by cloning the [https://github.com/larmorgs/FinalProject github] repository on both the bone and the host machine by running the following:<br />
<br />
both$ '''git clone git@github.com:larmorgs/FinalProject'''<br />
<br />
On the host machine, run the following:<br />
<br />
host$ '''cd ~/FinalProject'''<br />
host$ '''./setup.sh'''<br />
<br />
Make sure you only do this <b>once</b> because it is adding on our modules to the Kconfig and Makefile in <code>~/BeagleBoard/kernel/kernel/driver/char</code>. The files are backed up in the same folder with <code>.orig</code> appended.<br />
<br />
Next run the following on the host machine:<br />
<br />
host$ '''make kernel'''<br />
<br />
This will copy the files <code>example.c</code> and <code>lpd8806.c</code> into the <code>~/BeagleBoard/kernel/kernel/driver/char</code> directory, make the kernel, and then scp the files to the bone.<br />
<br />
Moving over to the bone, run the following:<br />
<br />
bone$ '''cd /lib/modules/3.2.25+'''<br />
bone$ '''mv modules.dep.bin modules.dep.bin.orig'''<br />
<br />
Next modify <code>modules.dep</code> to include <code>kernel/drivers/char/example.ko:</code> and <code>kernel/drivers/char/lpd8806.ko:</code><br />
<br />
Upon successful completion, you should be able to run the following:<br />
<br />
bone$ '''modprobe example'''<br />
bone$ '''modprobe lpd8806'''<br />
<br />
== User Instructions ==<br />
<br />
Run <code>dmesg</code> or <code>lsmod</code> to make sure the modules have loaded properly. You should now find two folders inside <code>/sys/firmware</code> called <code>example</code> and <code>lpd8806</code>. Feel free to play around in the example folder. If you go into this folder and then one folder further into device, you will find two files. The <code>test</code> file holds an unsigned integer, while the <code>data</code> file holds a string of length 10 (initially empty). You can read and write from these files as you would any other sysfs file.<br />
<br />
Next we will hook up the LED strand. <b>For this make sure the beagle is powered externally</b>. The USB power supply does not have enough current to run the 5m strand at full brightness.<br />
<br />
To get started hook up pins 30 (D12/SPI1_D1) and 31 (A13/SPI1_SCLK) to SPI data and SPI clock on the strand (see the silkscreen for guidance. Hook up the ground to ground (obviously), and the 5V wire on the strand to the <b>3.3V</b> pin on the bone. <b>Do not use the 5V pin on the bone or the suggested Adafruit 5V power supply directly connected to the strand without also adding logic level voltage shifters to the data and clock lines</b>.<br />
<br />
[[File:Bone_P9_pinout.jpg]]<br />
<br />
You may need to modify your muxes (if they have been changed from the default). If so, do the following:<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_d1'''<br />
beagle$ '''echo 0 > /sys/kernel/debug/omap_mux/spi0_scl'''<br />
<br />
Now that the strand is hooked up, we can run the following:<br />
<br />
bone$ '''cd /sys/firmware/lpd8806/device/'''<br />
bone$ '''echo "127 127 127" > grb'''<br />
<br />
You should see the first LED (closest to the bone) light up bright white. You can also do something like the following:<br />
<br />
bone$ '''echo "127 0 0 0 127 0 0 0 127" > data'''<br />
<br />
The <code>data</code> file is written directly out to the strand while the <code>grb</code> file treats the strand like a big shift register. <b>Be careful with using <code>data</code></b>. Buffering problems can cause the kernel to seg fault or crash completely (see Future Work).<br />
<br />
== Highlights ==<br />
<br />
We have created a simple C example that uses this sysfs driver. You can run it by doing the following:<br />
<br />
bone$ '''cd ~/FinalProject'''<br />
bone$ '''make'''<br />
bone$ '''./test'''<br />
<br />
{{#ev:youtube|8d9n5QUyH38}}<br />
<br />
The program shows the capabilities of the strand running in shift mode. Because of the nature of the strand's construction, it would be very simple to daisy chain many chains end to end. Also, the kset implementation means that we can have as many separate strands as there are SPI buses. Normally you could have even more, but the strand only runs 3 wire SPI (no chip select).<br />
<br />
The speed is increased greatly when the strand is running in direct access mode by using the <code>data</code> file instead of the <code>grb</code> file. However, due to time limitations we were unable to debug the buffering issues. A good place for future work would be to figure out how the buffering problem can be alleviated.<br />
<br />
== Theory of Operation ==<br />
<br />
There are many layers to the implementation, so we will break them out into subsections.<br />
<br />
=== Light Strand ===<br />
<br />
The light strand uses the LPD8806 controller chip. Each chip controls the brightness of two 3 color GRB LEDs using PWM running at 1.2 MHz. SPI is used to communicate with the controller chips. The controller has its SPI bus rated somewhere around 20 MHz, but we are only running at 10 MHz. Each LED is 21-bit color, which leaves three bits available for latch control.<br />
<br />
So, as you write color values out on the SPI, the first chip receives them. If the chip hasn't written a color to one of its to LEDs, it does so and thus ends the transmission. However, if it has already assigned a color to each LED then it passes the SPI along on a separate bus to the next chip. This is how the strand is able to be 5m and still run at 10 MHz.<br />
<br />
It is still unknown how exactly the 3 latch bits are used (because the chip manufacturer has kept the interface a secret). However, if you write 6 bytes of "latch" the strand restarts at the beginning. Perhaps less bytes of "latch" can be sent and get the same effect, but due to time limitations we were unable to debug this completely. This is a simple place to start for future work.<br />
<br />
=== SPI Bus ===<br />
<br />
We use the default SPI controller to control the SPI lines. All we had to do is find what master is controlling the bus (2 in our case) and add a device. Initially, the SPI bus we want is being used by the default configuration of spidev. So, all we do is unregister the device from spidev and reregister it for our driver. There are a few things that go into the configuration of the device like speed, number of bits, chip select, and mode. Once these are set, you can add the device and it will then be associated with your driver.<br />
<br />
=== Sysfs Kernel Driver ===<br />
<br />
The sysfs kernel driver is based on the references above. It uses a kset to store kobjects (the basic building block of the kernel). Each kobject has associated with it certain attributes. These attributes are brought out to the user as files. When the files are read from or written to, the kernel calls back into the kobject's read/write routines. Here, we are able to decide which attribute is being addressed and manipulate the buffer as we see fit.<br />
<br />
There are some alternative implementations to this that were looked into in addition to kset. The driver could have been implemented as a sysfs device driver instead of a kernel driver so that it shows up in <code>/sys/class</code> with everything else. Another option is that it could be implemented as a straight up device/kernel driver making it show up in <code>/dev</code> instead. There doesn't seem to be much of a difference though between these implementations as far as performance is concerned. However, finding where this driver fits best is another good place for future work. <br />
<br />
== Work Breakdown ==<br />
<br />
=== Sean Richardson ===<br />
* Researched using SPI on the BeagleBone<br />
* Debugged the LED strand (the first one we received was broken)<br />
* Wrote code to interface with the strand using spidev<br />
* Helped integrate the SPI interface into the sysfs driver<br />
<br />
=== Greg Larmore ===<br />
* Researched kernel drivers and sysfs<br />
* Helped debug the LED strand<br />
* Wrote example sysfs driver<br />
* Integrated the SPI interface into the sysfs driver<br />
<br />
== Future Work ==<br />
<br />
While the strand works well as it is, there are some things that we would like to see looked into if there is future work on this project.<br />
<br />
=== Latching and Controller Interface ===<br />
<br />
According to Adafruit, the interface to this part has been reverse engineered. The one part that really remains unknown is how exactly the 3-bit control interface works for each LED. We were able to achieve a latching effect by sending 6 empty transmissions. The code in [github.com/adafruit/lpd8806 Adafruit's github] doesn't seem to be using this many latch transmissions.<br />
<br />
=== Buffering Problem ===<br />
<br />
There is a problem with buffered output going into the <code>data</code> file (because it is so big). When the output buffers it causes 2 sequential writes which weren't being handled well by the attribute's store function. This could be alleviated with a circular buffer and an index that can be controlled by the user, but really the driver should be able to handle this condition.<br />
<br />
=== Sysfs File Location ===<br />
<br />
The decision to have these drivers located in <code>/lib/modules/3.2.25+/kernel/drivers/char</code> and run out of <code>/sys/firmware</code> was pretty much arbitrary. It would be nice to do some research into how the kernel is supposed to be structured so that we can match it. This also applies to the example driver included in this project.<br />
<br />
== Conclusions ==<br />
<br />
In this project, we were able to get SPI (a lesser used interface on the bone) to work well with our LED strand. More impressively, we were able to interface with the SPI through a sysfs interface. In the process of developing this sysfs interface to the LED strand, we developed an example sysfs driver that can be used in future ECE497 classes. Lastly, we developed a sample application that uses this sysfs interface for our LED strand to show off the results.</div>Yoderhttp://www.elinux.org/BeagleBone_PRU_NotesBeagleBone PRU Notes2013-06-05T15:23:39Z<p>Yoder: Added a link to some work PRU examples</p>
<hr />
<div>[[Category:ECE497Notes |PRU]]<br />
<br />
The goal of this page is to record information that is pertinent to getting started with the BeagleBone's AM335x Programmable Real-time Unit (PRU).<br />
<br />
== BeagleBone Programmable Real-time Unit ==<br />
This is also called the PRU Subsystem (PRUSS) or PRU and Industrial Controller Subsystem (PRU-ICSS). It is optimized to perform embedded tasks that require real-time constraints.<br />
<br />
Most important is the purssdrv library to expose functions to the PRU. You can load this library by typing modprobe uio_pruss.<br />
<br />
=== PRU capabilities ===<br />
[[File:PRUSS.png|AM335x PRUSS]]<br />
<br />
* The PRU has dual 32-bit RISC cores, shared data and instruction memories and an interrupt controller (INTC).<br />
* 8KB data memory and 8KB instruction memory<br />
* 12KB shared RAM<br />
* A small, deterministic instruction set<br />
<br />
There is no pipelining done on the processor and there are 29 (r1-r30) registers to use.<br />
<br />
Data Sheet is located at http://www.ti.com/lit/pdf/spruh73<br />
<br />
=== Software examples ===<br />
BeagleBoard/TI has provided example C programs that utilize the PRU on [https://github.com/beagleboard/am335x_pru_package github.]<br />
<br />
These include: PRU_memAccess_DDR_PRUsharedRAM, PRU_memAccessPRUDataRam, PRU_PRUtoPRUInterrupt, and a PRU assembler.<br />
<br />
Full assembly guide is located at http://processors.wiki.ti.com/index.php/PRU_Assembly_Reference_Guide<br />
<br />
=== Instruction Set ===<br />
Nearly all instructions (with exception of accessing memory external to PRU) are single-cycle execute (5 ns when running at 200 MHz)<br />
<br />
==== Four instruction classes ====<br />
* Arithmetic<br />
* Logical<br />
* Flow Control<br />
* Register Load/Store<br />
<br />
==== Instruction Syntax ====<br />
* Mnemonic, followed by comma separated parameter list<br />
* Parameters can be a register, label, immediate value, or constant table entry<br />
* Example<br />
** SUB r3, r3, 10 <br />
** Subtracts immediate value 10 (decimal) from the value in r3 and then places the result in r3<br />
<br />
==== Example Assembly ====<br />
<pre><br />
;INTC_SIR_IRQ/INTC_SIR_FIQ register address<br />
INTC_SIR_IRQ_ADDR/INTC_SIR_FIQ_ADDR .word 0x48200040/0x48200044<br />
; ACTIVEIRQ bit field mask to get only the bit field<br />
ACTIVEIRQ_MASK .equ 0x7F<br />
_IRQ_ISR/_FIQ_ISR:<br />
; Save the critical context<br />
STMFD SP!, {R0-R12, LR} ; Save working registers and the Link register<br />
MRS R11, SPSR ; Save the SPSR into R11<br />
; Get the number of the highest priority active IRQ/FIQ<br />
LDR R10, INTC_SIR_IRQ_ADDR/INTC_SIR_FIQ_ADDR<br />
LDR R10, [R10] ; Get the INTC_SIR_IRQ/INTC_SIR_FIQ register<br />
AND R10, R10, #ACTIVEIRQ_MASK ; Apply the mask to get the active IRQ number<br />
; Jump to relevant subroutine handler<br />
LDR PC, [PC, R10, lsl #2] ; PC base address points this instruction + 8<br />
NOP ; To index the table by the PC<br />
; Table of handler start addresses<br />
.word IRQ0handler ;For IRQ0 of BANK0<br />
.word IRQ1handler<br />
.word IRQ2handler<br />
</pre><br />
<br />
== Leads ==<br />
Here's some sources of information. <br />
<br />
* [http://www.element14.com/community/community/knode/single-board_computers/next-gen_beaglebone/blog/2013/05/22/bbb--working-with-the-pru-icssprussv2 BBB - Working with the PRU-ICSS/PRUSSv2] Has very detailed instructions for working with the Black.<br />
* [http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=shortlog;h=refs/heads/arm335x-hal-pru-tasks Working PRU examples]</div>Yoder