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.
Does anyone know if it is possible to malloc HDATA (far memory) rather than having to use XDATA on a Dallas 390 in continous mode?
The source code for malloc, calloc, free, and realloc is provided in the \KEIL\C51\LIB folder. Yes, Keil had to give in to the PC types that think they can do the '51 Erik
Dear Erik, I bow to your wisdom, I know you understand these things better than I. Perhaps you should tell Dallas Semiconductor to stop using Java on the on the DS80C390 ... The DS80C390 is hardly a standard '51 when it can access 4MB of ROM and 4MB of RAM directly. Similar to PC don't you think? Didn't that PC boffin Billy Gates say 640K would be enough for anyone? I am quite aware of the effects of RAM fragmentation that malloc creates, which I assume you are referring to. Even PC types know that, which you seem to have assumed I am. If your not going to be any help don't bother replying. It is a waste of your time and mine.
Stuart, Don't let Erik irritate you. He doesn't mean to. He just tends to see things in black and white. I agree with him to the extent that *in most situations* malloc() is an inappropriate thing to use in an 8051 environment, however I can see that if RAM is plentiful and speed not critical then there are arguments for its use if the problem in hand lends itself to dynamic memory allocation. Out of interest, what code are you writing that needs malloc()? Stefan
Stefan We have built a relative complex system into the DS80C390, I expect more complex than most '51 systems, and much more complex than Intel's original intention for this type of microcontroller. We did this solely to save money, as this processor had nearly all features we needed and we had some experience of the DS87C520. It has proved to be more than quick enough for our purposes. I originally wrote this query a year or so ago and we have since got around the issue. Anyway here was the original problem. In a previous embedded system we had some code that created a number of menus based on a constant array, varying the amount of memory needed for each menu. This memory was malloc'ed at switch on. We intended to port this to this new system with as little changes as possible, as the system was relatively complex and worked. The malloc'ing was just done for convenience so that we did not need to keep extending the array when a menu item was added. This previous system also had a vast amount of memory (1MB). As we could not seam to use the keil malloc we rewrote the code so that it used a large array that was compiled in and then allocated to the menu items at startup, and checks to see if text file exceeds the array. I expect there are other way of achieving the same thing but it works and is quick enough so …. Anyway thanks for the help Stuart
I am quite aware of the effects of RAM fragmentation that malloc creates, which I assume you are referring to. Even PC types know that, which you seem to have assumed I am. The Keil malloc routines do not fragment memory as badly as MOST malloc routines. The Keil routines merge FREE'd blocks. This is the technique proposed by Donald Knuth. Jon