HDMI-VGA adapter for Raspberry Pi

This year Santa left an HDMI to VGA adapter under the christmas tree. I have an old LCD monitor with only a VGA input while the Raspberry Pi and Beagleboard/Beaglebone boards only have HDMI outputs.
The specific adapter is under $10 from seeedstudio.com, although I see a bunch of others on ebay and other sites that look similar.
Setup on the Raspberry Pi was pretty easy - only one Google search. Had to edit the /boot/config.txt file to force the Pi to use the HDMI output and to set the screen resolution (both VGA and HDMI can report screen resolution back to the host, but it doesn't seem to happen with this setup).
Configuration info was found at www.raspberrypi.org/forums/viewtopic.php?p=269212.
Internally the adapter is just a Chrontel CH7101A chip to do the HDMI-VGA conversion, and an Everest Semiconductor ES7144LV audio output chip. My unit pulls about 180 milliAmps from the +5 volt output of the HDMI connector. That's way more than the 50 mA maximum (according to Wikipedia), but the Pi is driving it without any problems. I haven't tried the adapter with Beagles yet, but research so far indicates that they require an externally powered adapter because they can't supply enough current via HDMI.
Caution: poking around inside will most likely void the warranty and might smoke the adapter and/or the Beagleboard. You're on your own if you try something like this:
Interestingly, there's space on the lower right corner of the PCB for a USB connector as an alternate +5 input. I took out the zero-ohm resistor (R1, just to the left of the USB connector footprint), and brought out 3 wires: Ground, HDMI +5 out, and +5 power in. Now I can just connect the +5's together for the Pi and should be able to use external power for the Beagles.

Debian on BeagleBoard classic.

I have one of the original beagleboards with the omap3 processor, which is ARM+DSP coprocessor. Originally it used the Angstrom Linux distribution, which uses bitbake to build the kernel and all related software tools. I saw recently that Debian is now supported on this device; I like to run Debian on everything including my PC's, BeagleBone Black, and Raspberry Pi (raspbian - almost Debian), so why not on the beagleboard as well?
My hardware setup is a USB-serial adapter from a Linux (Debian, of course) host to the serial port of the Beagleboard. I also have a Sabrent USB-Ethernet adapter on the Beagleboard.
The "official" instructions seem to be at elinux.org/BeagleBoardDebian, which I found from beagleboard.org/project/debian. Per those instructions, I downloaded the netinstall package from github.com/RobertCNelson/netinstall (using git of course), and put it on a 16GB SD card using the command:

sudo ./mk_mmc.sh --mmc $SDCARD --dtb omap3-beagle --distro wheezy-armhf --firmware --serial-mode

On my PC I have SDCARD=/dev/sdb, because that's where the memory card shows up when it's plugged in. MAKE SURE you get this right, because you could wipe out a disk on the PC if you get it wrong. I decided to uses the --serial-mode option to work from the serial port and avoid any HDMI display issues.
Moved the SD card from the PC to Beagleboard, powered up, and got a typical Debian install menu on the serial port! I used

minicom -D /dev/usb/prolific2303 -b 115200 -o

to connect to the USB-serial port. The Beagleboard serial port does not use the modem control lines, so had to turn off the "Hardware Flow Control" and "Modem has DCD" options in minicom.
The netinstall process was just like installing Debian on a PC: select some options and wait for it to download a bunch of packages. It found the Sabrent ethernet and used it with no problem; device usb0 shows up as a network device as well, so it should be possible to install by using a USB connection to the PC host, but I didn't try that.
Finished the install, rebooted the Beagleboard, aaaannnd - nothing happened!!! Load process just stopped in uboot. After a few hours of screaming, hair-pulling, and spelunking in uboot macros, I found the problem:
I had set up /boot as a separate partition.
The uboot macros look for  /boot/uEnv.txt on each partition and then boot Linux using that partition as the root partition. Made /boot a normal directory instead of a mount point, patched up /etc/fstab, and uboot brought up Debian with no problem.
Did my usual Debian tweaks (sensicomm.blogspot.com/2013/01/my-debian-tweaks.html) and everything seems to be working as expected.

Goats and Coffee

OK, this post is way off normal topics. Last month my wife and I were part of a team that visited a non-government organization working on economic development in Guatemala. The project related to raising goats and fighting the coffee rust fungus that's been causing so many problems in Central America.
I put together a writeup that gives more background on the problem and how it's being approached: www.rothweiler.us/guatemala-2014 .
It's outside my area of expertise, but looks like an interesting approach that makes good use of local resources. Comments (positive or negative) from folks with more experience are welcome.

Parallel port jtag

I've been using a homebrew version of the Xilinx DLC5 parallel port jtag adapter for programming my fpga boards. The DLC5 is no longer supported by Xilinx, but some Linux jtag programmers still support it.
Recently I moved to a new PC, and my DLC5 hack no longer works with that parallel port. I can see on the scope that the right pins are moving, but the chip won't program. I suspect that either the rise and fall times are too slow, or there's noise on the signal lines.
Anyway, I had a sample of the SiLabs si8663 digital isolator, so I decided it's time to build a new interface. The Si8663 is a hex isolator (3 signals each direction), that's spec'ed to operate up to 150 Mbps bit rate (WAY more than needed for this app). Another neat feature is that the drivers on each side work from 2.5 to 5.5 volts, providing a level shifter at no extra charge.
Board is available on OshPark (www.oshpark.com) for anyone interested. Project name is "isopartag 140513". Circuit's simple: chip + 4 bypass caps on the bottom. The design includes resistors to tap power from unused pins of the parallel port, but they haven't been added yet, to that feature is untested. For now I just tap 5 volts from an unused keyboard or mouse port.
Caution:The Si8663 comes in two versions: a wide body for safety isolation, and a narrow body intended more for electrical noise isolation. I'm using the narrow version, and the board is not designed with wide separation between the input and output sides. In other words, this design is for low voltages only, don't use it where safety is an issue.

via-rhine in Debian Wheezy

This blog post is only of interest to a small handful of people,  but since you found it, it might be you :). As always with system changes, there's a chance of damage or data loss. So check your backups first.

