rtems from TMS570 SDRAM or INTRAM

[Gedare Bloom]

On Mon, Mar 20, 2017 at 7:05 PM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
> Hello Nikolay,
>
> On Monday 20 of March 2017 15:16:41 Nikolay Komashinskiy wrote:
>> Thank you for your reply. I will have the ability to work with a board in a
>> month. My target board is TMS570LC43x LaunchPad.
>> But I need advice - what can be implemented during the GSoC by me?
>> Personally, I am interested in SPI and Serial interfaces, because many
>> peripheral work with them.
>
> serial interface should be supported, TMS570LS3137 UARTs support should
> be compatible with TMS570LC43x (I hope). The SPI worth to be
> implemented for both targets, we have many SPI peripherals
> working in our non-RTEMS TMS570 project so that board can be used
> for testing. TMS570 SPI driver conforming actually adopted Linux API
> on RTEMS would be nice.
>
>> Also, i2c and GPIO are used by me.
>
> Some example of RTEMS style defined GPIO functions can be found
> in Raspberry Pi BSP
>
> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/raspberrypi/gpio/rpi-gpio.c
>
> The bank parameter is necessary on TMS570 because there is large
> number of GPIO groups each with same set of the control registers.
>
> I2C would be nice too.
>
i2c and spi Linux APIs are preferred, see cpukit/dev/*

GPIO + i2c + spi is a realistic scope of work.

>> I am interested in Ethernet protocol itself (want to know more how
>> it works). And that is strange for me that BBB has IEEE 1588v2 support and
>> TMS570 doesn't.
>
> There quite lot of work even on base ETHERNET/LwIP integrations still.
>
Working on the ethernet side can be put into the stretch goals.  There
are other useful peripherals to consider supporting also, which I'm
not sure if they are done: full support for all hw timers, multi axis
motor control, ADCs, and the EMI.

> I am not sure how much work can fit in GSoC. It depends mainly
> on the amount of work required for the board bring-up.
> If you have working JTAG debugger from the startup then things
> are much easier. You can use CCS for debugging even of RTEMS
> applications even that fully open source toolchain is more preferred
> by me.
>
> The LaunchPad kit has disadvantage that there is no SDRAM
> so you need to flash application for each iteration.
> That is quite time consuming and even CSS seems to be considerably
> slower (at least on GNU/Linux system) than OpenOCD. But making OpenOCD
> to work on the given chip variant can be quite large project in itself.
> The other disadvantage of missing SDRAM is that TMS570 code (not much
> smaller data) Flash has limited erase cycles declared. Only 1000
> are guaranteed. I expect that at a normal conditions (temperature etc.)
> the Flash would sustain much more cycles functional. But it is limiting
> factor as well. On the full HDK there is a SDRAM which requires
> much more complex setup but then it makes furher development
> easier.
>
> Best wishes,
>
> Pavel
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users