Archive for the The Downside of software development Category

Upgrading Quartus

Posted in The Downside of software development on May 9, 2014 by asteriondaedalus

Well, that was my fault be being lazy.  Since the Quartus downloads take so much time, once I found 13.1 didn’t have support for Cyclone II, I played safe and went for 10.1 sp1.

I am now downloading and installing 11.1 sp2 software to get around problems with Qsim (hopefully) as well as giving me Cyclone II and Max II support (still).

Go figure though, I installed 11.1 University Program (UP) with Qsim over 10.1 okay and Qsim would run, though its wave editor would not.

Now I install 11.1 UP over 11.1 Quartus and naught, nothing, na da, no Qsim installed.

On top of that, the 11.1 install of ModelSim does not recognise the 11.1 install of Quartus, even then I manually point it into the directory, so it won’t install.

Why did I bother?


Where we are at now is I have ripped out all Altera software and reinstalled:

  1. Quartus II sp2 Build 259 into clean directory “11.1” and program group “Altera 11.1”
  2. ModelSim-Starter 11.1 sp1 Build 216 into directory “11.1” created in step above and used the same program group “Altera 11.1”

Having said that, it took quite a while with slow downloads and installing and uninstalling to get that sorted.

We will have to go back to our SOPC example to re-do it in the new Qsys tool, though that isn’t as scary as it sounds.

What we might do next is add a few personalized instructions to our CPU – just to buzz out that process.

This newer development environment includes a “better” way of doing this apparently.

Setting up ModelSim with Quartus II … how hard can it be?

Posted in The Downside of software development on May 9, 2014 by asteriondaedalus

Starting with the “Getting Started with Quartus II Simulation Using the ModelSim-Altera Software” get straight into trouble.

You need a “” file that is, you guessed it, not in the distro.

Various “” files appear an Altera site and, of course, there are about 1 billion trillion of them on the interwebby thing all up.

Seems the one needed has a “counter.qpf” inside of it … have you seen it?  Hmmm?

So I went back to Altera and downloaded a raft of docco for 10.1.

I don’t know … I don’t get the feeling you get the same bang for buck this way Xilinx as you do for Altera.

In any event, I feel another laboratory report coming on.


Cylone II-Exp.11-Epiphany! Or ah ha!

Posted in Cyclone II Experiments, NIOS II Experiments, The Downside of software development on May 4, 2014 by asteriondaedalus

I pinged the board vendor to see if there were any gothchas when setting up this board.

Turns out, a couple of steps missing from the tutorial from Altera – go figure, you have to have priori knowledge to be a Newbee.  I hate the idea of Newbee, I am not sure why in a world of liberal education the idea persists.  If an educator was to take the viewpoint that someone ‘new’ was to be left to the devices of people not more knowledgeable than they for help then parents would be rioting and burning schools down I suspect.  Once you’re out of school, it is okay to make people put on a dunce’s cap and make them stand in the corner.

In any event, at least one step missing was to set the un-used pins to tri-stated inputs.  The other potentially missing step appeared to be running a second menu command to auto select interrupt vectors (inline with Step 11.).

We’ll see where those new bits of information get us.

Cylone II-Exp.11 – the saga continues

Posted in Cyclone II Experiments, NIOS II Experiments, The Downside of software development on May 4, 2014 by asteriondaedalus

Can’t clear the screaming board, software loads but board screams.

I did a compare between the hand built and example project *.ptf and nothing jumps out.

Tried building against VHDL instead of Verilog and got “Error: generation skipped because the system has validation errors”!

So, building a 5 component software core, with defaults, in a wizard, based on an example from Altera, and can’t even get the tool to generate the files.

Wretched isn’t it.

I am downloading 11.1 SP2 and will remove 10.1 and re-install etc.

I am not holding my breath and neither should you.

Memory leak

Posted in The Downside of software development on October 22, 2013 by asteriondaedalus

Ah well, computer started slowing down, choking, screen blinking, non-responsive, blue screening.

I uninstalled McAffee and viola!  So, McAffee installed … memory leak and computer crash.  McAffee not installed. … no memory leak and no computer crash.

Seems like an old problem creeping back in from older chatter on their user group.  Same old denial etc.  Not worth chasing, will take my money elsewhere.


Go figure.  Free AVG kept popping up with a malware warning on a file that wasn’t on my machine.  Support wouldn’t fix the problem unless I bought an AVG licence and so I am back with McAfee (better the devil you know).  The problem with the AVG support mentality was that AVG let the malware onto my machine and could not remove it as often as it tried OR had a bug that prompted a cyclic malware problem in the absence of one.

