Charles' corner of the webhttps://www.ghz.cc/charles/2017-06-25T22:52:16-04:00Fluid.app2017-01-03T10:41:38-05:00tag:www.ghz.cc,2016-06-06:charles/fluid.html<p><a href="http://fluidapp.com">Fluid.app</a> (the paid version, or the free version starting with macOS
Sierra) is a handy OS X solution to keep your social media and banking cookies
separate from your regular Safari instance. It lets
you create a new app specific to each web site (a site-specific browser).</p>
<p>I only have a few minor gripes, which I reported to the author a while back:</p>
<ul>
<li>Error messages for slashes in the browser name aren't intuitive. (The
browser name needs to be a valid directory name for the app bundle.)</li>
<li>There isn't a way to set up defaults for each browser instance.</li>
</ul>
<p>Favicons (and the higher-resolution PNG icons) are used for the app icon,
although sometimes the Finder icon will not update if the app destination
folder is a stack in the dock.</p>
<p>To address the defaults problem, I wrote this small script:</p>
<table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre>1
2
3
4
5
6
7
8</pre></div></td><td class="code"><div class="highlight"><pre><span class="c">#!/bin/bash -e</span>
<span class="nv">plist</span><span class="o">=</span><span class="s2">"</span><span class="nv">$1</span><span class="s2">"</span>
cp -p <span class="s2">"</span><span class="nv">$plist</span><span class="s2">"</span> <span class="s2">"</span><span class="nv">$plist</span><span class="s2">"</span>.orig
defaults write <span class="s2">"</span><span class="nv">$plist</span><span class="s2">"</span> FUToolbarShown -bool TRUE
defaults write <span class="s2">"</span><span class="nv">$plist</span><span class="s2">"</span> FUUseSeparateCookieJar -bool TRUE
defaults write <span class="s2">"</span><span class="nv">$plist</span><span class="s2">"</span> SUEnableAutomaticChecks -bool TRUE
</pre></div>
</td></tr></table>
<p>After creating the new site app, you pass the preferences plist file to the
script (I recommend dragging the plist from the Finder, but any way that
escapes spaces should work):</p>
<p><code>./fluid-defaults.sh ~/Library/Preferences/com.fluidapp.FluidApp.YouTube.plist</code></p>
<p>Happy browsing.</p>
<h2>Addendum - macOS Sierra (10.12)</h2>
<p>With macOS Sierra (10.12), the latest Fluid.app defaults to separate cookies
(which is no longer a premium feature). However, if you upgrade from OS X
10.11, you might be stuck with site-specific browsers based on Fluid 1.8.5,
and you might run across an issue which appears as though cookies have been
disabled across the board.</p>
<p>The short answer (staring me in the face at the top of <a href="http://fluidapp.com">http://fluidapp.com</a>)
is to upgrade your main copy of Fluid.app to 1.8.6, which has macOS Sierra
fixes, and then rebuild each of your site-specific browsers. (If you rename the
old browser apps, and recreate the new ones with the same names, they should
inherit the preferences. I kept the old browser apps around long enough to save
off their icons, then deleted them.)</p>
<p>The maddening part was that only certain sites exhibited the problem. Google
Calendar worked just fine, as did the Google account page within that app, but
both Gmail and Google+ got into a loop where they claimed that cookies were
not enabled (but would not allow me to click on the logout button). Another
well-known social media site did not exhibit any problems.</p>Sleepy Pi2015-10-14T20:48:50-04:00tag:www.ghz.cc,2015-08-16:charles/SleepyPi/<h2>Putting the Raspberry Pi to sleep</h2>
<p>As much as I wanted the <a href="https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html">SmartUPS</a> to work for the OspreyCam project, I
decided to take a look at the Spell Foundry <a href="http://spellfoundry.com/products/sleepy-pi/">Sleepy Pi</a> instead. The Sleepy
Pi is basically an Arduino board with regulators and switching transistors to
control the power to a <a href="https://www.raspberrypi.org/">Raspberry Pi</a> board. It also has a real-time
clock (RTC) chip, which will be handy for keeping track of the date when the
Raspberry Pi does not have an internet connection. The RTC can also be used
for waking up the Sleepy Pi (and optionally, the Raspberry Pi) at
predetermined times.</p>
<h2>Programming the Sleepy Pi</h2>
<p>I will admit, I am an Arduino novice. I keep looking around under the hood,
wanting to see the actual compiler and header files. But first things first.
To do anything more sophisticated than blinking an LED, you will need the
SleepyPi and RTC libraries:</p>
<div class="highlight"><pre><span class="nv">$ </span><span class="nb">cd</span> ~/sketchbook/libraries/ <span class="c"># created by Arduino IDE</span>
<span class="nv">$ </span>git clone -o github https://github.com/SpellFoundry/SleepyPi.git
<span class="nv">$ </span>git clone -o github https://github.com/SpellFoundry/DS1374RTC.git
<span class="nv">$ </span>git clone -o github https://github.com/rocketscream/Low-Power.git LowPower
<span class="nv">$ </span>git clone -o github https://github.com/PaulStoffregen/Time.git
</pre></div>
<p>The File/Examples/SleepyPi/ButtonOnOff example is a good place to start.</p>
<h2>Using the RTC in Raspbian</h2>
<p>Since the original <a href="http://spellfoundry.com/sleepy-pi/accessing-real-time-clock-raspberry-pi/">RTC on Raspberry
Pi</a>
instructions were published, Raspbian has undergone a change in the way that
peripherals are configured in the kernel. The I2C drivers are configured via
Device Tree blobs, rather than by passing options into the modules when they
are loaded.</p>
<p>According to this <a href="https://www.raspberrypi.org/forums/viewtopic.php?p=675658">Device Tree forum post</a>, the new way to enable I2C
is to add the following line to <code>/boot/config.txt</code>:</p>
<div class="highlight"><pre>dtparam=i2c_arm=on
</pre></div>
<p>Since I occasionally use the <a href="https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html">SmartUPS</a> for testing indoors, I use the
following line instead to drop the I2C baud rate to 50 kHz:</p>
<div class="highlight"><pre>dtparam=i2c_arm=on,i2c_arm_baudrate=50000
</pre></div>
<p>Since we're talking about editing <code>config.txt</code>, another thing I tend to tweak
is the camera LED:</p>
<div class="highlight"><pre># http://elinux.org/Rpi_Camera_Module
disable_camera_led=1
</pre></div>
<p>Also, the I2C /dev and RTC modules need to be loaded by adding the following
to <code>/etc/modules</code>:</p>
<div class="highlight"><pre>i2c-dev
rtc-ds1374
</pre></div>
<p>After making sure that <code>/etc/rc.local</code> is executable, add the following lines
before the <code>exit 0</code>, and reboot:</p>
<div class="highlight"><pre>echo ds1374 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
#printf "\nSetting system time from hardware clock\n"
#/sbin/hwclock -s
</pre></div>
<p>I commented out the call to <code>hwclock</code> because you will probably want to allow
the Raspberry Pi to grab the actual time from the internet via NTP, then call
<code>/sbin/hwclock -wu</code> to set the time in the RTC. After that, you can uncomment
the <code>/sbin/hwclock -s</code> and the line above it.</p>
<h2>Reference</h2>
<ul>
<li>The main <a href="http://spellfoundry.com/products/sleepy-pi/">Sleepy Pi</a> site</li>
<li>The <a href="https://www.raspberrypi.org/forums/viewtopic.php?p=675658">Device Tree</a> post on the Raspberry Pi Forums</li>
</ul>hibernatemode on a desktop Mac2015-08-06T09:56:21-04:00tag:www.ghz.cc,2015-02-14:charles/hibernatemode/<p>TL;DR: If you migrated system settings from a notebook Mac to a desktop, run
<code>sudo pmset -a hibernatemode 0 autopoweroff 0</code> on the desktop machine.</p>
<p>In 2014, I replaced a MacBook Pro 17" with a refurbished late 2012 Mac
Mini (Macmini6,2). One of these years I should probably ditch the home
directory that I have been carrying around since <a href="http://www.apple.com/osx/">Mac OS X</a> debuted, but at
the time, the MacBook was suffering from intermittent graphics card problems,
and needed to be replaced ASAP. Playing musical chairs with the contents of my
home directory really wasn't on the schedule.</p>
<p>Part of my thinking, actually, was that I really wanted the desktop to do the
heavy lifting, and that I needed something smaller for on the road. So I would
start with an empty home directory on the replacement portable.</p>
<p>The part I had not considered was that migrating the system settings from a
laptop to a desktop would bring along some laptop-specific power settings. In
particular, the Mac Mini started throwing all kinds of Sleep Wake Failure
errors, and the system spontaneously rebooted after a few of these
events. (I should have saved the logs, but I can't find them any more.) A bit
of digging, and one of the <a href="http://apple.stackexchange.com/questions/119423/random-restarts-with-sleep-wake-failure-error-on-mavericks/132738#132738">Apple support forums</a> recommended setting
hibernatemode to 0 on a desktop Mac. It sounded absurd that this would have
gotten changed, but sure enough, the migration to the Mini had brought along
the value of 3 for hibernatemode. According to the documentation:</p>
<blockquote>
<p>hibernatemode = 3 (binary 0011) by default on supported portables. The
system will store a copy of memory to persistent storage (the disk), and
will power memory during sleep. The system will wake from memory, unless a
power loss forces it to restore from disk image.</p>
</blockquote>
<p>No issues (knock on wood) since I changed back to the recommended default:</p>
<blockquote>
<p>hibernatemode = 0 (binary 0000) by default on supported desktops. The system
will not back memory up to persistent storage. The system must wake from
the contents of memory; the system will lose context on power loss. This
is, historically, plain old sleep.</p>
</blockquote>
<p>Running OS X 10.9.5.</p>OpenElectrons SmartUPS2017-06-25T22:52:16-04:00tag:www.ghz.cc,2014-09-30:charles/NUT/OpenElectrons_SmartUPS.html<p>I have been experimenting with a <a href="https://www.raspberrypi.org">Raspberry Pi</a> Model B and a Pi camera
board, and I wanted to make it slightly more portable. <a href="https://www.raspberrypi.org/magpi/issues/26/">Issue 26</a> of The
MagPi mentioned a new battery-powered <a href="tag/ups.html">UPS</a> with a USB power output,
so I decided to give that a try.</p>
<p>My main goals were to power the Pi on battery, and to have the Pi shut down
cleanly when the batteries were depleted. If I didn't want to worry about the
shutdown signal, almost any USB battery pack (for charging cell phones and
other portable electronics) would power the Pi. But I figured it would be
better to do a clean shutdown.</p>
<p>Enter the MindSensors.com (formerly OpenElectrons) <a href="http://www.mindsensors.com/rpi/41-uninterruptible-power-supply-for-raspberry-pi">SmartUPS</a>.
It takes three NiMH AA batteries, and it
can charge them when hooked up to an external USB power supply. With its
<a href="tag/i2c.html">I2C</a> control interface, you can query the battery status, and
command an early shutdown. A programmable button can also be queried for its
status. Similar to ACPI PCs, holding down the button performs a hard power-off.</p>
<p>The <a href="http://www.mindsensors.com/index.php?controller=attachment&id_attachment=124">SmartUPS documentation</a> claims that the UPS can supply 5V at 1.5A. While
I haven't measured the current draw of my Raspberry Pi setup, I have been
running it with a 5V/1A USB AC adapter with no issues. But when using the
SmartUPS on battery, high CPU load would cause USB devices to disconnect. Since
I typically log in with SSH over WiFi, this causes problems.</p>
<p>I contacted OpenElectrons support, and they worked with me to diagnose the
problem. They swapped my SmartUPS with a unit set to output a slightly higher
voltage, but that didn't completely solve the USB disconnection issues. Often,
the devices would reappear on the bus, but not in a way that would allow me to
log in again. Eventually, I sent them the Pi, the SmartUPS, and all of the
peripherals. They narrowed the issue down to one command that I was running as
part of a stress test (building <a href="http://www.networkupstools.org/">NUT</a>, actually), and the upshot was "don't
run that command". Time to set up a <a href="https://github.com/raspberrypi/tools/tree/master/arm-bcm2708">cross-compiler</a> on another box, I guess.</p>
<p>At any rate, I wrote a <a href="https://github.com/clepple/nut/tree/oe_smartups">driver</a> for the UPS. If you need a battery backup for
your Raspberry Pi, this is IMHO a decent solution. With the NUT driver (similar
to the closed-source vendor software), if your USB network devices do disconnect, you
can still hold down the SmartUPS power button, which signals <code>upsmon</code> to shut
down the Pi.</p>
<p>Commands to grab and build the driver:</p>
<div class="highlight"><pre>apt-get install git
apt-get build-dep nut
apt-get install libi2c-dev <span class="c"># new dependency for oe_smartups</span>
git clone https://github.com/clepple/nut.git
<span class="nb">cd </span>nut
git checkout oe_smartups
./autogen.sh
./configure --with-drivers<span class="o">=</span>oe_smartups,dummyups
make <span class="o">&&</span> sudo make install
</pre></div>
<p>The <code>ups.conf</code> file should look like this:</p>
<div class="highlight"><pre><span class="k">[smartups]</span>
<span class="na">driver</span> <span class="o">=</span> <span class="s">oe_smartups</span>
<span class="s"> port = /dev/i2c-1 # or /dev/i2c-0 if you have an old Raspberry Pi</span>
</pre></div>
<h2>Cross-Compilation</h2>
<p>These notes should be expanded into their own page, but until then:</p>
<p>To get autoconf to see additional libraries or headers, you can put them in the sysroot: <code>arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/arm-linux-gnueabihf/libc</code> (I am sure there is a better way.)</p>
<p>The autoconf invocation looks like this: <code>./configure --host=arm-linux-gnueabihf</code> (additional info from <a href="https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi">ffmpeg</a>).</p>
<h2>I2C and Device Tree</h2>
<p>Although the original I2C spec was designed for a clock speed of 100 kHz, it
seems that the SmartUPS cannot keep up at that speed. Symptoms include random
bit flips, noticeable on ASCII values such as the SmartUPS firmware version
string. (It is unclear whether the BCM2708 I2C master and/or the SmartUPS
support I2C clock stretching, which should solve this problem without slowing
down transfers to other devices on the bus.)</p>
<p>The January 2015 Raspbian update added Device Tree support, which ignores the
previous I2C settings in <code>/etc/modules</code> or <code>/etc/modprobe.d/*</code>. To force the
3.18+ kernel to drop back down to 50 kHz, add the following to
<code>/boot/config.txt</code>:</p>
<div class="highlight"><pre># Force BCM2708 ARM I2C controller to 50 kHz:
dtparam=i2c_arm=on,i2c_arm_baudrate=50000
</pre></div>
<p>More details are available on the <a href="https://www.raspberrypi.org/forums/viewtopic.php?p=675658">Raspberry Pi forums</a> or in
<code>/boot/overlays/README</code>.</p>
<h2>Power Draw</h2>
<p>This is also a section in search of a home, but if you are interested in
comparing the power consumption of the various members of the Raspberry Pi
family, you might be interested in this <a href="http://raspi.tv/2014/raspberry-pi-a-how-much-power-does-it-need">current draw comparison</a>.
Since I typically run with the WiFi dongle enabled, I would not see as much of
a savings by moving to a newer unit like the B+, but it's good to know for
reference.</p>
<h2>TODO</h2>
<ul>
<li>Auto-detect RPi I2C port</li>
<li>Split NUT I2C detection into kernel and user headers</li>
<li>Make I2C address configurable</li>
<li>Parse firmware version</li>
<li>Map startup options to NUT commands and settings</li>
<li>Find an appropriate variable for remaining charge time (including negative values)</li>
<li>Expose battery health</li>
<li>Add threshold for mapping battery health to RB status</li>
</ul>JTAG adapter for Digilent XC2-XL Xilinx CPLD board2014-09-23T22:44:17-04:00tag:www.ghz.cc,2014-09-23:charles/JTAG-XC2XL.html<p>Here are some notes for connecting a Digilent XC2-XL CPLD board to a standard
20-pin JTAG header.</p>
<p>Note that Pin 1 for J1 is at the bottom of the board, closest to the J1 label
(also has a square pad on the solder side).</p>
<p>In <a href="http://openocd.sourceforge.net/">OpenOCD</a> 0.8.0, the JTAG auto-detection misses the size of the XC2C256
Instruction Register (IR). It should be 8 bits, but autodetection sees it as 2,
and then prints an error later.</p>
<table>
<tr> <th># (20-pin)</th> <th>JTAG</th> <th>XC2-XL</th> <th># (J1)</th> </tr>
<tr> <td>1</td> <td>VREF</td> <td>VDD</td> <td>6</td> </tr>
<tr> <td>2</td> <td>VREF</td> <td>VDD</td> <td>6</td> </tr>
<tr> <td>3</td> <td>TRST_N</td> <td>NC</td> <td> </td> </tr>
<tr> <td>4</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>5</td> <td>TDI</td> <td>TDI</td> <td>2</td> </tr>
<tr> <td>6</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>7</td> <td>TMS</td> <td>TMS</td> <td>1</td> </tr>
<tr> <td>8</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>9</td> <td>TCK</td> <td>TCK</td> <td>4</td> </tr>
<tr> <td>10</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>11</td> <td>RTCK</td> <td>NC</td> <td> </td> </tr>
<tr> <td>12</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>13</td> <td>TDO</td> <td>TDO</td> <td>3</td> </tr>
<tr> <td>14</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>15</td> <td>SRST_N</td> <td>NC</td> <td> </td> </tr>
<tr> <td>16</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>17</td> <td>NC</td> <td>NC</td> <td> </td> </tr>
<tr> <td>18</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
<tr> <td>19</td> <td>NC</td> <td>NC</td> <td> </td> </tr>
<tr> <td>20</td> <td>GND</td> <td>GND</td> <td>5</td> </tr>
</table>Porsche 944 : Cruise Control2014-09-23T23:15:27-04:00tag:www.ghz.cc,2014-09-17:charles/Porsche/tempostat/<p>Note: nearly ten years after I sold the 944, I still get a fair number of
web visitors. I ran across the original servo and its controller in the
basement the other day, so I thought I'd post some updated commentary. The
original technical content is from 2003.</p>
<p>Here are the <a href="https://www.ghz.cc/charles/Porsche/tempostat/pins.html">pinouts for the servo and original
controller</a>.</p>
<p>I attempted to build a digital replacement for the mostly-analog tempostat
circuitry. The <a href="https://www.ghz.cc/charles/images/usb_dev_schem.pdf">schematic diagram of my replacement
board</a> is available. It used a PIC16C765
for low-speed USB 1.1 connectivity. In retrospect, this was a bad choice for
several reasons. The 'C7x5 series uses a UV-erasable EPROM (remember those?),
and the available bandwidth for low-speed USB was less than a high-speed RS-232
link. A Cypress EZ-USB would have provided higher-speed transfers, and I could
have used a serial EEPROM for code storage.</p>
<p>Here are the original <a href="https://www.ghz.cc/charles/Porsche/tempostat/PIC_pin_assignments.html">servo board pin
assignments</a>. The idea was to use
the 40-pin 16C765 for development, and drop in a smaller OTP 16C745 for the
final design.</p>
<p>And here is a diagram of the <a href="http://www.pelicanparts.com/944/944_parts/944_83-85/Pic143.jpg">cruise control mechanism</a>,
courtesy of Pelican Parts (servo is part 5).</p>
<p>Note that this entire discussion is based on the early 1985 model year. The
1985/2 and later have a two-part connector on the controller box, which might
be very different than this one.</p>Network UPS Tools2015-03-06T09:41:33-05:00tag:www.ghz.cc,2014-09-17:charles/NUT/<p>I have been involved with <a href="http://www.networkupstools.org/">Network UPS Tools</a>, an open-source
<abbr title="Uninterruptible Power Supply">UPS</abbr>
monitoring system, for about ten years. What started as a simple patch for one
of the serial UPS drivers turned into a full-fledged software engineering
experience, including setting up a continuous integration system with
<a href="http://buildbot.net/">Buildbot</a>, and a migration to Subversion, and subsequently, <a href="http://git-scm.com/">Git</a>
(via Eric S. Raymond's <a href="http://www.catb.org/esr/reposurgeon/">reposurgeon</a>).</p>
<p>Source code is hosted at <a href="https://github.com/networkupstools/nut">GitHub</a>.
Occasionally, I will post test code to my own Github
<a href="https://github.com/clepple/nut">repository</a>, but that usually gets merged
after testing.</p>Fink packages for EDA2015-02-25T10:02:35-05:00tag:www.ghz.cc,2014-09-05:charles/fink/<p>If you're looking for open-source Electronic Design Automation (EDA) software
that runs under <a href="http://www.apple.com/osx/">Mac OS X</a>, you've come to the right place.</p>
<p>Updated for OS X 10.10 (Yosemite).</p>
<p>My daily driver still runs 10.9, and I don't use the bindist, so bear in mind
that a few things might need to be adjusted. Feel free to email corrections to
the address shown at the bottom of <code>fink info geda-gaf</code>. The output of
<code>fink --version</code> is helpful.</p>
<ul>
<li><a href="https://www.ghz.cc/charles/fink/why.html">Why Fink?</a></li>
</ul>
<p>The rest of this page assumes that you have <a href="http://finkproject.org/">Fink</a>, Xcode, and Xquartz (X11 runtime) installed on your machine.</p>
<h2>Getting Started</h2>
<ul>
<li><a href="http://www.finkproject.org/download/index.php">Fink Download Quick Start</a></li>
<li><a href="http://www.finkproject.org/doc/users-guide/index.php">Fink User's Guide</a></li>
<li><a href="http://www.finkproject.org/doc/x11/intro.php">Fink Running X11 guide</a></li>
<li><a href="http://xquartz.macosforge.org/trac/wiki/X11-UsersFAQ">XQuartz FAQ</a></li>
<li><a href="http://finkcommander.sourceforge.net/">FinkCommander</a> is a nice shell around the Fink package build and installation process.
(Note: if you use FinkCommander's feedback feature, please describe the problem
you are having, or indicate if everything worked. Otherwise, I get confusing
blank emails.)</li>
</ul>
<h2>Binary Packages</h2>
<p>If you are running 10.10 (Yosemite), 10.9 (Mavericks) or 10.8 (Mountain Lion),
and you use the default Fink installation directory of <code>/sw</code>, you can use
<a href="http://bindist.finkmirrors.net">binary packages</a> instead of compiling from source.</p>
<h2>Building from Source</h2>
<p>Fink automates the process of downloading dependencies, patching if necessary,
and building binaries. In this regard, it is similar to <a href="http://www.macports.org/">MacPorts</a> or
<a href="http://brew.sh/">homebrew</a>. However, one distinction is that Fink stashes the resulting
build in Debian-style <code>.deb</code> files that can be managed with <code>dpkg</code>, and goes
to great lengths to ensure that nothing is stored outside of the installation
directory (<code>/sw</code> by default).</p>
<h3>The gEDA bundle</h3>
<p>When the gEDA suite consisted of many separate packages, it was convenient to have
a "bundle" package to update everything. Now, it is probably easier to install
the ones you need:</p>
<ul>
<li>geda-gaf</li>
<li>iverilog or iverilog-snapshot,</li>
<li>pcb</li>
<li>gerbv</li>
<li>ngspice</li>
<li>gtkwave</li>
</ul>
<p>After gEDA 1.6.0, gschem and friends (gaf) come in a single tarball.
If you only want the core gEDA packages, run <code>fink install geda-gaf</code>.</p>
<p>Project web site: <a href="http://www.geda-project.org">http://www.geda-project.org</a></p>
<p>Fink package database:
<a href="http://pdb.finkproject.org/pdb/package.php/geda-gaf">geda-gaf</a></p>
<h3>ngspice</h3>
<p>Use ngspice for your analog and mixed-signal simulations. Currently
maintained by David Fang.</p>
<p>Project web site: <a href="http://ngspice.sourceforge.net/">http://ngspice.sourceforge.net/</a></p>
<p>Fink package database:
<a href="http://pdb.finkproject.org/pdb/package.php/ngspice">ngspice</a></p>
<h3>pcb</h3>
<p>PCB allows you to design printed circuit boards. You can use gnetlist (part of
geda-gaf) to create a netlist to ensure that your PCB matches a schematic
diagram created with gschem. You can then use gsch2pcb to forward-annotate the
PCB with part footprint and attribute information from your schematic.</p>
<p>Project web site: <a href="http://pcb.geda-project.org/">http://pcb.geda-project.org/</a></p>
<p>Fink package database: <a href="http://pdb.finkproject.org/pdb/package.php/pcb">pcb</a></p>
<h3>gerbv</h3>
<p>Once you have laid out the entire circuit, you will probably want to generate
Gerber files and verify them. That's where gerbv comes in handy.</p>
<p>Project web site: <a href="http://gerbv.sourceforge.net">http://gerbv.sourceforge.net</a></p>
<p>Fink package database: <a href="http://pdb.finkproject.org/pdb/package.php/gerbv">gerbv</a></p>
<h3>Icarus Verilog</h3>
<p>Icarus Verilog is a <a href="http://en.wikipedia.org/wiki/Verilog">Verilog</a> simulation and synthesis engine. Mac OS X support
has been in Icarus for a while; however, this Fink package makes it easier to
deal with the library and tool dependencies.</p>
<p>Project web site: <a href="http://iverilog.icarus.com/">http://iverilog.icarus.com/</a></p>
<p>Fink package database:
<a href="http://pdb.finkproject.org/pdb/package.php/iverilog">iverilog</a></p>
<p>If you are interested in the latest development version of Icarus, you can see
if the snapshot package has been updated.</p>
<p>Project web site: <a href="ftp://icarus.com/pub/eda/verilog/snapshots/">ftp://icarus.com/pub/eda/verilog/snapshots/</a></p>
<p>Fink package database:
<a href="http://pdb.finkproject.org/pdb/package.php/iverilog-snapshot">iverilog-snapshot</a></p>
<p>You may also be interested in the <a href="https://github.com/steveicarus/ivtest">Icarus Verilog testbench</a>. I try to
include testbench results in the <a href="http://fink.cvs.sourceforge.net/fink/dists/10.7/stable/main/finkinfo/languages/iverilog-snapshot.info?view=log">commit logs</a> when I update the iverilog and
iverilog-snapshot Fink package files.</p>
<h3>GTKWave</h3>
<p>GTKWave is a fully featured GTK+ based wave viewer for Unix and Win32 which
reads LXT, LXT2, VZT, FST, and GHW files as well as standard Verilog VCD/EVCD
files, and allows their viewing.</p>
<p>Project web site: <a href="http://gtkwave.sourceforge.net">http://gtkwave.sourceforge.net</a></p>
<p>Fink package database:
<a href="http://pdb.finkproject.org/pdb/package.php/gtkwave">gtkwave</a></p>
<h2>Disclaimer</h2>
<p>No warranties, etc. [insert boilerplate legal text here] I only wrote the
Fink description files, not the software-- it is your responsibility to check
each package for license information. If it breaks, you get to keep the
pieces.</p>Fink packages for EDA: Why?2006-09-26T00:00:00-04:00tag:www.ghz.cc,2006-09-26:charles/fink/why.html<h2>Why Fink?</h2>
<p>It took a bit of arm-twisting for me to realize why anyone would want a
packaging system on OS X. After all, it goes against the idea that we can just
move app bundles wherever we want. Or, we could just compile from source, like
people did for years on SunOS and IRIX (before Linux and the explosion of
package management systems).</p>
<p>OS X has a unique BSD heritage, and there are more quirks than you can shake a
stick at. It's a small price to pay for the legendary Apple GUI, but working
around those quirks for each new program can be tedious.</p>
<p>If you only install one or two Unix-style (versus Mac-style) programs from
source, you probably won't find Fink to be worth the trouble. On the other
hand, if doing something more than a couple of times in a shell makes you
think, "I could write a Perl script to do that...", then you might benefit from
the automation that Fink provides.</p>
<h2>Why compile from source?</h2>
<p>Fink provides a great environment for making sure that your compile goes
smoothly (assuming the packager did their job correctly). But in the end, you
have a bunch of binary packages that you could have just downloaded from
somewhere. Why would you bother with compiling from source, given the added
time and chance for error?</p>
<p>Part of the beauty of open source software is that you don't have to wait for
an officially sanctioned release to get bug fixes. You can get your hands
dirty, and fix it yourself, if you are so inclined. (Often, patches will
surface on a mailing list.) And the binary packages are almost never as current
as the source code.</p>
<h2>What on earth inspired you to do this?</h2>
<p>I'm not totally sure. Back in grad school, when time was more abundant than
money (but after I had already purchased a Mac), I worked on various
electronics design projects. Since my Mac was several times faster than my
laptop, I wanted to have access to the same EDA tools that I had in Linux, but
without installing Linux on the Mac. (I'm a sucker for Aqua.)</p>
<p>Common sense would have dictated that I stop after I got them to compile once,
but eventually I put together some Fink packages.</p>Porsche 944 information2006-05-21T00:00:00-04:00tag:www.ghz.cc,2006-05-21:charles/Porsche/<p>I used to own an early '85 Porsche 944.</p>
<p><img alt="Porsche 944" src="https://www.ghz.cc/charles/images/car.jpeg" /></p>
<p>The <a href="https://www.ghz.cc/charles/Porsche/tempostat/">cruise control</a> was a little flaky, so I decided
to take it apart.</p>PIC16C765 Pin Assignments2002-11-01T00:00:00-05:00tag:www.ghz.cc,2002-11-01:charles/Porsche/tempostat/PIC_pin_assignments.html
These pin assignments are for the <a href="https://www.ghz.cc/charles/Porsche/tempostat/">replacement PIC board</a> that I tried to build.
<table cellpadding="2" cellspacing="2" border="1" width="100%">
<tbody>
<tr>
<th valign="top">Function<br>
</th>
<th valign="top">Pins<br>
</th>
<th valign="top">'745?<br>
</th>
<th valign="top">Notes<br>
</th>
</tr>
<tr>
<td valign="top">USB status lights<br>
</td>
<td valign="top">RD0-7/RB0-7<br>
</td>
<td valign="top">B<br>
</td>
<td valign="top">no changes in firmware if RB0-7 are used (jumper
provided)<br>
</td>
</tr>
<tr>
<td valign="top">Servo H-bridge PWM<br>
</td>
<td valign="top">RC0-2<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top">PWM on CCP1 (?)<br>
</td>
</tr>
<tr>
<td valign="top">H-bridge current sense<br>
</td>
<td valign="top">(2 AN)<br>
</td>
<td valign="top">no<br>
</td>
<td valign="top">AN6, AN7, <br>
</td>
</tr>
<tr>
<td valign="top">H-bridge temp flags<br>
</td>
<td valign="top">(1)<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Solenoid driver<br>
</td>
<td valign="top">(1)<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr>
<td valign="top">Servo feedback<br>
</td>
<td valign="top">(1 AN)<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top">AN0<br>
</td>
</tr>
<tr>
<td valign="top">Cruise control switches<br>
</td>
<td valign="top">RB2-7 (5)<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top">int-on-change: [cancel, clutch, brake], accel, resume
</td>
</tr>
<tr>
<td style="vertical-align: top;">Speed sensor<br>
</td>
<td style="vertical-align: top;">T0CKI<br>
</td>
<td style="vertical-align: top;">yes<br>
</td>
<td style="vertical-align: top;"><br>
</td>
</tr>
<tr>
<td valign="top">DIP switches<br>
</td>
<td valign="top">RD0-7, RE2<br>
</td>
<td valign="top">no<br>
</td>
<td valign="top">reading will cause LEDs to blink switch setting<br>
</td>
</tr>
<tr>
<td valign="top">LCD interface - serial<br>
</td>
<td valign="top">RC6, RC7<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top">can use I2C, wide voltage VFD<br>
</td>
</tr>
<tr>
<td valign="top">ICD/ICP connector<br>
</td>
<td valign="top">MCLR, RB{3,6,7}<br>
</td>
<td valign="top">yes<br>
</td>
<td valign="top">will need to pull LED resistor pack<br>
</td>
</tr>
</tbody>
</table>
Parallel Port Info2001-12-09T00:00:00-05:00tag:www.ghz.cc,2001-12-09:charles/pport.html
<h1>Parallel Port Miscellany</h1>
by Charles Lepple<br>
<h1>Introduction</h1>
<p>
Parallel port documentation for IBM PC compatibles can be
inconsistent. Most sources quote other sources, and little
information is based on first-hand experience. This document is meant
to remedy this shortfall.</p>
<h1>Overview</h1>
<p>
The PC parallel port outputs TTL-compatible logic signals, although
in most computers, the signal levels are much closer to 5
volts than ordinary TTL circuits generate. </p>
<p>
There are five basic types of parallel ports: standard, PS/2,
bidirectional, EPP and ECP. My personal experience so far has
only been with the standard and bidirectional parallel ports,
although I may be able to provide some EPP data in the
future. The IEEE-1284 standard, which covers all of the common
parallel port de facto standards, recommends that the EPP and
ECP be backwards compatible with legacy hardware, so
enhancements will not conflict with predefined functionality.
The difference is that the standard port provides eleven
outputs and five inputs (a state which caters towards
output-only devices such as parallel printers), where the
enhanced parallel ports (EPP) provide an eight-bit wide
bidirectional data path, plus some enhancements associated with
bidirectional communication. The ECP is in a class of its own,
providing protocols for multiple devices, ultra-fast and
efficient transmission with compression, et cetra.</p>
<h1>Details</h1>
<h2>Pin Assignments</h2>
<p>
The connector on the back of the computer is a male 25 pin
job. You need a female 25 pin connector to interface. You can
use an IDC connector (crimps onto ribbon cable), or you can be
sensible and get some wire and solder it to a DB-25F connector
(<$3 at Radio Shack). I find that UTP wire (4 twisted pairs,
approx. 28 gauge) works nicely. You will need several doubled
lengths, fastened at regular intervals.</p>
<center>
<table border="1">
<tr> <td colspan="4">Pins on DB-25 on computer side</td> </tr>
<tr> <th>Pin #</th><th>Function</th>
<th>Direction</th><th>Inverted</th></tr>
<tr> <td>1</td> <td>*Strobe</td> <td>out</td> <td>yes</td> </tr>
<tr> <td>2</td> <td>Bit 0</td> <td>out</td> <td>no</td> </tr>
<tr> <td>3</td> <td>Bit 1</td> <td>out</td> <td>no</td> </tr>
<tr> <td>4</td> <td>Bit 2</td> <td>out</td> <td>no</td> </tr>
<tr> <td>5</td> <td>Bit 3</td> <td>out</td> <td>no</td> </tr>
<tr> <td>6</td> <td>Bit 4</td> <td>out</td> <td>no</td> </tr>
<tr> <td>7</td> <td>Bit 5</td> <td>out</td> <td>no</td> </tr>
<tr> <td>8</td> <td>Bit 6</td> <td>out</td> <td>no</td> </tr>
<tr> <td>9</td> <td>Bit 7</td> <td>out</td> <td>no</td> </tr>
<tr> <td>10</td> <td>*Ack</td> <td>in</td> <td>no</td> </tr>
<tr> <td>11</td> <td>Busy</td> <td>in</td> <td>yes</td> </tr>
<tr> <td>12</td> <td>PE</td> <td>in</td> <td>no</td> </tr>
<tr> <td>13</td> <td>Select</td> <td>in</td> <td>no</td> </tr>
<tr> <td>14</td> <td>*AutoFd</td> <td>out</td> <td>yes</td> </tr>
<tr> <td>15</td> <td>*Error</td> <td>in</td> <td>no</td> </tr>
<tr> <td>16</td> <td>*Init</td> <td>out</td> <td>no</td> </tr>
<tr> <td>17</td> <td>*Select</td> <td>out</td> <td>yes</td> </tr>
<tr> <td>18-25</td> <td>Ground</td> <td></td> <td></td> </tr>
</table>
</center>
<p>
These pins have special meaning if you are planning to use the
port through special interfaces such as the BIOS or your OS's
printer devices. Usually, one uses direct port output and
ignores the services tailored to printer-type devices (unless,
of course, you are building a printer-like device).</p>
<p>
In the names above, a leading asterisk denotes a signal which
the printer interprets as "active low".</p>
<p>
In case you're interested, here are the meanings of the signal
names. "*Strobe" is the signal which indicates to the printer
that the data is valid. "*Ack" is acknowledge, "Busy" is
obvious, "PE" indicates a "paper empty" condition, "Select" (the
incoming signal) would normally mirror the "online" light on a
printer, indicating that the printer is ready, "*Select" goes
high to prevent a printer from acting on data, but printers
usually have a dip switch to override this signal. "*AutoFd" has
to do with whether a line feed is added after a carriage return,
"*Fault" indicates a general error, "*Error" is obvious, and
"*Init" resets the printer.</p>
<h2>Port Locations</h2>
<p>
Port address assignments are a bit unusual. The BIOS searches in
a predetermined order, and assigns numbers (in the range 0-2 in
a usual setup) only to ports which exist. Restated, if you have
a port at 0x3BC and a port at 0x278, they are numbered 0 and 1
respectively, regardless of the fact that there is no port at
0x378 (which is usually assigned 0 or 1, depending on the
existence of a port at address 0x3BC). DOS device names are
formed by appending the BIOS number, plus one, to "LPT". LPT1 is
also designated "PRN" for convenience.</p>
<p>
The rationale is this: address 0x3BC is reserved for parallel
ports integrated into the motherboard or on a display adapter
(usually only on obselete ones such as the Hercules Graphics
Card or IBM's veritable Monochrome Display
Adapter). Multifunction add-on boards usually use the next two
sets of addresses.</p>
<p>
If you program for an operating system which allows access to
the BIOS data tables (ie DOS, or a DOS emulator), you can
examine memory at segment 0x40, offsets 0x8, 0xA and 0xC, which
are hex words with the base port addresses of BIOS printers
numbers 0, 1 and 2 respectively.</p>
<center>
<table border="1">
<tr> <th>Port numbers</th> <th>IRQ</th> </tr>
<tr> <td>0x3BC-0x3BE</td> <td>?</td> </tr>
<tr> <td>0x378-0x37A</td> <td>7</td> </tr>
<tr> <td>0x278-0x27A</td> <td>5</td> </tr>
</table>
</center>
<p> To test if the port exists, write a zero to the first address
given. If it returns zero, you might have a parallel port. If it
returns anything else, you either don't have a parallel port at
that address, or it is too broken to use. A hex value of "FF"
usually means that you've got a wrong number and nobody lives
there. This is because the TTL buffers used on the address busses
interpret a lack of a device as a "high" value (hence 0xFF, or all
high bits).</p>
<h2>Port Functions</h2>
<p>
These are the pins controlled by the three port locations. The
"base" value is the first port listed in the list above.</p>
<center>
<table border="1">
<tr> <th></th> <th>Dir.</th> <th>bit 7</th> <th>bit 6</th> <th>bit
5</th> <th>bit 4</th> <th>bit 3</th> <th>bit 2</th> <th>bit 1</th>
<th>bit 0</th> </tr>
<tr> <th>base+0</th> <td>out</td> <td>p.9</td>
<td>p.8</td> <td>p.7</td> <td>p.6</td> <td>p.5</td> <td>p.4</td>
<td>p.3</td> <td>p.2</td> </tr>
<tr> <th>base+1</th> <td>in</td> <td>p.11</td> <td>p.10</td>
<td>p.12</td> <td>p.13</td> <td>p.15</td> <td>n/c</td>
<td>n/c</td> <td>n/c</td> </tr>
<tr> <th>base+2</th> <td>out</td> <td>n/c</td> <td>n/c</td>
<td>n/c</td> <td>I.E.</td> <td>p.17</td> <td>p.16</td>
<td>p.14</td> <td>p.1</td> </tr>
<tr> <th>value</th> <td><center>-</center></td> <td>128</td>
<td>64</td> <td>32</td> <td>16</td> <td>8</td> <td>4</td>
<td>2</td> <td>1</td> </tr>
</table>
</center>
<p>
Where "n/c" stands for "no connection" and "I.E." stands for
"interrupt enable". The interrupt occurs on the negative-going
transition of the *Ack pin if bit 5 of (base+2) is on. The
interrupt number is the IRQ number plus 8, and the IRQ is listed
in the table above.</p>
<p>
When you read from (base+0), you get either zero or what you
wrote before, depending on the port. When you read from
(base+2), you usually get what you wrote before. In any case,
the output bits are all latched, and the input bits are
<strong>not</strong> debounced. To keep track of the status of
the output ports, keep their values in global variables in your
program. This way, you do not need to read the ports (which
might return zero on some machines) to find what has been
latched at the outputs.</p>
<h1>Guidelines</h1>
<p>Here are some miscellaneous points to keep in mind.</p>
<ul>
<li> You need an external power supply. Your computer would
prefer it to be in the vicinity of 5 volts.
<li> Use buffers so as not to damage the port. Some buffers
are more sensible than others. For instance, the 74LS54x
series has inputs on one side, and outputs on the other. The
LS540 inverts, and the LS541 does not.
<li> Nothing is better than experimentation. Intelligent
experimentation is more effective, though. Be a rebel and use
</code>DEBUG</code> in DOS, or write a PERL script to write to
the <code>/dev/port</code> device in Linux.
<li> If you do use an advanced operating system such as Linux or
a flavor of BSD, there are calls to allow access to ports and
also to access the ports individually. However, direct port
access in a multi-user O/S usually requires superuser
priveledges, and as such is a possible security hole. Write a
device driver, using the printer driver as an example. For
instance, in Linux, one need only to make the "lp" driver a
module, and then recompile and insert it into the kernel while
it is running. This allows for easier development when you do
not have root access to try a standalone program.
</ul>
<ul>
<li> <b>Update:</b> You may want to check out Tim Waugh's
<a href="http://cyberelk.net/tim/libieee1284/">libieee1284</a>
as a nice structured alternative to directly frobbing
<code>/dev/port</code> or other such silliness. I no
longer use a PC as my primary desktop machine, so I have
not tried this library myself. YMMV.
<li> Svein Erlang Seldal has written a kernel driver to talk
to TI TMS320C31 DSKs over the parallel port. You may wish to
take a look at his code. The home page is
<a href="http://www.omegav.ntnu.no/~sveinse/dsktools.html">here</a>.
</ul>
<h2>Extended features of the EPP</h2>
<p>
The EPP uses eight control ports as opposed to the three ports
used by standard parallel ports. The first three are the same as
those used by the standard port, and the next is used as an
address port to send a device address out over the port. The
next four ports can be written to as a double-word, word or byte
port, and the port's driver chip sends four, two or one bytes
with corresponding strobe signals. This allows for much faster
transfer than if the program must manually pulse *Strobe low
then high after every character. Unfortunately, there is very
little documentation available for this version. Maybe next
time.</p>
Porsche 944 : Cruise Control : Pinouts2001-10-17T00:00:00-04:00tag:www.ghz.cc,2001-10-17:charles/Porsche/tempostat/pins.html
<h2>944, '83-'85</h2>
<table border="1">
<tr>
<th align="center" colspan="4"> Pin</th>
<th rowspan="2"> Function </th> <th rowspan="2">Sense</th>
</tr>
<tr>
<td align="center">servo</td><td> color</td><td> gender</td>
<td align="center">controller</td>
</tr>
<tr><td colspan="3" align="center">-</td><td align="center"> 1 </td><td> V+ </td> <td>(tied to ignition)</td> </tr>
<tr><td colspan="3" align="center">-</td><td align="center"> 3 </td><td> Cancel button</td> <td>normally tied to V+</td></tr>
<tr><td colspan="3" align="center">-</td><td align="center"> 4 </td><td> Accelerate button </td><td>tied to V+ when pressed</td></tr>
<tr><td colspan="3" align="center">-</td><td align="center"> 6 </td><td> Resume button </td><td>tied to V+ when pressed</td></tr>
<tr><td colspan="3" align="center">-</td><td align="center"> 14 </td><td> Clutch disable switch </td><td> normally tied to ground </td></tr>
<tr><td colspan="3" align="center">-</td><td align="center"> 11 </td><td> Hall effect sensor </td><td> low: < 1V; high: > 6V (on front left wheel) </td></tr>
<tr><td align="center">7</td><td>purple</td><td align="center"> M </td><td align="center"> 10 </td><td> Servo motor + </td><td> 3-15 Ohms</td></tr>
<tr><td align="center">1</td><td>orange</td><td align="center"> M </td><td align="center"> 7 </td><td> Servo motor - </td><td> </td></tr>
<tr><td align="center">4</td><td>red</td><td align="center"> F </td><td align="center"> 9 </td><td> Potentiometer + </td><td> 2-4 kOhm </td></tr>
<tr><td align="center">3</td><td>green</td><td align="center"> F </td><td align="center"> 13 </td><td> Potentiometer wiper </td><td> </td></tr>
<tr><td align="center">6</td><td>blue</td><td align="center"> M </td><td align="center"> 8 </td><td> Brake lights </td><td>tied to V+ when brakes activated</td></tr>
<tr><td align="center">5</td><td>brown</td><td align="center"> M </td><td align="center"> 5 </td><td> Servo clutch </td><td> 12V (?), 30-40 Ohms </td></tr>
<tr><td align="center">2</td><td> black</td><td align="center"> F </td><td align="center"> 12 </td><td> Ground </td><td> (chassis) </td></tr>
</table>