It will be difficult to replace how well the PowerPC motor controllers work for motor control when the canned, pre-written eTPU code do what you need. It's a great architecture, the DMA chain is well thought out.
There is a Bosch "GTM" Generic Timer IP module that is intended to replace the eTPU. I'll look at that to see how close it comes to providing the clean support for motor control coupled to a general purpose processor that the eTPU / PowerPC has. When I see "IP" in a "chip" description I get nervous - I assume Bosch is selling "IP" and the integration is up to the licensor. That said, ARM works well. > On Sep 14, 2023, at 15:22 , o...@c-mauderer.de wrote: > > 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 Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
