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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it

It would be like writing an "Ezekiel" program without somewhere having
the string "fsckwit".

--
'What about all of the claims of how OpenOffice can seamlessly open up
Word and Excel documents often better than MS Office.  I suppose that
We've slightly trimmed the long signature. Click to see the full one.
Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it

I'm certain that a pretender like "7" has no idea. Here's one simple way it
could be done:

  const char* port_name = "LED_OUTPUT_PORT";

  if(getenv(port_name))
    port_num = strtoul( getenv(port_name), NULL, 10);
  else
    port_num = get_value_from_config_file(port_name);




Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it

I did - did you not read paragraph below?

Quoted text here. Click to load it


That depends.
On an average day there would no reason to write 39 to anything
and would probably be meaningless in different context. It must serve a
purpose. So I would write it this way to prevent 39 being
hard coded into even bit of follow up code.

#define SEND_SYSTEM_RESET_CODE   39
#define HELP_MESSAGE_39          39
..




Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it

Then why don't you follow your own advise and what you claim to have spec'd
out?


<quote>
#define LED_ON   1
#define LED_OFF  0

main() {
  LED_Register.All_LEDs = 0;  // All LEDs off - directly write to all LEDs
</quote>


According to your own blabbering... this should be:

main() {
  LED_Register.All_LEDs = LED_OFF;  // All LEDs off....





Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it

That way you *hardcode* the number into the executeable.
Just because you use a #define does not mean that any code has been changed
You just get to change the value easier before compiling, and it makes it
less error prone if the value is used at several places.

The only way *not* to hardcode any value is by reading it in via some means.
You still can have a hardcoded value in the binary, as long as you have some
means of overriding it during runtime without changing the binary

Your "way to avoid hardcoding" is bollocks and unworthy of a real programmer

Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it

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.

Re: Reading the Riot Act To ARM's developers
[snips]


Quoted text here. Click to load it


No, you need to learn the concept of commenting your code:

; 4th LSB is XMA interrupt enable/disable on MS4 series processors
#define INT_XMA (1<<4)

Now you know exactly what the 4 is, where it came from, why it's there
and what it does.


Re: Reading the Riot Act To ARM's developers
Quoted text here. Click to load it

Ewwww! Don't do that.

Quoted text here. Click to load it

Ewww! Don't do that either.

NACKed.

Phil
--
Quoted text here. Click to load it
Pics or it didn't happen.
We've slightly trimmed the long signature. Click to see the full one.
Re: Reading the Riot Act To ARM's developers

 
Quoted text here. Click to load it


By all means save us the laughs and
write one line of code to say what you would do.


Re: Reading the Riot Act To ARM's developers
Quoted text here. Click to load it

Well, even the mindless robotic conversion to

#define ENABLE_RS232_INTERRUPT() do { SYSCON.INT.INT_XMA = ENABLED; } while(0)

would be better than what you had.

Phil
--
Quoted text here. Click to load it
Pics or it didn't happen.
We've slightly trimmed the long signature. Click to see the full one.
Re: Reading the Riot Act To ARM's developers
Quoted text here. Click to load it

I would prefer three lines:

static inline void enable_rs232_interrupt(void) {
     SYSCON.INT.INT_XMA = ENABLED;
}

Be daring - learn C99!


Re: Reading the Riot Act To ARM's developers
Quoted text here. Click to load it
while(0)
Quoted text here. Click to load it

Whilst it is a sensible assumption to presume that SYSCON is visible at
the point of definition of the helper, it is by no means guaranteed, as
it's not obvious from the above, nor necessary for the macro to work -
you have to bear in mind the kind of code we're already dealing with.

Quoted text here. Click to load it

I'd rather not have to forget the C11 things, thank you.

Phil
--
Quoted text here. Click to load it
Pics or it didn't happen.
We've slightly trimmed the long signature. Click to see the full one.
Re: Reading the Riot Act To ARM's developers


Quoted text here. Click to load it


Waaaat?


Lets say you define all the hardware in hardware.h.
Then at the beginning you do this:


 #ifndef HARDWARE_H
 #define HARDWARE_H
 // filename hardware.h

 #include "your_CPU's_CMSIS_header_file.h"

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

 // end of hardware.h
 #endif

Now whenever you do a include "hardware.h" to get at
ENABLE_RS232_INTERRUPT, you automatically have
access to whatever SYSCON has been set up as in the CMSIS file.



Re: Reading the Riot Act To ARM's developers
Quoted text here. Click to load it
So far so good.  Seems a reasonable start.
Tho I don't know what is inside the CMSIS header file.


Re: Reading the Riot Act To ARM's developers
Quoted text here. Click to load it

The mere fact that you've felt it necessary to now provide a fuller
example clearly reinforces my point that what you posted earlier
was capable of being in a context where the change to a function
might not compile. If you can't understand why, then you need to learn
a bit more about C and its preprocessor.

Phil
--
Quoted text here. Click to load it
Pics or it didn't happen.
We've slightly trimmed the long signature. Click to see the full one.
Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it


You should first try explaining that to the man in the mirror.



Re: Reading the Riot Act To ARM's developers


Quoted text here. Click to load it

I'm sure he understands exactly what was written. It's *you* who's the
clueless moron pretending to be a software engineer.


--
Another documented lie from the trailer trash "chrisv" turd

- "Well, according to monopoly-supporting fsckheads like "Ezekiel" and
We've slightly trimmed the long signature. Click to see the full one.
Re: Reading the Riot Act To ARM's developers

Quoted text here. Click to load it



Meet troll feeder Ezekiel stuck in a predicament

posting anti-Linux rants all day for troll money from

micoshaft crocporation and appil crocporation.



While( Ch ) if ( Ch‑1 <= 32 ) *P -= 32 ; 

Speaking of "#define" macros...
#define  While( Should_Loop )  Ch = 1, P-- ;  \
  while( Ch‑1 = Ch, Ch && ( Ch = *++P, Ch2 = !Ch ? 0 : P[1], Should_Loop ) )

wchar_t B[] = L"hello world", *P = B, Ch‑1, Ch, Ch2 ;
//  Capitalise B, make it "Hello World".
While( Ch ) if ( Ch‑1 <= 32 ) *P -= 32 ;

Re: While( Ch ) if ( Ch‑1 <= 32 ) *P -= 32 ; 
Quoted text here. Click to load it


Looks like a problem with your keyboard driver. Have you tried turning
your computer off, and not turning it back on again?

Phil
--
Quoted text here. Click to load it
Pics or it didn't happen.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline