We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I have an address on the APB which has a READ functionality and a WRITE functionality. If I read from it I get the status, and when I write to it, I set something else (Has nothing to do with the status).
I declared this address using a variable which is located using the _at_ keyword, and I get the "L30 memory space overflow" warning. Now I understand the warning is OK, but I wanted to know if there's a way to remove it for these specific addresses (I don't want to disable L30 entirely), or maybe uVision supports this specific issue somehow...
Thanks..
That is a huge :(
"every hardware access has to be via a function call - which incurs time & code size overheads."
In the worst case scenario, yes.
But typically, I find that hardware accesses are not done in isolation; i.e., rarely is it the case that a function just gets called, access the hardware once and then returns.
There are normally a few hardware accesses strung together with some other logic; such as a little bit twiddling.
So, put it all together into a little assembler routine and it's really not difficult to end up with a function that is as least as good as the C equivalent - Usually, I would expect it to be better.
"There are normally a few hardware accesses strung together with some other logic"
Absolutely.
"So, put it all together into a little assembler routine"
but I still don't see the need to specifically insist that it must be an assembler routine. Especially for C51.
I would apply the same rule to these routines as to the rest of the code - do it in 'C' unless assembler is specifically necessary.
But, as you say, that's just my opinion.
"but I still don't see the need to specifically insist that it must be an assembler routine."
I'm not so much saying that this is specifically insisted, rather I feel it is something that tends to naturally lend itself to this approach.
For example, the bit twiddling to which I previously mentioned is something that I normally find far easier to do in assembler. I never need to then concern myself with the efficiencies (or lack of) that the C compiler might carry out when doing such things as rotations and maskings.
In a low level driver, these operations are commonly hardware dependant and frequently go together with the hardware access - So putting them all together into a single assembler module assists the overall project layout.
"I would apply the same rule to these routines as to the rest of the code - do it in 'C' unless assembler is specifically necessary."
To me, one of the most important points in a project is the consistency. If different rules are used by different (or even worse, the same) programmers within a project then trouble normally follows. I have witnessed and had to recover such projects in the past!
So I may not necessarily agree with your rule, but I cannot fault the consistency.
We can agree on that one!
:-)