Category: stuff

About two months ago I was once again sidetracked by another project. I had a very specific problem. I have two software protection keys from the same company for two different sets of software. This company unfortunately didn’t have the foresight to make these two keys compatible. So I had to physically remove one key and insert the other key to get the software to work. This was getting tedius and in a process I’ve otherwise been able to automate.  A quick search on my favorite parts site, digikey, shows a few USB hub ICs and I know there are USB microcontrollers around.  This is a problem I can solve. Get a hub, connect one port to the USB microcontroller, the other ports can go to the devices, then have the microcontroller recieve commands via USB to power the other two ports on and off. I looked for an existing commercial solution, but what I found went the other way. Selecting one USB devices between mutliple PCs instead of selecting between multiple USB devices connected to one PC. I might could have found an existing device if I looked harder, but life is a journey, rock it. And so I present to you this thing I made.

It’s pretty simple, I just followed the reference design for the USB hub and whacked in the smallest, cheapest USB microcontroller I could find, following it’s reference design as well. It’s a PIC16LF1454. Microchip even provides a driver framework which does most of the work for you and samples to get you running quick. Of course something has to go wrong. Murphy knows me well, sometimes I wonder if he is a benevelant being who knows I won’t learn anything if I don’t make mistakes. And Murphy does so want me to learn. The first problem I encountered is the debugger doesn’t work under windows 8, because… windows 8. I solved this by connecting to the debugger under Linux and updating the firmware. The next problem I encountered is that I couldn’t get windows to recognize the microcontroller after loading any of the samples. First I hooked up the microcontroller seperately, directly to the computer to debug just it. Windows sees the device but doesn’t recognize it when I run the debugger. I noticed I could output the clock on one of the pins and on a whim decedied to enable it and probe it on my scope. Oddly enough the output wasn’t the right frequency. Score one for dumb luck. It turns out the samples support using an internal and external oscilator. I had already verified the samples were set for the internal oscilator and the config bits were also set correctly. It turns out I had to add a few lines to change the internal oscilator frequency. Fixed that and now it’s running.

I hooked up the complete board with the new firmware and still no dice. I probed the USB hub and all the device power enable signals are deasserted, why, because all the the overcurrent signals are asserted. The microcontroller overcurrent signal I just plain screwed up. I connected the active low signal to ground, meaning it was asserted. Woops. The next issue was a few missing pullup resistors. The reference design calls out the power switch IC I’m using, but it didn’t include the pullup resistors. I didn’t check this against the power switch data sheet, which looking at now, clearly indicates they are required. Woops again. Luckily my top layer has a power pour so I can just scratch off the solder mask here and there, cut a trace, drop in a solder bridge, whack in a few resistors, and now all is well. I made those changes to the board, but I haven’t gotten new boards manufactured.

Lessons learned: trust your data sheets, but not blindly, verify them against other data sheets if possible. SC70-3 chips are hard to hand solder.

I decided that I had learned enough from my prototype board and that it was time to start working on the real board. A single board that would have everything on it, no need for a seperate FPGA board. This time I will compile everything before ordering the boards. I decided to start with the SPU, I can also test this with my Papilio. My initial goal was to basically put a midi file in shared memory and point the SPU at it. I started to write a midi file reader in VHDL, the state machine got complicated in short order. Looking at it, it started to look like a processor. Then I thought, why not implement it as a soft processor. And this is the point where I get sidetracked. I designed a 16-bit register based RISC CPU, implemented it in software, wrote an assembler, implemented it in VHDL, and started creating a C compiler. The soft processor worked well enough to output hello world over a UART and even output a sine wave through a memory mapped delta sigma DAC.

Though there were a few lose ends to tie up. I had a 32-bit 16.16 fixed point unit in the design with add/subtract/multiply/divide. The divide translates to a 48-bit integer divide and I saw VHDL has a divide operator. I didn’t expect it to work, surely it won’t make timing, doing the divide in a single cycle, but I also didn’t expect it to fail quite as badly as it did. It wouldn’t even compile. The Xilinx tools told me I was trying to use 125% of my available resources. Woops. Luckily removing the fixed point instructions dropped my resource utilization down to 60%. I still need to remove those instructions completely or re-implement them using multiple cycles. I also noticed a few instructions I hadn’t tested yet had bugs in them. Then there was the C compiler. I had a pre-processor, parser, syntax analyzer, and I had started on the semantic analyzer, but I still had to finish it and implement the code generator and optimizer. Of course I’d also want a debugger and perhapse this is getting out of hand. Looking at my FPGA resource utilization, after adding JTAG debugging, the video unit, and the SRAM controller, I may well run out of resources before I get everything implemented.

