Riot: cpu/lpc2387: part is obsolete

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

Not sure what to do about this issue, although the part is obsolete I think @maribu is using it, there has has been some activity and fixes have shown up.

I does make sense to ask our-self what we should do about obsolete hardware in general, should we start deprecating it?

I think we discussed a related question in Helsinki: Under which circumstances board support should be added to RIOT.

I think the consensus was that at least one of the following three needs to be true:

1. The board has a significant user base
2. The hardware is easy to obtain
   
   
   
   • This often results in 1.
   
   
   • It makes it easy for RIOT developers to obtain and test stuff on the board
   
   
3. The board is actively maintained
   
   
   
   • So they are optional modules that don't cause maintenance overhead for RIOT developers other than those willing to actively maintain the module
   
   
   • So that they do not block PRs (e.g. clean ups) due to missing responses / testing
   
   
   • Or in short: They don't cause pain for anyone else
   
   

To me, this would be a good base line for estimating if deprecation / removal of any module is reasonable (skipping point 2. for modules that are not related to hardware).

Currently, the LPC2387 is actively maintained (to be honest: mostly by @benpicco rather than me), so I say point 3 applies. Also: The FUB, the HAW, and the OVGU still have lots of MSB-A2 and the Hochschule Beuth is using MCB2388 boards for teaching, for which support was recently added to RIOT. So there are also some users left for this CPU, even though a significant user base might be an overstatement. Point 2. however certainly doesn't apply anymore to the MCU (or boards).

Maybe the general question of when to deprecate modules would be a good point to discuss in the next virtual maintainer assembly?

Maybe the general question of when to deprecate modules would be a good point to discuss in the next virtual maintainer assembly?

We should propose it as a discussion subject, but if it doesn't fit the schedule I think your 3 points based approach makes sense to me in why add or remove support. If we can't fit in the agenda, I would try to add this in our guidelines somewhere.

Linux just got support for the SGI Octane - and as long as people are using & maintaining the code, why should we remove it?
Retro-computing can be fun :wink:

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

The support for the lpc2387 is now in a pretty good shape, thanks to @benpicco. Even for recent developments like the inline-able IRQ API the old ARM boards were part of the early adopters.

I'm closing this now. If anyone disagrees, feel free to re-open.