rtems from TMS570 SDRAM or INTRAM
gedare at rtems.org
Tue Mar 21 17:49:15 UTC 2017
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
> 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
> Best wishes,
> users mailing list
> users at rtems.org
More information about the users