Writing PE out of the project

[DustyStew]

While PE has been quite helpful in getting my code up and running, at this stage I would like to write it out. This is apparently a somewhat intricate operation as there are no doubt many dependencies created by PE.

BTW I am using CW 10.4 with a Kinetis MCU, GCC compiler (C project).

I started by taking all the code from the Generated Code folder and moving it to my source folder, in the hope that PE would not blow any of it away. This more or less works, but you've also got to rename the various files (Events.c etc) that are in the source folder.

I then removed as many of the PE components as I dared. I left the MCU, but it kept generating the header files, cpu.c, and so on. So I removed that, and then found I had a compiler error  -- no target specified. So I put it back in.

Then discovered I could disable PE code generation and in the project properties. Should have worked that out earlier obviously.

I began a slash and burn operation on the PE code, getting rid of a lot of the device structures, just leaving the register accesses. This by and large worked, the code still compiled and ran. It seemed that in many of the components, the use of the device structure is unnecessary, it holds no useful information. Then consolidating code into fewer files. All this was working fine.

Then I made the fool mistake of trying to organize some code into subfolders. That is, MY code, not PE code. Just one .c file and one .h file were moved first to a new source folder (compiler couldn't find them) then to a subfolder. I tried changing the paths so that the header files could be found, etc. It didn't work. Now I had two new compile errors:

cannot find -lrt

cannot find -luart

So I put things back to the way they were before (got rid of the subdirectory, put the files back where they were), but these two errors persist.

Knowing how CW works (ie "in mysterious ways") I am guessing this has nothing to do with moving the files to the subfolder, and everything to do with PE.

Any clues?

TIA

[BlackNight]

You probably have found this out already, that you can disable code generation by component(s), see Disable my Code Generation

Another way is simply to remove the .pe file in your project root, see Dissection of MCU10 Projects for all the different files

As for

cannot find -lrt

cannot find -luart

it looks like the compiler tried to compile thes as files. You probably changed the command line options, or the linker ones. Have a look at the command line generated in the console view, this should give you an idea (hopefully).

-luart looks like something created/used by the linker.

I hope this helps.

[DustyStew · Accepted solution]

Thanks for your reply Erich. Your site is great.

I had already gone to a scorched Earth policy vis-a-vis PE, so it was too late to simply disable the code generation. Also I was disturbed by the fact there were references to PDD header files, which were not in my project. I wanted all the code in one place, and PE out of the picture.

So emboldened by Erich's information regarding CW project files, I continued slashing and burning, deleting everything that had a "pe" in the file name. After that, it would not compile. Some error related to PE. PE just would not let go of my project.

So I created a new project, without PE. Then copied all of my code into its Source folder. Then went and found every PDD header file I could that looked relevant, and copied these into the new project's Source folder. These were in the CW folder, down a few levels. Then compiled, errors indicated some PDD header files were missed, and went and found these and copied them in Sources.

Then the error was that the startup code & vectors were duplicated. I deleted two files from the Startup_Code folder (kinetis_startup.c & .h I think they were called).

Now it compiles, and it runs. PE-free!

The code size was about 98k, now its 76k. The build seems to be faster.

[Monica]

Thomas,

that is great news!

We're lucky to have you sharing your skills with us! :smileygrin:

Best regards,

Monica.

[DustyStew]

Don't encourage me Monica I am bound to start expounding on the philosophy of software design...oh oh here goes....

PE it starts with a great idea. That is, to take all of the registers in an MCU, and break out all the bit fields into a property sheet. Give each field a sensible name, provide documentation with a click, provide legal values for bit fields on lists...and so on. Great idea.

But with PE, that is combined with a lot of code behind the scenes, and that code is dubious.

- it is terribly verbose, the naming convention is long which makes it difficult to see the structure

- comments often only state the obvious, stuff like:   file_read(); // read the file

- page-long headers for one-line macros and functions (makes it hard to navigate)

- there are several layers of indirection, making it difficult to find out what the code is actually doing

- the code generally uses interrupts which is dodgy in a realtime system

That last point is the main problem in my estimation. The first thing you learn about event-driven programming in the software world is that the results are often unpredictable. Interrupts are the hardware-level equivalent of software events. While there is a time and place for using every interrupt the MCU has to offer, generally in realtime systems it is better to use one timer interrupt, and poll everything. Then your timing can be 100% predictable and the system will be 100% reliable. As you add more and more interrupts firing off at random times, it becomes impossible to know the exact timing of your system, in fact, it is impossible to test all combinations. So when you take a dozen different PE peripheral drivers, put them on a system, the timing is "Lord knows what".

PE code is good for learning one peripheral, it isn't really suitable for a complex realtime system.

I realize this could become a religious argument, but the main point is, if the programmer chooses to follow this programming model (ie polling peripherals with a timer interrupt) then the PE code takes a lot of work to whip into shape. I would have appreciated some simpler examples, straight to the metal, so I could more easily co-relate the code to the documentation. But the job is done now. :smileyhappy: