MPLAB Code Configurator with a bum licence

I've been looking at the MPLAB Code Configurator to help set up the PIC16F enhanced range. It is known as MC² (hmmm). It is interesting, has a decent layout, helps quite a lot but I won't be using it very much at all.

Working on a laptop with the NetBeans IDE that the MPLAB X uses is a tight fit. Fitting all of the windows across the screen can be a bit awkward. MC² adds extra windows on tabs to increase the clutter, but is does it as well as can be expected and fits in the general layout theme well enough.

Firstly it lets you review and set the configuration bits of the micro controller. It reflects all of the configuration of the chosen micro controller and help select the system clock settings too. This is quick and useful.

It then allows you to include settings for each feature of the micro controller you want to use, including all of the GPIO. There is a pin manager view of the micro controller which shows you the package layout of your choice and which pins are used by the features you are using. GPIO pins can be renamed. Interrupts are set up where necessary. There is then a button to click to generate the code for the chosen options.

The code is generated in separate .h and .c files and, if you want it, a main.c is generated too which has all the includes and calls set up ready the main body to be added. The code all carries generated comments to help understand what the code does. All of the generated headers and code, except main.c, are in folders called MCC Generated Files to help find them.

When a GPIO pin is renamed a number of #defines in the headers use the name to allow more understandable code. For example if the portb pin 3 is renamed to LED then a #define LED_GetValue() is created to read the pin, LED_SetHigh(), LED_SetLow() and LED_toggle() are amongst the other #defines. The fact that these look like functions but are actually substituted as a small piece of code means the code will execute quickly, the stack won't over flow with too many calls and only code that is used will be incorporated by the compiler.

All of the other features are suitably handled, interrupt code is generated and so far all is well.

I said earlier that I won't be using this. It sounds, and is, useful so what is wrong?

All of the generated headers and code have a boilerplate licences on the front of them. It claims the code is written by Microchip Technology inc., which it is. This is followed by a bespoke licence making it clear that the code is only available to be used, modified, copied and distributed in an embedded on a Microchip controller. Under copyright law I could probably justify copying snippets in a post like this, but I cannot copy the code onto a code sharing service such as Github. The licence doesn't mention any time period - I would need it to be perpetual - so I don't know if Microchip will just revoke the licence in the future. Of course I could just ignore the licence and hope no one notices, or even just delete the boilerplate and pretend the code is mine, but that's not for me.

I dislike restrictive licences, so I won't be using or supporting it and I hope you don't either. MC² looks interesting and useful, but the licence is a serious obstacle.

Enhanced mid-range

I had a browse through a comparison of Microchip's PIC microcontrollers and noticed the enhanced mid-range. I'm thinking about controlling some motors and some of these enhanced range have multiple PWM outputs. I bought a couple of PIC16F1827 to try.

I have been using the MPLab X IDE with XC8 C compiler on a laptop running Linux to program the PICs. I use Pickit 3 to send the code into the PIC and that is compatible with the enhanced PIC16s. I discovered the MPLAB Code Configurator which should help setting up the new PICs - it doesn't work with any of the old ones.

The enhanced range have various improvements, including being optimised for C code with a bigger instruction set, more interrupt lines, more input and output options, such as more analogue and PWM lines. It seems there is a more powerful internal clock, up to 32MHz on some PICs. If that works well, not needing an external crystal would be handy, not least because on small PICs that would free up two more GPIO pins.

I thought I'd set up a simple test bed and see what I can do.