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 o...@c-mauderer.de:
Hello Peter,
Am 13.09.23 um 19:22 schrieb Peter Dufault:
On Jul 25, 2023, at 10:14 , Joel Sherrill <j...@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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH & Co. KG
Herr Thomas DOERFLER
Dornierstr. 4
82178 Puchheim
Germany
email: thomas.doerf...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
