avr-libc malloc IRQ protection

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,
I cannot find any stubs left into the malloc implementation to fill with IRQ disabling/enabling routines. Is this supposed to be handled from outside (on ARM newlib there's malloc inner support for this IRQ protection mechanism).

Thanks in advance,
RM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely this would only be an issue if you tried to call malloc() reentrantly from an ISR() but you wouldn't malloc() from an ISR would you? Failing that surround the entire malloc() call with ATOMIC_BLOCK protection in the mainline code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Surely this would only be an issue if you tried to call malloc() reentrantly from an ISR() but you wouldn't malloc() from an ISR would you? Failing that surround the entire malloc() call with ATOMIC_BLOCK protection in the mainline code.

If you happen to also be using preemptive multitasking, then attempting to use malloc/free in two concurrent threads can be a problem which would require interrupt protection.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

In that case, attempting to use malloc/free in two concurrent threads can be a problem.

You'd kind of hope that if it were any kind of decent OS it would provide its own malloc()/free() anyway. In my experience(*) most do.

(*) though I've never felt the need to use an RTOS on an 8bit micro - maybe "small" RTOS do not provide such luxuries? Certainly professional OS like VxWorks and Nucleus Plus do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

In that case, attempting to use malloc/free in two concurrent threads can be a problem.

You'd kind of hope that if it were any kind of decent OS it would provide its own malloc()/free() anyway. In my experience(*) most do.

(*) though I've never felt the need to use an RTOS on an 8bit micro - maybe "small" RTOS do not provide such luxuries? Certainly professional OS like VxWorks and Nucleus Plus do.

I'm writing the OS, that is why.. and as I already have code running on ARM where I can call malloc and free without having to wrap those, I expected the same from avrlibc.. I guess I'll have to change names to all calls in ARM and wrap malloc with protection...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes,

The source of the C lib is, of course, open source so you can amend the source if you like and build copies locally. As I say most RTOS *do* supply their own local malloc()/free() specifically so it can service multiple threads.

BTW you said "ARM", are we talking at cross purposes? This is the Xmega forum.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Yes,
BTW you said "ARM", are we talking at cross purposes? This is the Xmega forum.

This is related to Xmega and avr-libc: I'm trying to understand if there is a common behavior between the avr-libc malloc/free implementation and the rest-of-the-world embedded target processor's libc malloc/free implementations.
Currently I had the chance to inspect avrlibc (for AVR) and newlib (for ARM).
I need to find out if it is a better approach to patch avrlibc or to wrap the malloc from outside, depending on the answer to the above.

R

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well there's no mystery about the AVR-LibC implementation, Source is here:

http://svn.savannah.nongnu.org/v...

Note the comment:

/*
 * Exported interface:
 *
 * When extending the data segment, the allocator will not try to go
 * beyond the current stack limit, decreased by __malloc_margin bytes.
 * Thus, all possible stack frames of interrupt routines that could
 * interrupt the current function, plus all further nested function
 * calls must not require more stack space, or they'll risk to collide
 * with the data segment.
 */

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Well there's no mystery about the AVR-LibC implementation, Source is here:

http://svn.savannah.nongnu.org/v...

Note the comment:

/*
 * Exported interface:
 *
 * When extending the data segment, the allocator will not try to go
 * beyond the current stack limit, decreased by __malloc_margin bytes.
 * Thus, all possible stack frames of interrupt routines that could
 * interrupt the current function, plus all further nested function
 * calls must not require more stack space, or they'll risk to collide
 * with the data segment.
 */

I see..