Time to shelve this, maybe pick it up later with a new project with the soft processor taking up the entire FPGA. I decided instead to greatly simplify the audio unit and go back to implementing it in VHDL. Now instead of trying to read a midi file it would just handle the audio channels, generating sine waves and mixing them, with the CPU doing the sequencing. This simpler design was implemented and tested without too much fanfare and once again I’m on track. I added in the video unit modified from my earlier VGA/DVI tests and the SRAM controller and everything compiles.

Lessons learned: dividing is hard.

Why the hell does MSI support the the standard 4 number W.X.Y.Z versioning scheme, and then ignore the last number in the version.  It apparently does it’s own thing for the last digit and that works fine for files, but it ignores the last number in package versions.  Packages don’t have anything to fill in for that last digit.  I use a major.minor.revision.build version scheme and I have to install new revisions of software with the version number the same except the build number.  It’s getting all confused because it can’t tell the difference between version 1.20.0.230 and 1.20.0.231 of the package.

Luckily I hardly ever reset the build number so I can swap the build and revision numbers and still get a unique version even if the last number is ignored.  So that’s what I’m gona do.  The build number is only incremented about twice a day, so at that rate I have to reset the build number once every 89 or so years.  I think that’ll do.

When did installing software become so damn complicated.  It used to be all you had to do was copy these files to this place and be done with it.  Actually for the most part that’s all you still have to do.  Of course Microsoft had to make it complicated in their MSI format.  I’ve been trying to move from NSIS to MSI using WiX and I still can’t get the whole put this file there thing working.

With NSIS it’s pretty easy to do, but that’s about it.  The “programming language” that NSIS uses is so primitive that it’s damn near impossible to do anything else.  You have to find someone who wrote a DLL that does what you want and then you have to piece together 20 lines of code just to call a function.  I know damn well the VM in NSIS is complete enough to support an actual language instead of that bastardized assembly like thing they use.  It’s all way too much work to do something really simple, something that would be just a few lines of C code.

An installer will inevitably have to call other installers to install it’s dependancies.  With NSIS you can at least do this, it’s not even possible with MSI.  Apparently the shit will hit the fan and all hell will break loose if you try to install an MSI file from within another MSI file.  Of course this was a feature Microsoft once touted then being able to do with MSI, and then they realized that it never worked right and caused all sorts of problems and forbade it’s use.  Just like most everything in the Win32 API that has a DWORD reserved parameter that must be NULL for NT but 42 for 9x.

The newest version of MSI will let you chain MSI files which is nice if all of your install stuff is strait MSI, which is never the case.  No-one distributes a plain MSI file; there’s always either a setup program with an embedded MSI file that you can’t get to, at least not without angering the computer gods, or there’s an MSI file with a bootstrapper.  So many MSI developers had to use a bootstrapper that they gave it a name and formal definition.  And why does one need a bootstrapper.  Because MSI can’t run other installers and therefore install dependancies, so you have to do it in an external program.

Wow, four whole paragraphs and I haven’t even gotten to what started this rant.  I’m trying to make an installer with WiX.  Don’t get me wrong though, I have a lot of respect for the WiX guys, and the NSIS guys as well.  But it’s bit a huge pain in the ass.  WiX exposes you to the soft squishy underbelly of MSI; which is as great as it is terrible.  If you’ve ever used a Windows box for more than just web surfing you’ll realize eventually that the soft squishy underbelly of anything that Microsoft does is a complicated mess.  And MSI is no exception.  I get the feeling if I were to sneeze too hard around MSI it would fall apart, cats and dogs would rain from the sky, start mating, and give birth to creatures God never intended to exist and for good reason.  Then my eyes would pop out, dangle there for a second, and then explode.  Not sure exactly why, maybe I left them open when I sneezed.

But, I digress; again.  The problem of the hour is that my WiX files are generating warnings like:

warning: L407: you forget to snarfle the garflonk

So I look up L407 and if I’m lucky enough it tells me how to snarfle the garflonk, else I google till my eyes bleed.  Eventually I manage to snarfle the garflonk.  And then I get this:

error: L408: you snarfled the garflonk

So I can never get it to compile without errors or warnings.  It seems that most of the files I have that compile with no errors, but with warnings go from anywhere between not installing  properly to to failing horribly.  Meanwhile the files that compile with errors and a few warnings in there for good measure seem to work just fine.

Just great.  I think the compiler is just garbage in, garbage out and will only fail if something horrendous happens.  Which isn’t an unreasonable thing to do.  Then they rely on the ICE validation scheme to produce all the errors and warnings.  But their implementation of ICE validation is teh suck.

Alright, I’m done.  You can go away now.

I’ve had this site for years, and I haven’t updated it in years minus a few.  So why now?  Well, I had a “this is so absurd I have to blog about it” moment.  Of course my website was all “go away” ever since some douchebag spammer flooded my users table and I subsequently lost all the code to the site after taking it down and fixing it then having a harddrive crash.  Yay.  So I had to do something quick.  So I installed WordPress.  And now here we are.