Category Archives: Uncategorized

Adding Menu Options to A Sketch

Did you know that you can add UECIDE menu items to your sketch? Not sure what I mean? Ok. Here goes.

Imagine you have one sketch that you want to use in multiple different ways. Maybe you have both “master” and “slave” code within the same sketch and want to select between them. Or maybe you want to be able to set a different communication speed, or a different buffer size, depending on how you are using the sketch at that moment. The traditional way of dealing with that sort of thing is to use #define and #ifdef, etc:

#define BUFSZ 1024

int16_t bufferA[BUFSZ];
int16_t bufferB[BUFSZ]; Continue reading


Debugging chipKIT sketches in MPLAB-X

You have a rather complex sketch. It’s not working right, and you just can’t find out why. If only there were a way to single-step the program and see what it’s actually doing.

Well, there is now, and here’s how.

From version 0.8.6t (beta version) there are now enhanced facilities for linking up with MPLAB-X.

First you will need a decent hardware programmer, such as a PICkit™3, ICD, or the chipKIT™ PGM. Secondly you will need to install MPLAB-X (if you don’t already have it).

Once that’s all set up and running as it should be you are ready to set it up for chipKIT debugging.

The first thing you need to do is tell it what a .ino or .pde file is.  So in MPLAB-X, go to Tools -> Options, then select the Miscellaneous section.  Within there is a Files tab.  You need to add two entries to the File Associations section.

Start by clicking the New… button and entering “ino” as the file extension.  Now in the Associated File Type (MIME) drop-down list select “C++ Data Loader (text/x-c++)”.

Repeat for “pde” with the same MIME type.  Once done, press the “OK” button and you are good to go.

Now for the debugging. 

Load up UECIDE and open the preferences.  Switch to the “Compiler” tab, and turn on the “Compile the sketch in the sketch folder” option.  This will place the build folder inside your sketch folder rather than in your temporary directory. It also won’t delete the build folder when you exit UECIDE. You also want to ensure that “Remove old build folder before each build” is turned off.

Now load your program into UECIDE as per normal, ensure your board etc are all selected right.  Now comes the magic.  For the programmer, select “Pickit 2”.  It doesn’t matter that you’re not using a PICkit 2.  What this does is change the linker script that is used by the compiler to the “-nobootloader” version.  The sketch can then be run stand-alone without the need for the bootloader (in fact parts of it replace the bootloader completely, so you will want to replace the bootloader once you have finished debugging – I’d go grab the hex file for it now if I were you).

Hit the build button in UECIDE (not the program button, just the build button), and it should generate you, amongst other things, a .elf file within the build folder in your sketch.

Now back to MPLAB-X.  Create a new project in there, and select “Microchip Embedded” and “Prebuild (Hex, Loadable Image) Project”.  For the Prebuilt FIlename, browse to the .elf file that has just been generated.  Select the right chip in the Device drop-down, and your programmer in the list of programmers.  Hit finish, and it should load your program into MPLAB-X.

You can now use all the debugging tools in MPLAB-X to find out what has gone wrong with your program.

Any changes you want to make, just switch back to UECIDE, make the changes, hit compile, and MPLAB-X should see that new version of the .elf file automatically.


If MPLAB-X says the programmer can’t communicate with the board, or it’s not in debugging mode, etc, then it could be that the settings in the linker script for the chip on your board don’t exactly match the layout of your board. Unfortunately the linker scripts are set up by chip, not by board, and some boards which use the same chips have different layouts, especially as to which programming pins they use.  If that is the case, then you may want to create a new blank project in MPLAB-X for your chip type and use the Configuration editor (Window->PIC Memory Views->Configuration Bits) to create a configuration that is correct for your board.  Copy the HEX values for the configuration into the “config0” – “config3” settings in the -nobootloader.ld file for your chip (located in %UECIDE%/cores/chipKIT/api).

Creating a portable UECIDE bundle

Since the very beginnings of UECIDE there has been a little known feature that allows you to create your own portable bundle of UECIDE.  That is, your own copy of UECIDE that you can place on a USB memory stick, network drive, SD card – wherever you like – and wherever or however you access it you get all the same boards, cores, compilers, etc.

The most common platform for wanting to do this on is, of course, Windows, so we’ll detail doing it on that platform, but the principle is the same for all others.

Ok, so what do you need to get started with making your own portable bundle?  First, you need to download the latest version of UECIDE.  You need to ensure you get the “full” version, so it includes the Java Runtime Environment (JRE), and get it as a ZIP file, not an installer.

Step two is to just extract the ZIP as normal, (maybe onto your desktop?), and run UECIDE.  Once UECIDE is up and running, install your boards, compilers, cores, etc as per normal.  Make sure everything works.

Now comes the magic…

Close UECIDE – you won’t need it for a few moments.

All the things you have downloaded will have been placed into your own user’s “uecide” folder.  Assuming your username is “Bob”, (Hi, Bob…) that will be located in C:\Users\Bob\AppData\Roaming\uecide.  Open that location in an explorer window – you’ll see a preferences.txt file, and folders named “boards”, “cache”, “cores”, “compilers” and “plugins”.  You’re interested in, of course, the “boards”, “cache” and “cores” folders.

In a second window, open up the location you extracted your UECIDE ZIP file to.  One of the folders in there is called “hardware”.  Open that folder.  It should be completely empty.

