The DockerHub images link back to my GitHub, and I’m using the auto-build feature so that when I update the Dockerfile and scripts to build the software, it gets rebuilt over at DockerHub automatically.

Here’s an example of one of the builders for W1HKJ’s FlDigi software suite. Simply run the container volume mounting in some working directory to /opt/source in the container, and the build script finds the latest source, downloads, untars, and builds it, spitting out the results in your working directory.

jacob@jacob-aspire:/tmp/fldigi$ docker run --rm -v $PWD:/opt/source jacobcalvert/fldigi-build:latest 
Building fldigi-4.1.18
--2021-05-26 12:39:39--  http://www.w1hkj.com/files//fldigi/fldigi-4.1.18.tar.gz
Resolving www.w1hkj.com (www.w1hkj.com)... 143.95.246.118
Connecting to www.w1hkj.com (www.w1hkj.com)|143.95.246.118|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4847091 (4.6M) [application/x-gzip]
Saving to: 'fldigi-4.1.18.tar.gz'

     0K .......... .......... .......... .......... ..........  1%  736K 6s
    50K .......... .......... .......... .......... ..........  2% 1.53M 5s
   100K .......... .......... .......... .......... ..........  3% 2.52M 4s
   150K .......... .......... .......... .......... ..........  4% 27.7M 3s
   200K .......... .......... .......... .......... ..........  5% 3.33M 2s
   250K .......... .......... .......... .......... ..........  6% 2.67M 2s
   300K .......... .......... .......... .......... ..........  7% 28.3M 2s
   350K .......... .......... .......... .......... ..........  8% 8.94M 2s
   400K .......... .......... .......... .......... ..........  9% 9.29M 2s
   450K .......... .......... .......... .......... .......... 10% 7.04M 1s
   500K .......... .......... .......... .......... .......... 11% 4.42M 1s
   550K .......... .......... .......... .......... .......... 12% 8.31M 1s

  <<<<<<<<<<<<<<<<<<<<<<<< snipped for brevity >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

make[1]: Nothing to be done for 'all-am'.
make[1]: Leaving directory '/opt/source/flrig-1.3.54'
Done!!
jacob@jacob-aspire:/tmp/fldigi$ ll
total 11224
drwxrwxr-x  5 jacob jacob    4096 May 26 13:05 ./
drwxrwxrwt 18 root  root     4096 May 26 13:05 ../
drwxr-xr-x  9 jacob jacob    4096 May 26 13:05 fldigi-4.1.18/
-rw-r--r--  1 root  root  4847091 Jan 29 06:50 fldigi-4.1.18.tar.gz
-rw-r--r--  1 root  root  4847091 Jan 29 06:50 fldigi-4.1.18.tar.gz.1
drwxrwxr-x  7 jacob jacob    4096 May 26 12:45 flmsg-4.0.17/
-rw-r--r--  1 root  root   876560 Sep  8  2020 flmsg-4.0.17.tar.gz
drwxr-xr-x  7 jacob jacob    4096 May 26 12:46 flrig-1.3.54/
-rw-r--r--  1 root  root   891644 Feb  3 08:35 flrig-1.3.54.tar.gz

The post Docker Builders for Easy Updates appeared first on Jacob N Calvert.

I have a dual-band handheld radio for the 2m and 70cm bands. The so-called rubber-duck antenna that comes with it performs ok but it isn’t ideal. I could get into my local repeaters which are about 10mi away with enough power to break the squelch, but my audio was weak and quality was poor. Naturally, I decided I should put up an antenna!

To Build or to Buy?

You can buy antennas on the web or at local shops like my local (and fantastic) GigaParts, however in true geeky-nerd style, I have to DIY an antenna to feel I truly understand what is going on.

Self-Education

I’ll be the first to admit, prior to starting this DIY antenna journey, I didn’t have a great understanding of how antenna theory related to an actual antenna. I understood the general 1/2 wave, 1/4 wave relation to the designed frequency of an antenna, but until digging in, I didn’t get the math behind it. I found this website to be invaluable for a plain-language (plain to someone with a bit of an engineering tilt) introduction to the core concepts and how to apply them.

