uEZ v2.00 has been released!

Hello, World!

Welcome to uEZings!  From time to time, the folks from Future Designs, Inc. will post information and commentary on the what we’re doing with our middleware embedded software solution called uEZ (“Muse”).  I intend to keep our posts informal but informative.  When you see something you like … or even possibly what you don’t … feel free to voice your opinion here.

So, on with the show/blog ….

uEZ v2.00 Release

Today we have released a new version of uEZ and many you are wondering, “What’s with the 2.00 number?  Weren’t we just on v1.12 or so?  Is this going to make everything I’ve done with uEZ become incompatible?”

The quick answer is that uEZ v2.00 is v1.12 plus a whole lot more.  So much more, I think you will want to change to the new design — thus, the v2.00.  Let me give you the details.

uEZ v2.00 is a Library

The previous version of uEZ were built along the idea that uEZ would be compiled into each and every project.  In fact, the original design of uEZ was to be code where every file is included in a project and with one handy #define, you can change from one processor to another.  Alas, that design turned out to be much harder than we expected.  With the need to support different compilers and assembly language files as well as general linker and other configuration files, we quickly found out each multiple projects based on processor and compiler type were necessary.  So, we split up uEZ into multiple builds.

We still kept close to our heart the idea that we could still somehow have one big monolithic blob of code where #define’s could turn on and off the features needed and so we added multiple config files until we ended up with four:  Config_Processor.h, Config_Platform.h, Config_App.h, and Config_Build.h.  But feedback has shown that people just like it and find them hard to use.  If anything, developers want the whole thing to Drop In and Just Work(TM).   Add to the complex configuration several hundred files and developers start to get a bit overwhelmed.

So, like a graphics library, we are changing uEZ to be just that — uEZ v2.00 is now a library.  If you look in the /uEZ/Build/Generic directory, you’ll find a tree of multiple processor, RTOS, and compiler types that can be compiled into two easy libraries:  Debug and Release.  To make the process even easier, we’re also providing uEZ in precompiled libraries you can link with your project.

uEZ v2.00 is Easier to Configure Hardware with Require functions

Since we went to a library, we could no longer depend on #define tricks that would change the code from one setting to the next.  If you want access to the SPI0 bus, you no longer can just set UEZ_ENABLE_SPI0 to 1 in your configuration files and have it turned on.  Additionally, we only want the SPI code to be in the project if it is needed.  Therefore, we have chosen to depend on the linker to pull in the needed code through what we call “Require” functions.  A require function merely is a routine that adds the device driver or subsystem to uEZ at startup.  Require functions only work once.  If the same require function is called twice, it will ignore the second call.  A SPI0 driver can be required multiple times in the code and it will be initialized on the first requirement.

Require functions also declare what the configuration will be for that device.  For example, on many processors, the SPI can be connected to 1 of several pin locations.  The require function declares which pins to connect to that SPI peripheral.  On the NXP LPC1788, this can be done in a simple function as follows:

    LPC1788_SPI0_Require(GPIO_P2_22, GPIO_P2_26, GPIO_P2_27, GPIO_NONE);

In this example, the four parameters represent the SCK, MISO, MOSI, and SSEL pins for the LPC1788.  Since we only use the first 3 pins, the fourth is left unconfigured and available for another device.  As well, this registers the HAL driver for the SPI0.

We’ve also added new logic to the GPIO system.  As shown above, all pins on a CPU can now be referenced by a single 16-bit value.  No more passing around HAL_GPIOPort ** and a pin index.  Routines such as UEZGPIOSet() and UEZGPIOClear() make toggling a pin easy to handle.  Although not all of our drivers have been changed over, we’re working on using it more and more.  More importantly, GPIO pins can be “locked” when configured.  All require functions lock any GPIO pins used with the command UEZGPIOLock().  The pin is marked as used when locked the first time.  If another service or peripheral tries to the lock the pin again, an error is flagged on the LCD as a BSOD (Blue Screen of Death).  You’ll no longer have to be debugging code only to find that the pin was double assigned and not in the initial mode you expected.

In the past, we put it on the developer to setup all the pins in the routine UEZBSP_CPU_PinConfig() possibly using a “pin config” file.  This is no longer the case.  Going forward, all HAL uEZ drivers will lock and configure the pins needed for that peripheral.

uEZ v2.00 is Easier to Configure Platforms

Require functions are also in the platforms (specific hardware implementations).  The platform uses the above require functions to setup the device drivers that interface to the low level HAL drivers.  Routines such as UEZPlatform_Serial0_Require() not only create a device driver for serial #0, but also connects it to the proper HAL serial driver for your hardware.

These uEZPlatform require functions can be thought of small installers who not only bring up the device driver but also bring up anything else needed for that functionality.  For example, when using an LCD, the UEZPlatform_LCD_Require() routine will pull up the LCD Controller, Backlight generator, and power on/off control lines.  Application developers can then call UEZPlatform_LCD_Require() in any system and know that the LCD has been setup and all requirements met before continuing.

An added advantage of doing it this way is only the code needed is linked into the source code.  If an application never needs the LCD, then the backlight code is not needed either.

uEZ just requires  a single routine in your application code to setup the platform called uEZPlatformStartup().  It calls all the standard uEZ requirement routines for devices needed.  In the FDI platforms, we help shorten this routine by also including a bulk requirement routine called UEZPlatform_Standard_Require() who calls a large number of the standard requirement routines we believe all users will need for a project.  A version called UEZPlatform_Minimal_Require() has been created for small implementations and UEZPlatform_Full_Require() added for those who want everything uEZ can offer on that platform.

To support these functions, all our platforms have been updated to with require functions and we hope you like them.  Many of the bug fixes can be carried back to previous editions, but we recommend going forward to uEZ v2.00.

Although I could go on and on about all the little bugs and changes we’ve made to uEZ, these are the big changes:  library builds, require functions, easy to configure platforms, and changed GPIO system.  The basic uEZ v1.12 is still there, but now it is easier to access.  Take a look and tell us what you think.

And one last thing:  Be sure to check out the file “uEZ v2.00 New Project Creation Guide.pdf” for getting started with a new project using the newly added uEZ v2.00 Templates.