[RFC] Aging Platforms

[Giovanni]

Hi,

I think it is clear that we have a bandwidth problem here, the scope of the project grew way beyond the initial plans thanks to the introduction of HAL and all other components. ChibiOS/RT was meant to be just the kernel but it quickly expanded beyond my expectations.

Probably the aging platforms should go in an "unmaintained" state at some point in order to reduce maintenance effort and allow bandwidth for new platforms.

I am thinking to make 2.6.x the end-of-line for STM8 (mainly because shitty compilers, too bad), LPC2148 and STM32F1xx.

End-of-line would mean that starting from 2.7.x the platform would no more be present in the main distribution, the support will continue in the 2.6.x stable branch. Users would still be able to forward-port the old platforms by themselves of course, there would not be problems in doing so.

Thoughts?

Giovanni

[mabl]

Hi Giovanni,

while I understand your desire to strip away target platforms, I'm not exactly sure if it is the best way. I'm ok with STM8, since I guess the user base is really small. But the F1 is still a often used development board. I personally have several F1 projects using ChibiOS. If I were a company using ChibiOS on STM32F1 I'd be annoyed by dropping support. On the other hand, new projects would probably use F4/F2, or so.

I guess the question is, how much trouble is the F1 code? I mean it's tested and found stable already (except maybe I2C..). I imagine there is not too much work to just leave it in place?

If you strip away code, will you re-licence it to BSD/Apache, so that others can keep on maintaining the code?

[Giovanni]

The F1 code is very stable but each time that a new STM32 is introduced often I have to do family-wide changes so the cost of STM32 support is proportional to the number of sub-families (and F1 are 3 sub-families not just one: F100, F103 and F107). Think also to all the demos and test applications that could be dropped and are now updated each time something changes in chconf, halconf, mcuconf or makefiles.

Note that support would continue in the last branch where the code is present so bugs would be fixed in that branch, just not ported over to new versions. Note that in this moment both 2.2.x and 2.4.x are being maintained and updated regularly.

As you pointed out it is unlikely that new project would use the F1, so maintaining it in older branches should be sufficient, re-licensing the code as BSD is a very good idea anyway, I think it is feasible.

Giovanni

[mabl]

Ok Giovanni, you have convinced me Throw the old stuff out in the next development session

[barthess]

Hi, Giovanny
I agree with your desire to drop F1x because support of this huge bulk of semi compatible lines is headache.
Currently I have some projects for F1x but think about migrating to something less errated (f*ing I2C cell ).
What MCUs you recommend to check as a successor of F1x (probably slightly less powerful)?
For calculation hungry projects I think about LPC4xxx.

[Giovanni]

To replace the F1 I would consider the F3, I am working on it right now and I am impressed from what I am seeing. It has all the improvements of the F0, including the new I2C, and 4 (four) very advanced ADCs, the best ever seen on the STM32.

For power hungry application wait to see the ST/Freescale SPC5xx/MPC56xx family I am porting, there are devices with dual e200z7 cores running at 300MHz and flash sizes up to 6MB, not cheap I must say because it is next-gen automotive-level stuff.

New Freescale Kinetis and Atmel L devices are also interesting for different reasons.

Giovanni

[Freddie Chopin]

I don't think dropping support for something as popular as STM32F1 is a good idea... I also don't know who would consider something else for a new project, when STM32F1 are cheaper, wide selection of tools, documentation, examples, books etc. Sure - STM32F4 is really cool, it just costs 10x the cheapest STM32F1... In simple projects that don't need 168MHz or 200kB of RAM or 100 pins, STM32F1 is all it takes, even with some bugs in silicon. I just finished two projects with STM32F1, I will do another one very soon, and in my previous work each new project had STM32F1 in it. It's not like when ST releases something new people are switching the same day to use the most powerful and most expensive devices. Look how many people use '51 or AVR - why, if STM32F1 that you want to retire is 1000x better?

4\/3!!

[Giovanni]

Good points.

It would not happen before version 2.8.x which would be 2014 at earliest anyway.

My problem is trying to determine at which point a legacy platform does no more require newly developed software, for new projects, I imagine, newer products are preferred. Even 2014 might be too soon for the F1, not sure.

My general idea is to optimize the use of a finite resource, development bandwidth.

Giovanni

[Badger]

I agree that it is too soon to make STM32F1 obsolete. Maybe in 2 years, who knows. there are a lot of STM32F1 boards out there, and very few F2/F4, they will probably be popular for quite some time.

I see the problem with maintaining the demos, it would be a shame to lose these as they are very useful. I've mentioned this before, but perhaps a more sophisticated 'chibios project' generator is needed, that can spit out up-to-date config and makefile for a demo, with only any deviation from a set of defaults from the device being specified. I'd imagine such a system developed in perl would be cross platform and easy to write, and wouldn't even need to be run by the user (but might prove handy to release). The community could no doubt help out (i'd be willing!).

[gmb42]

perl would be cross platform and easy to write

Somewhat tongue in cheek, but in my experience, Perl stuff is a nightmare to maintain if the originator takes a walk.

I haven't looked at the issues of supporting "older" architectures, but why does their code need to be changed as ChibiOS moves on? As long as the ChibiOS interfaces don't change, or if they do, you keep backwards compatibility, they should just work. If they do need extensive rework isn't that a sign that the interfaces aren't correct?