NXP Libraries and C/C++ Compiler's Packed Option

basically miscellaneous, if it doesn't fit another sub-forum enter it here, we might even promote it to its own sub-forum
Post Reply
TodWulff
Posts: 51
Joined: Fri Oct 19, 2012 4:03 am
Location: The Mitten State - Shores of Lake Huron

NXP Libraries and C/C++ Compiler's Packed Option

Post by TodWulff » Thu Sep 13, 2018 4:01 am

In an effort to get smarter about C++/C, and TypeDef Structures/Enumerations, I've been doing some reading, with a goal to acquire enough knowledge to port library code over from NXP's headers/libs, and/or make use of their on-chip drivers.

I've read this article which was quite illuminating in that it shed a lot of light for me on the structure of structures. :D

However, I am left with some questions that I believe Bruce, Mike, or someone else familiar with NXP C++/C source being compiled on NXP devices, can answer:
  1. Is it known if the NXP libs and C++/C compiler are normally configured for/intended to have structure's elements packed tightly vs. being word aligned for each element therein, when compiled?
    • I struggle with speculating as I understand that the libs are intended for use on MCUs, not a 'traditional computing' devices (i.e. laptop/desktop/tablet).
    • As such, I could see where the lib authors could have been overtly concerned with each and every byte that compiled code would consume on an embedded device.
    • Conversely, I acknowledge that these aren't MCUs with extremely constrained memory resources (i.e. PICs/etc.) and maintaining word alignment for bit/nibble/byte structure elements won't have much of a detrimental impact.
    • knowing this will also possibly help with using AB arrays to build structures that will be used by NXP's libs or on-chip drivers.
  2. In section 9 of the document linked to above, cache-line locality is discussed. I suspect that I know the answer, but in case not:
    • From an AB user's perspective, does this have any legitimacy when considering runtime execution efficiency? I am asking as I am morbidly curious (from an academic perspective only).
    • Does the AB compiler consider these sort of dynamics when compiling user code?
  3. Lastly, does the ARMbasic compiler address any need for Flash wear leveling, considering a fixed number of write cycles before the Flash fails? I suspect that it is up to the user to address this, if there is ever an implementation that may justifiably cause concern. I'd be curious if there has been a use case in ARMbasic that caused such a concern.



basicchip
Posts: 985
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: NXP Libraries and C/C++ Compiler's Packed Option

Post by basicchip » Thu Sep 13, 2018 12:05 pm

We use NXP library for USB. For Ethernet we ended up rewriting a great deal of it, same for the file system.

We find much of their code too object oriented even when not built as an object. For simple peripherals it is often way too complex and with a lot of overhead.

As for Flash wearing out, it is pretty unlikely.

TodWulff
Posts: 51
Joined: Fri Oct 19, 2012 4:03 am
Location: The Mitten State - Shores of Lake Huron

Re: NXP Libraries and C/C++ Compiler's Packed Option

Post by TodWulff » Thu Sep 13, 2018 11:48 pm

Understood on NXP libs and Wear Leveling. Thanks.

Post Reply