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?
I want to keep a modular and efficient code,
Those goals are ultimately in contradiction to each other. Modularity requires clean interfaces, but clean interfaces cost CPU-cycles to set up and use.
You'll have to decide which you prefer.
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
That is a nice thing with assembly code. Calling a "function" and have the flag in zero or carry processor flag and optionally the character in the accumulator.
well, theoritically, an assembler 'function' can return regs8 +ac1 +b1 +dptr2 = 12 (maybe more) values.
"A 'clean interface' is not a requirement for modular code"
On the contrary, I think it most certainly is a requirement!
"it is only a requirement for 'isolated module' code."
To me, that is a tautology.
Think about modular hardware: to be truly "modular", you want a single, well-defined connector; replacing the module requires knowledge of just that connector and its specs...
OK we can differ on how modular something must be to be called modular :)
I just want to avoid that non-modular (by the 'firm' definition) becomes equalized with spaghetti.
So let us agree that you can have well organized code that is not modular (by the 'firm' definition).
I have seen truly modular code and I have seen code that made me call for tomato sauce, and then I have seen well organized code.