Because a lot of people have asked me about PIC programming using the AMICUS18 BASIC compiler and how to do things, I thought it would be interesting and useful if I wrote a series of articles on the subject (see here).

So, to kick things off I’ve placed the first three on this website. I’ve never done anything like this before so please let me know what you think or if there are any topics you would specifically like me to cover.

I’ll be adding more parts on an on-going basis.

You can find the dedicated page here:

Now I love clocks, I really do. They are great projects because you can place them on the mantelpiece or in other prominent locations as a functional working device, partners can’t complain about it being another piece of junk because they do something useful, they come in all sorts of shapes and sizes and are great beginner projects and once you’ve built it, you can tell people “I made that”.

Recently, I’ve been working on a new clock project and it suddenly occurred to me that except for the physical display aspect of the clock, the internals are nearly always the same. A battery-backed RTC for the date/time (usually a Dallas DS1302) with support components, a PSU section of some type that usually puts out 5v for the logic and possible an additional higher voltage for larger LED displays, a PIC to glue everything together and some display driver hardware.

The only really custom part is the physical display, and the PIC firmware, and this got me thinking; “Can I construct a generic clock that can have many different displays connected, and just need to update the PIC firmware as required”?

So, this is what I’m currently working on. Some more thought is required on some of the projects finer attributes but I have an initial prototype sat on my breadboard that’s driving a strange looking LED display with 60 LEDs on it (I’ll post pictures later) and it seems to be working well.

The next part is to design several other display units and make sure that they can be driven by the hardware.

I recently posted details of a complete construction project for a digital thermometer and clock, partly in response to a request but also because I’d been thinking about building one for a while. Because I wanted this to be an easily maintainable project by anybody, I opted to use the new AMICUS18 free compiler from Crownhill (I already use their PROTON BASIC+ compiler but you have to purchase that though it supports most, if not all, 10F, 12F, 16F and 18F parts). In a nutshell, the AMICUS18 compiler and IDE allows you to write Proton BASIC programs for two specific Microchip PICs, and these PICs just happen to form the core of Arduino compatible CPU boards and shields, so this basically means that you no longer have to work with ATMEL CPU’s exclusively if you want to play with Arduino hardware, and because AMICUS18 is free, this opens up a whole pile of possibilities for project construction, for as long as you limit yourself to a couple of PICs (18F25K20 and 18F25K22), then you can write unrestricted and very powerful code in good old friendly BASIC.

I’ve also realised that whilst there are many web sites containing lots of projects to build, they tend to supply you just a circuit diagram and if you’re lucky, a .HEX files for the CPU. These are ok for seasoned constructors who in reality, probably just want to grab some circuit ideas and wouldn’t usually build the project in it’s entirety in the first place, but for beginners and novices, something more akin to what the great electronics magazines of yester-year used to produce is more appropriate and that’s why I’ve opted to try and provide full construction details for some of my projects.

So, with all this in mind, I’m currently working on another project – an Evaporator.

Ok, actually this is a device that produces a small amount of heat and has a thermometer and timer built in. You set the run time in minutes, maximum temperature you want, and the device attempts to maintain a “hot-zone” at the required temperature for the specified time. In this version of the project, I’m using a 12v / 20w halogen lamp has the heat source and it’s used to gently warm an evaporating basin (small porcelain dish) that’s full of liquid that in turn has a solid dissolved in it. You could use it to recover the salt (and the other solid material) from a few mL of sea-water for example. With a few changes to the physical hardware layout and perhaps a different heating element, you could use this as an incubator. The unit has an LCD display, some push button switches, a temperature sensor, a MOSFET that can switch around 35A if required, PSU section, and a PIC 18F25K22 running some firmware written using the AMICUS18 free compiler; this means you can customise the firmware as you please. One upgrade may be to fit a fan so that if it gets too warm it can cool; perhaps the addition of a Peltier module - the skys the limit when you start thinking about the possible options.

