Reading the Riot Act To ARM's developers - Page 2

The other engineers speak a different language and are on a different
continent and there is no direct link between all the production
and subcontracting centers.

[snips]





Are you actually using a tool so bad it doesn't let you define your own
symbols?

define    INT_XMA    (1 << 4)

...

SYSCON->INT |= INT_XMA

Need to change INT_XMA?  Change it in one place, *every* usage of it
changes.  If your development tools can't cope with this - and, ideally,
with include files - then you should consider using a macro preprocessor
to generate the compilable code from the maintainable code.

Either way, has nothing to do with ARM, per se; just to do with an
apparently crippled toolchain and/or a developer who can't look beyond
the trivial tool to see possible solutions.

The point I was making has been snipped.

The way I do it is independent of all these issues and much more verbose.


#define INT_XMA (1 << 4)
#define ENABLE_RS232  SYSCON->INT |= INT_XMA


The problem I am having is what does that '4' mean. Is it 4 or 14 or
something else? I need a datasheet. Thats just crap programming.

What I want to be able to do is

#define ENABLED 1
#define ENABLE_RS232_INTERRUPT  SYSCON.INT.INT_XMA = ENABLED

or something similar which is what PIC libraries do.
The flag has been defined for you so that you don't have to figure
out INT_XMA is (1 << 4) or (1 << 14) sifting through a datasheet.
When a CPU is changed, the magic of giving names to flags
still works and saves a lot of time when checking.


If you care to look at the support forums and sample code,
you will also find most programmers set multiple flags
with one setting.
That makes the problem 100 times worse because its even more
work trying to figure out which flags have been set.

The programmers who wrote the CMSIS libraries should be shot
and replaced with programmers who are a little more wiser.
They should spend more time with compiler writers that support
ARM to make sure that everybody sings from the same song sheet.

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 << 4) | (1 << 14)" means in this situation,
it is perfectly good programming.

Thats just crap!

I am most definitely not worried about my commented code.
I write gazillion lines of complex multi-threaded
working code and I don't remember a word
of it after a few days. So everything is based on search,
doxygen, call diagrams, html documentation and the rest.

The point I am making is over what others are doing or not doing.

And I blame the CMSIS librarians for creating this situation
in the first place.

I am switching to ARM from PIC and I can see the rot from
the outside. ARM's developers are blind in a most deliberate
way if they think they can get away with it.

So let me get this right - /your/ code is perfect, but other developers'
code is crap and it's all because of the evil ARM CMSIS library programmers?

No. What is "crap" is that piece of incomprehensible garbage that a Quickie
Mart employee like you wrote thinking that it's code.




Sure you do fraud.





How do you F'n think that tools like doxygen work?  They process your
comments and use that to document the code.

Then again, you don't actually write code or use doxygen.





He's a complete and utter idiot. There's a few low-life's in
comp.os.linux.advocacy who are clueless enough to call him a genius or
something ridiculous like that.

Nearly not correct. I have problems with CMSIS librarians who can't get
their act together right on the issue of giving flags names..
And judging by your comments, I probably have a secondary issue
now with CMSIS librarians not working with compiler makers to
sing from the same hymn sheet over how named flags should be get implemented
when read/modify/write operations are requested.

How about running your code without CMSIS, instead of whining?

My ARMs have been runnung happily without
a bit of CMSIS code.

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 <whatever> 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.

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.

What are you talking about?
Your claims don't even make real sense when talking about assembly language.

When talking about high level languages, they don't make any sense at all

"Hard coded numbers". Bullshit
You have not programmed anything ever

Hallelujah !

It's about time someone in the COLA herd admitted that 7 = Joseph
Michael doesn't have a clue what he is talking about.

Peter could stand it no longer, seeing the rubbish he posted.
+100 to Peter.

Well... will wonders never cease!
Finally, you did what needed to be done.

I will call bullshit on anyone, linux advocate or not, if they are talking
bollocks



Not "finally".
I don't read all posts, especially not from "7"

So, what post will get answered or not depends very much on chance

All of 7s post didn't look right from a programming point of view.

Irrelevant, as I rarely read *any* post from him

So, when I call bullshit it is simply because this time I did

Everyone writes code "their own way", even with formal coding standards
in place.



Magic numbers are poor coding practice, period.  Why aren't you having a
word or three with them - or their management?



Neat trick.  So, if you need to write something to, say, port 39 how do
you do it without encoding the number 39 somewhere?