Autor Tema: Cantidad en Flash en Arduino/Teensy.  (Leído 3338 veces)

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Cantidad en Flash en Arduino/Teensy.
« en: 02 de Junio de 2017, 15:28:19 »
.

Tengo un aplicativo hecho para un Teensy LC, bajo Arduino, como todo los Teensy.

El micro que monta el Teensy LC es un MKL26Z64VFT4, 64K Flash, 8K RAM, QFN48, pero como se me puede quedar corto en mi diseño, lo he reemplazado por un MKL26Z128VFM4, 128K Flash, 16K RAM, QFN32.

Para que Arduino contemple toda la Flash y la RAM del micro que he elegido, he editado el fichero boards.txt de Arduino, para cambiar los 64k por 128k, y los 8k por 16. El problema es que me encuentro lo siguiente sobre el micro del Teensy LC.

teensyLC.upload.maximum_size=63488
teensyLC.upload.maximum_data_size=8192


La primera linea define el tamaño de Flash,  y la segunda el tamaño de RAM. La segunda linea me cuadra, 8K * 1024 = 8192 de RAM, pero la primera que haría referencia a la Flash no la entiendo, esperaba 64*1024 = 65536, pero me encuentro con 63488.

¿ Alguien entiende porque me chorizan esos 2K (1024*2) ??, ¿ Puede que Teensy ocupe esos 2K con algún bootloader ?. Si es tema de bootloader, nuevo problema porque el objeto compilado no cargaría en la primera dirección de memoria de la Flash y precisaría si o si un bootloader o localizar y cambiar el linker script para que el enlazador ubique el objeto para ejecución inmediata sin bootloader.


Por otra parte si miro las definiciones de flash y RAM para un Teensy 3.6, que instala un micro de 1Mb de flash, me ponen esto. Entiendo que son 1024*1024=1048576 de Flash, lo esperado.

teensy36.upload.maximum_size=1048576
teensy36.upload.maximum_data_size=262144



El Teensy 3.5, instala un micro con 512K de Flash (512*1024= 524288 ), y en boards.txt me encuentro con esto, también me salen las cuentas:

teensy35.upload.maximum_size=524288
teensy35.upload.maximum_data_size=196608




« Última modificación: 02 de Junio de 2017, 15:46:50 por planeta9999 »

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #1 en: 02 de Junio de 2017, 15:54:06 »
.

He seguido investigando. Localizo el linkerscript para el Teensy LC y me encuentro con este contenido, que define la cantidad de Flash y RAM y la dirección de memoria inicial. Aqui no hay ningún bootloader, se está cargando el programa en la primera dirección de memoria de la Flash, ahora si que no entiendo porque me quitan 2K de flash en la definición de Arduino en boards.txt, y también en el linker Script, si no hay bootloader.

MEMORY
{
   FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 62K
   RAM  (rwx) : ORIGIN = 0x1FFFF800, LENGTH = 8K
}



Miro el linker Script del Kinetis que monta el Teensy 3.2, que es un MK20 de 256K, y tiene este contenido. Aquí si que respetan la totalidad de la Flash (256K), e igualmente no hay bootloader, el objeto se ubica en la primera dirección de la flash.

MEMORY
{
   FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256K
   RAM  (rwx) : ORIGIN = 0x1FFF8000, LENGTH = 64K
}



Y otro linker Script más, este del MK64 con 512K de flash, también respetan la totalidad de la Flash, con dirección de arranque en la primera dirección de la flash, sin bootloader.


MEMORY
{
   FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 512K
   RAM  (rwx) : ORIGIN = 0x1FFF0000, LENGTH = 192K
}
« Última modificación: 02 de Junio de 2017, 15:57:35 por planeta9999 »

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #2 en: 02 de Junio de 2017, 16:38:26 »
Lo primero que deberias revisar es el archivo del linker script que es lo que tenes ahi ( pero pusiste una parte nomas)

Luego tenes:

Citar
Teensy-LC is based on Freescale part MKL26Z64. It has 64K of flash (2K is reserved for emulating 128 bytes EEPROM) and 8K of RAM. A total of 27 digital I/O pins are available, 4 with 20 mA drive capability, the rest with 5mA output. Most pins have interrupts.
« Última modificación: 02 de Junio de 2017, 16:43:16 por KILLERJC »

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #3 en: 02 de Junio de 2017, 18:39:31 »
.

