Solutions
Lately, I’ve been putting quite a few hours in a little electronics project. It involves (amongst other things) a bunch of microcontrollers; primarily PIC18F2520 (or probably 18F2420 at a later point; it’s the same except for having less memory and being cheaper) but also an occasional PIC18F1330. These microcontrollers are supposed to talk to eachother using CAN.
CAN is a bus system that has some pretty neat features. It can handle a lot of devices, can achieve pretty good bit rates, it has very good error handling and bus arbitration functions, and so on. It was originally designed for use in vehicles (and in fact, any car manufactured in the last 10 or 20 years or so is largely built around tons of individual devices talking on a CAN bus) but of course there’s a lot of other situations in which the features offered by CAN are useful.
I’ve been trying out the new MPLAB X (which is still in beta). There are some major shortcomings, but overall it’s starting to look like a pretty good IDE, which is nice because I absolutely hate the old MPLAB. Compiling is done using Hi-Tech C.
Now, if you were to ask my opinion on Hi-Tech C a week or two ago, you’d get a pretty negative review. I’ve been having issues with it. Weird issues, like global variables not working (no matter what you write, they always read as 0 unless you access them via a pointer, which is a bit of a stupid and inefficient workaround). I’ve also been running it in Lite mode, rather than Pro, because in Pro mode it uses the big Omniscient Code Generation – an optimization technique which is actually quite good, except that it always seemed to turn out horribly bad code that performed nothing like it was supposed to.
It turned out that all of those issues were caused by the extended instruction set being enabled in the PIC’s configuration bits. What happens is that that bit doesn’t only make a few extra instructions available (8, in fact) that are primarily of interest to a C compiler, bit it also changes the way memory addressing is accomplished. Thus, if the extended instruction set is enabled while the compiler isn’t generating code that uses those extended instructions (or specifically, its way of addressing memory), things go wonky. Big time. Turn the extendend instruction set off, and everything works like a charm (OCG included, cutting the code size in half!). Today, I’m pretty darn happy with Hi-Tech C.
Of course, the user manual doesn’t make a single reference to the extended instruction set (I’d say this is exactly the sort of thing that should be mentioned in the manual, but yeah. It’s not).
Also, for the CAN part, I’ve been using a setup with the MCP2515 CAN controller IC, paired with an MCP2551 transceiver. By my initial look at the datasheets, this should have been easy, until the moment I got to actually using it and had to figure out how the bit timing configuration works (and it would seem that I havn’t been the only person to struggle with this). As it turns out, once you grasp it it’s simple enough, and since I havn’t been able to find a functional calculator tool on the Interwebz (just one for the older MCP2510, which isn’t entirely compatible), I might just find some time to write such a calculator.
Still, with the bit timing issue aside, the packets that one of two CAN nodes is transmitting don’t seem to be making it to the other end, for some reason. That’s a thing to figure out once I have the opportunity to put an oscilloscope in the mix and see what’s going on.
MicroVGA
A while ago I got one of these little buddies: the MicroVGA microcontroller VGA interface.
The concept is very promising. Basically, it’s an easy way to hook a microcontroller up to a VGA monitor (which is typically not a very simple process; you need some very high speed, very high timing accuracy, lots ‘o memory for the frame buffer, and some high-speed DACs). It provides a serial as well as SPI interface, accepts text (and standard VT100 escape sequences) and spits out text-mode VGA to a monitor. (No, it doesn’t do full-color per-pixel graphics, just the text mode (with colors) as you probably know from your PC’s BIOS setup tool.)
It also comes with an analog TV output, and a PS/2 keyboard connection. Not only does it read the attached keyboard and send keypresses back to you via RS232/SPI (whichever you use), it’s also used to access the module’s setup utility.
The whole thing sounds great, with potential for a large variety of applications. Only if it were that great in reality…
It’s not that the module doesn’t work. It’s easy enough to hook up and get it running: it just wants 5V and GND, and a serial input, which I provided directly from my PC (using a level shifter in between of course). Before you can talk to it from a PC, you’ll need to access the setup tool and change the baud rate, because by default it’s set to 1 000 000 baud, which most PCs cannot deal with, and there’s no auto-baud feature.
One thing that I immediately noticed when I had this module in my hands was the parts that are used on it. There is a PIC24HJ32GP302, a 16-bit microcontroller from Microchip, and A small Xilinx CPLD (Complex Programmable Logic Device), part number XC9572XL, which contains about 1600 gates. Other than that there is a voltage regulator and a standard 74-series buffer IC.
The interesting thing here is that, even though the module wants to send out VGA signals – which require pretty accurate timing – there is no crystal, or any other sort of accurate timing circuit on the PCB.
Unfortunately, it is there where the MicroVGA’s big problem lies. It turns out that, when it is connected to a monitor, there are three possibilities:
- The monitor will accept the signal, but the lines on the screen will constantly ‘wobble around’ a little bit. This makes it extremely hard on the eyes to read text on the screen for any period of time.
- The monitor will display the image, with the wobbling problem, but also occasionally just say ‘screw you’ to the VGA signal and re-adjust itself (resulting in the screen going blank for a few moments).
- The monitor rejects the VGA signal entirely.
In other words, the PS/2 interface aside (which doesn’t nearly justify the cost of the module), the MicroVGA is pretty much useless.
I have tried contacting the company that sells the MicroVGA, but haven’t gotten any response from them.
In other words, don’t waste your time (and money) on it. Even if I just had a bad copy, the lack of an accurate time source on a module that needs accurate timing is a very questionable design choice, and the bad support from the vendor alone is plenty reason not to buy it.
Poof
Bah. I was going to use an old Playstation controller for a small project. I used it before and was going to re-use the old code so it *should* have been pretty simple. Until I made a tiny little mistake and the magic smoke came out.
I opened it and surprise surprise, a filter cap is blown out. A little investigation showed that Sony didn’t really want to build these controllers to high standards: the capacitor in question has a *very* narrow voltage tolerance and is a really cheap type that doesn’t even have the pressure relief (the little grooves in the top) that capacitors usually have. So the top of the capacitor just blew off the bottom and there was capacitor goo all over the cheapass little PCB.
Replacing the capacitor won’t solve anything, the main chip of the controller is also blown. This one is never going to be useful again.
*sigh*
Maybe I’ll check Ebay or something for some old controllers. They’re still fun to play with.
Olimex ARM-USB-OCD & Win7 64-bit
So, occasionally I play with ARM processors, and when I do so I talk to the chips using a JTAG interface. Specifically, I use the ARM-USB-OCD from Olimex, which is a pretty neat device and inexpensive (or at least, compared to other products on the market, and not counting crappy parallel port/Wiggler type interfaces, which suck). And it comes with a built-in power supply and additional serial port which is awesome.
The only real issue I was having is getting it to work on my laptop, which runs Windows 7, 64-bit. The device uses a standard FT2232L chip, but with a customized Vendor/Product ID, so the drivers from the Olimex website won’t work with it directly, and as you may know Windows 7 can be a real bitch with drivers, especially in 64-bit.
Anyway, I finally got it to work and figured I’m not the only one who ran into this problem, so I thought I’d share the driver I used. (I modified it from the standard FTDI drivers).
To install, unzip the folder somewhere, go to the Device Manager, open the properties for the ARM-USB-OCD (it shows up twice: one for the JTAG interface, one for the serial port), find the ‘Update Drivers’ button, browse to the folder where you extracted the drivers, and voila. It will probably ask you to confirm you want to install an unverified driver, obviously you’ll have to accept there. No worries, it’s just the FTDI driver modified to accept the ARM-USB-OCD’s VID/PID combination.
Anyway, here it is: Olimex ARM-USB-OCD drivers for Windows 7 64-bit (and pretty much all other Windows versions too) – 1.18 MB
TI LaunchPad
TI (Texas Instruments) released a neat little product a while back: the MSP430 LaunchPad Value Line Development Kit, as they call it. It’s a basic introductory kit to their MSP430 line of microcontrollers. At just $4.something they are pretty much a complete giveaway, its impossible for TI to make any money at all on them. But then again, their point is not to make money but to introduce people to their micros, and well, at that price its a pretty good starting point for anyone.
But TI, why, why did you have to make it so difficult to buy them?
On the TI store, the first obstacle is registration. The account registration form just does not work in Firefox. You can fill it out and click submit… and it’ll say you havn’t completed any of the fields. Then, once you eventually get to the checkout page, the damn thing wants so much (detailed) information from you.. It’s just ridiculous. At the nth form where I had to make up all sorts of stuff just to get past that page I gave up.
Mouser doesn’t have any of these kits in stock and they’re on backorder which will take roughly forever, and at the lack of another place where I can buy it… Sorry, TI. You really missed your chance there.
Blue Toys
I got a new toy in yesterday: the NGX Technologies BlueBoard LPC1768-H. As the name suggests it is a blue board with a LPC1768.
What is a LPC1768? Well, it’s a microprocessor. More specifically, an ARM Cortex-M3 capable of running at speeds up to 100 MHz with 512 kb of Flash memory, 32 kb RAM, and a huge load of peripherals: eight DMA channels, Ethernet MAC, USB 2.0 (Device/Host/OTG), four UARTs, 2 CAN channels, SPI, I2C, I2S, 12-bit A/D converter, 10-bit D/A converter, 4 timers, and a real-time clock – amongst others. Disregarding peripherals, it comes with up to 70 GPIO’s (the chip itself is a 100-pin package, part of which is dedicated to things like power, crystal, and the JTAG interface).
It puts any PIC, AVR, or similar small micro to shame.
The reason I went with this particular board is that it doesn’t come with crap. Most development boards out there come with tons of circuits and peripherals (buttons, LEDs, LCD displays and whatnot) and don’t leave a whole lot of room to do what you actually want to do with the board. This one contains just the chip, all the basic supporting circuitry, a few things like a USB connector and an onboard LED for testing/status-displaying purposes, and all other pins are broken out on standard .1″ headers. Yay for that!
The board comes from NGX Technologies. I ordered from them directly – SparkFun also sells the board, but the SparkFun price was about as the total cost of the board and shipping directly from NGX, so that’s an easy choice. They were pretty quick with shipping – I had the package delivered via the EMS service. At first they e-mailed me warning about previous bad experiences with a package getting held up in customs, but that’s not the fault of the shipping service. Since the alternative was a lot more expensive I had them ship EMS anyway and it went fine, the package was here in about a week.
I’m using the Olimex ARM-USB-OCD programmer (starts at about $50, and is really the way to go over the parallel port Wiggler-type interfaces, which tend to be glitchy and slow), combined with Rowley CrossWorks for ARM ($200 for a home use license). Currently also connected to the board are my Saleae Logic (inexpensive, very user-friendly 8-channel USB logic analyzer – very happy with this one!) and some breadboard with RS232 line level converters, hooking up the chips UART0 and 1 to my PC.
I’ve never dealt with these chips before, and there are a few things to be aware of:
- In CrossWorks, you need to create a project (with the LPC1768 as target chip) and have that project open before the JTAG interface will connect to it. If you try to connect without an open project, it will say ‘target not responding’. This had me stuck for about half an hour at first.
- The startup file (LPC1700_startup.s) that comes with the CrossWorks LPC1000 support package by default does does not jump to code execution after a reset. There is a good reason for this (explained in the comments in the file). Your code will only run if you use the ‘Build and Run’ option (from the ‘Build’ menu), or when the STARTUP_FROM_RESET preprocessor directive is defined (at which point the startup code will jump to main() as normal).
- As with most electronics things, the first task is to get a blinking LED. The BlueBoard has a LED at pin 1.29. The initial delay routine I wrote consistently blinked the LED at 333 KHz no matter how long or short I made the delay loop. It turned out that the compiler optimization had a hand in this. After disabling optimization (build configuration under ‘Code Generation Options’), doing nothing for 4 million clock cycles produced a neat 1 second delay. (4 MHz is the default speed from the on-chip oscillator, at which the chip will always run after a reset; I’m not spinning it up to the full 100 MHz just to blink a LED
). - If you buy the Olimex ARM-USB-OCD, it comes with a DC jack outlet and a short cable the purpose of which is to power Olimex-built development boards, but it also works perfectly fine with the BlueBoard, removing the need for a dedicated lab power supply (though I’d prefer to use that anyway, since it can provide much more power than the USB port can and removes the risk of blowing up said USB port in case of a short).
Overall, even though the BlueBoard lacks an on-board RS232 level converter (which is useful, since RS232 is the best invention since sliced bread, or at least, it is when you’re dealing with embedded software) and there is no documentation to speak of (aside from the board schematic, which does contain all the info you need though), there aint much that can beat it, especially at the price. I would definately recommend it to anyone looking for an ARM to play with.
Ancient
Who still remembers the good ol’ days of the PlayStation One?
I certainly do. It has been the only game console (the venerable gameboy aside) that I’ve ever owned, and back in the day, I used to play on it a lot. I never got any other consoles afterward though, but that’s mostly because I’m not too much of a gamer anyway (an occasional game I enjoy, but not much more than that) and I don’t want to spend a fortune on a console, another fortune on accessories, another fortune on games, and even more fortunes if you want to be able to play said games online. Especially not if all of those fortunes are not going to be used more than once or twice a week, at best.
Anyway, on a little side project, this week I took an old PSX controller for something different. What else than play PlayStation games can one do with a PSX controller, you might ask? Well, hook it up to a microcontroller and use it to control whatever you want, of course!
The something else to control is kind of missing in this picture, but you get the idea. There’s a PlayStation controller hooked up to a PIC18F2520 (its a PIC18F2520 because I happened to have it at hand, and it’s running at 40 MHz – not because that much is needed to read a few buttons, but because all my delay routines and template configuration files are based on that and I was too lazy to adjust everything). There’s a few LEDs for testing purposes, RS232 connection which sens the state of the controller out to my PC, and my trusty USB logic analyzer (which is awesomely useful in projects like this).
Interfacing the PSX controller isn’t all that difficult. There are nine wires – two for power to the controller (red and black for +5V and GND, respectively), two for power to the vibration motors (various sources state 7-9 V, but they run on 5 V just as well), and five wires for communication (one for bits sent to the host, one for bits sent to the controller, clock, attention (like the chip select in SPI), and an acknowledge signal from the controller). The clock runs at 250 KHz (500 KHz for the newer PS2 controllers, though the protocol for those is identical). During a transmission the attention line is made low by the host, data is clocked in at the rising edge of the clock signal, and after each byte the controller pulls the acknowledge line low for a short period – in other words, fairly simple stuff. The only thing that is kind of annoying is that it is a synchronous protocol (i.e. data is sent to and received from the controller at the same time), but otherwise, it’s not hard.
The PIC asks the controller ‘how are you?’ about 50 times a second, and the controller responds with 6 bytes of useful data – 2 bytes for all of the buttons (there are exactly 16 buttons, so that’s convenient) and 2 for each of the analog sticks. The PIC compares the data to an internal buffer to detect if something has changed, and if so, the output on the serial console is updated. It poops out the status of all buttons, with some VT100 terminal control codes to clear the screen and make the output look pretty. On powerup, there is even a pretty screen with the classic “Press Start” message (in blinking text, woohoo!).
Unfortunately that is about as far as it goes right now. If I had more of these controllers and a little graphical LCD, you could do fun things with it though! (I need to keep that in mind )
Furthermore, I am also starting to play a bit with ARM microcontrollers. Got an evaluation copy of CrossWorks for ARM (which is an awesome piece of software – expensive, but awesome!), and a bunch of LPC2103/2138 chips (LQFP packages… not a lot of fun, but quite doable with a bit of practice). These chips are an awesome platform for a lot of things, thanks to their speed and memory size, which would put any PIC or AVR to shame, and with a much more efficient instruction set as well. But more on that later.
Playing (part 3)
Wheee! Things are starting to take shape on my little PIC project here
The code to control a character LCD is progressing nicely… it can now automatically align text on the screen and stuff like that. It’s also handling custom characters quite well. The nice thing with these screens is that you can display most ASCII characters on them, but also a number of customized characters (which are displayed by using the ASCII values that are normally non-printable characters, eg 0×00, 0×01, 0×02, etcetera).
Obviously, since I’m working in C the 0×00 one can be a bit of a problem at times, because in C it’s also the string termination character (but I can still send a 0×00 manually to the screen… so no big deal).
Also, in addition to powering the LCD, I also have a flashing LED once again! Only this time, it’s flashing at a pretty accurate 1 second interval, and is doing so using timers and interrupts. Once every 50 000 microseconds, an interrupt tells a variable to go up by one; once it reaches 25, we know that a second has passed 
(If you’re wondering what the hell an interrupt is: when certain events happen, such as a timer reaching its maximum value or the state of a pin changing, that may generate an interrupt, at which point the processor jumps to a certain location in the program to handle it. Basically it’s calling the processor’s attention away from whatever it’s doing to handle something that is urgent and which probably should be handled right now. Afterwards it’ll get back to what it was doing before the interrupt happened. It’s like you’re walking in the grocery store and your phone rings: you stop to pick it up, and when you’re done you continue shopping. It’s the same principle really (you’re the processor, and your phone just generated an interrupt to get your attention to the fact that someone’s calling you). Your PC also does this, but you don’t notice it normally.)
That may seem a bit elaborate, and well, erm, it is elaborate, really. It takes a good amount of code, as well as a bunch of calculations to make sure that the timer runs properly. But I’m learning the PIC to tell what time it is, and I’m just using the flashing LED to make it indicate to me that a second has passed. For some reason that remains unexplained sprintf() doesn’t seem to be working (and it’s a bigass function too… you’ll probably never notice it on a PC, but on a PIC the size of it is significant), so it’s going to be difficult making it actually show the time. But I’ll find a way
Playing (part 2)
As I mentioned in my post ‘Playing’, debugging PIC software is quite often not nearly as easy as debugging PC based software. My (current ) lack of experience with both PICs and C didn’t help a lot either. Though I have managed quite easily to pass the ‘hello world’ equivalent of blinking a LED on and off, the next step – actually displaying ‘Hello World!’ on an LCD – was less easy.
I had the basic code for writing instructions, and the actual instructions, to the LCD correct. It’s a standard 16×2 character LCD with a HD44780-compatible controller (you can control one of those using the parallel port on a PC actually). I have a great little simulation tool which has a module to simulate the display, but of course I couldn’t take the easy path for my actual hardware implementation.
My actual hardware implementation was a bit more tricky, because I wasn’t connecting the LCD directly to the PIC as the simulator assumes. I’m using a shift register for the data lines, which greatly reduces the number of pins needed on the PIC, which is good news because it doesn’t have a whole lot of I/O pins. I had a couple things wrong in sending data out of the shift register. (Basically, a shift register is a simple chip that accepts a serial input (2 lines) and translates that to a parallel output (8 lines).) It may have included sending the bits in the wrong order.
Obviously, because the instructions that did arrive at the LCD arrived in reverse order, they didn’t mean a whole lot and the most interesting thing I was able to do was blink the backlight on and off.
But a bunch of LEDs and some added delays allowed me to see exactly what was going on, and now finally, I have a display that shows ‘Hello World!’ 
I’ll take a picture later.
(And, further debugging should be relatively easy, because I now have a way to let the PIC tell me what it’s doing ).
And another thing… There’s a new menu item on the top, ‘PIC programming’. I’m writing a load of PIC-related stuff which could possibly be interesting to someone. Partially because even at this point, where there isn’t much actual content in it, it’s already gotten me up at least 5 ranks on WhatPulse (I’m 803rd of the world as I type this ^^). For the moment it remains inaccessible to anyone but me, but some day…
Playing
Lately I have, largely out of a lack of better things to spend time on, been playing around with PICs a bit. Since you are probably asking questions such as ‘what the hell is a PIC?’, or ‘why does it sound like a Dutch word for penis?’, here’s a short explanation. A PIC is a small chip that is essentially a tiny computer. It has a CPU, memory to store a program in, RAM, and usually a number of peripherals like an UART (a module to communicate on an RS-232 line), USB, timers, EEPROM memory for more long-term storage of data (such as configuration), and so on. They vary from the extremely small PIC10F200, which has only 4 pins that can be used for I/O (say, blinking a LED) to large 32-bit chips that run at 80 MHz or more and have more than 100 pins. The most popular series however are the PIC16, and more recently, the PIC18 series.
As for why it sounds like a Dutch word for penis, I have no idea. PIC could stand for Programmable Integrated Circuit, Peripheral Interface Controller, or a whole lot of similar acronyms (but according to Microchip, it doesn’t really mean anything).
Developing stuff on a PIC is a whole lot different than normally developing software. For starters, you’re not just developing software, but the hardware as well. This means that at least a basic knowledge of electronics is invaluable, and with that comes things like knowing which parts or ICs may be useful for your project and probably at some point you’ll want to be able of designing your own printed circuit board (and making those/having them made for you). Second, it’s great to have software on your PC, but you’d probably rather have the software on the PIC – so you need a programmer. A programmer is a device that does exactly that – it ‘uploads’ software to the PIC. There are lots of programmers on the market, but what I’ve been using so far is the Wisp648 sold by voti.nl, combined with Bumblebee as PC-side software.
The fun part however is the actual programming for the PIC. Microchip offers some free development tools (MPLAB), but I never liked that, and you’re going to be stuck to using assembly. Writing a program in assembly isn’t as bad as it sounds – especially if you have programming experience and the program remains small – but on a larger chip, say, a PIC18F4550, assembly quickly becomes a huge, unmanagable mess. That is when you will realize that a higher programming language would be great, and for this type of thing, C is probably the best choice. There are a number of C compilers for PICs on the market, but most are staggeringly expensive, and come with a lot of proprietary stuff, so you’ll be stuck with that particular package for the remainder of your natural life. There is, however, a great alternative: SDCC, the Small Device C Compiler. It supports all the most common PIC16/PIC18 devices, but there’s a great lack of documentation and source code, so you’ll have to figure out a lot on your own.
Not that figuring out stuff on your own is uncommon: developing hardware (and software) can be pretty much a trial-and-error process.
Installing SDCC is pretty simple, both for Linux and Windows (yes, it works on more than one platform! hooray!). To work, SDCC will also need the gputils package, which is again pretty straight forward to install. I do strongly suggest that you enable the option to include the binaries in the PATH variable in Windows, it makes life easier. After installation, you’ll probably be thinking ‘okay, what next?’ and that’s were it gets funny.
Since you’re doing stuff for an embedded device, this version of C is not something you can really compare to what you use to write software for your PC. Sure, the syntax is identical, and most of the standard C libraries are implemented (printf, math, stdio, …) but that’s about it. Half of the code you write will be directly accessing registers on the PIC (since they control all functions of the device). Half of the time you’ll be looking up stuff in the datasheet (which is usually over 400 pages) and the other half you’ll be wondering how the heck you are going to debug your code – after all it’s running on a small, isolated chip and getting anything at all on your computer screen isn’t quite as easy as with ‘regular’ software. Then there’s the limitations of the device – you probably have a lot of functionality you’d like to include, and only so much I/O pints to work with, and only a limited amount of code memory and RAM. Especially when using C, it’s easy to run out of any of those. Also, everything you’re doing is quite low-level code – you’re directly telling the chip which pins are doing what, handling interrupts, and so on – no fancy multithreading or whatever.
For debugging/testing purposes, I’ve also been playing with this tool. It simulates a PIC processor on your PC and behaves (almost) identical to it. You can see what each register and memory locations (or ‘general-purpose register’) is doing as your program runs, how much time everything is taking, and so on. Of course you can never rely 100% on a simulation (after all, on the PIC there are loads of variables that the simulation tool does not include) but it is extremely useful. Unfortunately it’s not a free tool, but the basic home-use version is only € 29 and it seems to be the best PIC simulator I’ve seen so far (and also by far the most user-friendly, which is great because I want to be developing the software, not spending 3 weeks learning to use the simulation tool).
Altogether there’s an amazingly steep learning curve, but that only makes the satisfaction all the greater when you’ve got your first ‘blink a LED’ (the PIC equivalent of ‘hello world’) working. And, of course, there’s a huge number of useful things you can do.
Note: as said before, there is an amazing lack of documentation and source code for this kind of stuff. Also for the electronics part: my father works with electronics, so I had already picked up a thing or two, but if you have zero knowledge on this kind of thing, you’re mostly on your own. Depending on how much time I have and whether I feel like it, I might be writing some tutorials and sample code/libraries for use with SDCC, which will probably show up in the menu bar on the right (but when something goes online, it’ll be posted here too, of course ).