TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

[Martin Galvan]

On Wed, Apr 1, 2015 at 7:35 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> Hello Martin,

Hi, sorry for the late answer.

> On Wednesday 01 of April 2015 21:08:19 Martin Galvan wrote:
>> 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.
>
> the solution is to define simple JSON format which can be even prepared
> or edited by hand which holds all information. Unfortuantelly,
> header files are bad for manual editing and according to Joel and Sebastian
> preferences we need three defines per each field. And I agree that this
> is reasonable solution to have consistent and standard approach
> for header files across different chips.

That's debatable. I agree that it would be great to have a consistent
formatting for register definition headers across al BSPs, though.
Perhaps we should consider adding a section for these on the style
guide, and suggesting (but not requiring) using the JSON approach.

>> 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).
>
> It is horrible amount of the hand work and used tools and macro
> helpers are not included in the repo. Ask Premek for more detailed
> description of his approach. I have success with simple pdftotext
> and sed for some other chips to generate thousands lines long
> header files. So that was my initial motivation. But unfortuantelly,
> Ti manual is prepared by multiple people and or tool for almost
> each peripheral so all straightforward solutions have proved to be
> unusable.

Therefore you conclude I'm right :)

> Python script is for cleaning generated JSONs and then for
> generating final header files from these JSONs. But even writting
> JSONs by hand is simpler than writing headers and JSONs can be easily
> read for check, debugging and other support. Header files are bad format
> for that and if use overlay structures then their manual writing
> from offsets is quite error prone.

Again, that's debatable. We'd have to make extra sure that the Python
script works perfectly, though, as any bugs will spread to future
BSPs.

>> 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.
>
> No, boot code has to be written from scratch but with help of manual
> and HalCoGen generated code as algorithms reference. But it is not
> so large amount of code at the end. But it is quite complex.
> As for FlexRay and other peripherals support, which we have supported,
> these does not use so much of HalCoGen code. Main work is in the drivers
> logic which is not helped by HalCoGen so much.

Understood.

>> 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.
>
> The project has not been so actively worked on. Premysl Houdek
> has some other duties and subjects etc.

I understand that. Unfortunately we need to get the full BSP on the
mainline as soon as possible. Like I said before, we're more than
willing to work on the init code ourselves.

>> 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.
>
> Please, try to negotiate some permissive license which allows
> headers inclusion and or try to negotiate machine processing and
> use of HalCoGen generated headers copy (and better even generated sources)
> in GPL licensed project.
>
> I have tried and failed. And we have been quite unhappy and aware
> of amount of additional work caused by that. I have checked how HalCoGen
> XML MCU description files looks like and it would be possible to generate
> header files from them directly without use of the HalCoGen tool.
> But even that last resort solution has been declared as not suggested
> and that it would not be blessed by Ti's lawyers department.
> Ti support people said, that mechanism and licenses are decided (may it be
> even negotiated with tools vendors) at a time when MCU is released
> and the changing of license is highly problematic even for Ti after
> that point. But you can be more sucesfull if you declare budget
> and projected production quantities.

I'm not saying we should include the Halcogen code directly. I'm
saying we could instead refactor it, trimming all the unnecesary bits
such as user hooks and leaving only the bare minimum to get the board
up and running. It's almost the same as writing the init code by hand
reading the manual, except it's easier on the developer because he
doesn't have to figure out everything by himself.

-- 

Martin Galvan

Software Engineer

Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211