Si, gracias Killer. Me respondió lo mismo Paul, en el foro de Teensy, se reservan 2k para emular una eeprom. La duda que sigo teniendo es si esos 2K los tengo que seguir reservando si cambio el micro por uno de 128K, no necesito emular ninguna eeprom en mi código.

Esos 2K solo se están reservando en los Teensy con los MKL26Z, los Teensy 3.0 y superiores ya no reservan nada de flash para otros menesteres.

Sobre el linker Script solo me fije en la parte que define tamaño y ubicación de Flash y RAM, creo que es lo único que tengo que modificar para cambiar un MKL26Z64 por un MKL26Z128, solo aumenta el tamaño de la Flash y la RAM.

« Última modificación: 02 de Junio de 2017, 18:44:35 por planeta9999 »

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #4 en: 02 de Junio de 2017, 18:44:27 »
Podrias tratar de modificar el archivo linker, y darle ese espacio de la EEPROM un largo de 0 (Tambien modificar la parte de la flash a 64K). Para ver si te tira error, si hay un error es porque intenta guardar algo alli.

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #5 en: 02 de Junio de 2017, 18:47:19 »
.


Este es el linker scrip completo que usan para compilar con el Teensy LC, no veo nada sobre la eeprom, solo que se asignan 62K de flash desde la dirección 0x00000000 para que el enlazador ubique el código objeto. Entiendo que los 2K de la parte alta de la Flash quedan sin asignar para que por programa se usen emulando una eeprom.

Estoy por coger simplemente este linker script y cambiar el 62K por 128k, y el 8k por 16k. Mis conocimientos sobre el linker script se limitan a lo que se define en MEMORY, tamaño y ubicación de flash, tamaño y ubicación de RAM, nunca he tocado otras cosas, solo la dirección de inicio de la Flash para usar un bootloader.

Código: [Seleccionar]
/* Teensyduino Core Library*/

MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 62K
RAM  (rwx) : ORIGIN = 0x1FFFF800, LENGTH = 8K
}


SECTIONS
{
.text : {
. = 0;
KEEP(*(.vectors))
*(.startup*)
/* TODO: does linker detect startup overflow onto flashconfig? */
. = 0x400;
KEEP(*(.flashconfig*))
*(.text*)
*(.rodata*)
. = ALIGN(4);
KEEP(*(.init))
. = ALIGN(4);
__preinit_array_start = .;
KEEP (*(.preinit_array))
__preinit_array_end = .;
__init_array_start = .;
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
__init_array_end = .;
} > FLASH = 0xFF

.ARM.exidx : {
__exidx_start = .;
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
__exidx_end = .;
} > FLASH
_etext = .;

.usbdescriptortable (NOLOAD) : {
/* . = ORIGIN(RAM); */
. = ALIGN(512);
*(.usbdescriptortable*)
} > RAM

.dmabuffers (NOLOAD) : {
. = ALIGN(4);
*(.dmabuffers*)
} > RAM

.usbbuffers (NOLOAD) : {
. = ALIGN(4);
*(.usbbuffers*)
} > RAM

.data : AT (_etext) {
. = ALIGN(4);
_sdata = .;
*(.fastrun*)
*(.data*)
. = ALIGN(4);
_edata = .;
} > RAM

.noinit (NOLOAD) : {
*(.noinit*)
} > RAM

.bss : {
. = ALIGN(4);
_sbss = .;
__bss_start__ = .;
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .;
__bss_end = .;
__bss_end__ = .;
} > RAM

_estack = ORIGIN(RAM) + LENGTH(RAM);
}



Y este es el linker script que se instala para el mismo micro con el KDS de NXP. Nunca había visto esa división de memoria en cuatro partes, en los linker script de Microchip siempre me salían asignación para flash y para Ram, nada más, cada una con dirección de inicio y tamaño, igual que en el linker script de Teensy.

También me llama la atención la definición de tamaño del stack y del heap, que varía con respecto al siguiente linker script, de un MKL26Z64 a un MKL26Z128. En el anterior linker script el tamaño del stack se define como ORIGIN(RAM) + LENGTH(RAM), y aqui se le asigna una tamaño de 0x0100. En el anterior linker script no veo nada sobre el/la heap.

