I would recommend a useful little feature that most programming languages support - "comments".
Magic numbers are a problem if the same number is used several times in a program, or if they are used without explanatory comments. But with a comment explaining what "(1
How did ARM support services reply when you talked to them about this? Or did you contact the hardware vendor or toolchain vendor rather than ARM?
If you want help or advice, a Usenet group is a fine place to ask - and people will try and help with your problems and questions.
If you want to change the way these libraries are made, then you need to contact the people involved in making them.
But if you just want to whine and rant with no thoughts to the reality of the situation, and no desire to listen to help or suggestions, then please do it somewhere where you won't annoy other people.
My final recommendation to you is to go back to PICs. If you can't handle programming with ARMs, don't use them.
I've been using ARM parts for 13 years now, and I had never even heard of CMSIS until I saw this thread (and I still have absolutely no clue what CMSIS is).
--
Grant Edwards grant.b.edwards Yow! Are you mentally here
at at Pizza Hut??
It a new library aimed at giving registers names so that developers can use a consistent set of names for their coding. Though good idea, it stops short of giving names to individual flags in registers. It is available for Cortex M3, I'm not sure if its available for others.
Then you miss the point I made earlier that your code won't be compatible to mine as we would both use different names and methods to access registers.
Its OK if you go solo and not expecting the company or the product to be sold on, but not with product development across teams and range of products that get reworked frequently.
Thats worth whining about to get right before tons of software are built on piles of rubbish created by the CMSIS developers.
This may sound a bit flip, but my first response is "so?".
After using ARM parts for over a decade, I have yet to run into the requirement that my code be compatible with yours.
I've lost count of how many times I've seen somebody start off on a quest for a "portable, generic, universal for embedded systems". All of those quests have been complete and unqualified failures.
Embedded code is never portable because the hardware and requirements are never the same from one project to the next. If you can manage readable and easy to understand, you've done a good job and the next guy that works on it will be happy.
If using something results in unreadable, hard-to-understand code, then I agree that it's broken.
But, figuring out ahead of time what "portable" means just doesn't work. Given two almost identical sets of requirements and two similar hardware designs, it might be practical to come up with common software that can be reused between the two projects. Trying to design something that's portable and useful for some undefined future project is (in my experience) futile.
--
Grant Edwards grant.b.edwards Yow! Do you have exactly
at what I want in a plaid
I've had to debug other people's code. Its damn hard if they guy has written everything their own way and with numbers instead of designated registers and flag names. I've also had to use other people's code and make newer product. Thats where I'm coming from. It just sucks when its all hard coded numbers. Its impossible to follow when you got tens of pages of numbers that flip back and forth.
When a newer model came out, I spec'd the newer software to be written without use of hard coded numbers.
The code was instantly readable, and caught many bugs that way. Simple search would always work miracles when all else fails.
When reading documentation, it was always quicker to connect documentation with programming which says a lot about code being verbose and readable.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.