rtems from TMS570 SDRAM or INTRAM
Gedare Bloom
gedare at rtems.org
Sat Apr 29 12:17:20 UTC 2017
On Sat, Apr 29, 2017 at 5:11 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
> Hello Nikolay,
>
> On Friday 28 of April 2017 17:16:44 Nikolay Komashinskiy wrote:
>> > Do you want to use BeagleBone as the SPI and I2C slave/peripheral?
>> > Using full features system as the peripheral has significant
>> > andvantage for debuggin and hardware in the loop testing.
>> > But problem is that SPI slave functionality is not present
>> > in the current mainline Linux SPI drivers at all
>>
>> Oh, yes, I forgot about it, then I can use an stm32 board with HAL layer.
>> It has the spi slave capabilities.
>
> Yes, that would be simpler and I expect that example with device/slave
> I2C function would be available for STM32 as well.
>
>> > For SPI, the simple test is to interconnect MISO and MOSI and check
>> > if you read back some patter which you send to the device.
>> > Then connect MISO to VCC (+3.3V probably on Begle Bone) and check
>> > that you read all 0xFF then to GND and check for 0x00.
>> > Then you need oscilloscope or some real device to check
>> > chip selects and correct phase, polarity mode for clock
>> > versus data changes alignment.
>>
>> Yes, I am going to do it in this way, also I has a simple logic analyzer.
>
> OK
>
>> > I have TMS570LC4357 HDK there and it is the next most
>> > interresting target for me, but it is more complex.
>> > If you have intention to work on it, I add terminal pins
>> > file for this variant into RTEMS mainline. TMS570LC4357
>> I am going to work with TMS570LC4357 with LAUNCHXL2-
>> 570LC43 board with its onboard dubugger (XDS110). I think
>> I can use it in a couple with openocd debugger. And I already
>> have this board.
>>
>> The current stage of investigation of the board - I've just installed
>> Halcogen under Wine and generated some code.
>> I hope, I can compile it and debug it soon.
>>
>> I want to work with this board, because, for example, one of my
>> colleagues wants to start to program it with a bare-metal Ada(!).
>> So, I can see some interest to this board in my lab.
>>
>> I feel a need to show results of my work somewhere, could you
>> recommend such a place? I don't like blogs, because they don't
>> allow to easily represent the current stage and just show the process.
>> Maybe, it is better to use some wiki + comments under the project's ticket?
>
> I suggest to use GitHub. Create some repository for experiments.
> Something like
>
> https://github.com/AoLaD/rtems-tms570-utils
>
> Or if you want to use some of these utils, you can fork the project.
>
> When you start RTEMS work, the standard model is to fork RTEMS mainline
> mirror from GitHub and continue work from this point. Use rebase
> and merge then to keep track with mainline.
>
> I expect that LAUNCHXL2-570LC43 is great target for applications.
> But TMS570LC4357 HDK would be easier for development.
> It is easier and faster when you can load code tor RAM.
> The debuging in Flash allow only relatively limited number
> of hardware breakpoints. The standard breakpoint instruction
> placement is possible in RAM. So SDRAM on HDK allows to
> load and debug complex application including networking etc.
> On the other hand, the critical development of chip initialization
> and simple tests with UART and other drivers (except Ethernet)
> fits into internal RAM memory on TMS570LC4357, so Launchpad
> should be no limitation for your planned work.
>
> Questions to others: should I push my pin definition files
> for TMS570LC4357 into mainline?
>
Yeah go ahead. I think it would be good to have it available in general.
> Best wishes,
>
> Pavel
>
More information about the users
mailing list