Código: [Seleccionar]
/*
/* Entry Point */
ENTRY(Reset_Handler)

HEAP_SIZE  = DEFINED(__heap_size__)  ? __heap_size__  : 0x0200;
STACK_SIZE = DEFINED(__stack_size__) ? __stack_size__ : 0x0100;
M_VECTOR_RAM_SIZE = DEFINED(__ram_vector_table__) ? 0x0100 : 0x0;

/* Specify the memory areas */
MEMORY
{
  m_interrupts          (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00000100
  m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010
  m_text                (RX)  : ORIGIN = 0x00000410, LENGTH = 0x0000FBF0
  m_data                (RW)  : ORIGIN = 0x1FFFF800, LENGTH = 0x00002000
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into internal flash */
  .interrupts :
  {
    __VECTOR_TABLE = .;
    . = ALIGN(4);
    KEEP(*(.isr_vector))     /* Startup code */
    . = ALIGN(4);
  } > m_interrupts

  .flash_config :
  {
    . = ALIGN(4);
    KEEP(*(.FlashConfig))    /* Flash Configuration Field (FCF) */
    . = ALIGN(4);
  } > m_flash_config

  /* The program code and other data goes into internal flash */
  .text :
  {
    . = ALIGN(4);
    *(.text)                 /* .text sections (code) */
    *(.text*)                /* .text* sections (code) */
    *(.rodata)               /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)              /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)               /* glue arm to thumb code */
    *(.glue_7t)              /* glue thumb to arm code */
    *(.eh_frame)
    KEEP (*(.init))
    KEEP (*(.fini))
    . = ALIGN(4);
  } > m_text

  .ARM.extab :
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } > m_text

  .ARM :
  {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } > m_text

 .ctors :
  {
    __CTOR_LIST__ = .;
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin.o(.ctors))
    KEEP (*crtbegin?.o(.ctors))
    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
    __CTOR_END__ = .;
  } > m_text

  .dtors :
  {
    __DTOR_LIST__ = .;
    KEEP (*crtbegin.o(.dtors))
    KEEP (*crtbegin?.o(.dtors))
    KEEP (*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
    __DTOR_END__ = .;
  } > m_text

  .preinit_array :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } > m_text

  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } > m_text

  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } > m_text

  __etext = .;    /* define a global symbol at end of code */
  __DATA_ROM = .; /* Symbol is used by startup for data initialization */

  /* reserve MTB memory at the beginning of m_data */
  .mtb : /* MTB buffer address as defined by the hardware */
  {
    . = ALIGN(8);
    _mtb_start = .;
    KEEP(*(.mtb_buf)) /* need to KEEP Micro Trace Buffer as not referenced by application */
    . = ALIGN(8);
    _mtb_end = .;
  } > m_data

  .interrupts_ram :
  {
    . = ALIGN(4);
    __VECTOR_RAM__ = .;
    __interrupts_ram_start__ = .; /* Create a global symbol at data start */
    *(.m_interrupts_ram)     /* This is a user defined section */
    . += M_VECTOR_RAM_SIZE;
    . = ALIGN(4);
    __interrupts_ram_end__ = .; /* Define a global symbol at data end */
  } > m_data

  __VECTOR_RAM = DEFINED(__ram_vector_table__) ? __VECTOR_RAM__ : ORIGIN(m_interrupts);
  __RAM_VECTOR_TABLE_SIZE_BYTES = DEFINED(__ram_vector_table__) ? (__interrupts_ram_end__ - __interrupts_ram_start__) : 0x0;

  .data : AT(__DATA_ROM)
  {
    . = ALIGN(4);
    __DATA_RAM = .;
    __data_start__ = .;      /* create a global symbol at data start */
    *(.data)                 /* .data sections */
    *(.data*)                /* .data* sections */
    KEEP(*(.jcr*))
    . = ALIGN(4);
    __data_end__ = .;        /* define a global symbol at data end */
  } > m_data

  __DATA_END = __DATA_ROM + (__data_end__ - __data_start__);
  text_end = ORIGIN(m_text) + LENGTH(m_text);
  ASSERT(__DATA_END <= text_end, "region m_text overflowed with text and data")

  /* Uninitialized data section */
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss section */
    . = ALIGN(4);
    __START_BSS = .;
    __bss_start__ = .;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
    __END_BSS = .;
  } > m_data

  .heap :
  {
    . = ALIGN(8);
    __end__ = .;
    PROVIDE(end = .);
    __HeapBase = .;
    . += HEAP_SIZE;
    __HeapLimit = .;
  } > m_data

  .stack :
  {
    . = ALIGN(8);
    . += STACK_SIZE;
  } > m_data

  /* Initializes stack on the end of block */
  __StackTop   = ORIGIN(m_data) + LENGTH(m_data);
  __StackLimit = __StackTop - STACK_SIZE;
  PROVIDE(__stack = __StackTop);

  .ARM.attributes 0 : { *(.ARM.attributes) }

  ASSERT(__StackLimit >= __HeapLimit, "region m_data overflowed with stack and heap")
}



