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

8052 data memory 128bytes or 256 byte?

Hello,
i am using 8052 in my project and according to datasheet the data memory is 256 bytes but in my code if i exceed 128 bytes the code is not compiled

do i need to use it as x data memory?

please help

Parents
  • what to do if a malloc call fails

    This is usually the biggest issue for my projects. I typically have to guarantee that the system supports M widgets and N thingies. And the system can't just not work, or throw up a dialog box and reboot. You pretty much have to guarantee before turning on the power that enough memory is available to do the worst-case job.

    The biggest exception is when the design has some acceptable tradeoffs. Maybe it can accomodate up to M widgets max, and N thingies max, but you can configure it to have m < M widgets and n < N thingies in some combination. In this case, you might consider the partitioning to be "dynamic" in that it's not pre-allocated static memory. But the code still wouldn't likely be creating individual widgets and thingies on the fly. It would just allocate the max size tables according to the configuration.

    It's fairly common for me to dynamically allocate an entry out of one of those tables. But that's not a call to malloc(), but rather some other routine that tracks usage of just that table. You can argue that using malloc() results in less work and less code than writing a bunch of individual allocators. On the other hand, a general-purpose memory allocator is almost always much slower and less efficient than special-purpose ones that can allocate fixed block sizes, and particularly known ones. And rarely are there many different types of objects (records, message buffers, whatever) that need to be allocated.

Reply
  • what to do if a malloc call fails

    This is usually the biggest issue for my projects. I typically have to guarantee that the system supports M widgets and N thingies. And the system can't just not work, or throw up a dialog box and reboot. You pretty much have to guarantee before turning on the power that enough memory is available to do the worst-case job.

    The biggest exception is when the design has some acceptable tradeoffs. Maybe it can accomodate up to M widgets max, and N thingies max, but you can configure it to have m < M widgets and n < N thingies in some combination. In this case, you might consider the partitioning to be "dynamic" in that it's not pre-allocated static memory. But the code still wouldn't likely be creating individual widgets and thingies on the fly. It would just allocate the max size tables according to the configuration.

    It's fairly common for me to dynamically allocate an entry out of one of those tables. But that's not a call to malloc(), but rather some other routine that tracks usage of just that table. You can argue that using malloc() results in less work and less code than writing a bunch of individual allocators. On the other hand, a general-purpose memory allocator is almost always much slower and less efficient than special-purpose ones that can allocate fixed block sizes, and particularly known ones. And rarely are there many different types of objects (records, message buffers, whatever) that need to be allocated.

Children
No data