Chief Delphi - malloc?

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - malloc? (http://www.chiefdelphi.com/forums/showthread.php?t=57944)

Does MPLAB not support the malloc() family, or am I just missing a library?

Quote:

Originally Posted by Jake M (Post 632387)

Does MPLAB not support the malloc() family, or am I just missing a library?

Dynamic memory allocation is something not usually done on a processor as small as the one in the RC (assuming that's what you're working on). What are you trying to malloc and why not just statically allocate it?

What I'm writing is just a terminal emulator, to work with the serial ports. What it needs to do, though, is let the rest of the program continue to run in the background. For example.....

Code:

Terminal_Print("Press a key: ");

char input = Terminal_Read();

...

Rather than sit at the second line and wait there for the user to provide input, it needs to look at the input queue, check if there is input or not, and then move on, letting the rest of the program continue normally.

After going through a long thought process of how to let this happen, without having the print statements re-print during each loop, and for each of the read statements to only read once, the solution is twofold.

First, there's a global variable that is 1 if any terminal function is waiting on input, and 0 otherwise. Built into each print statement is a simple check, so that the statement is only executed if the waiting flag is 0. This works out so that the flag is always 1 at print statements that have already been printed, and it is also 1 at any statements following the point where it's waiting for input.

However, to keep read statements that have already read input from reading again, I need a global array of bools, each representing one of the calls to Terminal_Read(). And within Terminal_Read() I call a handler that looks at and modifies this array to determine whether that particular call of the function is the one that should be reading the input.

Yes, I could certainly allocate statically, but it would make things a lot easier for me and for other teammates with very little programming experience to not have to redefine the array each time you make add or remove a read statement. Or, I could simply allocate an array of 1000 elements, since I probably would never need that many, but there's already not a whole lot of memory on a PIC.

I think I'll just go with a "Specify how many times you called Read()" approach. After all, it does get to a certain point where you don't change your terminal too much. I'll post it all here when I'm done.

There's gotta be a moderately automated way to do this.

One way I can think of to make the array-resizing a bit easier would be to do something like this:

Code:

enum ReadReasons (CAMERA_X,CAMERA_Y,CAMERA_Z,CAMERA_SPEED,TURN_SPEED,REASON_COUNT);

bool myArray[REASON_COUNT];



int main()

{

  Read(CAMERA_X);

  Read(CAMERA_Y); // the read function would perform behavior appropriate to whatever was passed in

  Read(CAMERA_Z);

}

void Read(ReadReason blah)

{

  switch(blah)

  {

    case CAMERA_X:

      if(myArray[CAMERA_X])

        Terminal_Print("Enter camera pan mode: ");

      Terminal_Read();

  }

}

Now, so long as the programmer defines a new entry in that enum each time they make a new call to Read, the array will be resized appropriately at compile time. IMO, it slightly improves code readability because you have a reason for each read that MUST be defined in clear english.

I keep thinking you could also use the preprocessor to do this, because having to do dynamic allocation for something that you know the needed size of at compile-time just sets of alarm bells in my head.

Hmm.....ingenious. I may well have to use that.

Preprocessor was exactly what I was thinking. When I get time, I'll bet there's a #pragma or something similar that can do the job.

My original idea was to duplicate a basic DOS-Style console app, from the programmer's perspective; printf, scanf, etc; very flexible. And essentially, that's what it's turned out to be, even to the point that my version of scanf takes a pointet to where the data is stored as an argument, rather than returning it, which was not originally intended. The only slight difficulty is that you have to #define the number of read calls you make. But I figure, just leave it at 100 or so until you've got the terminal communication part finalized. Plus, there may yet be a preprocessor way to do this. Gimme a day or two to comment it all and such and I'll post it up here. I'm sure someone will find a uses for it.

I believe what you're looking for is a buffer. You statically allocate a char array, and have an index showing the next place to write a character.

Also, if you want to get fancy, you can loop the buffer around--a ring buffer. So when you reach the end of the buffer, you start at the beginning. This is very eficiently done when your buffer size is a power of two. (index &= 0x1FF)

Just some thoughts.