Y este es el linker script para el MKL26Z128 que instala KDS.

Código: [Seleccionar]
/* Entry Point */
ENTRY(Reset_Handler)

HEAP_SIZE  = DEFINED(__heap_size__)  ? __heap_size__  : 0x0400;
STACK_SIZE = DEFINED(__stack_size__) ? __stack_size__ : 0x0400;

/* Specify the memory areas */
MEMORY
{
  m_interrupts          (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00000100
  m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010
  m_text                (RX)  : ORIGIN = 0x00000410, LENGTH = 0x0001FBF0
  m_data                (RW)  : ORIGIN = 0x1FFFF000, LENGTH = 0x00004000
}

/* Define output sections */
SECTIONS
{
  /* The startup code goes first into internal flash */
  .interrupts :
  {
    __VECTOR_TABLE = .;
    . = ALIGN(4);
    KEEP(*(.isr_vector))     /* Startup code */
    . = ALIGN(4);
  } > m_interrupts

  .flash_config :
  {
    . = ALIGN(4);
    KEEP(*(.FlashConfig))    /* Flash Configuration Field (FCF) */
    . = ALIGN(4);
  } > m_flash_config

  /* The program code and other data goes into internal flash */
  .text :
  {
    . = ALIGN(4);
    *(.text)                 /* .text sections (code) */
    *(.text*)                /* .text* sections (code) */
    *(.rodata)               /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)              /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)               /* glue arm to thumb code */
    *(.glue_7t)              /* glue thumb to arm code */
    *(.eh_frame)
    KEEP (*(.init))
    KEEP (*(.fini))
    . = ALIGN(4);
  } > m_text

  .ARM.extab :
  {
    *(.ARM.extab* .gnu.linkonce.armextab.*)
  } > m_text

  .ARM :
  {
    __exidx_start = .;
    *(.ARM.exidx*)
    __exidx_end = .;
  } > m_text

 .ctors :
  {
    __CTOR_LIST__ = .;
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin.o(.ctors))
    KEEP (*crtbegin?.o(.ctors))
    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
    __CTOR_END__ = .;
  } > m_text

  .dtors :
  {
    __DTOR_LIST__ = .;
    KEEP (*crtbegin.o(.dtors))
    KEEP (*crtbegin?.o(.dtors))
    KEEP (*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
    __DTOR_END__ = .;
  } > m_text

  .preinit_array :
  {
    PROVIDE_HIDDEN (__preinit_array_start = .);
    KEEP (*(.preinit_array*))
    PROVIDE_HIDDEN (__preinit_array_end = .);
  } > m_text

  .init_array :
  {
    PROVIDE_HIDDEN (__init_array_start = .);
    KEEP (*(SORT(.init_array.*)))
    KEEP (*(.init_array*))
    PROVIDE_HIDDEN (__init_array_end = .);
  } > m_text

  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);
  } > m_text

  __etext = .;    /* define a global symbol at end of code */
  __DATA_ROM = .; /* Symbol is used by startup for data initialization */

  /* reserve MTB memory at the beginning of m_data */
  .mtb : /* MTB buffer address as defined by the hardware */
  {
    . = ALIGN(8);
    _mtb_start = .;
    KEEP(*(.mtb_buf)) /* need to KEEP Micro Trace Buffer as not referenced by application */
    . = ALIGN(8);
    _mtb_end = .;
  } > m_data

  .data : AT(__DATA_ROM)
  {
    . = ALIGN(4);
    __DATA_RAM = .;
    __data_start__ = .;      /* create a global symbol at data start */
    *(.data)                 /* .data sections */
    *(.data*)                /* .data* sections */
    KEEP(*(.jcr*))
    . = ALIGN(4);
    __data_end__ = .;        /* define a global symbol at data end */
  } > m_data

  __DATA_END = __DATA_ROM + (__data_end__ - __data_start__);

  /* Uninitialized data section */
  .bss :
  {
    /* This is used by the startup in order to initialize the .bss section */
    . = ALIGN(4);
    __START_BSS = .;
    __bss_start__ = .;
    *(.bss)
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    __bss_end__ = .;
    __END_BSS = .;
  } > m_data

  .heap :
  {
    . = ALIGN(8);
    __end__ = .;
    PROVIDE(end = .);
    __HeapBase = .;
    . += HEAP_SIZE;
    __HeapLimit = .;
  } > m_data

  .stack :
  {
    . = ALIGN(8);
    . += STACK_SIZE;
  } > m_data

  /* Initializes stack on the end of block */
  __StackTop   = ORIGIN(m_data) + LENGTH(m_data);
  __StackLimit = __StackTop - STACK_SIZE;
  PROVIDE(__stack = __StackTop);

  .ARM.attributes 0 : { *(.ARM.attributes) }

  ASSERT(__StackLimit >= __HeapLimit, "region m_data overflowed with stack and heap")
}





