Arduino.ru

Никак. Можно на куче выделить, но это другое и не нужно в эмбеде. Выделяй сразу статически массив под максимальный возможный размер.

Печально(

возможно, есть один человек, который точно знает как такое сделать... если я правильно задачу понял.

А в чем проблема-то

byte * buf;

void setup() {
  unsigned int bufSize;
  //получаем размер буфера откуда-нибудь
  buf = (byte*) malloc(bufSize);
  if (buf == NULL)
  {
      //Увы, нужного количества свободной памяти нет. Вешаемся... 
  }

}

void loop() {
  buf[0]=23;

}

byte * buf;

void setup() {
  unsigned int bufSize;
  //получаем размер буфера откуда-нибудь
  buf = (byte*) malloc(bufSize);
  if (buf == NULL)
  {
      //Увы, нужного количества свободной памяти нет. Вешаемся... 
  }

}

void loop() {
  buf[0]=23;

}

так это из кучи и получается

и куда ползти будет наш массив? был вариант, кода такие массивы указывали в конце памяти так сказать, ползет пока место есть. Не помню, чтоб такие решения пользовались популярностью.

гораздо проще, сразу выделить, все что не занял код, а потом просто не использовать лишнее от массива.

т.е. просто засунуть размер в переменную которая ограничит наш массив в коде.

Ну так и в чем проблема-то? Какая разница - что из кучи, что статически, все равно из того же самого ОЗУ выделяться будет.

Нахрена?  Если массив не расширяется, оставь его в EEPROM и читай оттуда. 

Да даже если и расширяется, тоже оставь. Тока не пиши в него слишком часто. 

byte * buf;

void setup() {
  unsigned int bufSize;
  //получаем размер буфера откуда-нибудь
  buf = (byte*) malloc(bufSize);
  if (buf == NULL)
  {
      //Увы, нужного количества свободной памяти нет. Вешаемся... 
  }

}

void loop() {
  buf[0]=23;

}

Спасибо! Познакомился с динамической памятью.

Потому что просто не нужно. Потому что ты дал более сложную вещь и не научил как освобождать и как работать размером, то есть любезно разложил грабли.

И как ты работешь размером в случае обычного массива?

В случае статического массива мне не нужно считать байты, компилятор сам это делает. Ты объяснил, что твой код обосрется, если размерность элемента массива больше байта?

скорее всего никак, но в этом случае память отгрызается снизу, оставляя какое-то количество на стек, в противном случае память растёт вниз, отгрызая от стека и нет никакой уверенности, что даже если её хватило, в работающем коде стек не пересечёт границу (не залезет в память переменных), то-есть совсем никакой, на асме я это контролировал ручками не допуская неконтролируемой рекурсии, да и программки были мелкие от пару-тройку десятков байт до 3-5 килобайт, а памяти вагон - 64кб

Да познания блещуть....

Какие байты тебе не нужно считать?

А размерность - ну так объявляй нужную размерность и работай себе спокойно. Никто не обосрется. Ну разве что ты. 

Понятно, сам не знаешь, а других учишь. Стандарт. Ладно, ликбез.

Вот так это делается, если ты застрял в 85м: uint32_t * arr = malloc(n * sizeof(uint32_t));.

Вот этак это делается, если ты знаешь язык на котором программируешь: auto arr = new uint32_t[n]();

А круглые скопки зачем?  Вот так не работает? 

uint32_t *arr = new uint32_t[n];

Есть какой то нюанс?  

а так нельзя?
uint24_t *arr = new uint24_t[n];

1. Асам написал всё верно, естественно. Можно и так и иначе выделить память на куче. Это нормально, правильно и удобно. Тип указателя нужно привести к требуемому.

2. Есть одно "но". Несмотря на порядком задолбавшее хамство Ркит-а, есть резон и в его реплике. В том смысле, что в ембед-системах нет никакого резона так поступать. Допустим мы выделили не максимум памяти, а столько, сколько реально нужно массиву и было записано в ЕЕПРОМ. С сэкономленной  памятью что делать будем? На привозе торговать?

Тут смысл в принципиальном отличии программирования компа и контроллера. Некуда в контроллере использовать случайно свободную память. В нем работает одна программа, та, что автор написал, и не может быть ситуации в которой память, свободная от одного объекта, будет использована с выгодой другим.

Вернее сказать так: я могу написать такой код, который будет полезным образом использовать разное количество памяти, Женя сможет, ну еще пара человек на форуме смогут  так написать, но это будет не реальная задача, а так - баловство шаловливого ума.

wdrakula - ты другое подскажи, как отслеживать требуемую глубину стека, чтобы не напороться на пересечение

тут не соглашусь. Если мы пишем программу, которая должна обрабатывать данные максимально возможного обьема, то в этом случае идея заранее выделить максимум доступной памяти как статичесий массив не работает. Точнее работает, но несет кучу гемора для разработчика - по мере разработки основного кода ему придется постоянно пересчитывать размер свободной памяти и корректировать размер статического массива. Значительно удобнее занимать весь обьем доступной памяти динамически в ходе работы конкретной версии программы.

В связи с этим два вопроса

 - есть ли в микроконтроллерах способ в ходе выполнения запросить обьем свободной на данный момент памяти?

 - и точно такой же вопрос, но на этапе компиляции - можно ли как-то в конкретной строчке программы выяснить, что к этому моменту память, условно говоря. "вся разобрана"? :)

Есть.  Петрович разъяснял и показывал как. Где-то в этюдах

В первом случае можно так узнать

int freeRam () { 
 extern int __heap_start, *__brkval; 
 int v; 
 return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

Вот дырявая у меня голова, от того и кодить человечески не умею... 100% помню, что пару лет назад был ровно такой-же топик (по смыслу) и результат дискуссии  был аналогичен. т.е.

1.про разработчика, который что-то пересчитывает - сорян, но это поток сознания. Какие максимальные данные??? Это контроллер, вашу...ть! Он диодиками моргает, свет включает, температуру поддерживает... и т.п. какие в ж... массивы данных неизвестного размера ему обрабатывать???

2. конечно есть! и не нужно Женю беспокоить.

#include <stdlib.h>
#include <alloca.h>

void setup() {
Serial.begin(115200);

}

void loop() {
  byte *Pstack = alloca(1);
  byte *Pheap = malloc(1);

  Serial.print("Heap 1st free addres is:");
  Serial.println((int) Pheap);

  Serial.print("Stack 1st free addres is:");
  Serial.println((int) Pstack);
  
  Serial.print("free mem is:");
  Serial.println((int) Pstack - (int) Pheap +1);

  delay(2000);

  

}

обращаю внимание, что стек не меняется, что очевидно, а куча уменьшается по 4 байта, а не по 1. если ОЧЕНЬ интересно - расскажу почему, а лучше сам узнай! ;))

ESP32

В общем, если у Вас возникло желание поместить копию EEPROM в ОЗУ, это говорит об ошибке проектирования. 

Вы где нибудь видели, что я такое писал?

Есть настройка, храниться в EEPROM, какой глубиной требуется делать сглаживание термокадров.

В зависимости от этой настройки, нужно создавать массив uint32_t [X][32][32], X равный количества требуемых кадров для сглаживания.

Ну даже в случае поморгать и температуру поддерживать такая ситуация вполне может возникнуть.

Например есть датчики по которым нужно считать скользящее среднее по возможно бОльшему окну. Образовалось больше памяти - выделяем больше под буфера.

Или есть цветной дисплей с динамической индикацией. И вынь да полож ему экранный буфер. Но он может работать с разной глубиной цветности. Есть больше памяти - работаем с большим BPP 

Скорее уж в океане... ))