TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

[Martin Galvan]

On Wed, Apr 1, 2015 at 8:01 AM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> To Martin Galvan: What is your opinion? Would you join the work in
> this direction?

So if I understood correctly, what you did was converting the
datasheet PDF to some parseable format, then you parsed that file to
extract the registers and bit info and save it as JSON files, which
you feed to a separate Python script that generates .h files with all
the necessary #defines.

While the approach is indeed interesting, I don't think it's the most
convenient way to solve this problem. Here's why:

1) The parse script seems to be highly datasheet-dependant, thus
making it non-portable for a different board. The script will break
even if the datasheet for the same board changes in the slightest bit
(or rather, the parsable file generated from the PDF).
2) The cyclomatic complexity of the parse script is quite high, making
it hard to maintain.

Even if the parse script stays in the rtems-tms570-utils repo, I still
think that this approach doesn't scale because of how difficult it
would be to build a separate parse script for any future boards, just
so you can get the JSON files. It would be way easier to simply write
the headers by hand as they're needed.

I agree that writing large header files by hand is a drag, which is
why we have tools like Halcogen in the first place. I understand
there's a licensing issue here, but just how much different can a
register definition file be? You can license code, but you can't
license facts, and most of these files end up being just a mirror of
what's on the datasheet. I've seen this approach being followed on
other projects such as FreeBSD, where the headers used by some drivers
are a carbon copy of the ones used in Linux.

The same goes for generating the boot/initialization code using the
script approach. I don't know if such a thing is even possible; but
I'm sure it'll be quite complex. And we still don't know for certain
how reliable this whole approach is.

And then there's the timing issue. Given how much effort it has taken
to get to this point, I don't think it's worth to invest even more
time trying to follow the same approach for init code. You mentioned 8
months as a cap; there's got to be a faster way to fix this.

I suggest we go for a simpler, faster approach and refactor the
Halcogen-generated code. It's almost the same as following the
datasheet by hand, only a bit easier on the developer. We can remove
most of the hooks Halcogen generates, get rid of some redundant
typedefs, and even find and fix some bugs (such as this one:
http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/390756/1380267).
As long as the refactor is being done consciously, I don't see how
there could be a licensing issue.

We're willing to work on refactoring the Halcogen code ourselves. If
you already have the whole set of generated headers ready and tested
then feel free to send a patch and we'll test it on our side. I
skimmed through the code and saw a couple of issues here and there,
such as "ui32_t" being used instead of uint32_t (is this a typo?) but
I think we can work with it as long as the macro names are the same as
those used on the datasheet.

-- 

Martin Galvan

Software Engineer

Taller Technologies Argentina


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211