Today I think I will make a few introductory comments to get things started. For now, the topic will be the work I am doing in embedded software development.
The project I am working on for the last few months has proven to be interesting and challenging. The customer has a "legacy" product line build around older microcontroller technology: the motor controller circuit board appears to have been designed around 1990 or the late 80's, and is based around the Motorola 68000 (68k) CPU. When I first saw the board I was nearly in a state of shock: I don't recall the last time I was involved in a project where the circuit board did not utilize surface mount components! And EPROMs! I mean the ones that you have to erase with the UV lamp thingy!
If you know anything at all about the Motorola processors, you might realize that the 68k processor was cutting edge technology back in the Reagan years. This was a powerful micro for it's time: it's the CPU that found its way to the early Macintosh, many arcade video games, a few UNIX workstations, and even embedded applications.
The 68k has been obsolete (but not forgotten) for a long time now, and as a microcontroller for embedded applications, the 68k is - not really a microcontroller in the sense that I typically think of one. The 68k, being "only" a CPU, still requires a fair number of other integrated circuits in order to make it useful. Nowadays, its all about integration and even the lowliest Microchip PIC has a good bit of peripheral devices (timers, IO ports, etc) not to mention RAM and Flash ROM integrated into the package. The 68k was nonetheless a popular choice for embedded apps in its time. So much so that Motorola developed an extensive product line specific to embedded application, giving rise to the CPU32 family of controllers (but even those have been obsoleted in favor or newer technology such as the PowerPC architecture).
Often one of the first tasks on these kinds of jobs is get the software development environment and tools working. On this project we already have some "working" code (more on that later), so hopefully I can compile the previously released configuration of their code, and then (can you believe this part?): load the code to EPROMs! I mean real EPROMs with the little glass window thingy on the top where you can see through to the chip! Anyway if the compiler is setup and working properly then the code will compile and link, and then I will have a fresh firmware image available to load. After programming a new pair of EPROMs (which takes about 10 seconds using a chip programmer connected to the USB port on my computer), we grab an IC-desocketer-grabber-thingy (or a pliers or a hammer or whatever else is needed) and proceed to swap the new EPROMs to the board. If all has gone according to plan, then the board will do whatever it is supposed to do when it is powered it up. The developers of this board were wise enough to install some LEDs, and the software will blink the LED as long as the code is still running properly.
Prying the EPROMs off of the board every time you load and test code is of a course a pain in the behind - and for a while anyway there was an entire thriving cottage industry built around selling very expensive dongles and gadgets and doodads to people like me for (seemingly) ridiculous prices. The newer microcontrollers now almost invariably feature not only on-chip RAM and flash memory, but also dedicated IO pins and single-step modes of operation for debugging.
So now I have now found myself warped back to the ICE age (in-circuit-emulator age that is!). The previous devel team actually had been using a PROMice ROM emulator + resident ROM monitor in order to debug the software with the Xray debugger. On this board the CPU is not socketed, but the ROMs can be replaced to do software upgrades (imagine a time before every stinking gadget imaginable was connected to the internet and back before maybe even ... the existence of the internet itself?)
For those who are not in the know, the PROMice, at the risk of gross oversimplification, is basically a black box containing some RAM which is connected into the ROM sockets of your board (the emulator replaces the ROMs on the board with its own specially fabricated ribbon cable adaptor which matches the pinout of the ROM chip that is being emulated i.e. 28 pin devices require a 24 pin adapter, and so on for 28 pin or 32 pin devices etc). The emulator RAM is controlled from the host workstation or laptop by running a utility program on your workstation where you set up the memory size and some other properties, choose a firmware image to load (binary or hex format), and then download the image to the emulator memory. Once you power the board or reset it, the board runs from the emulator RAM as long as the emulator is powered.
So ... after extricating the PROMice from a cabinet where it was languishing beneath a bunch of old cables and circuit boards and nameless other technological artifacts, the first order of business is to dig the two EPROMs off of the board without buggering up those chips or the sockets. Following the instructions in the very clear and coherent end-user documentation, I proceeded to plug everything in. Did I mention that the PROMice works over parallel or serial (RS232) ports - try finding a laptop with those anymore. The PROMjet software is very cryptic, like it was developed in the Windows 95 era. Well I'm not surprised at all that the thing is not working.
Before I wasted a bunch of time debugging this antiquated piece of equipment, I contacted the emulator vendor (Grammar Engine)... and I found out that the company was no longer in the development tools business - Grammar Engine had discontinued operations and essentially had opened a new business developing some other kind of electronic product. Anyway, the fellow that had been responsible for the Grammar Engine product support had continued in the product engineer role at the new company. This fellow Arvind that I spoke to was very courteous in handling my call, and offered what assistance he could. He mentioned that they had actually continued to support the Grammar Engine products until just a couple of years ago, but they hadn't even taken any support calls for some time. I ended up getting a PDF of the emulator schematics for troubleshooting, but never did get the thing working. Well, I didn't try very hard... one can waste a bunch of time getting obsolete equipment to work, or... alternatively, go buy something else to replace it! And who doesn't like to buy new things...
