Re: 32 bits time_t and Y2038 issue

On 12/03/2025 08:44, pozz wrote:

Il 11/03/2025 17:32, David Brown ha scritto:
[...]

For anything other than a quick demo, my preferred setup is using makefiles for the build along with an ARM gcc toolchain.  That way I can always build my software, from any system, and archive the toolchain.

[...]
 Regading this point, it's what I want to do in new projects. What I don't know is...
 Why many silicon vendors provide a *custom* arm gcc toolchain? Are those customizations important to build firmware for their MCUs? If not, why they invest money to make changes in a toolchain? It isn't a simple job.
 

Some changes are reasonable.  A prime example is support for newer devices - or workarounds for bugs in existing devices.  The ideal way to handle this sort of thing, as done by a number of suppliers, is to figure out a fix and push it upstream.
Full upstream projects - primarily GCC and binutils - will generally add these in to their current development line.  They will generally only add it in to previous lines if the changes are small, fairly clean patches, important for code correctness, and don't require changes in additional areas (such as command-line options or documentation).  Even then, they only go a few releases back.
The main next-step upstream project for ARM GCC tools is ARM's GCC toolchain - they can be a bit more flexible, and maintain a list of patches that go on top of GCC and binutils releases so that such fixes can be back-ported to older sets.  Their releases are always a bit behind upstream mainline, because they need time to do their testing and packaging.
Finally, some microcontroller manufacturers will have their own packed builds based on ARM's builds.  (Other intermediaries used to be popular before, such as Code Sourcery, but I think ARM's builds are now ubiquitous.)  They can react faster to adding fixes and patches to existing code - they don't need to think about conflicts or testing with other people's ARM cores, for example.  But again, their releases will be even further behind mainline because they must be tested against all their SDK's and other code.
These sorts of things are all good for the user, good for the community as a whole, and good for the manufacturer - they can make quick fixes if they have to, but in the long term they keep aligned with mainline.
But some vendors - such as Microchip - put a great deal of effort into re-branding.  They are looking for marketing, control, and forced tie-in - they want it to be as hard as possible to move to other vendors.  And they can have PHB's that think the development tool department of the company should make a profit on its own, rather than be there to support sales from the device production - thus they try to force developers to pay for licenses.  IMHO this is all counter-productive - I am sure I am not the only developer who would not consider using microcontrollers from Microchip unless there was no other option.  (I am happy to use other parts from Microchip - they make good devices.)

Another point is visual debugging. I don't mean text editor with syntax hilighting, code completion, project management and so on. There are many tools around for this.
I used to have a button in the IDE to launch a debugging session. The generation of a good debugging session configuration is simplified in IDE if you use main debuggin probe (for example, J-Link).
 How do you debug your projects without a full-features and ready-to-use IDE from the silicon vendor?

That varies from project to project, part to part.  But I am quite happy to use an IDE from a vendor while using an external makefile and a standard GNU ARM toolchain for the build.