[ARV 1]

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

Да, именно такой подход планирую. В стандартной прошивке прошит стандартный эффект, а любые варианты пользователь по мере необходимости загружает сам.

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

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

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

Минус оверлеев - долгая загрузка, т.е. переключение эффектов занимает заметное время, а так же не очень большой ресурс перезаписи flash.

 

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

[aiwa 0]

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

 

Вы не совсем поняли. Я имел ввиду организацию дампа на карточке для подкачки.

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

В первом случае Вам по сути при перезаписи с карточки во флеш придется выполнить работу линкера. Этот случай более правильный и гибкий.

 

Второй случай: Вы прописываете файлы с предопределенной комбинацией эффектов.

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

Но головняк будет с созданием набора таких дампов и с увеличением количества эффектов он будет несоизмеримо возрастать.

 

 

 

[adnega 11]

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

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

Я в сообщении #13 привел пример исходников, которые можно собрать с известного адреса

и безболезненно с этого адреса грузить. Правда, придется под оверлей в основной программе

выделить ОЗУ и указатель на эту область сохранить во flash при загрузке оверлея.

[aiwa 0]

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

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

 

 

 

 

[adnega 11]

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

Про ОЗУ ничего не было и вряд ли могло быть, т.к. расход ОЗУ уж очень индивидуальная вещь.

Да и размер ОЗУ у AVR крошечный.

А вот функции можно описать в таблице.

 

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

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

[aiwa 0]

Перефразирую:

...

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

...

 

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

 

 

 

[adnega 11]

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

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

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

указатель на него оверлею.

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

число байт.

[aiwa 0]

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

 

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

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

 

 

 

[adnega 11]

и для их нужд заранее предопределены участки OЗУ.

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

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

[ARV 1]

Отвечаю оптом всем, цитировать не очень удобно.

Идея такая: "основная программа" выделяет некий буфер, грубо говоря, все свободное ОЗУ за вычетом необходимого пространства стека и собственных нужд. Адрес этого буфера известен всем оверлеям на этапе разработки, т.е. в модуле оверлея это просто указатель на буфер ИЗВЕСТНОГО размера. Оверлей накладывает на этот указатель тип структуры собственных данных и работает с ними. таким образом, все оверлеи разделяют одну и ту же область памяти, никакого выделения/освобождения не требуется - только инициализация при старте оверлея.

Как вариант, каждый оверлей имеет функцию №1 init, которой передается адрес этого буфера, что принципиально ничего не меняет.

На счет того, что будет содержать в себе оверлей в плане эффектов цветомузыки, я еще до конца не решил - то ли один-единственный эффект, то ли некий набор... Принципиальным тут для меня является крайне небольшой ресурс перезаписей flash у МК AVR - гарантируется 1000 раз всего-то... Разумеется, буду продумывать механизм проверки имеющегося оверлея на карточке на загруженность, чтобы не переписывать понапрасну, но все равно, 1000 "переключений" режима цветомузыки - это как-то маловато...

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

 

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

[adnega 11]

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

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

 

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

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

 

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

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

А вариант с Cortex-M не рассматриваете?

[VladislavS 39]

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

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

[haker_fox 61]

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

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

[_pv 79]

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

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

[VladislavS 39]

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

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