• State Not Answered
  • Locked Locked
  • Replies 17 replies
  • Subscribers 21 subscribers
  • Views 3548 views
  • Users 0 members are here
2025 survey

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.

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

Memory space overlap

Roi T

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..

Parents
  • 0 in reply to Andy Neil

    "I see: so what you're really saying is to keep all the hardware specifics in one place - whether it's an assembler place or a 'C' place is a separate issue..."

    In the past, maybe, but because I felt comfortable with the assembler, I ended up writing the complete driver modules in assembler. The whole module ended up being modular and very efficient (speedwise) and, I think, reasonably easy to maintain. Ok, some could have been done in C, but that would have probably made the structure more confusing.

    For 8051 and 68000 and V55 core projects, this really has proven to be a reliable method of maintenance and porting - For me.

    As I mentioned, if/when we go to the Cortex, it might
    be that we go for (close to) 100% C, so then the modules would be logically separated into groups.

Reply
  • 0 in reply to Andy Neil

    "I see: so what you're really saying is to keep all the hardware specifics in one place - whether it's an assembler place or a 'C' place is a separate issue..."

    In the past, maybe, but because I felt comfortable with the assembler, I ended up writing the complete driver modules in assembler. The whole module ended up being modular and very efficient (speedwise) and, I think, reasonably easy to maintain. Ok, some could have been done in C, but that would have probably made the structure more confusing.

    For 8051 and 68000 and V55 core projects, this really has proven to be a reliable method of maintenance and porting - For me.

    As I mentioned, if/when we go to the Cortex, it might
    be that we go for (close to) 100% C, so then the modules would be logically separated into groups.

Children