Оверлеи - посоветуйте или раскритикуйте, аналог динамической линковки для AVR Опции

[ARV]

Т.е. Вы планируете не все возможные варианты функций-эффкектов собрать в один файл, а на каждую допустимую комбинацию свой файл транслировать?

Да, именно такой подход планирую. В стандартной прошивке прошит стандартный эффект, а любые варианты пользователь по мере необходимости загружает сам.
Плюс "всех вариантов в одной прошивке" в том, что переключение эффекта быстрое и без ущерба микроконтроллеру.
Минус - память не резиновая, и угодить на все предпочтения нереально, в итоге из нравящихся мне эффектов (занимающих память!) другим и выбрать нечего...
Плюс оверлейного варианта - количество эффектов неограничено, каждый из них может быть существенно сложноее по алгоритму, т.к. ему достается гораздо больше памяти.
Минус оверлеев - долгая загрузка, т.е. переключение эффектов занимает заметное время, а так же не очень большой ресурс перезаписи flash.

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

[aiwa]

Плюс "всех вариантов в одной прошивке" в том, что переключение эффекта быстрое и без ущерба микроконтроллеру.

Вы не совсем поняли. Я имел ввиду организацию дампа на карточке для подкачки.
Здесь два варианта: иметь все спецэффекты в одном "файле", или иметь кучу "файлов" с разнообразным набором эффектов.
В первом случае Вам по сути при перезаписи с карточки во флеш придется выполнить работу линкера. Этот случай более правильный и гибкий.

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

[adnega]

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

Это как? А адреса? А распределение ОЗУ?
Я в сообщении #13 привел пример исходников, которые можно собрать с известного адреса
и безболезненно с этого адреса грузить. Правда, придется под оверлей в основной программе
выделить ОЗУ и указатель на эту область сохранить во flash при загрузке оверлея.

[aiwa]

Это как? А адреса? А распределение ОЗУ?

ТС вначале упоминал, что блоки ОЗУ распределены для каждого оверлея и адреса этих блоков уже известны на этапе разработки.

[adnega]

ТС вначале упоминал, что блоки ОЗУ распределены для каждого оверлея и адреса этих блоков уже известны на этапе разработки.

Про ОЗУ ничего не было и вряд ли могло быть, т.к. расход ОЗУ уж очень индивидуальная вещь.
Да и размер ОЗУ у AVR крошечный.
А вот функции можно описать в таблице.

Но вопрос в том, как скомпилировать модуль!

Я готовый шаблон привел для avr-gcc.

[aiwa]

Перефразирую:
...
- нужно уметь запускать этот код и размещать данные по указанным доступным адресам/смещениям;
...

Мне казалось, что под размещающимися по указанным адресам данным как раз и подразумевается ОЗУ.

[adnega]

Мне казалось, что под размещающимися по указанным адресам данным как раз и подразумевается ОЗУ.

Да, но не так вольно. У основной программы есть свободное ОЗУ. При загрузке оверлея можно
узнать сколько именно ОЗУ ему требуется. Выделить в ОЗУ основной программы необходимый участок и передать
указатель на него оверлею.
Хотя, если в один момент времени может работать только один оверлей, то можно и фиксировано выделить определенное
число байт.

[aiwa]

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

Топикстартер поправит, если я неправильно понял: есть набор функций №1, №2, №3 ... и для их нужд заранее предопределены участки OЗУ.
Каждая из этих функций имеет несколько различных вариантов реализации (в теме - оверлеев), и каждый вариант может использовать только свою область ОЗУ (ну, естественно и ОЗУ стационарной программы).

[adnega]

и для их нужд заранее предопределены участки OЗУ.
Каждая из этих функций имеет несколько различных вариантов реализации (в теме - оверлеев), и каждый вариант может использовать только свою область ОЗУ (ну, естественно и ОЗУ стационарной программы).

Это значительно упрощает реализацию.

[ARV]

Отвечаю оптом всем, цитировать не очень удобно.
Идея такая: "основная программа" выделяет некий буфер, грубо говоря, все свободное ОЗУ за вычетом необходимого пространства стека и собственных нужд. Адрес этого буфера известен всем оверлеям на этапе разработки, т.е. в модуле оверлея это просто указатель на буфер ИЗВЕСТНОГО размера. Оверлей накладывает на этот указатель тип структуры собственных данных и работает с ними. таким образом, все оверлеи разделяют одну и ту же область памяти, никакого выделения/освобождения не требуется - только инициализация при старте оверлея.
Как вариант, каждый оверлей имеет функцию №1 init, которой передается адрес этого буфера, что принципиально ничего не меняет.
На счет того, что будет содержать в себе оверлей в плане эффектов цветомузыки, я еще до конца не решил - то ли один-единственный эффект, то ли некий набор... Принципиальным тут для меня является крайне небольшой ресурс перезаписей flash у МК AVR - гарантируется 1000 раз всего-то... Разумеется, буду продумывать механизм проверки имеющегося оверлея на карточке на загруженность, чтобы не переписывать понапрасну, но все равно, 1000 "переключений" режима цветомузыки - это как-то маловато...
Еще одна проблема, над решением которой придеттся думать, это необходимость передачи оверлею набора функций из основной программы, т.е. аналогично некоему BIOS, чтобы в каждом оверлее не тянуть одинаковые функции типа memcpy или иные, которые активно используются в цветомузыке...

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

[adnega]

Адрес этого буфера известен всем оверлеям на этапе разработки, т.е. в модуле оверлея это просто указатель на буфер ИЗВЕСТНОГО размера.

Это упрощает реализацию. Оверлей всегда один в памяти МК в один момент времени?

Еще одна проблема, над решением которой придеттся думать, это необходимость передачи оверлею набора функций из основной программы, т.е. аналогично некоему BIOS, чтобы в каждом оверлее не тянуть одинаковые функции типа memcpy или иные, которые активно используются в цветомузыке...

Это легко. Только должен быть определен набор этих функций и известны все типы.

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

Если переключать раз в неделю, то можно. Если с частотой 2 Гц, то исключено.
А вариант с Cortex-M не рассматриваете?

[VladislavS]

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

Не одобряем. Надо параметризовать эффект-автомат и придумать какой-нибудь упрощённый язык его программирования. Программу для него писать в виде обычного текстового файла и разрешить пользователям самим это делать.

[haker_fox]

Известно, что основная беда всех программ для МК AVR - это высокая трудоемкость модификации прошивки.

Добрый день! Я работал с AVR. Какая там высокая трудоёмкость модификации? Обычный микроконтроллер. А вот делать из него компьюте с возможностью выполнения программ с внешней памяти - та ещё трудоёмкость))) Мне кажется, если это нужно, возьмите более подходящий МК (что-нить на Cortex-M3/4 или на крайний случай M0). Они могут исполнять код из ОЗУ. А тут ужу простора для фантазии больше)

[_pv]

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

не, лучше интерпретатор запилить какой-нибудь: ulua, pawn, forth наконец, если так уж хочется менять выполняемые программы.

[VladislavS]

Мне кажется, если это нужно, возьмите более подходящий МК (что-нить на Cortex-M3/4 или на крайний случай M0). Они могут исполнять код из ОЗУ. А тут ужу простора для фантазии больше)

Тут тяжёлый случай.