I have an old Averatec notebook that I use for travel and when I don't want to take risks with my main PC. I'm planning a trip so it's time to update to the latest debian distribution. After the update, everything seems to work, except the via-rhine wired ethernet.
The symptoms appear similar to Debian bug report 708757 . After a lot of hacking and experimenting, I finally upgraded to the latest kernel in wheezy-backports and the problem went away.

Details:

lspci shows the device as:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

It does work with Debian kernel packages:
 linux-image-2.6.32-5-686  # Old, from previous Debian distribution.
 linux-image-3.14-0.bpo.1-686-pae # Very latest, bleeding edge.

And does not work with
linux-image-3.2.0-4-686-pae # debian stable kernel for my system.

Fix:

To get the very latest kernel, you need the backports repository. Best instructions I found were:
scottlinux.com/2013/11/23/how-to-install-newer-kernel-from-debian-wheezy-backports
 Basically,
1) add wheezy-backports to /etc/apt/sources.list
2) apt-get update
3) apt-get -t wheezy-backports install linux-image-3.14-0.bpo.1-686-pae
4) done. reboot to use the new kernel.

Cleanup:

One side effect of the bug is that it returns a wrong and somewhat random MAC address for the ethernet controller. Recent versions of Debian try to ensure that each MAC address is always associated with a consistent eth* number. So each random mac address gets assigned to a new eth* number. If this is happening the output of dmesg will show messages like:

udev: renamed network interface eth0 to eth7

Every time udev sees a new MAC address it adds it to /etc/udev/rules.d/70-persistent-net.rules,
so the fix is to edit that file and remove all the junk MAC addresses.


Xilinx Spartan-3 I/O timing

Working on updating the MHZ100Q project, and one significant design issue is I/O delay. To review, the Xilinx Spartan-3A FPGA generates a 100MHz clock using an internal DCM block, and this clock drives an external 100MHz A/D converter. The total delays through the output buffer, A/D clock to output pins, and FPGA input buffer add up to 9 to 16 ns, while the clock cycle time is 10 ns. So aligning the clock and data at the input latch is tricky.
Per the A/D data sheet, the value on the output pins is stable for about 5ns (minimum) and the FPGA data sheet says the latches need about 1ns to capture the value (setup+hold times from the clock edge). So we have a 4 ns window in which everything will work right.
It's hard to measure the actual offset at the internal latch input of the FPGA, so for initial setup I would like to be able to adjust the phasing of the A/D clock relative to the internal latch clock over the full 10 ns range.
First option is to use the built-in delays. The *.ucf file supports the per-pin specifications IFD_DELAY_VALUE and IBUF_DELAY_VALUE which put variable amounts of delay between the input pin and the logic (the former applies when using the latch built-in to the I/O Block, and the latter applies when the I/O Block is just used as a buffer). Total adjustment range is about 2 ns, which might be enough.
Next step up in complexity is to use the Digital Clock Module (DCM) to adjust the phase of the generated clock. The DCM can produce essentially any clock phase, but for this application, I think I can just use the 4-phase quadrature outputs. That gives me effectively 0 2.5, 5, 7.5 ns adjustment points, and combined with the IFD_DELAY_VALUE, I can get within 0.5 ns of any required timing offset.

