#451 [RFC] Support "Doubly-Enhanced" PIC14 Cores, with examples of PIC16F15325/345

[Tom Li]

In recent years, Microchip has released a new revision of the PIC14 microcontroller with what I call "doubly-enhanced" 14-bit cores, whose support is currently lacking in SDCC. These "doubly-enhanced" cores are just like normal enhanced cores, the only difference is that they have 64 instead of 32 memory banks, and thus use a 6-bit Bank Select Register instead of 5 bits. In gputils, these devices are classified as PROC_CLASS_PIC14EX to distinguish them from ordinary enhanced cores, PROC_CLASS_PIC14E - gputils version 1.5.2 is necessary to support these devices.

Because of this crucial difference, a "doubly-enhanced" library is incompatible with ordinary "enhanced" library, and must be built and linked separately.

Changes Made by the Patch

My experimental patchset adds support for "doubly-enhanced" cores by doing the following:

1. Duplicate all the existing files in the libsdcc/enhanced directory (which creates libsdcce.lib) as libsdcc/enhanced2.
   • The name enhanced2 is chosen instead of enhancedx is due to a name conflict. In the existing code, the suffixx is already used to indicate experimental versions of the library. Adding another x would create significant confusion.
2. Modify the build script to build a new variant of the library for "doubly-enhanced" cores, known as libsdcce2.lib.
3. Introduce a new parameter value for pic14devices.txt, the field enhanced can have a new value 2 in addition to the existing Boolean 0 and 1. As it's a non-zero value, all the existing C comparison with isEnhancedCorein the code still works.
4. Modify main.c of the PIC14 target entry point to select libsdcce2.libif the enhanced field is equal to 2.
5. Finally, device definitions and headers for PIC16F15325 and PIC16F15345 are added as a demonstration. Future work is needed to add support of all devices in this new generation to SDCC.

Organization of the Patch

Since Step 1 (Duplicate all the existing files in the libsdcc/enhanced) and Step 6 (device definitions and headers for PIC16F15325 and PIC16F15345) creates a massive number of new files and 10000+ lines of automatically generated code, it would make reviewing the patchset extremely difficult.

Thus, this patch is spitted into 3 files and 7 commits. The first file duplicates all the existing files in the libsdcc/enhancedand there's little to be reviewed. The main part of the patchset is the second file, which contains 4 commits that perform the main body of work described above - this is the patch-of-interest for code reviewing. The third file adds device definitions and headers for PIC16F15325 and PIC16F15345, all is automatically generated, and again, there's little to be reviewed.

Remarks

As the patch is still in the Request-for-Comment stage, no attempt was made to build "doubly-enhanced" version of the C standard library or the C math library, until consensus on upstreaming the patch is reached.

I've successfully used this patched version of SDCC to build firmware to target PIC16F15345 in my personal project.

Cheers.

[Tom Li]

Second part of the patchset, contains main changes.

[Tom Li]

Final part of the patchset, contains PIC16F15325 and PIC16F15345 headers.

[Benedikt Freisen]

Alright. Since I am not a PIC programmer, I will have to limit my feedback to the very superficial level.

Regarding 1
Were you able to assess the quality of the code you are duplicating? Any potential bugs in it are obviously easier to fix in a single code base.

Regarding 2
In my experience the PIC library build scripts have severe stability issues that have repeatedly caused problems. Were you by any chance able to narrow some of them down?

Regarding 3, 4
Fair enough. Looks like a minimally invasive strategy.

Regarding 5
There have been discussions on generating PIC headers as part of the build process rather than clogging up the repository with auto-generated files.
If you have any idea on how to do that, that would be the most elegant solution.