« Última modificación: 02 de Junio de 2017, 19:12:17 por planeta9999 »

Desconectado KILLERJC

  • Colaborador
  • DsPIC33
  • *****
  • Mensajes: 8242
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #6 en: 02 de Junio de 2017, 19:38:30 »
Parece que lo hace por fuera del script del linker, tal ves en esos boards.txt que tenes.

El archivo del Linker del Teensy LC solo define la FLASH y la RAM

La FLASH tiene varios sectores.
El primero comienza con el sector ".vectors" en la direccion 0x0000, asi como tambien las secciones: ".startup*" (inicializacion C seguramente ) quedando seguidas de los vectores.
En la direccion 0x400 pone la seccion ".flashconfig*" luego ".text*" (codigo), luego ".rodata" (read only data) etc.

El stack es decreciente, asi que la cima del stack (top) esta dada por la direccion de memoria mas grande. Lo raro es la ubicacion de la RAM en el espacio de memoria.
1/4 de la RAM esta antes del 0x2000.0000 y 3/4 luego de los 0x2000.0000

Entonces tenemos 2K desde 0x1FFF.F800 a 0x1FFF.FFFF y luego 6K dese 0x2000.0000 a 0x2000.17FF

en este caso se calcula asi:

_estack = ORIGIN(RAM) + LENGTH(RAM);

_estack = 0x1FFF.F800+ 0x1FFF;  (8K - 1)
0x1FFFF800 + 0x1FFF = 0x2000.17FF

Esto te da un limite nomas, que es que no podes pasar de ese valor que es el cuando el stack esta vacio, a veces es mejor proveer otra proteccion y otro limite que es cuando esta lleno, tal ves porque sabes cuanto RAM vas a usar y no queres que jamas tu programa llegue a cambiar los valores de algun array por que lleno el stack de cosas. Un caso para esto es... una funcion recursiva, ya que los valores de PC se guardan en el stack lo estarias llenando y no quisieras que en algun momento este supere y cambie otras variables.
Para eso se da el otro limite como tenes en los otros archivos:

  __StackTop   = ORIGIN(m_data) + LENGTH(m_data);    -------  Limite Stack Vacio
  __StackLimit = __StackTop - STACK_SIZE;     --------------      Limite Stack Lleno (tal ves entre aca y salte una exepcion)


m_data posee las direcciones correctas de la RAM, nomas que en el Teensy se lo nombro RAM, y si observas es R/W

m_data                (RW)  : ORIGIN = 0x1FFFF000, LENGTH = 0x00004000.

El Heap tambien, uno debe darle un tamaño y no debe superarlo, es mejor tenerlo controlado, para el caso del Teensy parece que directamente NO genera codigo para el Heap, por lo tanto no lo tiene en cuenta. Esto me lleva a pensar que.. si intentas usar el Heap ocurre un error, o hay algo que administre el Heap externamente.
« Última modificación: 02 de Junio de 2017, 19:41:38 por KILLERJC »

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #7 en: 02 de Junio de 2017, 19:48:00 »
.

