far malloc

Aloha Stu,

This is an easy one. With the dallas chip
you need to declare your own 'far' type 'king' and make them 'const'

Regards

Elvis

I knew it!! You're alive!!!

Can you explain a little more? Maybe an example? How does this affect the calls to init_mempool, etc.

Did you ever get this working?

Can you explain what you did?

I never managed to get this to work, I do not think it is possible

Stuart

why are you using malloc anyhow, it has no place in a '51 design

Erik

1. The source code for malloc, calloc, free, and realloc is provided in the \KEIL\C51\LIB folder.

2. There is a #define in STDLIB.H that defines the memory allocation memory type as XDATA. I'm pretty sure you could change it to FAR and that's all you need.

I seem to recall that the malloc routines are limited to a 64K sized (int) memory pool. However, with a tiny amount of work on your part, you could change the source code to use a long type.

Jon

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