• State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 22 subscribers
  • Views 3627 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

inline \ MACROs

Roi T

Hi,
I want to avoid the CALL \ RET overhead of a certain function which is called only once in my program.

I understand the uVision compiler does not support the inline keyword (http://www.keil.com/support/docs/1755.htm), and I should use macros instead.
The problem is that uVision cannot step into macros when debugging.

Is there any good solution for this problem?

Parents
  • 0 in reply to HansBernhard Broeker

    Those goals are ultimately in contradiction to each other. Modularity requires clean interfaces, but clean interfaces cost CPU-cycles to set up and use.

    A "clean interface" is not a requirement for modular code, it is only a requirement for "isolated module" code.

    If you have all code related to stuffing and draining the UART in one module; I would still call the code modular even if another module had

    if (drain != fill)
    { .... = buffer[drain]; drain++;
    }

    I hate the fact that the site makes this into a crappy format (yes, I know about 'pre')

    isolated module code would, of course be
    ... = getUARTchar():

    Actually this is one case where I see the modularity prophets going overboard. You need to have getUARTchar() return an int which you then have to split into flags and (possible) received char which lead to making a ridiculous offering on the altar of modularity

    what I would do forgive me Mr. modular would be
    if (getUARTchar())
    { .... = global char
    }

    Erik

Reply
  • 0 in reply to HansBernhard Broeker

    Those goals are ultimately in contradiction to each other. Modularity requires clean interfaces, but clean interfaces cost CPU-cycles to set up and use.

    A "clean interface" is not a requirement for modular code, it is only a requirement for "isolated module" code.

    If you have all code related to stuffing and draining the UART in one module; I would still call the code modular even if another module had

    if (drain != fill)
    { .... = buffer[drain]; drain++;
    }

    I hate the fact that the site makes this into a crappy format (yes, I know about 'pre')

    isolated module code would, of course be
    ... = getUARTchar():

    Actually this is one case where I see the modularity prophets going overboard. You need to have getUARTchar() return an int which you then have to split into flags and (possible) received char which lead to making a ridiculous offering on the altar of modularity

    what I would do forgive me Mr. modular would be
    if (getUARTchar())
    { .... = global char
    }

    Erik

Children