Architecture for conditional compilation in Energia

[igor 163]

I am helping adapt a library to Tiva processors from Arduino.  

I would like to use conditional compilation to separate the Tiva code from that for other processors. (e.g. Arduino Due)

Is there a standard macro I can check to see whether Energia is set up for a Tiva/Stellaris processor (vs. another architecture, like MSP430, etc.)

 

I was thinking something along the lines of __ARM__, or __TIVA__.

 

If not, it could be a handy addition.

 

For a temporary fix I am just checking for all the Tiva/Stellaris processors supported by Energia, but that means having to update the library if a new processor is supported.

 

Thank you

[Rei Vilo 695]

You can use the general variable ENERGIA and then more specific MCU-related variables.

#if defined(ENERGIA)
// code for Energia
#else
// code for Arduino
#endif

Be sure to test ENERGIA first as the Energia IDE defines both ENERGIA and ARDUINO.

 

For more information, please refer to a tutorial I wrote Manage Code for Multiple Platforms.

 

Now, I'm not 100% the Processing IDE —on which both Arduino and Energia rely— manages the conditional define statements correctly...

[igor 163]

You can use the general variable ENERGIA and then more specific MCU-related variables.

#if defined(ENERGIA)
// code for Energia
#else
// code for Arduino
#endif

Be sure to test ENERGIA first as the Energia IDE defines both ENERGIA and ARDUINO.

 

For more information, please refer to a tutorial I wrote Manage Code for Multiple Platforms.

 

Now, I'm not 100% the Processing IDE —on which both Arduino and Energia rely— manages the conditional define statements correctly...

 

I had read your tutorial, which was helpful.

Unfortunately just checking for ENERGIA does not separate between MSP430 code, c2000 code, and Tiva/Stellaris.

(Of course, at the moment, the library doesn't have any code for MSP430 or c2000, but one could.)

[Rei Vilo 695]

So you need to test the MCU-specific variables, like __MSP430G2553__ __LM4F120H5QR__ and so on...

 

This the MCU-based approach, also explained in the tutorial.

[pabigot 355]

For any compiler there will be vendor- and architecture-specific flags that you can determine. For gcc the following incantation will display them:

echo | arm-none-eabi-gcc -dM -E - | grep -i arm

This gets you things like:

#define __ARM_SIZEOF_WCHAR_T 32
#define __ARM_ARCH_ISA_ARM 1
#define __ARMEL__ 1
#define __ARM_FP 12
#define __ARM_NEON_FP 4
#define __ARM_SIZEOF_MINIMAL_ENUM 1
#define __ARM_PCS 1
#define __VERSION__ "4.8.3 20131129 (release) [ARM/embedded-4_8-branch revision 205641]"
#define __ARM_ARCH_ISA_THUMB 1
#define __ARM_ARCH 4
#define __arm__ 1
#define __ARM_ARCH_4T__ 1
#define __ARM_EABI__ 1

If you need to support different vendor compilers, what I generally do is use these pre-defined flags to set some generic flag in a common header; e.g. you could detect and define ENERGIA_TIVAC, ENERGIA_TM4C129, ENERGIA_TM4C123, ENERGIA_MSP430, etc. to whatever level of refinement is important.

[Rei Vilo 695]

The large family of Processing-based Wiring-derived Arduino-like IDEs already pack variables for the IDEs and the boards / MCUs. The problem is they are not always documented.

 

The nice point is, all the platforms share the same framework with the same types int{8|16|32} and the same hardware abstraction layer for the UART, SPI and I²C ports. So the very same sketch developed for one platform can run on the other ones, provided it doesn't call MCU-specific functions.

[igor 163]

Thank you pabigot, the __arm__ macro was the sort of things I was looking for.

Unfortunately now that Energia will be supporting more than one ARM based processor family (Tiva and CC3200) the issue

once again rises of how to distinguish them.  (As far as I have read it looks like CC3200 is not supported by tivaware?)

 

I hope they Energia will include macros to distinguish the platform/library.  (Or if it does already, what are they,

I tried dumping the defines in Energia and didn't see any likely candidates for Tivaware.)

Then my library could just check something like __TIVA__, to know it has access to the tivaware libraries, rather than having

to test all the different processors (and need to be updated every time a new processor gets supported).

 

The hardware abstraction provided by Arduino is fine for some things, but it doesn't adequately abstract timers,

and it doesn't give fast enough access to ports (especially if need to write a bunch of pins at once, or take advantage of the

masking abilities of some processors).

[igor 163]

Similar question recently came up on 43oh, here is cross-link.

http://forum.43oh.com/topic/5670-one-sketch-multiple-architectures/