The MPLAB Code Configurator is changing the way I write embedded applications. Some of my (relatively) recent code is starting to look positively ancient by comparison. Take for example AN1673, “Using the PIC16F1XXX High-Endurance Flash (HEF) Block”. It was written in the pre-MCC era (actually MCC was just on the drawing board when I published it) and you can tell.
But if you don’t know what a High endurance Flash block is, I’ll need to take a brief moment to introduce the concept/feature, first.
Ok, the picture is about a (flight) endurance record set in 1949 in the city of Yuma (AZ) on an Aeronca Sedan, but I thought it was quite curious … (besides if you want to read more aviation stories follow this [link] to my favourite book collection)
High Endurance Flash blocks (HEF), featured on PIC16F1 microcontrollers, are novel hybrids between a data EEPROM and a Flash (program) memory block.
They get the benefits of both: the high erase/write cycle count (100K+) of an EEPROM but also the speed of the Flash block (up to 32 bytes written in 2.5ms max)!
Better, they are featured in the smallest and lowest cost PIC microcontroller models and they are usually mapped at the end of the regular Flash (program) memory array. This way, if you don’t need them, you can use them as regular Flash for your application.
AN1673 was an attempt at popularising this feature and making it easy(er) to use by offering/demonstrating just three simple (C language) functions:
HEF_ByteArrayWrite( block, *bArray, count); HEF_ByteArrayRead( *bArray, block, count); HEF_ByteRead( block, uint8_t offset);
The underlying idea was to simplify access by referencing the HEF memory in blocks (numbered 0..7, depending on model and size) and hiding all the complexity of handling the addressing and correct sequencing of flash memory block erase/write cycles.
This is essentially the foundation of every peripheral driver that MCC generates today. In fact thanks to MCC, today I would re-write the application note by building its logic, those same three functions, on top of standard MCC generated Flash drivers (memory.c / memory.h).
The big difference, compared with the original code, as you will see, is that thanks to MCC I didn’t need to worry anymore about the lower level details. MCC took care of it for me by defining convenient macros and customising the code to the specific device I chose (PIC16F1619 in this example). The code is cleaner and the responsibility to select the right memory sizes and address ranges is left to the maintainers of MCC and, ultimately, a small database that is already built inside MPLAB.
Less code, less complexity, more time to focus on the application, (hopefully) better designs.