RTEMS_DECONST - Should it be removed? - TMS570

[Martin Galvan]

On Wed, Jan 21, 2015 at 5:35 PM, Pavel Pisa <pisa at cmp.felk.cvut.cz> wrote:
> On Wednesday 21 of January 2015 19:44:21 Martin Galvan wrote:
>> What happened was that, in the SCI driver, driver_context_table was
>> declared as const and it included a variable called tx_chars_in_hw which is
>> used by the interrupt handler as a flag to mark that we just wrote a
>> character. tx_chars_in_hw was supposed to be set to 1 in
>> tms570_sci_interrupt_write; however because driver_context_table was
>> declared as const it was being placed inside the board's ROM. Therefore,
>> tx_chars_in_hw couldn't be written into, and the console got locked after
>> writing the first character. RTEMS_DECONST was being misused in
>> console_initialize to cast &driver_context_table.base to
>> rtems_termios_device_context *, thus masking out the source of the bug. The
>> only reason it was working for you is that RTEMS was loaded in RAM.
>
> That is important catch. If the structure/descriptor is const then
> work variable has to be moved to some other place/structure for sure.
> Bad that we have not catch that. So we need to check if driver_context_table
> should be read/write or if there should be other structure for runtime
> modified data.

Right now I removed the const from driver_context_table as a quick
fix. I'll see if we can make it const after we've finished fixing the
driver.

> You have removed parity and others termios options application from
> tms570_sci_set_attributes(). It should be implemented there generally,
> have you some hints what is broken in original code? Premysl Houdek
> should to correct that in longer therm.

I moved those to separate functions (tms570_sci_set_parity and
tms570_sci_set_prescaler) for readability.

>> I don't understand what you meant by that. Right now we're using the
>> HALCogen code for testing purposes only; is there any way to incorporate
>> them into the BSP code?
> You can use HalCoGen files in your proprietary or open source application
> but resulting code combination is not GPL license compatible
> (or at least Ti does not approve/know that). This means that no
> code or headers fragment (which is larger than some minimal size
> which makes code to fall under copyright) can be included
> in RTEMS mainline.

Understood.

> We have complete CAN and FlexRay support for Ti FreeRTOS and HalCoGen
> based codebase. But problem is again with copyright even that most
> of the code has been developed by us. So if you start clean room
> implementation we can help somewhere. But even if we start with RTEMS
> we need to reimplement most of that. That is why we wait for Premysl
> Houdek's preparation of header files from PDF to and then check
> what from our sources can be ported to new headers. Anyway, CAN is
> above size of his diploma thesis plans. You can look for API of our
> CAN and FlexRay library in the document
>
>   http://rtime.felk.cvut.cz/rpp-tms570/rpp_simulink.pdf
>
> There has been attempt to follow Autosar requirements when these APIs
> has been develop.
> If the RTEMS API is similar to above mentioned one then porting
> of TMS570 Matlab/Simulink support to RTEMS would be easier.
>
> You can look at our port of TMS570 CAN/Simulink code to Linux SocketCAN there.
>
>   http://rtime.felk.cvut.cz/gitweb/socketcan-simulink.git
>
> This layer is completely independent of HalCoGen and is BSD like
> licensed from us so it is fully compatible with RTEMS. But middle layer
> is more complicated problem.

That's great, we'll look into it later.

Thanks a lot for your answer!

-- 

Martín Galván

Software Engineer

Taller Technologies Argentina

San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211