On Wed, Jan 21, 2015 at 5:35 PM, Pavel Pisa <p...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
