Outdated list of BSPs in rtems-tools/config

Thu Sep 14 19:35:12 UTC 2023

Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the PowerPC 
architecture and favor ARM for automotive applications.

But the MPC5xxx controllers were developed in some sort of cooperation 
with ST microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)

wkr,

Thomas.

Am 14.09.23 um 21:22 schrieb oss at c-mauderer.de:
> Hello Peter,
> 
> Am 13.09.23 um 19:22 schrieb Peter Dufault:
>>
>>
>>> On Jul 25, 2023, at 10:14 , Joel Sherrill <joel at rtems.org> wrote:
>>>
>>> Most of those are recent and from a lot of different people. GSoC, 
>>> Kinsey,
>>> you, Vijay or Chris, Karel, etc. But I wonder about that 
>>> phycore_mpc5554. I
>>> think it has been around a LONG time.
>>>
>>
>> I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 
>> BSP in July.
>>
>> I am the one who added the Phycore-mpc5554 as a minor refinement to 
>> the Freescale MPC55xx embedded board BSPs developed by "eb".
>>
>> It *is* time to retire the Phytec board as that board is no longer 
>> available.
>>
>> But, I hope we can keep it around for a while as I now need to work on 
>> a follow-up to that BSP.
> 
> That thread was not about retiring or deprecating BSPs. It was about 
> some missing BSPs in the rtems-tools/config files. So if it is still 
> necessary, I don't think the BSP should be removed.
> 
>>
>> One of my clients uses the Phycore-MPC5554.  They missed the end-of 
>> life announcement for that board. They need to quickly update to 
>> something very compatible, and a BSP based on the PHYTEC MPC5674F will 
>> work, the MPC5674F has all the functionality they require without 
>> software changes.
>>
>> I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I 
>> develop equivalent MPC5674F support.
>>
> 
> OK for me.
> 
>> A related question. I think "eb" has a "gwlcfm" target that uses this 
>> NXP architecture in one of their products.  "eb", are you planning 
>> another "gwlcfm", or are you done with that, and what platform would 
>> you move to?  I'd like to learn about an architecture that works as 
>> well as the old Motorola architecture does without custom FPGA 
>> programming.
>>
> 
> I think it's possible that a new batch of the gwlcfm hardware will be 
> manufactured in the next few years. But it's quite unlikely that the 
> software will get an upgrade.
> 
> The question about a good architecture is quite difficult because it's 
> always quite application specific.
> 
> For RTEMS work that I do, usually a customer already selected a chip 
> (most of the time some ARM). Therefore, I can't pick a platform that 
> often. For eb-projects, we usually use NXP or ST chips. On the NXP it 
> would be i.MX or now also i.MXRT and for ST it's one of the many STM32 
> chips.
> 
> Personally I would like to play a bit with Risc-V chips. But I haven't 
> found any time yet. Additionally, it seems that there are still not that 
> many manufacturers that produce Risc-V chips.
> 
> 
>> If I leave the old Motorola PowerPC's architecture targeted at engine 
>> control, I will miss how the ADC DMA chain works together with the 
>> eTPU and also schedules the output so cleanly do background motor 
>> control, and other timing intensive applications, so that the main CPU 
>> is free to e.g. run RTEMS (and in my case position servo control).
> 
> Difficult. Best bet is some NXP chip because they have quite some 
> peripherals that are still based on the Motorola chips. But I think you 
> know these chips already and it seems that they are not a good enough 
> replacement. Otherwise, you wouldn't ask.
> 
> At the moment a lot of chips start to provide two different ARM cores. 
> One bigger (often Cortex-A; sometimes multicore) and one smaller one 
> (most of the time Cortex-M). I haven't used both CPUs of these dual CPU 
> systems yet. But in theory they should allow some quite nice division of 
> tasks: The small CPU can handle the timing intensive application (maybe 
> with some bare metal code). The second CPU can handle higher level 
> control and communication. It would be interesting to implement 
> something like that.
> 
> Best regards
> 
> Christian
> 
>>
>> Peter
>> -----------------
>> Peter Dufault
>> HD Associates, Inc.      Software and System Engineering
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

-- 
embedded brains GmbH & Co. KG
Herr Thomas DOERFLER
Dornierstr. 4
82178 Puchheim
Germany
email: Thomas.DOERFLER at embedded-brains.de
phone: +49- 89-18 94 741 -12
mobil: +49-176-15 22 06 - 02

Registergericht: Amtsgericht München
Registernummer: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/