Widgets

Just posted a couple of little designs: a switching power supply and a wideband preamp. Blank pcb's are available from Oshpark www.oshpark.com/profiles/sensicomm , and my documentation is at http://mhz100q.sourceforge.net/widgetries.shtml . Mostly for my own tests and experimentation, but others might find them useful.

STM32 on Linux, again.

Starting another project using the STM32 micro, so time to update and reinstall the toolchain. This is an update to my previous post on the topic at http://blog.sensicomm.com/2012/01/stm32-stm32f4discovery-arm-eval-board.html

Compiler

Previously I used the summon-arm gersion of GCC http://summon-arm-toolchain.org/
but the git repo says it's "not under active development" any more. They recommend https://launchpad.net/gcc-arm-embedded , which seems to be an offically ARM-supported
version.

It looks like Debian has packaged the launchpad version into the "unstable" branch: http://packages.debian.org/sid/gcc-arm-none-eabi but I'm running "stable" so I got it directly from launchpad instead. Install was simple:

• Download  gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
• unpack in /opt,
• add to PATH
• Create symlink:  cd /opt && ln -s gcc-arm-none-eabi-4_8-2013q4 gcc-arm-none-eabi

That's my setup, the chosen directory is just a matter of personal preference.

Programming tools:

I'm using the STM32F4DISCOVERY board for development, so there are two ways to get code
into the chip:

1. Use the st-link USB input to the built-in programming hardware.
2. Connect directly to the USB port of the STM32F4 chip and use dfu-util.

I used dfu-util before. That's now in Debian, and should still work but I haven't retested it.



Code for the st-link interface is available and built with no problem:

• git clone git://github.com/texane/stlink.git stlink
• cd stlink && ./autogen.sh && ./configure && make && make install

Programs are installed in /usr/local/bin: st-flash st-info st-term st-util

An example was successfully placed in flash using:
st-flash write *.bin 0x8000000

Libraries:

The open source libraries and examples at http://libopencm3.org/wiki/Downloads built without problem using the launchpad compiler. My build command was:
PATH=/usr/bin:/bin:/opt/gcc-arm-none-eabi/bin DESTDIR=/opt/libopencm3 make install

ST has standard peripheral library source code on their website, but it doesn't come with Makefiles. A USB serial example at http://vedder.se/2012/07/usb-serial-on-stm32f4/ includes some (all?) of the ST libraries and compiles fine with the launchpad compiler. I downloaded and unpacked STM32F4_USB_CDC.zip and "make" ran without problems. I only had to change the top-level Makefile so that BINPATH points to the directory that arm-none-eabi-gcc is in
(BINPATH=/opt/gcc-arm-none-eabi/bin for my install).

HDMI Breakout Part 2

 I see the PCB in my Nov 6, 2013 post is getting some interest, so here's more info about it. The image to the left is a Kicad screenshot. The breakout connector (P1, CONN_5X2) is at the top, and pin 1 is the top right pad. Odd-numbered pins on top, and even-numbered on the bottom.
Top connections are:
1 Ground
3 HOTP-J
5 DCC_D-J1
7 DCC_C-J1
9 CEC-J1
and the bottom connections are:
2 +5V (J1 and J2 both)
4 HOTP-J2
6 DCC_D-J2
8 DCC_C-J2
10 CEC-J2

So to use the board as a passthrough connection, add jumpers connecting 3-4, 5-6, 7-8, and 9-10. Obviously, it's NOT a good idea to have a jumper connecting 1 and 2 (ground and +5V).

Here's the schematic. Pin 20 is the metal shell of the connector, not a real pin.