The re-install of McAfee seems to be a new look and feel as well and it has run now for a few hours without crashing my machine with a memory leak so I will just keep vigilant.  This sort of problem, with a bug being re-introduced every now and then, is a symptom of poor software configuration management.  Microsoft was another culprit who used to do the same thing to us.

It would appear then that McAfee didn’t acknowledge that they injected the fault but snuck in a fix the next release after the problem was injected.

Xmas holidaze – bad Ubuntu

Posted in The Downside of software development on January 1, 2013 by asteriondaedalus

So, a couple of things sorted so that they are on hand.


Atom board setup with 32bit Debian.

Why not Ubuntu?  Well started out with Ubuntu 12 odd.  Server version wouldn’t install.  Tried two times and got desktop running.  Spent a little time reading int X11 to get X-windows set up – as I am running the Atom box downstairs in the entertainment centre as it doesn’t have wireless LAN and is hard wired into the ASDL router.

Turns out setting up X11 is strangely tricky.

The usual wanking opensource drivel – if you haven’t done it before you’re not good enough to use it.  Yeah yeah, I know I am dumb because I haven’t done it before YOU freaking gimps!

Turns out, Ubuntu is less likely the choice for X11 etc because they are trying to be seen as replacement for Windoze so all sorts of things “native” to earlier versions of Ubuntu, and certainly of other Linux distros, are not there by default no more.

Blah blah, so on and so forth.  Scanned internet.

Came up with a couple to three good sources of information (not from Canonical!) and viola!  Installed XDM.

Changed a default line in config script to un-comment it.  Restarted the machine and …

… it hung in the Ubuntu booting, slowly ticking away … forever …


Now, maybe I am dumb but how does un-commenting a default line in a default installation cause a mostly raw installation of Ubuntu to hang?  Probably a combination of the following:

  • Ubuntu 12 is not really Atom friendly (who know why it installed at all let alone took two installation attempts before taking).
  • XDM is not a “native” of Ubuntu.  The warning when you install it is that it isn’t ported to Ubuntu by Canonical.

The upshot …


Installed 32 bit Debian on the Atom box, wiping out Ubuntu.

Half a day later I had Tight VNC on my Acer desktop (Windoze 7) and remoted into my 32bit Debian Atom box to install and test both of ROS and Urbi.

So, I have an old 64bit machine to build an that will definitely be a Debian installation.

Gotta hate/love opensource

Posted in Software, The Downside of software development on September 3, 2012 by asteriondaedalus

Go figure, now that I am chaffing at bit I am sucking in Python modules and trying to compile this and that and …

Of course, you can’t hook all you want to into one installation of Python.  Some muck is 32bit, some muck is 64bit.

And of course some of the useful network based muck needs to be on a POSIX compliant Linux and not your WINDOZE box.

Because I wanted to use mucky 32bit SNAP and SNAPpy (and especially Connect) it turns out I can have PyCUDA to port some of the mucky real-time SLAM examples because that needs 64 bit muck.  Of course, on Windoze so there goes some of the neater RPC and parallel programming tools.

Was even tempted to bang together either an ATOM motherboard I have around the place, or a couple of dual core AMD64 with linux so I can have a 32bit LINUX and a 64bit LINUX.

Of course the LINUX leaning makes sense because of ROS, but I was actually looking at other distributed cache and linda-like tuple spaces as I don’t get the impression the ROS topics give you much more than that (and I wanted something that ran on 32bit without LINUX).

Most of this is because I am looking at offloading processing to a server over wifi so that you can get away with less smarts on the indoor/outdoor rovers.  Especially since the SNAP Portal is running Python2.7/32bit I was restricted to that on the laptop.  So a pure Python RPC is in order to skip between the laptop and the ATOM running 32bit LINUX/ROS.

Mind you, as exciting as all that sounds it hasn’t been – going through the trial and error and trying to build things from the mucky instructions people write for building.

The one thing I learnt years ago, working in Defence on software maintenance, no one did good help files.  With the advent of Open Source it’s all gone downhill further.

Still, all this to match the RPC of the SNAPpy with python based RPC across server applications.

Especially if this pesky OpenCV compiles without muckiness on my laptop.  They talk about python bindings but you need the bin directory full there was talk of windoze binaries but they don’t appear in the download I chose.  Otherwise import cv works fine, just no blinking module calls.  None of this is clear and the gist of the problem is the depth and breadth of priori knowledge you appear to need to get it up and running.