AVR Freaks

I am pretty certain that it comes down to the linker script.

Yes,  I am sure that I could simply add my own malloc().  But I would prefer to see what has gone wrong with the v1.7.x releases

Then all the standard Arduino code should start working.

sbrk() returns NULL so it might be that I need to implement sbrk()

The Newlib code is fairly daunting.    It would help if I could find out how the Italians had actually built it.  e.g. what configuration.

Yes,  adding a working rand() is very straightforward.    I can just add it to the variants/arduino_zero/ folder.

David.

Thanks,   Cliff.

I edited the linker script:

	.heap (COPY):
	{
		__end__ = .;
		PROVIDE(end = .);
		PROVIDE(_heap_start = .);
		*(.heap*)
		. = . + 0x2000;
		__HeapLimit = .;
		PROVIDE(_heap_end = .);
	} > RAM

to provide some external labels.   (and a fixed 8192 byte heap)

and added a _sbrk() function to samd/core/startup.c

/*
 * _sbrk -- changes heap size size. Get nbytes more
 *         RAM. We just increment a pointer in what's
 *         left of memory on the board.
 */
extern caddr_t _heap_start, _heap_end;
#include <errno.h>

caddr_t _sbrk(int nbytes)
{
  static caddr_t heap_ptr = NULL;
  caddr_t        base;

  if (heap_ptr == NULL) {
    heap_ptr = (caddr_t)&_heap_start;
  }

  if (((caddr_t)&_heap_end - heap_ptr) >= 0) {
    base = heap_ptr;
    heap_ptr += nbytes;
    return (base);
  } else {
    errno = ENOMEM;
    return ((caddr_t)-1);
  }
}

I am not happy that this is the proper way to do things.   But it makes <SD.h> work.    And provides a working library malloc(), sbrk(), ...

Your link showed the heap being tested against RAMSIZE.   Which sounds like a scalar to me.

I am happier with limits.    I don't like the idea of the Heap running into the Stack without warning.

Hopefully,  an arm-gcc expert will drop by and advise.

David.

Thanks,  Bill.     You have a trailing space in your weblink.

I don't see any technical issues posted there.    It is mostly sparring between the two Arduino factions.

It looks as if the 'other' side is going to release a 'Zero' soon.    In which case,   we might get cooperation to get any bugs ironed out.

Hopefully,   both Zeros will have the same pin-mapping.     So it should not matter too much to the punter which one is used.

It is my bedtime.    I will look at the Due branch in the morning.

Meanwhile,   I will have to think about where to put these patches.     i.e. in variants/zero_pro or in syscalls.

Likewise,    I have several changes in variants/zero_pro/libraries and variants/zero_pro/variant.cpp

I note your comments about SPI mapping.    I still feel that a board that has UNO geography needs to match the most common UNO shields by default.    (with an option to use the 3x2 ISP header as an alternative)

Obviously a DUE is more similar to a MEGA2560 geography.

I will wait until I get a bit more familiar with the system before adding anything to 'issues'

And then I will probably want to get the Zero_Pro running with Rowley.

David.