What kind of antenna should I build?

This was the next question I needed to answer. My antenna only had a few real requirements, namely:

1. Support the 2m band
2. Support the 70cm band
3. Be outdoor-mountable
4. Be home-manufacturable

This list ruled out a standard di-pole, because although I have learned you can “load” a dipole to make it multi-band, I didn’t feel I had the mounting capability at present for that. I also ruled out a ladder-line j-pole, because I couldn’t find ladder-line anywhere near me. It used to be more common I suppose when OTA TV used it for their antennas, but no more. I ruled out a Yagi also, based on the complicated layout, and I didn’t necessarily want a directional antenna. After scouring the web, I settled on a standard J-pole.

J-Pole: what is it and how does it work?

If you navigate to the Wikipedia entry for J-pole antenna , you will notice there are many “form-factors,” but they all follow the similar J shape, hence the name. But looking at the typical design, I couldn’t understand how the feed point (which separated only by a short distance) doesn’t just ruin the antenna performance. Take a look at the image below, credit ZyMOS.

I found the most useful explanation in a YouTube video (an aside: you can anything on YT these days) which I will link.

How it works, condensed version

A little prerequisite knowledge will help the understanding of how this antenna works.

1. The impedance in the middle of a 1/2 wave dipole is very low
2. The impedance at the ends of a 1/2 wave dipole is very high
3. The impedance somewhere between “very low” and “very high” is our magical 50Ω
4. We can end-feed a 1/2 wave antenna, but the impedance is very high (as seen in item #2)

Basically, the bottom U part of the j-pole is where the feed-point is adjusted to 50Ω (or thereabouts), and at the ends the impedance is very high, which is perfect to end-feed our 1/2 wave antenna (the long part of the J). As a result of this configuration, it really doesn’t matter which “leg” of the antenna is tied to shield vs. conductor for the feed-point.

But this is still for a single band, right?

Yes, but conveniently, the “long” side of the j-pole for 70cm band is pretty darn close to the “short” side of the j-pole for the 2m band, and since it doesn’t matter which element is our “radiating” element, we can essentially reuse one of our elements. See the rough diagram below for an example of this.

Let’s Build It!

So I had armed myself with the knowledge (at least the theory) and now I just needed to create a plan. Like any good engineer, I looked around the web for any prior work in this area (no reason to reinvent the wheel!) and much to my delight, someone had posted a PDF of an easy build process for such an antenna. Following this guide, I was able to construct my first dual-band j-pole.

Tuning the antenna

This step is very important, and can be made easier by the use of SWR meters or in my case a Vector Network Analyzer. I purchased the NanoVNA (wonderful tool, works like a charm) and was able to adjust the elements of my new antenna to achieve a great SWR and feed-point impedance in the 2m band, and pretty good SWR and impedance in the 70cm band. See captures below.

2m Tuning Results

70cm Tuning Result

Some notes on the 70cm performance

You’ll notice the oscillatory nature of the SWR and impedance in the 70cm band. I do not completely understand this, and may return to tweak the antenna a little more. I get decent performance in several “buckets” of the 70cm band, so it’s workable, but not ideal. I have a couple of theories as to why this is, but I don’t know for sure. If any readers have some comments on this, I’d love to hear it, please comment or send me some email!

Element Diameter

The elements in the 70cm legs of the antenna are 3/8″ rod as opposed to 3/4″ EMT conduit. I suspect that the deep V around 441MHz is the center frequency for these stubs, and the antenna just has a narrow bandwidth because the elements are small. I will likely try to build another one with all 3/4″ elements to see if the antenna is improved.

Element Smoothness

I’m not sure that this has an impact or not, but the 3/8″ rod is threaded at 24-TPI and the 3/4″ elements are smooth EMT conduit. I wonder if this interplays with the skin effect?

The End Result

I mounted this antenna up on the roof, and boy-oh-boy does it work great! I am able to be heard at least 17mi away by an APRS digipeater, which was not possible with the rubber duck antenna. I can now full-quiet the local repeaters and my voice is loud and clear. Also, mounting the antenna outside has greatly reduce computer and monitor based interference, which was a pleasant surprise. All said, I’d say this was a great learning experience and fun project to boot!

Thanks for reading!

The post J-Pole Antennas for Ham Radio appeared first on Jacob N Calvert.

Here’s a breakdown: on the FT232R, the max speed I can set the adapter to is 3MHz. This has given me a transfer speed (loading via GDB) of around 3KB/s. Not too bad for small projects of only a few hundred KiB. But now my code size is approaching a ~5 MiB, the debug cycle was way too long… 5MiB @ 3KB/s = ~28mins to load… not good!

Still in my pursuit of a cheap JTAG debugger (I mean come on! It’s just a serial protocol!), I did buy something. The Adafruit FT232H breakout is exactly what I was looking for. At only $15 with Amazon Prime shipping, I was back to debugging at a reasonable speed in two days.

The FT232H breakout is about as barebones as it gets. The board breaks out untouched ACBUS0-ACBUS7 and ADBUS0-ADBUS7 to 0.10″ pitch headers. Since the FT232H has a single MPSSE channel, I can use this breakout to get faster JTAG speeds.

My configuration files from the previous post had to change a little to accommodate. I’ll break it down below in comments in the file because it’s a little bit cryptic.

#
# FTDI USB Hi-Speed to MPSSE Breakout from Adafruit
#
# This should work for any bare FT232H
#

# Setup driver type
adapter driver ftdi

# 30000 kHZ -> 30MHz
adapter speed 30000

# Using JTAG (also could be SWD)
transport select jtag

# Common PID for FT232H
ftdi_vid_pid 0x0403 0x6014

# Set sampling to allow higher clock speed
ftdi_tdo_sample_edge falling


# Layout
# On this breakout, the LEDs are on ACBUS8 and ACBUS9, can't assign them
# registers are <ACVALUE><ADVALUE> <ACCONFIG><ADCONFIG>
# so we set 0x0308 to mean only ACBUS nTRST and nSRST, ADBUS3 (TMS) asserted high
# and we set 0x000B to mean only AC3,AC2,AC0 outputs -> (TMS,TD0, TCK)
ftdi_layout_init 0x0308 0x000b

# Pins
# pin name      | func. |
# --------------|-------|
# ADBUS0        | TCK   |
# ADBUS1        | TDI   |
# ADBUS2        | TDO   |
# ADBUS3        | TMS   |
# ACBUS0        | nTRST |
# ACBUS1        | nSRST |
#---------------|-------|

# When data == oe -> pins are switched from output to input to give
# the tri state (L, H, Hi-Z) effect 
ftdi_layout_signal nTRST -data 0x0100 -oe 0x0100
ftdi_layout_signal nSRST -data 0x0200 -oe 0x0200

So now it is as simple as connecting the corresponding pins on this breakout to the RPi3, and running OpenOCD again.

With the increased throughput of this MPSSE-supported interface, I now get ~587KB/s. Much better! It only takes ~8s to load my image now.

The post Better JTAG on the Cheap with the FT232H appeared first on Jacob N Calvert.

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.

In our new house, we had a hallways closet that was massive. It was very deep, and fairly wide, but had low overhead, due to the stairs passing above it. My wife had the brilliant idea to turn this into a dropzone for shoes, parcels, mail, etc. She took to Pinterest to gather ideas, and I turned it into a weekend project.

The Project Plan

Regrettably, I didn’t capture all the “design” pieces, and only have a picture of my materials list. You can get an idea of what went into the design though. I measured the space, and used good old pencil, paper, and a ruler to draw a scale-sized picture of what I wanted to build. I then got buyoff from the wife, of course.

The Final Product

We wanted the walls to be beadboard, painted white, with shelves under a benchtop, and hooks all around the top to hang things. Check out the gallery below for a step-by-step on producing this. I think it turned out quite well!

The post Turning my Hallway Closet into a Drop Zone: Gallery appeared first on Jacob N Calvert.

PCB and Parts are here!

The printed boards from OSHPARK arrived recently and so did the components. Below is a list of the components I selected for this board.

Prototype PCB from OSHPARK

Check out the images of the PCB OSHPARK made for me.

Prototype PCB

Some Corrections

I started to build the pedal circuit and realized I did not need 100mF caps everywhere. I re-simulated the circuit with 100uF caps, and it works just fine. I started with a huge cap value just as a placeholder and never updated the schematic.

Prototype One

For the first build, I soldered the components on and just left fly wires hanging off. I did this so I could pump signals into it and test the circuit response. See the prototype one below.

Prototype One

I didn’t save my oscilloscope captures.. I will remember next time! The good news is that from 20Hz to 8kHz there was a good solid amplification with minimal change of the input signal. Driving the input harder resulted in soft-clipping, but it was very minimal and still showed a solid gain performance. As predicted in the previous post, there was an amplification of around 2-3x the input signal, resulting in a noticeable volume increase.

Prototype Two

The second prototype is the “final product.” I stuck the circuits + inputs/outputs in the enclosure I purchased. It made for a nice looking product at the end of the day.

I am very happy with the results! It works and sounds great!

Restrospective

So, the question must be asked, did I complete my stated list from the previous post? The list is below as a reminder.

1. Take an AC signal around 300mV pk-pk and boost it by some multiple
   1. Check! It takes an input signal and boosts it by 2-3x
2. The boosted signal should not be muddled or distorted/clipped in any way
   1. Aside from the soft clipping when driving the input stage hard, yes!
3. The output signal should model the input signal, with the only difference being the amplitude
   1. Check!
4. It should run on +9V (either a battery or a standard guitar pedal wall-wart)
   1. Check!
5. It should have an adjustable output gain
   1. Check!
6. It should have a bypass capability
   1. Check!
7. It should not load the input source too much
   1. Check! Simulation showed less than 10mA sink.
8. It should have enough power to drive the output easily
   1. Check! It drives my amp input just fine!

In retrospect, I completed my requirements. But no retrospective is complete without some lessons learned and a demo!

Lessons Learned

1. I need to think about power input filtering on my next design. My 1Spot brand wall wart induces a high pitch whistle into the output stage that a 9V battery does not. It does this on every pedal I own, so this may be more of a power supply issue, but it might be solved with some input filtering. The whistle is barely noticeable, but in a very quiet room, I hear it.
2. More time needs to be spent on laying out the physical interface. I just sort of hacked this one together, but a more complex project could have been difficult.
3. Use quieter switches. I bought cheap DPDT switches, and they’re pretty loud engaging/disengaging. Listen for them on the demo.

Demos

Clean Boost Example

This example shows the clean boost aspect of the pedal. It simply boosts the volume of the signal.

Overdrive Boost

This example shows the pedal driving an amp harder into overdrive and getting a nice crunchy result.

Wrap-Up

All in all, I had a great time building this pedal, and I’ll continue making more pedals in the future! Stay tuned for the next project!

Thanks for reading!

The post Build Your Own: Clean Boost Guitar Pedal Part 2 appeared first on Jacob N Calvert.

In this series, I will detail how I have built my own clean boost guitar pedal. I will detail the schematic, what parts are chosen, the circuit stages, and how they operate, as well as following through to the finished product.

The Beginning

A clean boost guitar pedal should accomplish a few things:

1. Take an AC signal around 300mV pk-pk and boost it by some multiple
2. The boosted signal should not be muddled or distorted/clipped in any way
3. The output signal should model the input signal, with the only difference being the amplitude
4. It should run on +9V (either a battery or a standard guitar pedal wall-wart)
5. It should have an adjustable output gain
6. It should have a bypass capability
7. It should not load the input source too much
8. It should have enough power to drive the output easily

So what’s a clean boost pedal for anyway? Think about driving your amp a little hotter going into a lead part, or maybe you just need a little extra volume. With an adjustable clean boost, you can get that perfect amount of pre-gain for any sound you want.

The Design

The design of the clean boost started with the above design considerations in mind.  The circuit needed to have a few key components to satisfy my requirements. First, the circuit needed to have a pre-filtering stage that would prevent loading the input signal too much. There would also need to be a boost stage, and lastly an output stage to provide the output specs I wanted. I came up with the following circuit to accomplish this.

Schematic

Build Your Own Boost

The circuit is comprised of very few components, and is made up of four stages.

Input Stage

Input Stage

The input stage does a few things for the boost pedal. Notice the power supply section. The diode provides a little circuit protect from reverse biasing the circuit. Next notice the capacitor C1 feeding into the the pull-up-down resistor network. This section of the circuit provides the input AC signal with a DC offset of 1/2 the supply voltage. This allows us to use GND for the negative reference of the op-amp and the supply voltage as the positive reference.

Pre-Boost Stage

Pre-Boost Stage

The pre-boost stage is comprised of the op-amp, and a capacitor. This section of the circuit serves to satisfy the no-load requirement from the input source, as the op-amp is in a voltage follower configuration. Since the input signal to the op-amp is between GND and the supply voltage, with AC perturbations from the input stage, the output will follow that exactly. The capacitor at the end of this stage serves to block the DC component of op-amp output, and only pass the AC component on to the power stage.

Power Stage

Power Stage

The power stage does what its name implies. It provides the power for the boosted signal. The input from the op-amp perturbs the NPN BJT, and because the resistor network surrounding it has the BJT in its active region, the output taken on the collector is boosted. One thing to note at this stage, the output is inverted from the input signal. The signal amplitude has been boosted by several times. This is the essence of our clean boost pedal. Also note that the output signal has a large DC offset which is not what we want for the output.

Output Stage

Output Stage

This final stage serves to take the DC component out of our signal (C3) and to attenuate the signal. I have chosen to represent a potentiometer with two series resistors. When we move the wiper of the potentiometer, R7 and R8 will adjust to give us a variably attenuated output signal.

Simulation of the Circuit

To see how the circuit might perform, I used LTSpice to simulate the circuit under various circumstances.

I simulated the input signal to be a sine wave at 880Hz  with an amplitude of 150mV. The power supply was set to 9V. Basing my simulation on a B50k and going in 5% steps, I obtained the following data.

Example of Simulation Data

The Implementation

I knew I’d want to have a PCB printed for this project, just to make things really clean. I drew up the schematic (with a few logical modifications) in EagleCAD and laid out the board.

Schematic Capture

Schematic Capture

Notice there are a couple of key differences. I have added 0.1″ pitch terminals for the the signal in/out, 9V in, and two 3×1 0.1″ pitch terminals for a boost select and bypass select. Also, there are two op-amp; one is in use and the other is in a strange configuration. The series of op-amp I have elected to use has two amplifiers in the package. To keep the unused one from injecting noise, I put it in a known configuration so it will not be noisy in the circuit.

Boost select is where the potentiometer will wire into the circuit. Bypass select will allow me to put a SPDT switch in and connect common to the pole number 2. In position 1, the pedal will be engaged, in position 2, it will be fully true-bypassed.

Layout

The Layout

The layout is based on the size of a Hammond 1590G project box. The 3-terminal part for the footswitch is located at the bottom of the board, while the 3-terminal part for the boost select is located at the middle-top area. The signal in is on the top right of the board, and signal out is on the top left. Power (9V) in is in the center of the top.

PCB Spin

I use OSHPARK for all my prototype PCBs because they’re quick, good quality, and have free shipping. Here’s what OSHPARK says the final product should look like:

OSHPARK Render

Next Steps

Next, I need to order the PCBs, order my parts, and wait! I will make another post when the parts and PCBs come in, and show how it turns out. I ‘ll also include and audio test.

Thanks for reading!!

The post Build Your Own: Clean Boost Guitar Pedal appeared first on Jacob N Calvert.