Arduino / chipKIT Compatibility Strategy — Ideas?

Created Tue, 02 Aug 2011 12:10:39 +0000 by avenue33

avenue33

Tue, 02 Aug 2011 12:10:39 +0000

Hi!

I've read the many threads about the Arduino / chipKIT compatibility issue.

May I suggest the need for defining a strategy about compatibility?

Two possibilities:

• chipKIT only emulates Arduino, even when Arduino is misleading example: Arduino int type instead of more precise stdint.h int8_t type.
• chipKIT uses a stricter subset which is fully accepted by Arduino example: confusing int type usage isn't recommended but int8_t type is fully accepted by both Arduino and chipKIT.

What do you think :?: Any ideas :idea:

GeneApperson

Thu, 04 Aug 2011 04:23:23 +0000

I think that part of what you are talking about is writing C code for portablility across processor architectures. One aspect, as you mention, is sizes of the data types. If the behavior of the algorithm depends on the size of the data type, an explicitly sized type should be used (e.g. int16_t instead of int). If the behavior of the algorithm won't be affected, then performance consideration might matter. 16-bit integer arithmetic will be faster than 32-bit on an AVR, but it's the other way around on a PIC32.

Another thing that trips up a lot of people is assuming that the size of a pointer is the same as the size of some specific integer type. For example, sizeof(short) and sizeof(*short) are the same on an AVR but are different on a PIC32.

Gene Apperson Digilent

WestfW

Thu, 04 Aug 2011 05:48:56 +0000

Does anyone have ideas on a strategy on solving the use of non-standard types in the Microchip-provided include files for their proprietary libraries? It's things like "pic32mx/include/peripheral/uart.h" that are full of "UINT", "BOOL", "BYTE" and other long-unstandard types, not the ChipKit or Arduino code (though it doesn't help that Arduino uses BYTE for something other than a type, and "byte" for a type.)

Can those types be #defined and #undefined again, just around the Microchip-dependent bits? ("#include "Undo_GenericTypes.h" ?) Do the chipKit files HAVE to include <plib.h> and get exposed to ALL of the peripheral includes instead of just those it really deals with?

WestfW

Thu, 04 Aug 2011 06:07:07 +0000

Huh.

typedef unsigned char BYTE;
#define BYTE 0

doesn't result in any errors. I guess that makes sense; the typedef is a C statement, while the #define substitution occurs during pre-processing. Assuming that the statements are placed as shown at the very start of a program, the typedef will still happen, but there won't be ANY occurrences of "BYTE" in the pre-processed code. Switching the lines around causes obvious errors, though.

avenue33

Thu, 04 Aug 2011 12:23:17 +0000

Thank you for your feed-back.

I have both cases:

• ones where speed comes first and thus, native types (16bits for AVR, 32bits for OIC32) are more suitable,
• others where strict types (uint8_t, uint16_t) are mandatory, when talking with serial or i2c devices with defined protocols.

Porting my Arduino libraries to make them compatible with chipKIT raises a lot of questions ;) Your hints are making it easier.

GeneApperson

Fri, 05 Aug 2011 02:23:26 +0000

@avenue33

As you no doubt know, the sizes of the intrinsic data types aren't defined by the C language spec. They are left up the implementer to define. Normally, int will be a size the gives good integer arithemetic performance.

I doubt that there has ever been a C implementation that had int's be less than 16 bits. When I know that the range of data can never overflow 16 bits, I would probably want to use an int, as the compiler implementer will have chosen a size for int that gives good performance.

Obviously, as you point out, where the data sizes are determined by external conditions, explicitly sized types should be used.

Structure packing can also trip you up when going between platforms. Different implementations pack structures differently. Some processors have data alignment requirements. E.g. word size data has to be word aligned on some processors. They aren't capable of fetching a word value from an odd address. So, for example, a word followed by a byte will be at a different structure offset on some machines than on others. The compiler puts in padding within the structure to force alignment. This can cause problems when saving a structure to a file or sending it over a communications channel.

Gene

jasonk

Fri, 05 Aug 2011 05:39:52 +0000

There's also a few other types in stdint.h (machine/int_mwgwinttypes.h) that may be useful.

/* 7.18.1.2 Minimum-width integer types */
typedef	__signed char		  int_least8_t;
typedef	unsigned char		 uint_least8_t;
typedef	short int		 int_least16_t;
typedef	unsigned short int	uint_least16_t;
typedef	int			 int_least24_t;
typedef	unsigned int		uint_least24_t;
typedef	int			 int_least32_t;
typedef	unsigned int		uint_least32_t;

/* 7.18.1.3 Fastest minimum-width integer types */
typedef	int			   int_fast8_t;
typedef	unsigned int		  uint_fast8_t;
typedef	int			  int_fast16_t;
typedef	unsigned int		 uint_fast16_t;
typedef	int			  int_fast24_t;
typedef	unsigned int		 uint_fast24_t;
typedef	int			  int_fast32_t;
typedef	unsigned int		 uint_fast32_t;