Global Variables vs. Pointers in Embedded Design

One more thing, and I'm out:

I am sitting around playing with pointers this afternoon and profiling pointers. I think this probably puts the pointer question to rest for me.

#include <MCUHeader.h>

struct Lion
{
        char Age;
        char Name;
        char Weight;
};

void SetAge(struct Lion *Lion, char age)
{
        Lion->Age = age;
}

void main(void)
{
        char x;

        struct Lion Leroy;

        for (x = 0; x <10; x++)
        {
                Leroy.Age = 5;
        }

        x = 10;

        for (x = 0; x <5; x++)
        {
                SetAge(&Leroy, 10);
        }
}

I was messing around with using the Setter function with the Lion struct vs. accessing the struct member without the function.

//////////////////////////
5497 Cycles w/ Struct Init
for (x = 0; x <10; x++)
{ SetAge(&Leroy, 5);
} //////////////////////////

3857 Cycles w/ Struct Init
for (x = 0; x <10; x++)
{ Leroy.Age = 5;
} //////////////////////////

That's like a 30% performance hit to use the Setter function! I'm not super familiar with the compiler, maybe you can tweak that performance with an inline function. (God, I realize I've become an embedded developer, if I'm freaking about the function overhead now).

WOW. I was not expecting a penalty like that, which goes back to Mr. Burmans point.

(Keep in mind, I didn't start using these MCUs with assembly...!)

Erik -- I totally hear you on the RTOS on an 8051, at least on these cheap Asian MCUs the power consumption is atrocious compared to the PIC's and ARM Cortex M's I've used. I am looking through a modern RTOS source code, and can't even fathom running it on the C51 for our products.

We'll just program the bare metal interrupts and get the timing right... I'm not building nuclear missile guidance systems on a $0.20 MCU from Taiwan...

My #1 goal is to put these 8051s back to IDLE mode AS SOON POSSIBLE, and put that power pig to sleep.

One more thing, and I'm out:

I am sitting around playing with pointers this afternoon and profiling pointers. I think this probably puts the pointer question to rest for me.

#include <MCUHeader.h>

struct Lion
{
        char Age;
        char Name;
        char Weight;
};

void SetAge(struct Lion *Lion, char age)
{
        Lion->Age = age;
}

void main(void)
{
        char x;

        struct Lion Leroy;

        for (x = 0; x <10; x++)
        {
                Leroy.Age = 5;
        }

        x = 10;

        for (x = 0; x <5; x++)
        {
                SetAge(&Leroy, 10);
        }
}

I was messing around with using the Setter function with the Lion struct vs. accessing the struct member without the function.

//////////////////////////
5497 Cycles w/ Struct Init
for (x = 0; x <10; x++)
{ SetAge(&Leroy, 5);
} //////////////////////////

3857 Cycles w/ Struct Init
for (x = 0; x <10; x++)
{ Leroy.Age = 5;
} //////////////////////////

That's like a 30% performance hit to use the Setter function! I'm not super familiar with the compiler, maybe you can tweak that performance with an inline function. (God, I realize I've become an embedded developer, if I'm freaking about the function overhead now).

WOW. I was not expecting a penalty like that, which goes back to Mr. Burmans point.

(Keep in mind, I didn't start using these MCUs with assembly...!)

Erik -- I totally hear you on the RTOS on an 8051, at least on these cheap Asian MCUs the power consumption is atrocious compared to the PIC's and ARM Cortex M's I've used. I am looking through a modern RTOS source code, and can't even fathom running it on the C51 for our products.

We'll just program the bare metal interrupts and get the timing right... I'm not building nuclear missile guidance systems on a $0.20 MCU from Taiwan...

My #1 goal is to put these 8051s back to IDLE mode AS SOON POSSIBLE, and put that power pig to sleep.

With prices of MCU generally in free fall, and an abundance of computational power made available by Cotex M machines, it makes little sense to me to build new products using a highly limited platform that is both outdated and out-performed. Choosing such a chip at the heart of a product nowadays makes no sense as it offers no growth capabilities as many system require. A Cotex M0 will outperform any 8051 with its hands tied behind its back...

it makes little sense to me to build new products using a highly limited platform that is both outdated and out-performed.
true - in many cases - but have a look at a '51 ISR with 'using' and with a 8051f120 at 100 MHz you get less than half the response time of a 166 MHz cortex. now, of course if that ISR is to do a lot, things may reverse.

I disagree with using the '51 where it does not fit (I use cortex a lot) but the '51 should not be thrown out of the toolbox.

for a small job you can have the whole '51 project running before you get the cortex BSP done.