The prototype which is sat on a bread-board right now, works remarkably well. I use PWM (Pulse Width Modulation) to drive the heater (lamp) via the MOSFET. The heat from the lamp is detected by a DS18b20 1-wire temperature sensor (I had a couple spare from my digital thermometer project), and fed back to the PIC. The PIC constantly monitors the temperature and using a very simple algorithm attempts to maintain the temperature by adjusting the brightness of the lamp. Once it warmed up, it was maintaining the temperature to within 0.1 oC which for a first attempt was rather impressive I thought.

I’ll publish full construction details soon, probably when I get back from vacation.

The one subject that rears its ugly head from time to time and is always a catalyst for a heated debate is “which programming language to use for PICs”, and I am talking about only PICs here, though this is probably the same for many of the embedded type CPUs available.

Assembler is the best to use as it allows the developer to get as close to the PIC hardware as possible, gives the most flexibility and offers the best performance, and this is true… to a point.
It’s also the most complicated as many simple tasks require a lot of assembler instructions, so there’s more you have to type, so more you can get wrong. On the flip side, you have the opportunity to fine tune the program and validate the need for every instruction within your program. Another problem is that every CPU manufacturer has their own assembler and instruction set and it can be a real pain moving from one CPU manufacturer to another. Often, the same manufacturers often use different assemblers and instruction sets for different CPUs that they make.

For the best performance and the tightest control, in the hands of a highly skilled programmer you can’t beat assembler, but you have to know exactly what your doing and you stand an equal chance of creating slow, bloated and buggy code.

“C” – is a higher level language than Assembler which means that it shields the programmer from some of the nitty gritty issues that Assembler has. It’s easy to read but like any programming language, if you don’t know what you’re doing, you can make a complete pigs ear of things.

The advocates of “C” will brandish around phrases and words like “ANIS compatible”, and portable. Unfortunately, in the PIC world, one also has to brandish around the word “rubbish” as well.  “C” as a programming language has only a few instructions associated with it. Most of the really cool features like talking to the A2D ports or the I2C hardware within the PIC are actually performed by 3rd party libraries; there is NO native support within the "C" language for this. Usually supplied with the language installation, some of these libraries are written in Assembler, some written in “C” but they aren’t standard across all “C” implementations. This means that “C” from Microchip is different from the “C” version from FED so you can’t just cut and paste source code and watch it re-compile without a page full of warnings or errors.

Now my favourite, BASIC.

I can hear the groans and moans about how BASIC is slow and bloated. RUBBISH !!!!

BASIC comes in two main flavours; compiled or interpreted. Interpreted BASIC’s are usually slower than compiled languages and that’s a fact, but you get a bit more flexibility. For example, you don’t always need a PC (or a PIC programmer) to program a PIC that’s running interpreted BASIC; a dumb terminal will often suffice. (Yes, you can get boot-loaders, but they still usually need a PC unless you use a PICKIT with it's on-the-go programming feature and these don't allow you to develop new code; just flash the device with a pre-built HEX file).
Also, interpreted programs are often simpler to debug as you can stop them mid way through execution and look at variable contents. However, speed and code size are usually more important than ease of development once you've passed the pure beginner stage.

Compiled BASICs are no slower than “C” programs and I’ve timed them to prove it !!

All the “C” compilers that I’ve found work in the same way. They parse your “C” source code, spit out a file containing PIC assembler, and then pass that assembler to the standard Microchip assembler to generate the .HEX file for the PIC. And why not? There's no point creating your own assembler as the Microchip one is maintained by the supplier, is free, and rather good at what it does.

The BASIC compilers tend to work in exactly the same way.

The ONLY thing that makes one compiler better than another is the tightness of the assembler code it produces and the quality of the associated libraries and code optimiser and this rule is programming language independant.  I compared Proton+ BASIC with Microchip “C” and found no difference in the speed of execution for some simple tasks.  Some differences were noted when using some library routines and there were swings and roundabouts with both.

Yes, it’s possible to write slow and bloated code in BASIC, but that’s also true in “C” or any programming language.

Some of the cool features like bit manipulation that are common in "C" but not often found in PC type BASICs are fully supported in PIC BASICs.

The bottom line is find a programming language you like, learn it well, and you should be able to write fast and efficient code.

The "thing" about BASIC; nobody expects it to be portable or "standard".