Forums

Struct/Union designated initialisers and Code Composer 3.3

Started by Stuart November 9, 2009
Hi all...

I'm porting a driver for a CAN device (the CAN module in the TMS320{LF,C}2406A DSP in fact) over to a CAN library that I have written. (I hope to release this library and drivers as opensource, but that will come later).

Anyway... so as to make the CAN library easily extendable, the core CAN library (which manages queueing of the messages and device access arbitration) accesses the functions of a device driver by way of function pointers in a "const struct can_driver". All drivers define one in their top-level header... and this information is passed in to the CAN library when calls are made to transmit messages. On Windows i386 and MSP430 using GCC, this all works rather well. I also plan to port it across to Linux... which should work fine with SocketCAN.

I got around to porting the driver I had previously written for an older CAN library (my first stab at the above in fact). I copied and pasted the old code in... updated it for the new functions... then came to the initialiser for this struct:

/*! Driver Handle definition */
const struct can_driver tms320c2406a_driver = {
.fetch = &tms320c2406a_fetch,
.send = &tms320c2406a_send,
.get_rx_count = &tms320c2406a_get_rx_count,
.get_tx_count = &tms320c2406a_get_tx_count,
.get_status_flags = &tms320c2406a_get_status_flags,
.get_int_flags = &tms320c2406a_get_int_flags,
.ack_int_flags = &tms320c2406a_ack_int_flags,
.get_err_flags = &tms320c2406a_get_err_flags,
.ack_err_flags = &tms320c2406a_ack_err_flags,
.get_rec = &tms320c2406a_get_rec,
.get_tec = &tms320c2406a_get_tec,
#ifdef CAN_ENABLE_REQUEST
.request = NULL,
#endif
#ifdef CAN_ENABLE_AUTOANSWER
.set_autoanswer = NULL,
.clear_autoanswer = NULL,
#endif
#ifdef CAN_ENABLE_DEBUG
.dump_regs = NULL,
#endif
.driver_id = "TI TMS320C2406A CAN Driver",
.num_filters = 4,
.num_tx = 2,
.num_rx = 2,
.num_trx = 2
};

When I attempt to compile the project... I got the following:

----------------------------- libcan.pjt - Debug -----------------------------
[tms320c2406a.c] "C:\CCStudio_v3.3\C2400\cgtools\bin\dspcl" -g -q -fr"C:/stuartl/git/libcan/Debug" -i"C:/stuartl/git/libcan" -d"_DEBUG" -d"CAN_RX_BUFFERS=8" -d"CAN_TX_BUFFERS=4" -d"CAN_16BIT_BYTE" -v2xx -@"../../../Debug.lkf" "tms320c2406a.c"
[tms320c2406a.c]
"tms320c2406a.c", line 736: [F001] syntax error at or near symbol '.'

Build Complete,
1 Errors, 0 Warnings, 0 Remarks.

If I change it to the old-style initialiser (that is, not specifying the field names, just the values in order)... it compiles perfectly. I'd like to use the C99 style however, as I think it is more readable, and I couldn't get the other variety to work right when initialising unions.

Has anyone struck this before, and does anyone know a reasonable workaround? Or am I stuck with the less-than-readable initialiser style?

Regards,
Stuart Longland

_____________________________________
Hi Stuart,

Yes, I have ran into this issue previously and modified initializers back
to the C style.

The C6000 compiler v 6.1.11 has an option --gcc "Enable support for GCC
extensions" in the Project->Build Options->Compiler->Assembly. With this
option the C99 style initializers are compiled just fine.

You are working with a C24xx compiler, which may or may not have a similar
option. I was unable to find it in the compiler ver. 7.04 - is it an obsolete
version?

Rgds,
Andrew

> Struct/Union designated initialisers and Code Composer 3.3
> Posted by: "Stuart" stuartl@l... sjlongland
> Date: Mon Nov 9, 2009 4:44 am ((PST))
>
> Hi all...
>
> I'm porting a driver for a CAN device (the CAN module in the
> TMS320{LF,C}2406A DSP in fact) over to a CAN library that I have written. (I
> hope to release this library and drivers as opensource, but that will come
> later).
>
> Anyway... so as to make the CAN library easily extendable, the core CAN
> library (which manages queueing of the messages and device access
> arbitration) accesses the functions of a device driver by way of function
> pointers in a "const struct can_driver". All drivers define one in their
> top-level header... and this information is passed in to the CAN library when
> calls are made to transmit messages. On Windows i386 and MSP430 using GCC,
> this all works rather well. I also plan to port it across to Linux... which
> should work fine with SocketCAN.
>
> I got around to porting the driver I had previously written for an older CAN
> library (my first stab at the above in fact). I copied and pasted the old
> code in... updated it for the new functions... then came to the initialiser
> for this struct:
>
> /*! Driver Handle definition */
> const struct can_driver tms320c2406a_driver = {
> .fetch = &tms320c2406a_fetch,
> .send = &tms320c2406a_send,
> .get_rx_count = &tms320c2406a_get_rx_count,
> .get_tx_count = &tms320c2406a_get_tx_count,
> .get_status_flags = &tms320c2406a_get_status_flags,
> .get_int_flags = &tms320c2406a_get_int_flags,
> .ack_int_flags = &tms320c2406a_ack_int_flags,
> .get_err_flags = &tms320c2406a_get_err_flags,
> .ack_err_flags = &tms320c2406a_ack_err_flags,
> .get_rec = &tms320c2406a_get_rec,
> .get_tec = &tms320c2406a_get_tec,
> #ifdef CAN_ENABLE_REQUEST
> .request = NULL,
> #endif
> #ifdef CAN_ENABLE_AUTOANSWER
> .set_autoanswer = NULL,
> .clear_autoanswer = NULL,
> #endif
> #ifdef CAN_ENABLE_DEBUG
> .dump_regs = NULL,
> #endif
> .driver_id = "TI TMS320C2406A CAN Driver",
> .num_filters = 4,
> .num_tx = 2,
> .num_rx = 2,
> .num_trx = 2
> };
>
> When I attempt to compile the project... I got the following:
>
> ----------------------------- libcan.pjt - Debug -----------------------------
> [tms320c2406a.c] "C:\CCStudio_v3.3\C2400\cgtools\bin\dspcl" -g -q -fr"C:/stuartl/git/libcan/Debug" -i"C:/stuartl/git/libcan" -d"_DEBUG" -d"CAN_RX_BUFFERS=8" -d"CAN_TX_BUFFERS=4" -d"CAN_16BIT_BYTE" -v2xx -@"../../../Debug.lkf" "tms320c2406a.c"
> [tms320c2406a.c]
> "tms320c2406a.c", line 736: [F001] syntax error at or near symbol '.'
>
> Build Complete,
> 1 Errors, 0 Warnings, 0 Remarks.
>
> If I change it to the old-style initialiser (that is, not specifying the
> field names, just the values in order)... it compiles perfectly. I'd like to
> use the C99 style however, as I think it is more readable, and I couldn't get
> the other variety to work right when initialising unions.
>
> Has anyone struck this before, and does anyone know a reasonable workaround?
> Or am I stuck with the less-than-readable initialiser style?
>
> Regards,
> Stuart Longland

_____________________________________