self.clue++

So this was long time since the last post. Working with a CPLD for the first time wasn’t trivial, and there are so many other things to do…

I will split this up into two parts, the first showing the frequency counter stuff itself, the second one dealing with connecting it to an MCU and showing the results.

Since I had already drawn a schematic for the simulation, which also worked fine, I decided to implement in the CPLD with a schematic also. I thought that it wasn’t too complex, and wanted to save the effort to learn VHDL or Verilog for later. It turned out to be a mixed success, mainly because the Xilinx schematics editor seems not to be intended to be used for larger projects (though it has some interesting features, it also has some quirks making stuff complicated).

First thing to notice is that there aren’t any 24 bit counters. One can choose from a large number of different counter implementations, each with slightly different features (like loadable inputs, different version of reset and so on). But the largest counter is 16 bits - so we need to add another 8-bit-counter to it.

Apart from that the scematic looks like the one from the simulation (there are additional inverter since the D-Flip-Flops don’t have an inverted output).

One can also see the input and output connectors, together with buffers. They are needed to instruct the compiler to create external connections - otherwise the wires are only connected to other wires with the same name (possibly on other sheets).

I connected the ‘finish’ and ‘toohigh’ output lines to the LEDs on the breakout board, and the ‘start’ input to the button. My first test case involved a 20MHz crystal oscillator connected as reference clock, and a 10MHz one as input clock. The expected outcome was to have the ‘finish’ LED light up after about one second. But but did not - because the button on the board is connected to ground, but the original schematic expected a high pulse as start signal. After inverting this input, the LED lit up as expected.

Next test was replacing the 10MHz oscillator with a 40MHz one, to test the overflow mechanism. Here, only the ‘toohigh’ LEDs lights up, as wanted.

The last test used only a single oscillator as reference clock, and I created the input clock by just manually creating a single short pulse (by touching a wire to the input pin). For that, I reporgrammed the CPLD so the ‘toolow’ output is routed to one of the LEDs. This test also worked fine.

The final build looked like this:

Next step is to route the counter outputs to output pins too, and connect everything to a MCU. Stay tuned!

I recently got asked how a Java programmer by day comes around to work with embedded MCUs by night. We Java developers are famous to think more in giga bytes, which is somewhat counterproductive in the embedded world.

Actually the reason is simple - I started my electronics career before I became a software developer. Back then east germany was still alive, and electronics was an expensive hobby. So I stayed with quite small projects, more in the sense of small experiments. After the wall came down, it was easier to start real projects - but being in school limits the financial abilities a little bit. And electronics, back then,still meant only small scale stuff for someone starting in the field.

But at the same time I got my first own computer (there was some previous contact due to organized spare time activities, but owning my own one is different). And working with it was much more rewarding, because one gets much faster feedback, and it’s much easier to retract from errors. And so I got sucked into the world of programming - first BASIC, then assembler. I never really lost my affection to the world of electronics - but I discovered that the combination with a computer can be really powerful (adding hardware like stepper motors, displays and such stuff to a computer is even more rewarding than a running program). And there were so many extensions one can build…

When I then started going to university, taking all the electronics stuff was too cumbersome, so it was degraded to weekend work. And so the software won over more and more of my time - and studying Business Informatics didn’t help with that. This was also the time where I got into contact with Java. After having worked with languages like Turbo Pascal, COBOL, C and C++ it was refreshing. And then came my first real job.

It was only 10 years after that I decided to need a hobby to have a diversion from my job, and to get some time for myself. I discovered some old unfinished projects of mine (which have followed me through several homes), and started working on them. And then I found, in the great vastness of the internet, how far hobby electronics have come since then. MCUs were now affordable, and even the programming tools were often free (in the mid 90s, the software for programming a XC9572 cost several hundereds bucks)! There were things like the LaunchPad, the Cypress PSoCs or the mbed. I took part in several design contests (and I even won one :)

So how does working on Java compare with all the embedded stuff? In the end they are just different challenges. On may day job I care about building a eCommerce software (or more a platform, dpending how one views it) being able to handle millions of orders. So I care more about things like clean APIs, building the right frameworks, implementing the business processes properly, or how to talk properly to an Oracle DB. When working in the embedded world, I think more about how to make best use of the sparse pins, how to implement my stuff in C, and how to choose the right peripheral component. Due to the fast MCUs available now, performance is not really an issue to me (but memory consumption sometimes is).

