michallenc commented on PR #19004:
URL: https://github.com/apache/nuttx/pull/19004#issuecomment-4600058574

   > @michallenc So you're saying that some families can be in the same 
directory, others can't. What criteria are you using for this? What about the 
stm32f0l0g0, which also supports the stm32c0, which isn't in the name? What 
about the stm32u0, which should also end up in stm32f0l0g0 directory?
   > 
   > Regarding mixing core types, this has not been true for some time. The 
STM32H7 supports Cortex M4 and Cortex M7 and uses the same peripheral drivers. 
How do you suggest to solve this issue? Where should support for Cortex M4 
drivers for the STM32H7 be placed? In `arch/stm32`? Or maybe in `arch/stm32l4`? 
My solution doesn't have that problem; everything that's reusable is placed in 
`common/stm32`.
   > 
   > EDIT: and there are other STM32 chips that have AMP architecture, so the 
situation like mix cores in STM32H7 will be repeated.
   
   Honestly I don't know what criteria are the best, that's my point here. If 
we decide to merge all STM support to one directory, we should probably follow 
this example with other controllers as well - should we merge nrf52 and nrf53 
as well? They are different chips with different Cortex versions so I would say 
no. But if we merge completely different STM chips together, then maybe yes. 
What about nrf54 support? That chip seems similar to nrf53... I have a board 
with PIC32CZ CA80 that I'd like to get NuttX running on, I plan to implement it 
to pic32cz directory where it will support both CA80 and CA9X series. But 
Microchip also manufactures PIC32CK (Cortex M33), PIC32CX (Cortex M4F) and many 
other chips in PIC32C series. Should they all go to a common pic32c directory 
or should we split the support to pic32cz, pic32ck, pic32cx...?
   
   I just think we should standardize the way we write the support for chips, 
ideally discuss it on the mailing list as well (if it wasn't done already and I 
missed it). I am more inclined to the current state where the support is split 
across the directories and we get a simpler code, but I agree it has its own 
problems. I agree splitting the support according to name isn't always the best 
option because sometimes marketing department wins and the chip gets a name 
that doesn't make sense. STM is an extreme in this, they have a complete mess 
in their naming.
   
   STM32H7 is a bit different I think, because Cortex M4 is there as a second 
core, it doesn't make much sense to have it separated.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to