Outdated list of BSPs in rtems-tools/config

Thu Sep 14 19:22:20 UTC 2023

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