I've extended the serial.c and serial.h files from the demo application to facilitate writing strings and debug information to the serial console in my application. I'm using snprintf() and similar library functions defined in stdio.h. These functions use parameters of type " char * ". When passing strings created by these functions to xSerialPutChar() and xSerialPutString() a must cast to a " signed char * " to avoid compiler warnings. Before I make any changes, I'd like to fully understand the types used and the reasons behind them.
Why does xSerialPutChar() use a signed char in it's prototype?
signed portBASETYPE xSerialPutChar( xComPortHandle pxPort, signed char cOutChar, TickTypet xBlockTime );
I'm also not sure I understand the full meaning of the parameter type "const signed char * const pcString" used in xSerialPutString. Could someone help me interpret this type and the use of const twice?
void vSerialPutString( xComPortHandle pxPort, **const signed char * const **pcString, unsigned short usStringLength );
Background: I've created my application based on the AVRATMege323WinAVR demo applicaiton. I'm using AVR Studio and it's native GCC complier.
You are looking at quite an old file. For portability, the original coding standard did not allow unqualified char types (without the signed or unsigned qualifier) because some compilers default char types to signed and some to unsigned. That has since been relaxed to allow unqualified char types if the char is an ascii character or pointing to a string of ascii characters.
I'm also not sure I understand the full meaning of the parameter type "const signed char * const pcString"
That is a C question, easy to look up in any C reference book or on the web - we like to keep questions on the forum specific to FreeRTOS as it is more valuable to FreeRTOS users that way - there are plenty of general embedded programming forums [the answer in this case is that the type is a const pointer to a const string - neither the pointer, nor the string in points to, can be modified.]
On the C question, I'll be more resourceful in the future.