Drag-and-drop the boards, cores and compilers folders out of your uecide folder and into the empty hardware folder.  It may take a moment or two to move all the files – compilers often have huge numbers of small files in them.

One that’s finished you are as good as done.  If you downloaded any plugins, such as the Grapher plugin, you will want to get those into the bundle too.  They go in a slightly different location.  Where you extracted the UECIDE ZIP, alongside the hardware folder you found earlier, there should be a “plugins” folder.  That should have some plugins (.jar files) in there already.  The plugins folder in your user’s uecide folder should also contain .jar files.  Just drag them from one to the other, as you did with the boards etc.

And that’s about it.

Fire up UECIDE again and make sure everything is still there and working right.  You can drag the whole extracted UECIDE zip folder onto wherever you want to keep it, and run it direct from there.  Try it out.  Plonk it onto a USB memory stick, plug it into your friend’s computer, and you should be able to run UECIDE direct from it, including all your boards and other downloads being there already.

Linking binary files

Have you ever had the need to add a binary file to your sketch?  You know, you are working on a project with a TFT screen, and you have a couple of nice icons you’d like to import into the sketch to then display them on the screen, or you’ve got some hardware attached for generating audio, and you’d like to embed a couple of small WAV files into your sketch.  It’s not the easiest thing to do, normally, is it?  It typically involves converting the binary file into source code, usually an array, and adding it into your sketch that way.  A bit clumsy really.

Well, with the release of the latest version of UECIDE (0.8.3b), there is a better way (compiler permitting):

You can now create a special folder inside your sketch called “objects”.  Any files placed in this folder will be gathered together at compile time, and converted (usually with objcopy) into object (.o) files.  These files are then linked with your sketch, and you get full access to the data in them.

No more messing with programs to convert the file into source code.

So how does it work?

Well, at this moment in time it’s only supported for PIC32 targets, but it will be rolled out to the other major compilers as soon as we are able, but the standard toolchain command “objcopy” has the ability to convert just about anything into an object file.  When it creates the object file it adds a couple of standard symbols into it as well, so you can access the data.  These symbols give you the start address of the data, the end address of the data, and the size of the data.  Each one is unique and is derived from the source file the object file is created from.

So let’s say you have a file “icon.565”, which is an icon file you have converted into 16-bit “565” format common to most TFT screens.  Placing that in the “objects” folder and compiling your sketch will create “icon.565.o” in the build folder, which is then linked to the sketch.  Now, unfortunately it’s not just a case of defining an “extern” to the symbols you want to use.  Instead you have to use a little tiny bit of assembly to reference the symbols.  Don’t worry, it’s pretty straight forward:

extern uint16_t icon[] asm(“_binary_objects_icon_565_start”);

You can then access the array “icon[]” and get at all your data.

The format of the symbols is: _binary_(munged filename)_start, _binary_(munged filename)_end and _binary_(munged filename)_size.  The munged filename is the path of the file you added, including the “objects” folder, with any slashes and dots replaced with underscores.  Thus, icon.565 becomes _binary_objects_icon_565_start etc.


Welcome to the new UECIDE blog.

I felt it was about time I made a blog to help keep people up to date with what we have planned for the future of UECIDE – what is in the works, what we’d like to add in the future, etc.  And so, here it is.

So without further ado, what is happening in the UECIDE-o-sphere?

New systems

We are in the process of adding new families of hardware targets.  Most notable of these is the PIC16 target, mainly for the CHIPINO family of boards, but can also be used with any PIC16 based board.  We’re experimenting with using the open source SDCC (Small Device C Compiler) compiler, which if we get it working right for all platforms will also open the door to many other 8-bit chips, such as the Z80 and the 8051 amongst others.

Also in the works is support for the Teensy boards.  Unfortunately we don’t actually have a teensy board to try our code out on, so all we can do at the moment is hope that it’s working until we can find someone to test it out for us (or who can donate some hardware to us).

New Preprocessor

Experiments are underway to create a new source code preprocessor to replace the rather simplistic regex based preprocessor that is a hangover from the Arduino code.  We are looking into the possibility of using the compiler (when it has such facilities) to do proper preprocessing of the code.  This will allow proper use of #define macros to selectively compile code which, until now, have been causing untold problems with the automatic insertion of function prototypes.

Theme System

Big changes to the theme system are on the horizon.  What we really want is a nice clean way for the end user to be able to edit the theme, or install third party theme archives, through a nice simple user interface.  No more fiddling with theme.txt files.  Integrating it with the plugin distribution system would also be one of the main goals – maybe massively expanding the whole plugin manager system in the process.  Watch this space.

New Name

While the name UECIDE is perfectly adequate and describes exactly what UECIDE is, it’s not really a catchy name.  Other IDEs have great names – Eclipse; Anjuta, Netbeans, to name but a few.  UECIDE just doesn’t trip off the tongue.  So we’re in the market for a new name.  We’ve had a few suggestions already, from ranging from the ambiguous Chameleon to the rather tasteless Suecide, but none of them have yet really jiffled our tipples.  It needs to be something that encapsulates the whole idea of the universal IDE; the IDE to rule all IDEs (and no, Ring IDE or Nasgul IDE aren’t really in the running I’m afraid).  So get your thinking caps on. Suggestions on a postcard please.