Gracias Killer, probaré a compilar con el primer linker script modificando tamaño de flash y Ram, y luego usando el linker script del KDS.

De todas formas ahora mismo el programa solo ocupa 12K, y solo tengo que añadir SPI para controlar un módulo de radio y otro SPI Master/Slave para comunicar dos MKL26. Es posible que todo quepa en los 64k, aunque el micro tiene 128K, supongo que si no supero los 64K de flash y los 8K de RAm no tengo que modificar el linker Script.

Con el SPI ya estoy teniendo problemas, porque parece que las librerías de Teensy o de Arduino para este micro o de Arduino en general, no contemplan configurar el micro como SPI Esclavo. El caso es que estuve apunto de diseñar el hardware para comunicar ambos micros por la  UART, a que mala hora los conecte por SPI, me huelo que una vez más la placa va a ir a la basura.

« Última modificación: 02 de Junio de 2017, 19:51:34 por planeta9999 »

Desconectado Picuino

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5892
    • Picuino
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #8 en: 02 de Junio de 2017, 20:38:14 »
¿Puede funcionar esto en Tennsy con modificaciones?

http://forum.arduino.cc/index.php?topic=52111.0

Código: C
  1. #include "pins_arduino.h"
  2.  
  3. char buf [100];
  4. volatile byte pos;
  5. volatile boolean process_it;
  6.  
  7. void setup (void)
  8. {
  9.  Serial.begin (9600);   // debugging
  10.  
  11.  // have to send on master in, *slave out*
  12.  pinMode(MISO, OUTPUT);
  13.  
  14.  // turn on SPI in slave mode
  15.  SPCR |= _BV(SPE);
  16.  
  17.  // turn on interrupts
  18.  SPCR |= _BV(SPIE);
  19.  
  20.  pos = 0;
  21.  process_it = false;
  22. }  // end of setup
  23.  
  24.  
  25. // SPI interrupt routine
  26. ISR (SPI_STC_vect)
  27. {
  28. byte c = SPDR;
  29.  
  30.  // add to buffer if room
  31.  if (pos < sizeof buf)
  32.    {
  33.    buf [pos++] = c;
  34.    
  35.    // example: newline means time to process buffer
  36.    if (c == '\n')
  37.      process_it = true;
  38.      
  39.    }  // end of room available
  40. }
  41.  
  42. // main loop - wait for flag set in interrupt routine
  43. void loop (void)
  44. {
  45.  if (process_it)
  46.    {
  47.    buf [pos] = 0;  
  48.    Serial.println (buf);
  49.    pos = 0;
  50.    process_it = false;
  51.    }  // end of flag set
  52.    
  53. }  // end of loop

PD: o este otro https://forum.pjrc.com/threads/23428-Teensy-3-0-as-SPI-Slave
Saludos.
« Última modificación: 02 de Junio de 2017, 20:41:13 por Picuino »

Desconectado planeta9999

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3520
    • Pinballsp
Re:Cantidad en Flash en Arduino/Teensy.
« Respuesta #9 en: 02 de Junio de 2017, 21:33:55 »
PD: o este otro https://forum.pjrc.com/threads/23428-Teensy-3-0-as-SPI-Slave
Saludos.

Ese hilo me lo han comentado en el foro de Teensy. Ya veré si lo pruebo, o no me caliento la cabeza, meto la placa al microscopio y cableo dos hilos finos de cobre esmaltado, para usar una UART. Como es un prototipo, ya modificaré el PCB para la versión final, ahora solo necesito poder modificar el hardware para desarrollar el firmware.

Esta es la librería que proponen, creo que el esclavo solo puede recibir, que en mi caso es suficiente.
https://github.com/btmcmahan/Teensy-3.0-SPI-Master---Slave

El problema es si esa librería puede compartirse con otro SPI Master que controla otro dispositivo. Tendría el SPI0 para controlar un módulo de radio, y el SPI1 para enviar datos a otro MKL26 que estaría configurado como esclavo.

 
« Última modificación: 02 de Junio de 2017, 21:40:53 por planeta9999 »