Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.advocacy > #88475
| Date | 2012-02-12 10:24 +0100 |
|---|---|
| From | David Brown <david.brown@removethis.hesbynett.no> |
| Newsgroups | comp.os.linux.advocacy, comp.os.linux.embedded |
| Subject | Re: Reading the Riot Act To ARM's developers |
| References | <WGiYq.100467$WX2.28685@newsfe28.ams2> <4iah09-1p2.ln1@spankydtr.localhost.net> <PYqZq.3558$FY5.2955@newsfe10.ams2> <_ImdnTsu9qPQ5avSnZ2dnUVZ8gCdnZ2d@lyse.net> <u7EZq.13069$2t3.756@newsfe09.ams2> |
| Message-ID | <PLedncuK6o_cGKrSnZ2dnUVZ7oSdnZ2d@lyse.net> (permalink) |
Cross-posted to 2 groups.
On 12/02/12 01:56, 7 wrote: > David Brown wrote: > >> On 11/02/12 10:58, 7 wrote: >>> Kelsey Bjarnason wrote: >>> >>>> [snips] >>>> >>>> On Tue, 07 Feb 2012 23:43:43 +0000, 7 wrote: >>>> >>>>> Typically the CMSIS library forces you to write code using hard coded >>>>> numbers. So you want to set some flag to enable an interrupt it would >>>>> read something like >>>>> >>>>> SYSCON->INT |= (1<<4) >>>>> >>>>> Here is the crunch, who the hell is going to know if its the 4th bit or >>>>> the 14th bit when you got a million of these lines of code? >>>>> >>>>> Shortest possible answer NOBODY. Not even you!!!!!!!!! >>>>> >>>>> And then you change CPU, and something changes in hardware, how will >>>>> you know what to look for - you gonna search for "4" all throughout the >>>>> code????? >>>> >>>> >>>> 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?
Back to comp.os.linux.advocacy | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Reading the Riot Act To ARM's developers Kelsey Bjarnason <kbjarnason@gmail.com> - 2012-02-10 21:22 -0800
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-11 09:58 +0000
Re: Reading the Riot Act To ARM's developers David Brown <david.brown@removethis.hesbynett.no> - 2012-02-11 15:16 +0100
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-12 00:56 +0000
Re: Reading the Riot Act To ARM's developers David Brown <david.brown@removethis.hesbynett.no> - 2012-02-12 10:24 +0100
Re: Reading the Riot Act To ARM's developers "Ezekiel" <zeke@nosuchemail.com> - 2012-02-12 08:21 -0500
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-12 19:12 +0000
Re: Reading the Riot Act To ARM's developers Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2012-02-13 08:54 +0200
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-13 21:37 +0000
Re: Reading the Riot Act To ARM's developers Grant Edwards <invalid@invalid.invalid> - 2012-02-13 22:07 +0000
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-13 23:31 +0000
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-13 23:31 +0000
Re: Reading the Riot Act To ARM's developers 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-13 23:31 +0000
Re: Reading the Riot Act To ARM's developers Peter Köhlmann <peter-koehlmann@t-online.de> - 2012-02-14 10:35 +0100
more troll spew from eternal-september.org 7 <email_at_www_at_enemygadgets_dot_com@enemygadgets.com> - 2012-02-14 11:27 +0000
Re: more troll spew from eternal-september.org Peter Köhlmann <peter-koehlmann@t-online.de> - 2012-02-14 13:17 +0100
Re: more troll spew from eternal-september.org Big Steel <SteelOne@SteelOne.com> - 2012-02-14 07:55 -0500
Re: more troll spew from eternal-september.org Foster <frankfoster50@yahoo.com> - 2012-02-14 09:09 -0500
Re: Reading the Riot Act To ARM's developers Foster <frankfoster50@yahoo.com> - 2012-02-14 08:38 -0500
Re: Reading the Riot Act To ARM's developers DFS <nospam@dfs.com> - 2012-02-13 17:21 -0500
Re: Reading the Riot Act To ARM's developers David Brown <david@westcontrol.removethisbit.com> - 2012-02-13 09:12 +0100
Re: Reading the Riot Act To ARM's developers Kelsey Bjarnason <kbjarnason@gmail.com> - 2012-02-11 10:34 -0800
csiph-web