What is it?

JTAG stands for the Joint Test Action Group, and the TAP or Test Access Port this group defined is one of the most (if not the most) common way to program and debug embedded devices and computers of all flavors. For the professional, JTAG devices are bountiful and usually not too much of a strain on the commercial budget. But for the hobbyist, things aren’t so peachy. A Segger J-Link EDU can be had for ~$70 USD shipped, but the full featured J-Link is still ~$400, which is more than I want to pay as a hobbyist.

What does it do?

The JTAG TAP port consists of a few standard signals which essentially give you complete control over the systems in the JTAG chain. The chain is exactly what it sounds like: multiple devices which support JTAG chaining can be chained up and accessed from a single JTAG port. Need that flash programmed? JTAG can do that. Need to debug that microcontroller? JTAG can do that too. Want to do both without switching out tools? Yep, JTAG can do it. See this helpful diagram at Wikipedia for a visual representation.

JTAG for the Hobbyist

Chances are that you’ve got an USB -> Serial cable or breakout board lying around somewhere in your hoard. Chances are also, that it’s based on the wildly popular FTDI FT232R or a similar FT232-esque chip which converts USB to RS232. If you’re lucky enough to have this essential piece of hobbyist equipment, you’ve got a USB->JTAG adapter waiting to be unlocked!

Enter OpenOCD

OpenOCD (Open On-chip Debugger) is a fantastic project which aims to create an open and extensible OCD solution for all, and lucky for us, this includes the hobbyist! The OpenOCD project defines interfaces between the common parts of the OCD process, such as the target board or device, the OCD device used, etc., and using these well-defined interfaces is able to create a modular system which can support many different targets and debuggers with only a configuration change. This is a simplification of how this works, but it is sufficient to understand what we want to do with it.

So back to the FT232R. This little chip can be re-configured to use the RS232 signals as bit-banged JTAG signals, and OpenOCD can drive it. Even better, once the OpenOCD agent is up and running, we can then use GDB to connect to and drive our debug efforts. This mode of operation is detailed over at their documentation site (hint: search for ft232r).

The OpenOCD tool can usually be installed with your package manager on Linux. I’m running Linux Mint, so I apt install’d openocd. When I ran the tool pointing to the ft232r config file, it complained that it was not a supported interface… so I guess we’ll build from source!

Building OpenOCD with the Right Interfaces

All we need to do is build OpenOCD from source with the right interfaces enabled and we can make it work. What follows next is my step-by-step on doing this. I’m doing this in /tmp just so I can recreate the steps I did earlier in my apps directory.

Grab the Source

Go get the source from the GitHub mirror here and drop it in a working directory. I would also read the README for any dependencies you didn’t have already on your machine.

jacob@jacob-aspire-mint:/tmp$ git clone https://github.com/ntfreak/openocd.git
Cloning into 'openocd'...
remote: Enumerating objects: 74, done.
remote: Counting objects: 100% (74/74), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62845 (delta 36), reused 50 (delta 21), pack-reused 62771
Receiving objects: 100% (62845/62845), 24.17 MiB | 24.90 MiB/s, done.
Resolving deltas: 100% (51571/51571), done.
jacob@jacob-aspire-mint:/tmp$ 

Run the bootstrapper

This little piece of code essentially checks that your build environment is sane and you have all the tools needed to build OpenOCD. Output is below, you should come away with no errors.

