RTEMS_DECONST - Should it be removed? - TMS570

[Pavel Pisa]

Hello Martin,

On Wednesday 14 of January 2015 18:27:41 Martin Galvan wrote:
> Hi everyone! We're currently working on improving the TMS570 BSP, and
> in the process we discovered an important bug caused by a misuse of
> the RTEMS_DECONST macro. Said macro seems to be used in a few other
> places throughout the code to bypass const restrictions.

Please, can you provide more details?
I have contributed to RTEMS_DECONST and TMS570 BSP - directly
and as GSoC menthor. So bugs can fall to my head.


> What's the purpose of having something like this in the codebase?
> Should it be removed to maintain const-correctness throughout the
> code?

The RTEMS_DECONST is the tool how to suppress warning when
the target function can cope with const and non-constant
pointer, can distinguish if it is non-const case from some
data in from the poited to structure or other parameter
and it needs to change some data/reference counts in non-const
case for example. Such cases cannot be solved cleanly with
C in some specific cases and programmer has to take  responsibility
into his/her own hands. But there could be bug for sure.

As for TMS570 BSP, Premysl Houdek is due to finish some
things in the BSP in the next months. He needs to complete
his master thesis and submit it.

I have spent considerable time with him to negotiate
and prepare format and way to extend coverage of TMS570 header
files. I have communicated with Ti representatives about
releasing files under RTEMS compatible license but they are
not able to change that for more reasons. So we work on preparation
of RTEMS license and format friendly header files from PDF manual.

Premek has promised to complete ETHERNET support in frame
of his thesis. My other colleague finished work on TMS570 ETHERNET
for Ti provided FreeRTOS to really work. So we have knowledge
now how the EMAC works. We work on Matlab/Simulink support
in our other industrial partner paid non-RTEMS TMS570 and RM48
project based on Ti provided CodeComposer support. So I would be happy
if we can one day extend TMS570 to support RM48 as well but that
is far far future without contract. But I hope that TMS570
will be extended in next months.

So please, if you plan to introduce more changes, please, send
plan of your work in advance to coordinate things.
If you want to text TMS570 for real application which is computational intensive
then you probably want to try change board configuration files to specify 
hat FPU should be used for math. We have used soft-float
for initial porting but thanks to Sebastian Huber generic
ARM work, TMS570 float is supported too.
I have build RTEMS with next change applied and most of the tests
proceed 


diff --git a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram.cfg b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_
index e90414a..6ca23e6 100644
--- a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram.cfg
+++ b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk_intram.cfg
@@ -6,7 +6,8 @@ include $(RTEMS_ROOT)/make/custom/default.cfg

 RTEMS_CPU = arm

-CPU_CFLAGS = -march=armv7-r -mthumb -mbig-endian
+#CPU_CFLAGS = -march=armv7-r -mthumb -mbig-endian
+CPU_CFLAGS = -mbig-endian -mthumb -march=armv7-r -mfpu=vfpv3-d16 -mfloat-abi=hard

 CFLAGS_OPTIMIZE_V = -O2 -ggdb
 BINEXT?=.bin


As for RTEMS_DECONST, its definition should not be removed for sure.
But it is possible that it is used in incorrect place or even that
that macro has bug. So please, specify in more detail what is
the problem and what are your planes.

Best wishes,

             Pavel Pisa