What I have seen so far is that my day work influences my embedded work - I try to make my software more modular, and I try to come up with a clean architecture in the end. On the other hand, working in a constrained environment helps my in my day work - we care about memory usage and performance there too. And working with all the more-or-less standardized electronics components (its all just volts and amperes, you can always connect them together and it will work most of the times ;-) makes me wish to have that in software too.

I have known about the AVR transistor tester project for quite a while, but did never come around to build one. Doing a proper PCB is still a major undertaking for me…

But when Markus offered to send some his spare PCBs for free, I took my chance. I verified to have all parts available (except for the ATMega8), and the asked for one. It arrived really fast (the swiss post seems to be rather fast), but it proved Ians method of sending PCBs to be the right one:

So I waited for my ATMega to arrive, and collected all parts:

The I went out to solder the board. It uses the smallest avilable size for all components, which make soldering the resistors quite fun (some of them sit a little bit wild). I found out that 2 resistors are swapped with regard to the schematic (the are originally the same size, but for providing the LCD contrast I needed to bridge one of them so it mattered to me). Since my LCD has a quite unusual pin assignment (pin 1 is in the middle) it was attached to the back of the PCB. Therefore the button and some connectors are also located there.

Since Markus provided multiple locations for the test connectors, I used one for attaching a socket, and the other one for the Jacks. maybe I will use the third one for attaching some fixed wires on the case.

For programming I used by Buspirate again (together with AVRDude), and put everything on a breadboard:

Programming went without hiccups. But when I then tested everything, it didn’t work. The display got somehow initialized, but ended up will all characters black. The tester also didn’t turn off, which it should. So some debugging was in order.

First the supply voltage - check. Next the test outputs - check (all are 0 volts). But strangely the analog voltage reference output was also 0 volts, which it shouldn’t.

Markus suspected that somehow the programming went wrong. So I re-downloaded the firmware from the project page again (before I used the firmware builder), programmed again - check. So somehow the first firmware I used was wrong.

So the last step was building it into a case. I did simply use a small box left used for some samples from Coilcraft

and just added a cutout for the LCD and holes for the connectors:

It’s not the prettiest one, but it works nicely.

For my initial tests (just to check whether this board works), I just used my Buspirate as XSVF player. I flashed it with the proper firmware for that, and connected everything except Vcc to the JTAG connector. For powering the board, I connected the 5 volt line of the Buspirate with Vcc of the breakout (to avoid damaing the LDO on the board). After I discovered that I needed to set the Vio jumper, and that the BP and the drivers are somewhat picky with regard to errors (and need a complete reboot), everything worked fine.

But it is a hassle to create a XSVF file for each try, and the BP is really slow. So I went to build a better programming cable. The easiest one is called “Xilinx parallel cable II” aka “DLC5”. It gets connected to the parallel port (I fortunately still have one, even if it’s a PCI card), and contains just some driver. The schematics are provided by Xilinx for free, but I used a variation by Peter Ivanov because I just happened to have only a single 74HC125 at hand.

The schematic is really simple.

I made some additional changes to it:

• use some different transistors
• used schottky diodes, because with normal ones the logic levels might be too low for the parallel port (3.3 volts minux 2 time 0.6 volts is only 2.1 volts)
• removed the power LED, since it just shows when the board is powered (and I have a LED there)

I didn’t bother with a proper PCB, but rather build it on a perf board. It looks a little bit improvised:

but it worked the first time I connected it:

Since I had troubles with Xilinx ISE complaining about the cable “being locked”, I went out and used open source tools. urJtag doesn’t really work with the XC9572XL (some timings are wrong), so OpenOCD was the next candidate. It worked with the first try, but for just programming a XSVF file it really is too awkward to use. A much nicer tool I found is x3cprog, which is simple, fast and can read the JED files created by ISE, which spares the conversion to XSVF.

So now I’m settled with the tools, and can start really experimenting and building some stuff. Since I found a SPG8640BN programmable crystal oscillator in my parts bin (a nice chip which is unfortunately not available anymore), I skipped the generator project and decided I need a frequency counter. So stay tuned…

One of the tasks when starting with CPLD (or FPGA) development is to install the tool suite provided by the chip vendor. In the case of the XC9572XL this is the Xilinx ISE software. Xilinx provides a free WebPack version, which contains all the basic tools needed for the first designs.