jacob@jacob-aspire-mint:/tmp/openocd$ ./bootstrap 
+ aclocal
+ libtoolize --automake --copy
+ autoconf
+ autoheader
+ automake --gnu --add-missing --copy
configure.ac:26: installing './compile'
configure.ac:37: installing './config.guess'
configure.ac:37: installing './config.sub'
configure.ac:16: installing './install-sh'
configure.ac:16: installing './missing'
Makefile.am:46: warning: wildcard $(srcdir: non-POSIX variable name
Makefile.am:46: (probably a GNU make extension)
Makefile.am: installing './INSTALL'
Makefile.am: installing './depcomp'
Makefile.am:23: installing './mdate-sh'
Makefile.am:23: installing './texinfo.tex'
Setting up submodules
Submodule 'jimtcl' (http://repo.or.cz/r/jimtcl.git) registered for path 'jimtcl'
Submodule 'src/jtag/drivers/libjaylink' (http://repo.or.cz/r/libjaylink.git) registered for path 'src/jtag/drivers/libjaylink'
Submodule 'tools/git2cl' (http://repo.or.cz/r/git2cl.git) registered for path 'tools/git2cl'
Cloning into '/tmp/openocd/jimtcl'...
warning: redirecting to https://repo.or.cz/r/jimtcl.git/
Cloning into '/tmp/openocd/src/jtag/drivers/libjaylink'...
warning: redirecting to https://repo.or.cz/r/libjaylink.git/
Cloning into '/tmp/openocd/tools/git2cl'...
warning: redirecting to https://repo.or.cz/r/git2cl.git/
Submodule path 'jimtcl': checked out 'a9bf5975fd0f89974d689a2d9ebd0873c8d64787'
Submodule path 'src/jtag/drivers/libjaylink': checked out 'f73ad5e667ae8b26a52b847c603fdadaabf302a6'
Submodule path 'tools/git2cl': checked out '8373c9f74993e218a08819cbcdbab3f3564bbeba'
Generating build system...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
libtoolize: copying file 'build-aux/config.guess'
libtoolize: copying file 'build-aux/config.sub'
libtoolize: copying file 'build-aux/install-sh'
libtoolize: copying file 'build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:42: installing 'build-aux/ar-lib'
configure.ac:37: installing 'build-aux/compile'
configure.ac:30: installing 'build-aux/missing'
Makefile.am: installing './INSTALL'
libjaylink/Makefile.am: installing 'build-aux/depcomp'
Bootstrap complete. Quick build instructions:
./configure ....
jacob@jacob-aspire-mint:/tmp/openocd$ 

Run the configure script

This is where we determine that we want the FTDI FT232R to be supported. We do this by adding a flag to the configure line. Output is cut short in the middle because it’s quite long, but the important part is at the end.

jacob@jacob-aspire-mint:/tmp/openocd$ ./configure --enable-ft232r 
checking for makeinfo... no
configure: WARNING: Info documentation will not be built.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk

[ ... snip ... ]

libjaylink configuration summary:
 - Package version ................ 0.2.0-git-f73ad5e
 - Library version ................ 0:0:0
 - Installation prefix ............ /usr/local
 - Building on .................... x86_64-pc-linux-gnu
 - Building for ................... x86_64-pc-linux-gnu

Enabled transports:
 - USB ............................ yes
 - TCP ............................ yes



OpenOCD configuration summary
--------------------------------------------------
MPSSE mode of FTDI based devices        yes (auto)
ST-Link Programmer                      yes (auto)
TI ICDI JTAG Programmer                 yes (auto)
Keil ULINK JTAG Programmer              yes (auto)
Altera USB-Blaster II Compatible        yes (auto)
Bitbang mode of FT232R based devices    yes
Versaloon-Link JTAG Programmer          yes (auto)
TI XDS110 Debug Probe                   yes (auto)
OSBDM (JTAG only) Programmer            yes (auto)
eStick/opendous JTAG Programmer         yes (auto)
Andes JTAG Programmer                   yes (auto)
USBProg JTAG Programmer                 no
Raisonance RLink JTAG Programmer        no
Olimex ARM-JTAG-EW Programmer           no
CMSIS-DAP Compliant Debugger            no
Cypress KitProg Programmer              no
Altera USB-Blaster Compatible           no
ASIX Presto Adapter                     no
OpenJTAG Adapter                        no
SEGGER J-Link Programmer                yes (auto)

Build it

Finally, we build it. Again, I’m snipping the output down to size, but you should end up with an executable binary in src/ called openocd. This final step doesn’t take long (on my machine only about 45s).

jacob@jacob-aspire-mint:/tmp/openocd$ make
Makefile:4634: warning: overriding recipe for target 'check-recursive'
Makefile:4045: warning: ignoring old recipe for target 'check-recursive'
cat src/helper/startup.tcl src/jtag/startup.tcl src/target/startup.tcl src/server/startup.tcl src/flash/startup.tcl | ./src/helper/bin2char.sh > src/startup_tcl.inc || { rm -f src/startup_tcl.inc; false; }
cp src/jtag/drivers/minidriver_imp.h src/jtag/minidriver_imp.h
make  all-recursive
make[1]: Entering directory '/tmp/openocd'
Makefile:4634: warning: overriding recipe for target 'check-recursive'
Makefile:4045: warning: ignoring old recipe for target 'check-recursive'
Making all in jimtcl
make[2]: Entering directory '/tmp/openocd/jimtcl'


[ ... snip ... ]

libtool: link: ranlib src/.libs/libopenocd.a
libtool: link: rm -fr src/.libs/libopenocd.lax src/.libs/libopenocd.lax
libtool: link: ( cd "src/.libs" && rm -f "libopenocd.la" && ln -s "../libopenocd.la" "libopenocd.la" )
depbase=`echo src/main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
gcc -DHAVE_CONFIG_H -I.   -I./src -I./src -I./src/helper -DPKGDATADIR=\"/usr/local/share/openocd\" -DBINDIR=\"/usr/local/bin\" -I./jimtcl -I./jimtcl  -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -g -O2 -MT src/main.o -MD -MP -MF $depbase.Tpo -c -o src/main.o src/main.c &&\
mv -f $depbase.Tpo $depbase.Po
/bin/bash ./libtool  --tag=CC   --mode=link gcc -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -g -O2   -o src/openocd src/main.o src/libopenocd.la  ./jimtcl/libjim.a  -ldl 
libtool: link: gcc -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -g -O2 -o src/openocd src/main.o  src/.libs/libopenocd.a -lusb-1.0 -lm ./jimtcl/libjim.a -ldl
make[2]: Leaving directory '/tmp/openocd'
make[1]: Leaving directory '/tmp/openocd'

Testing OpenOCD

Now that we have a binary, we need to test it out and see if it works. My target for today is a Raspberry Pi 3 B. We first need to gather some info about our target, i.e., the Raspberry Pi 3. We need to know which pins on the GPIO header correspond to which JTAG signals.

First let’s grab the BCM2835 pinout reference. (Side note: we use the BCM2835 reference because there is no BCM2837 reference, and it seems the pinouts are roughly the same.) This will tell us what each GPIO pin does. Some of the GPIOs are only designated for one singular function, whereas many other GPIOs are multi-function, and their function is software programmable. These alternate functions are designated ALT on the reference material. I used the reference over at e-Linux because I find the table easy to read. Searching the table, we find the JTAG signals we’re interested in (TRST, TCK, TMS, TDI, TDO) are assigned in the range of GPIOs 22-27 for the ALT4 function. Next we want to pull up the schematic of our Raspberry Pi 3 B, and see what each of those map to on the GPIO header. I’ve created the table below to keep things straight.

Once we’ve got these figured out we’ve got to prep the Pi for JTAG usage. This is the simplest part in the whole setup. On the Pi’s SD card, add the following line to the config.txt.

enable_jtag_gpio=1

Finally, we’re ready to hook up our JTAG debugger. Looking in the documentation for the OpenOCD FT232R configuration, we find the following table which shows us which RS232 signals correspond to which JTAG signals. We need to (powered down of course!) hook up our FT232R module/cable and Pi accordingly, and don’t forget the ground wire!

    - RXD(5) - TDI
    - TXD(1) - TCK
    - RTS(3) - TDO
    - CTS(11) - TMS
    - DTR(2) - TRST
    - DCD(10) - SRST 

Once things are hooked up, we need to setup our configuration for the OpenOCD tool. The default config from the ft232r.cfg is sufficient for the interface, but I wanted to add one item and to get us debugging we need to tell OpenOCD how to connect to the Pi and its four cores. I’ve based my rpi3b.cfg config off of a fellow GitHub contributor’s config but made some modifications.

ft232r.cfg

adapter driver ft232r
adapter speed 3000
ft232r_restore_serial 0x15

I modified the ft232r.cfg to increase the adapter speed to 3M (3000 kHz) and to restore the port config when OpenOCD is done so the adapter can be used as a serial device again.

rpi3b.cfg

transport select jtag

adapter speed 3000

reset_config trst_and_srst

jtag_ntrst_delay 500

if { [info exists CHIPNAME] } {
  set _CHIPNAME $CHIPNAME
} else {
  set _CHIPNAME rpi3
}

if { [info exists DAP_TAPID] } {
   set _DAP_TAPID $DAP_TAPID
} else {
   set _DAP_TAPID 0x4ba00477
}

jtag newtap $_CHIPNAME tap -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_DAP_TAPID -enable
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.tap

set _TARGETNAME $_CHIPNAME.a53
set _CTINAME $_CHIPNAME.cti

set DBGBASE {0x80010000 0x80012000 0x80014000 0x80016000}
set CTIBASE {0x80018000 0x80019000 0x8001a000 0x8001b000}
set _cores 4

for { set _core 0 } { $_core < $_cores } { incr _core } {

    cti create $_CTINAME.$_core -dap $_CHIPNAME.dap -ap-num 0 \
        -ctibase [lindex $CTIBASE $_core]

    target create $_TARGETNAME.$_core aarch64 \
        -dap $_CHIPNAME.dap -coreid $_core \
        -dbgbase [lindex $DBGBASE $_core] -cti $_CTINAME.$_core

    $_TARGETNAME.$_core configure -event reset-assert-post "aarch64 dbginit"
}

Putting it All Together

Now we have all the pieces we need to debug using our JTAG adapter. Let’s begin!

jacob@jacob-aspire-mint:/opt/apps/openocd$ sudo ./src/openocd -f ./ft232r.cfg -f ./rpi3b.cfg 
Open On-Chip Debugger 0.10.0+dev-01047-g09ac9ab1 (2020-02-04-09:11)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
FT232R restore serial: 0x0015 (enabled)

Warn : Transport "jtag" was already selected
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 3000 kHz
Info : JTAG tap: rpi3.tap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : rpi3.a53.0: hardware has 6 breakpoints, 4 watchpoints
Info : rpi3.a53.1: hardware has 6 breakpoints, 4 watchpoints
Info : rpi3.a53.2: hardware has 6 breakpoints, 4 watchpoints
Info : rpi3.a53.3: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 3334 for gdb connections
Info : Listening on port 3335 for gdb connections
Info : Listening on port 3336 for gdb connections

Now we’re cooking! You can connect GDB up to each core, debug that way, or use the OpenOCD interface, see below:

OpenOCD Interface

acob@jacob-aspire-mint:/tmp/openocd$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> halt
rpi3.a53.3 cluster 0 core 3 multi core
target halted in AArch64 state due to debug-request, current mode: EL3H
cpsr: 0x000003cd pc: 0x20001c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> targets
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0  rpi3.a53.0         aarch64    little rpi3.tap           running
 1  rpi3.a53.1         aarch64    little rpi3.tap           running
 2  rpi3.a53.2         aarch64    little rpi3.tap           running
 3* rpi3.a53.3         aarch64    little rpi3.tap           halted

> reg
===== Aarch64 registers
(0) x0 (/64): 0x0000000000000003 (dirty)
(1) x1 (/64): 0x00000000C1000000
(2) x2 (/64)
(3) x3 (/64)
(4) x4 (/64)
(5) x5 (/64)
(6) x6 (/64)
(7) x7 (/64)
(8) x8 (/64)

[ ... snip ... ]

GDB Interface

jacob@jacob-aspire-mint:/tmp/openocd$ aarch64-none-elf-gdb
GNU gdb (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 8.3.0.20190709-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-none-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.linaro.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :3333
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x0000000000200028 in ?? ()
(gdb) si
0x000000000020002c in ?? ()
(gdb) si
0x0000000000200074 in ?? ()
(gdb) si
0x0000000000200078 in ?? ()
(gdb) 

Wrapping Up

Now we have a JTAG solution that can debug many, many flavors of processors and microcontrollers given the right configuration. It becomes even more useful if your FT232R module supports selecting the logic level voltage like mine does. See below for some pros and cons of this approach.

Pros

This is a quick and dirty way to get a JTAG adapter at no cost if you’ve already got these FTDI chips laying around. It’s quick and fully configurable (check out the OpenOCD config pages for all it can do) and makes a great debugger.

Cons

Since we are bit-banging our way to success here, it is a bit on the slow side. It’s not unusable, but it is slower than a native interface. If you don’t have one of these chips already at your disposal, I’d opt for one of the FT232H or better yet the FT2232H, both of which have an MPSSE engine which greatly improves emulation.

The post JTAG On the Cheap with the FTDI FT232R appeared first on Jacob N Calvert.

I recently stumbled upon HypriotOS while looking for Docker-ready distributions for my Raspberry Pi 3B+. I flashed this onto and SD card and started playing around with it. It works incredibly well, but I noticed that it was built for armv7l which is a 32-bit implementation. Since the Raspberry Pi 3B+ has a 4x core Cortex-A53 which is 64 bit, I wanted to make use of the 64 bit processor! I’ve worked with Yocto before (in fact, my day job uses Yocto), so I decided I’d build my own. For more on containers, see my other blog posts on what it is, what it can be used for, and how to use it.

Process

Prerequisites

Yocto is a build, not a distribution, so it is quite resource intensive. I would suggest having at least 60GB free disk space, and a quad core machine at a minimum. You’ll also need a Linux installation, and the build essentials installed (git, gcc, etc.).

EDIT: Checking the disk usage after the builds shows around 55GB used. On a 2C4T Intel Core i5 it took about 2H to build.

Project Setup

First, create a working directory and clone all the piece-parts we need to build.

mkdir rpi3bplus-build-yocto
cd rpi3bplus-build-yocto
git clone git://git.yoctoproject.org/poky
git clone git://git.openembedded.org/meta-openembedded
git clone git://git.yoctoproject.org/meta-raspberrypi
git clone git://git.yoctoproject.org/meta-virtualization 

Next create the project and add the base layers.

source poky/oe-init-build-env rpi64
bitbake-layers add-layer ../meta-raspberrypi
bitbake-layers add-layer ../meta-openembedded/meta-oe
bitbake-layers add-layer ../meta-openembedded/meta-python
bitbake-layers add-layer ../meta-openembedded/meta-perl
bitbake-layers add-layer ../meta-openembedded/meta-networking
bitbake-layers add-layer ../meta-openembedded/meta-filesystems
bitbake-layers add-layer ../meta-virtualization

Edit the conf/local.conf file sections as needed:

MACHINE ??= "raspberrypi3-64"
CORE_IMAGE_EXTRA_INSTALL += "kernel-modules htop openssh iperf3 docker-ce bash ntp "

INHERIT += "extrausers"

EXTRA_USERS_PARAMS += " useradd pi; \
                       usermod  -p 'raspberry' pi; \
                       usermod  -a -G sudo pi; \
                       usermod -P root root; "

DISTRO_FEATURES_append = " virtualization"

Next we will build the image. This will take a while depending on how beefy your build machine is.

bitbake core-image-minimal
Parsing recipes: 100% |########################################################################################################################################################################################################| Time: 0:02:16
Parsing of 2540 .bb files complete (0 cached, 2540 parsed). 3827 targets, 140 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "aarch64-poky-linux"
MACHINE              = "raspberrypi3-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0"
TUNE_FEATURES        = "aarch64 cortexa53 crc"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "master:6bb4a252199cfd5d44ad7ab6fc4118c80a1aae92"
meta-raspberrypi     = "master:a0a5d3848e76b7f90ef8e42c56211da78db1c7ba"
meta-oe              
meta-python          
meta-perl            
meta-networking      
meta-filesystems     = "master:d9f3e6dbed8e5d96f2069280f0a566af89afb2fa"
meta-virtualization  = "master:5fb77ae4c4e1015e40257f9e59e16c497e30c53c"

After a couple of hours, you will have a completed, ready to flash SD Image at <build>/rpi3bplus-build-yocto/rpi64/tmp/deploy/images/raspberrypi3-64/core-image-minimal-raspberrypi3-64.rpi-sdimg which you can burn to an SD card with:

dd if=./core-image-minimal-raspberrypi3-64.rpi-sdimg of=/dev/sdX status=progress

Your image should boot up and docker will be running!

NOTE: You will manually have to set the date to pull from Docker registries over HTTPS because the certification validation will fail otherwise. We could add and configure NTP to fix the but… for another day. Use:

date "+%d-%m-%C%y %H:%M:%S" -s "2019-12-22 00:30:01"

There is one last thing you’ll want to do. You’ll want to use GParted or similar tool to enlarge your filesystem partition to take up the rest of your SD card so you will have some room for container images. You need to do this because the default SD Image builder script only provides enough space for the root filesystem and no more. In my configuration it ended up being ~300MB, so I expanded it take up the remaining ~59GB. See example below:

Results

As it turns out, I have a system that can build and run 64-bit Docker images and is pretty darn slim. Here’s a screenshot of htop running.. only 12 processes – not bad!

Some Metrics

The is the minimal image and it has 12 processes, with an incredibly low footprint. I loaded up an Ubuntu container and installed iperf3, then ran a test to my laptop. I was impressed to find the following result:

[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-10.13  sec   116 MBytes  96.0 Mbits/sec    9             sender
[  5]   0.00-10.13  sec   113 MBytes  93.8 Mbits/sec                  receiver

Even running that test, the load on the Pi was:

root@raspberrypi3-64:~# cat /proc/loadavg 
0.05 0.22 0.19 1/141 2125
root@raspberrypi3-64:~# 

Downloads

The post Building a Customized Linux Image for Raspberry Pi with Yocto + Docker Support appeared first on Jacob N Calvert.

The post Strange but neat trick on the new RPi appeared first on Jacob N Calvert.

I bought a 2A power supply, an Edimax EW-7811Un USB Wireless b/g/n nano adapter, a Cobbler-T breakout panel, and a 32GB µSD card. I am a big Debian fan so when it came to what OS to use, Raspbian was the obvious choice. My problems began here though! I had previously downloaded the 01-07-14 dated Raspbian image on my computer for a friend’s RPi project. He has a Mac and couldn’t get the disk imager to correctly format his SD card, so I did it for him though Linux Mint. Anyway, I imaged my SD card with this image and popped it into the RPi and guess what? No luck. RPi powered up, and the activity (green light) LED went out immediately. No output on the HDMI port or anything. I Tried several different ways to image the SD card, I even went to Windows to do it (crazy right!?).. I downloaded the NOOBS net install and tried it. It booted right up! I really wanted Raspbian all the way though so I pressed on. After an hour or so of reading forums as to why this could happen, I decided to download the latest Raspbian image and try that. The latest image named 2014-12-24-wheezy-raspbian loaded on the SD card just fine, no blips. I powered on my RPi and success!!! I setup the RPi and started to play around with it. It’s awesome FYI!!

I ran into a few technical issues with my setup though, and thought I’d post them here in case someone else runs into these problems.

Problem 1

The OS I was trying to use was outdated. Should have been a no-brainer, but I struggled with it – don’t make this silly mistake, just update the file

Problem 2

The Edimax wireless adapter I am using has power saving features. Sounds nice, but if you’re SSH’d in and you step away from the session for a few minutes, connectivity goes down. The only solution to get it back up is to restart the Pi. The long-term solution to this came from the official RPi forum. Basically you have to turn off the power management feature, which can be accomplished via a file and a few config options.

Problem 3

The root account is funky on the RPi. I couldn’t get root access. The trick, although it seems backwards, is to actually set the root password from the default user account. From the logged in terminal, issue:

sudo passwd root

You’ll be prompted to set the root password. Voila! Root access.

I have some DC motors, motor controllers and other toys on the way, so I hope to post some more about my Raspberry Pi creations!
Thanks for reading!!

The post Raspberry Pi B+: my setup story appeared first on Jacob N Calvert.

Thanks for reading!

The post RPiComponents, a wrapper for GPIO/SPI in Python appeared first on Jacob N Calvert.

I quickly learned that I would want a class to wrap up all the GPIO sets/gets. I’ve been writing a package in Python which I’m calling RPiComponents containing the basic interfaces necessary for controlling the GPIO pins in an object-oriented fashion. I’ll be posting it to GitHub as soon as I finish the documentation for it. As a preview though, you can currently do things like:

	import RPiComponents as parts
	red_led_pin = 21  # using the BCM pin numbering
	initial_brightness = 0  # initially off
	red_led = parts.LED.FadableLED(red_led_pin, initial_brightness)
	red_led.set_brightness(50)  # set the brightness to 50%
	red_led.set_brightness(100) # '   '   '          '  100%
	red_led.off()

	motor_enable_pin = 21
	motor_fwd_pin = 20
	motor_rev_pin = 16


	motor = parts.L293DMotor.VariableSpeedL293DMotor(motor_enable_pin, motor_fwd_pin, motor_rev_pin)
	motor.enable()  # sets the motor controller enable bit to HIGH
	motor.set_speed(50)  # sets the motor speed to 50% of it's max

	motor.fwd()

	motor.stop()

	motor.rev(90)  # starts the motor in reverse at 90% of the max speed

	motor.disable() # all speed and direction setting are kept but the motor will stop

	
	def some_callback(some_arg0):
		print "Called some_callback with argument %s" % (some_arg0)

			
	switch_pin_number = 6

	switch = parts.Switch.SwitchWithThreadedCallback(switch_pin_number, callback=some_callback, callback_args=[1,2,3])
	
	switch.start()

	#  calling switch.start() starts a monitor thread that waits for a rising or falling edge
	#  due to the switch changing state, it will then fire off callback with the arguments given
	#  or if callback_args is None, it will simply call the callback

	switch.stop()

	#  switch.stop() properly terminates the monitor thread

	parts.finalize()  # clean up after ourselves and reset the GPIO pins for some other use

There’s also a few super simple abstractions like BasicToggleOutput with methods high() and low() in a module called BasicLogic. I hope to add some more neat functionality later on as well. I’ll post again when the source is on GitHub and attach a few examples for starters!

Thanks for reading!!

The post Raspberry Pi and GPIO updates appeared first on Jacob N Calvert.