Это што это я толькашо прочитал? О_О
Боюсь даже спросить, чем тыкая?
Перстом.
… ну вот в случае экран-буфера, там берём massiv_bufer[128][64] , а тут massiv_bufer[3*N].
Без взгляда на исходники библиотеки промолчу. Мне до следующей пятницы запрещено фантазировать, лимит исчерпан. Вы и правы и нет. При желании можно сделать как хотите.
Это библиотека Adafruit_NeoPixel.h. Я думаю во всех вариантах-обновлениях одинаков этот момент. Компиляция проходит успешно, процент динамической памяти показывает нормально … и ап! скетч не работает.
Это не моё желание 
Это вроде бы как здравый смысл для любого пользователя. Мне просто интересна причина этой кривизны. Она непреодолима в рамках языка, или это недоработка авторов.
Осмысленное признание ошибки не грех…грех - неосмысленное
… потому жена и говорит - ты никогда не признаёшь своих ошибок.
Потому, что буфер запрашивается во время исполнения функцией malloc. Во время компиляции его ещё просто нет и компилятору просто неоткуда знать, что он вообще когда-то будет.
Переменная pixels НЕ МАССИВ. Посмотрите, как она описана! Где там массив? Это просто указатель, а память запрашивается функцией malloc.
Это то здесь причём? Места не хватает для pixels, а не для massiv_bufer.
А как они могут это сделать? Ну, проверили, И? Что им делать, если проблема? Всё подвешивать? Так оно и так подвешивается. Выводить в сериал? А откуда им знать есть он у Вас или нет, проинициализирован или нет? Включать светодиод? Откуда им знать на каком пине у Вас светодиод “авария” и есть ли он у Вас вообще?
Они дали Вам возможность проверить самому и делать то, что Вам нужно.
К сожалению я не понимаю логики авторов (и уж тем более текста библиотеки). Просто затык не в количестве пикселей, их может быть любое число, а в необходимости хранения данных компонент цвета в массиве оперативной памяти. Он и ограничивает число пикселей для данного МК. Почему бы в библиотеке не число исходных пикселей задавать, а размер массива, тем самым однозначно выдавая использованный ресурс при компиляции? Ленте ведь глубоко всё равно сколько пикселей её длины объявлено. Её лишь может быть недостаточно или избыточно под заданный размер.
…интересно, в фаст лед такой же подход (я никогда не пользовался толком ею).
Это для удобства пользователей, скрыть внутри по максимуму. По идее авторов. А язык позволяет многое.
Для систем без динамики (или с внешним своим менеджером памяти) возможен такой подход:
У библиотеки спрашивается требуемый размер под поданные параметры инициализации, создается массив нужного размера, указатель на массив отдается библиотеке. Это заморочнее для пользователя, но предсказуемее и надежнее. Для надежных встроек самое то.
Нифига себе удобство! Всё нормально, грузи скетч, только работать не будет! Интересно (забыл уже, может проверял), а если написать 1000 пикселей в ленте, библиотека тоже пропустит? Но работать не будет
…ладно, ясно.
…опять интернет исчезает, по непонятным причинам.
Мнение дилетанта-любителя
Вот @ЕвгенийП показал пример(#35), как можно проверить, если количество запрашиваемой памяти известно.
А если данные приходят из вне, и, их кол-во меняется? Как можно узнать заранее, сколько придёт, скажем по сериалу (если заранее неизвестно)? Предусмотреть , чтобы не приходило больше максимально допустимого значения? Допустим , что сделали так
А стек то , вообще растёт с другой стороны, навстречу куче. А если число каких-либо циклов в программе, зависит от поступивших данных? Наверное тоже можно как то узнать, подозреваю, что это сильно усложнит, и сделает громоздким ЯП и компилятор, который должен стать уже сразу и автоматическим отладчиком))
А зачем тогда программист?
Давайте без мата. Стеки, кучи, дилетанты. Я приводил пример библиотеки где сразу видно, что половина оперативки занята. Что здесь принципиально мешает авторам? Изъян языка или избыточная профпригодность?
…Ну а впрочем пофиг, раз так правильно, то ладно 
Наверно, точнее будет сказать : “половина оперативки точно занята.”
А что ещё , и, как, будет понаписано в программе - откуда знать библиотеке?
Опять же ИМХО. Если что не правильно говорю - извиняюсь, просто тема интересная.
Именно так. Просто когда в итоге компиляции написано 57% , а в реальности скачет ± 5 процентов это одно. А когда написано 57, в реальности больше 100 - это совсем другое. Есть понятия погрешность измерения, а есть промах измерения. Это разное.
Простите, Вы кто по специальности? Просто представьте себе, что человек, не имеющий представления в Вашей сфере деятельности начнёт так рьяно критиковать Ваши действия и выдавать Вам советы глобального масштаба. Представьте и посмейтесь.
Потому, что это породит гораздо больше проблем, чем решит. Например, начисто убьёт возможность манёвра памятью (запрашивать тогда, когда нужно и освобождать для других нужд, когда не нужно).
Вот представьте, чисто как пример, что у Вас устройство для формирование нескольких (в зависимости от разных причин) изображений. Так, как Вы предлагаете, Вам необходима память под все изображения, т.к. они все всё время будут сидеть в RAM (хотя нужны по очереди и одновременно никогда не показываются). А так, как сделано в библиотеке, Вам достаточно иметь память под одно (самое большое) изображение.
Слушай, воткни в самое начало этих своих fun_1,2,3,4 такоэ, в каждую:
{printf("In %s()\r\n",__FUNCTION__);return;}
Посмотрим, вызываются ли все 4 или нет.
PS: топика не читал, лень, сорян если уже предлагали.
Да, размером 3*N байт, где N - число пикселей. Почему по итогам компиляции это нельзя отображать?
Читайте внимательнее, я написал, что “достаточно” при динамическом запросе памяти. А при динамическом запросе компилятор не знает и не может знать сколько памяти будет (и будет ли вообще) запрашиваться
Причина найдена, скетч исправлен. Итоговый я выкладывал в 22 посте. Чтоб к исходному вернуть нужно массивы переходники из прогмем в оперативку вернуть. Лень.
1 лайк
Статический, это когда ты задаешь массив.
Динамический, это когда ты выделяешь память функцией malloc. Ну или оператором new.
В твоем когде вроде бы все статическое :).
Старайся по возможности ими и обходится.
А в библиотеке malloc, именно этим он и возмущается, только сказать не может.
1 лайк