On my initial test, I installed ISE 12.2, since I had in on a DVD somewhere. But for every start, it printed the error ‘couldn’t load XPCOM’, and some views weren’t working. So I started investigating. One of the things I wanted to make sure was that the installed version supported the Xilinx Parallel JTAG Cable III (a.k.a. DLC5), since I intended to build one. So I downloaded an older ISE version from Xilinx (10.1), and installed that one. Its release notes didn’t mention the DLC5, but the iMPACT tool (which is used for programming the CPLD) knows about it. This meant that the documentation was no reliable way to find out whether a version supoprts that cable or not - I needed to install them.

So I downloaded ISE 13.4, and installed it too. And lo’ and behold - it also knows about this cable type. It also looked better that the older ones (which were sometimes really ugly) and seemed easier to use. But it still reported some strange errors (about ‘cannot load XPCOM’ and the like), and still some things did not work. The installation needs to be run as root, btw.

First I tested whether it makes a difference to run it as user vs. root - nope. The I tried to preload the XPCOM libraries of firefox since it seemed to to find them. This helped, but now I got errors about a wrong version of libstdc++ - strange. As last resort, I did run the program under strace, and looked which libraries are searched in which places (ISE WebBench provides many libraries in its own version). It turns out that ISE wanted to start a firefox, but it changes the environment so FireFox cannot find its libraries. And when I changed the ISE environment to make FireFox work, ISE didn’t.

The solution is to create my own start script for firefox, which sets the proper environment, and tell ISE to use this one. The script looks like:

#!/bin/sh
# reset the library path
LD_LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6:/usr/lib/gcc/i686-linux-gnu/4.4:/usr/lib/firefox-10.0.2:/lib:/usr/lib:/usr/lib/i386-linux-gnu/:/lib/i386-linux-gnu:/usr/lib/firefox-10.0.2
# first look for an running instance
# if none can be found, create one.
/usr/bin/firefox -a any -remote "openURL($1,new-tab)" || /usr/bin/firefox $1

But since ISE insists on running as root (at least in my case, it might be possible to change the permissions to make it run as normal user), one needs to set a new $HOME, because FireFox otherwise complains that it cannot write to its .mozilla directory (because it’s run as root too). So we need a special starter for ISE too. But this is no big hassle, and we need one for the cable drivers anyway.

Xilinx provides its own peripheral drivers for its USB and parallel cables, but the run only under the supported Linux distributions (and Kubuntu is not supported). But there is a solution in the form of the drivers on Michaels pages. Just download them, compile them and preload them in the start script:

#!/bin/sh
# fix $DISPLAY so ISE doesn't complain
export DISPLAY=`echo $DISPLAY | sed 's/\.[0-9]*$//'`
# set $HOME so FireFox doesn't complain (and we avoid to accidentially breaking the users instance)
export HOME=/opt/Xilinx
# perload ISE config
source /opt/Xilinx/13.4/ISE_DS/settings32.sh
# preload drivers
export LD_PRELOAD=/opt/Xilinx/usb-driver-HEAD-2d19c7c/libusb-driver.so
# and run ISE
/opt/Xilinx/13.4/ISE_DS/ISE/bin/lin/ise

When using this script, one can use all tools (including the iMPACT programming tool) directly from ISE. When running iMPACT initially, choose to setup the cable automatically (make sure it is connected), and it will be configured properly).

When you get messages about “cable locked” or so, call iMPACT in batch mode to clear these locks.

If you want to run iMPACT manually, use the following script:

#!/bin/sh
export LD_PRELOAD=/opt/Xilinx/usb-driver-HEAD-2d19c7c/libusb-driver.so
/opt/Xilinx/13.4/ISE_DS/ISE/bin/lin/impact $*

If you don’t want to build a parallel cable, you can skip all this driver and preload stuff, and use iMPACT for just generating XSVF files. A good workflow was to start iMPACT once and set the project up, and create a XSVF file each time when the main ISE tool has finished its synthesis (just right-click on the shown CPLD, ‘create XSVF’, and it will ask for reloading the source file).

One drawback of the newer versions is their disk usage. Where 10.1 uses about 2 GB, 12.2 takes 4 and 13.4 about 7 GB. And one cannot just install only parts of that, or remove them afterwards (the tools just complain that they need them). The only parts I could remove were all the IP cores, which saved at least one GB.