[RFC] Aging Platforms

[mobyfab]

Forget about perl, as said it is a nightmare to maintain. I'd prefer python/lua.

For the F1, I think the best it to wait a couple years and check the popularity.
As of now it's still the most used CM3 by far.

[Giovanni]

The problem is that STM32 drivers are shared among all sub-families and there are abstraction layers (RCC , ISR, DMA etc) in order to hide the details, when a new STM32 is introduced it can happen that some things assumed to be common to all sub-families do change and further abstractions are needed.

This is the minor of the problems, changes are often done easily, the effort is in the time required for:
1) testing.
2) maintaining the documentation.
3) maintaining all the various demos (especially those with those dreadful XML projects like IAR and Keil).

Removing a support from mainline would not make the code disappear (it could also be re-licensed as suggested in a previous post) but would free me from 1, 2 and 3.

This is the alternate solution

I am thinking to reorganize the project instead of simply removing stuff. Basically ChibiOS/RT could be split in two repositories:
1) The mainline code repository, licensed as usual, with only code that is commercially-grade supported (test, documentation, tracking, coverage etc.).
2) A stage repository containing, all of contributed code (without heavy screening) and the code that is removed from mainline. The code in this repository could be BSD/Apache licensed. Code would be moved between the two repositories as needed. The second repository would be more community-oriented. The second repository would contain a code tree structured to be simply copied over the code present in the first repository in order to have the "full-ChibiOS". This second repository could be GIT (and someone will have to explain me how the fsck set this up ). It would be a good idea to have some community-maintainers to handle this.

I always felt that current "rules" are way too restrictive for a community-oriented project, way too much contributed code cannot be included because minor details, probably this is the real problem to be addressed. Let's switch the discussion on this hypothesis.

Giovanni

[Freddie Chopin]

This organization is used by FreeRTOS too - it has the "contributed ports" that are not supported by FreeRTOS.

I'd even go further - one repo for the kernel only (it doesn't need the HAL), one repo for HAL, one repo for examples of usage, one repo (just a download section) for user-contributed examples of usage. The examples don't need to be up to date all the time - just add readme with info about exact version of all tools used (compiler, libs, kernel, ...) and that's all.

4\/3!!

[Giovanni]

Hi,

There is no need to do such an extreme splitting of the repository. One of the projects that is going on in background is the slitting of ChibiOS in well defined "components", kernel, HAL, platforms and ports will be delivered also as independent Eclipse plugins (in addition to the current mega-zip file). This is related to this: viewtopic.php?f=3&t=672 but I still can't give details yet.

Giovanni

[Xamusk]

No! Please don't abandon STM32F1xx!

They are some of the most versatile MCUs out there, and some of the cheapest too, if you count all the peripherals. Only some LPCs are cheaper, but they lack the peripheral power, the cheap ones are usually in QFN package and the ChibiOS HAL for them is almost useless according to the Features Matrix page.

Maybe one alternative would be to step up the C++ interface? That would really get some good versatility to maintain support trees (inheritance and polymorphism is really good for that). I understand not all compilers have C++ support or only do with a more expensive version, but as I'm seeing on their pages now, at least IAR and Keil have a "C/C++ compiler"(no "C-only compiler"). Anyway, if one is considering just skipping to F4, which has quite some power, why not give GCC some emphasis? I'm not sure why saving 10K on an optimized C library is useful on a 168MHz/1MB Flash MCU.

[Giovanni]

Hi,

Don't worry I am not going to remove anything

Giovanni

[barthess]

Heh, moving to git is my wet dream.

[Giovanni]

I am quite happy with subversion for the main product, I created a git repository on SF for the contributions but truth is that I don't know how to use it and never have enough time to study it.

Barthess, are you able to initialize the git repository and create the same structure we have in trunk? my idea is to put all contributions (and aging components) in this alternate repository. It would also be a good idea to have some volunteers to handle submissions.

Giovanni

[barthess]

I will try to do it this weekend.

[mabl]

Hmm we could use the ChibiOS team I created on github. Maybe we also move the mirrored Git repository to it?