[PATCH] BSP for TMS570LS31x Hercules Development Kit from TI (TMS570LS3137)

[Pavel Pisa]

Hello Sebastian,

On Thursday 14 of August 2014 07:39:19 Sebastian Huber wrote:
> Hello,
>
> its nice that you use the new Termios device API.  I would be happy to
> receive comments if you found something odd about it.
>
> Contains the current GCC 4.8 or 4.9 branch HEAD all what is necessary for
> your BSP?

I have rebuild x86_64 -> arm-rtems4.11 toolchain after you have redone
Cortex-R patch and all Premek's works is done by that. Even newlib
has been updated after official single  liner correction.

> I recently committed a patch for the Cortex-M floating point unit.  There
> are probably now some conflicts with your Cortex-R floating point code.

As for floating-point, we use softfloat for Cortex-R still, sorry.
Premek has been busy enough with other stuff till now.
But I expect that after your change it should be quite straightforward
to test with VFP-D16. We do that.

As for registers and fields names, the initial fragments are generated
by Ti manual Python parser and then adjusted by hand.

https://github.com/AoLaD/rtems-tms570-utils/tree/master/parser

Again, parser has not been updated after Premek's initial version too
much because focus was to have something running first.

Comments and alignments are easy. I think that registers structures
per module are OK either. As for fields, I am not sure what to select.
One option is to use unions in structures

  union {
    uint32_t v;
    struct {
       unsigned xxx : 10;
       unsigned yy : 5;
    }
  }

This is roughly what original Ti headers use. But problem is that
BSP should be reusable for more TMS570 chips and in future even
for RM48 and RM57. The last two are used in industrial area may be
even more than TMS570 (automotive/safety) and are little endian.
Ti has all blocks of bitfields twice with endian ifdef. I would prefer
more Linux kernel MIPS approach if bitfields are used

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/include/uapi/asm/inst.h?id=refs/tags/v3.15#n486

But I generally prefer more only defines used for such fields.

Then it would look something like

  TMS570_SCI_SCICLEARINT_XXX

My notation is to add suffix "_m" for mask, "_b" for starting bit position
if used and where are offset from base "_o". The "_m" and "_b" quite usesfull
because C dosenit warn you when starting bit or mask is mixed and results
of mixing are quite damaging.

But use of macros leads to quite complex/long lines in the code.

As for formating, the LPC BSP uses mixing of defines and structure fields
declarations. Quite readable but on the other hand overview
of compact structure is little lost. So may it be that compact
structure and then list of macros with comment about field or even
offset macros would be more readabble

  TMS570_SCI_SCICLEARINT_o

The alone at beginning would be easier for Premek now than inserting
fields between already defined fields.

Anyway, I expect that the parser enhancement is the right way
and only manageable way for us if we consider all periferals
which we already have running on Ti provided headers in our
other projects and which we want to move to RTEMS when it
we have solid support (SPI, CAN, FlexRay, N2HET etc.)
  http://rtime.felk.cvut.cz/rpp-tms570/
Because we have no resources to prepare all headers manually
and Premek does not look at Ti headers for unclear license reasons.

Best wishes,

                  Pavel

PS: I have not get to promissed testing of Cortex-M4F yesterday
    and I have only LPC1788 based board at hand now. I have struck
    mostly on consultation a helping move motion control to some
    FPGA based Profinet stack which is diploma thesis of our other
    student. I have testing Cortex-M4F on my list but I get to
    it probably only next week.