Перейти к содержанию

    

ARV

Свой
  • Публикаций

    1 143
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о ARV

  • Звание
    Профессионал
  • День рождения 30.03.1968

Контакты

  • Сайт
    http://arv.radioliga.com
  • ICQ
    252391897

Информация

  • Город
    Новочеркасск

Посетители профиля

3 389 просмотров профиля
  1. Проще всего не делать ничего - это факт, с которым не поспоришь. Чуть более сложно запилить цветомузыку на компьютере - для этого вообще ничего программировать не надо, полным полно готового - только лампочки подключи. Я сильно удивлен, что этих советов никто не дал. Что касается текстового языка и возможности пользователю самостоятельно создавать эффекты - это уже реализовано, только эффекты не цветомузыкальные, а обычные, т.е. не связаны с музыкой от слова никак. И, кстати, не сильно заинтересовались пользователи... Т.к. при описании эффектов думать надо. Более сложные интерпретаторы, увы, реализовать невозможно в рамках поставленной задачи. И поэтому пока что описанный мной метод оверлеев - единственный вариант обеспечить настоящее многообразие с минимальными усилиями конечного пользователя.
  2. Отвечаю оптом всем, цитировать не очень удобно. Идея такая: "основная программа" выделяет некий буфер, грубо говоря, все свободное ОЗУ за вычетом необходимого пространства стека и собственных нужд. Адрес этого буфера известен всем оверлеям на этапе разработки, т.е. в модуле оверлея это просто указатель на буфер ИЗВЕСТНОГО размера. Оверлей накладывает на этот указатель тип структуры собственных данных и работает с ними. таким образом, все оверлеи разделяют одну и ту же область памяти, никакого выделения/освобождения не требуется - только инициализация при старте оверлея. Как вариант, каждый оверлей имеет функцию №1 init, которой передается адрес этого буфера, что принципиально ничего не меняет. На счет того, что будет содержать в себе оверлей в плане эффектов цветомузыки, я еще до конца не решил - то ли один-единственный эффект, то ли некий набор... Принципиальным тут для меня является крайне небольшой ресурс перезаписей flash у МК AVR - гарантируется 1000 раз всего-то... Разумеется, буду продумывать механизм проверки имеющегося оверлея на карточке на загруженность, чтобы не переписывать понапрасну, но все равно, 1000 "переключений" режима цветомузыки - это как-то маловато... Еще одна проблема, над решением которой придеттся думать, это необходимость передачи оверлею набора функций из основной программы, т.е. аналогично некоему BIOS, чтобы в каждом оверлее не тянуть одинаковые функции типа memcpy или иные, которые активно используются в цветомузыке... Пока что все на этапе обдумывания, но, как я понял, принципиально идею оверлеев вы одобряете?
  3. Да, именно такой подход планирую. В стандартной прошивке прошит стандартный эффект, а любые варианты пользователь по мере необходимости загружает сам. Плюс "всех вариантов в одной прошивке" в том, что переключение эффекта быстрое и без ущерба микроконтроллеру. Минус - память не резиновая, и угодить на все предпочтения нереально, в итоге из нравящихся мне эффектов (занимающих память!) другим и выбрать нечего... Плюс оверлейного варианта - количество эффектов неограничено, каждый из них может быть существенно сложноее по алгоритму, т.к. ему достается гораздо больше памяти. Минус оверлеев - долгая загрузка, т.е. переключение эффектов занимает заметное время, а так же не очень большой ресурс перезаписи flash. Пока только вникаю в данные рекомендации и думаю о целесообразности... Пересилят ли плюсы минусы?
  4. Этого (загрузки по произвольным адресам) не требуется (пока). Я в скриптах, как уже писал, не силен, и ответов на заданные вопросы не знаю... надеюсь на помощь.
  5. Именно переписыванием flash. Но вопрос в том, как скомпилировать модуль! Для бутлоадера есть заготовки, известны ограничения и т.п. У меня цель немного отличается от бутлоадера, и поэтому я спрашиваю: как скомпилировать? просто модуль компилируется в файл с расширением .a - объектный файл. как указать компилятору (или чему?), что адрес таблицы функций должен быть строго таким-то? все функции тоже должны быть строго в определенной области адресов? как потом получить hex-? avr-gcc, никакого IAR, и предполагается не вылезать за пределы 64К flash
  6. Какие-то советы не совсем по теме вы даёте, коллеги :) Основной код модифицировать не нужно, он знает только номера функций в таблице оверлея и адрес этой таблицы, и обращается по ним. А все варианты оверлеев содержат в самом своём начале эту самую таблицу, ссылающуюся на собственные функции. Поэтому в одном оверлее условно 5-я функция цветомузыки может быть "красный на максимум", а в другом - "синий на минимум". И как бы настоящую линковку мне не надо повторять, и разбираться с ней особенно не стоит, как и с форматом elf-файла - не влезет его разбор в AVR, да и ни к чему... Мне бы просто понять, как при помощи AVR-GCC собрать модуль с функциями и таблицей, и как из него получить HEX для записи...
  7. Коллеги! Обращаюсь к знатокам за советом. Появилась идея сделать нечто, функционально напоминающее динамическую линковку для программ AVR. Раньше, когда DLL еще не изобрели, такое называлось "оверлейными модулями"... Известно, что основная беда всех программ для МК AVR - это высокая трудоемкость модификации прошивки. И вот предлагаемая идея призвана значительно улучшить эту ситуацию. Идея такая: 1. Основную программу собираем, как обычно. В ней есть интерфейс к SD-карте, и определена раз и навсегда область памяти, где будут оверлеи. Ну и выделен блок ОЗУ для данных оверлея. 2. Адреса начала кода оверлея и буфера данных фиксированы, и на этапе разработки оверлея известны. 3. Оверлей - это единственная функция, либо (предпочтительнее) несколько функций, адреса которых определены в структуре, которая как раз и размещается с адреса flash, выделенного для оверлея - ну типа таблицы векторов или вызовов. В общем, не суть важно, как. 4. Когда мы хотим наделить наше устройство другим функционалом, мы записываем на SD-карту скомпилированный оверлей, стартуем девайс, который обнаруживает соответствующий файл на карте, и прошивает его содержимое в заданную область, после чего обращается через таблицу вызовов к функциям оверлея. Лично я хочу попробовать задействовать этот функционал для модификаци своего проекта "цифровой цветомузыки": сейчас в коде намертво прошито несколько эффектов, сменить которые для рядового пользователя достаточно сложно, как и избавиться от не нужных. Планирую каждый эффект сделать в виде оверлея, чтобы каждый желающий выбрал себе нужные и использовал без геморроя с перекомпиляцией прошивки. Как оцените идею? Это не совсем ситуация с самопрошивкой через бут-область AVR, т.к. объем прошиваемой области предполагается не с нулевого адреса, а скорее с середины flash, и при этом с перезатиранием области бута, которая в конце, как правило. Очень похоже, но чуточку отличается... в связи с чем и вопросы: - как компилировать оверлей? То есть как получить hex-файл для набора функций? - как задать секцию (т.е. конкретный адрес начала функции) для функции я знаю, но как сделать это для целого модуля? тем более для модуля, содержащего как функции, так и данне во flash? я сильно-сильно плаваю в скриптах линковщика (а точнее - вообще тону), и хитрости makefile меня тоже скорее пугают, чем помогают... Мне бы как-то попроще, если это возможно...
  8. Цитата(sunjob @ May 3 2018, 22:04) недавно разбирался с avr-size, не заметил особенностей и вариаций раскажите подробнее об этом, если не сложноформаты вывода разные
  9. Цитата(k155la3 @ Apr 12 2018, 21:06) А как передатчик узнает, что ему надо передать инф. на приемник ? Есть ли обратный канал связи, от приемника на передатчик ? Есть: в приемнике есть газоразрядная импульсная лампа типа ИФК-120, она даёт вспышку, которая запускает передачу передатчика. У него есть фотодиоды, которые на эту вспышку реагируют. Никакой информации в сторону передатчика не передается, только один импульс.
  10. Только что проверил на всех имеющихся на сегодня дампах - при выбрасывании третьего с конца байта XOR двухбайтных слов всегда 0000! Предположение _pv полностью подтвердилось! Цитата(k155la3 @ Apr 12 2018, 17:07) А ТС стопроцентно уверен, что пакеты "проснифферены" без ошибок ? (проверить-то их пока невозможно без КС) ?Вы считаете, можно ошибиться в снятии протокола с выхода ИК-приемника типа TSOP при помощи логического анализатора? Снятый поток импульсов крайне удачно ложится на традиционный UART 4800 и более того, адрес в этом пакете на самом деле тот, который написан на транспондере, следовательно, протокол просниффен корректно Тут еще в голову одна мысль пришла... размер пакета 39 байт - какая-то странная цифра... чтобы предположение _pv работало, надо 1 байт выкидывать. Но 39 делится на 3 - буду пробовать трехбайтные XOR-ы в разных комбинациях. Есть в этом смысл по вашему мнению или я снова тупить начинаю? Набросал утилитку, XOR-ящую строку группами байт, осталось только выбирать нужные байты в строке...
  11. Идеи требуются. Но еще сильнее требуется какое-то обсуждение, потому что в одну голову думать - с ума сходишь, а толку ноль. А единомышленников нет вокруг _pv вон какое классное предложение произнес: все ТУПО! причем, если посмотреть, то 5-й байт есть XOR предыдущих 4-х. теперь логично предположить, что есть третий с конца байт - и дело в шляпе! тут уже и перебором можно взять приемник на измор лишь бы _pv оказался прав на всех пакетах всех транспондеров...
  12. Цитата(_pv @ Apr 12 2018, 14:44) последние два байта - тупо xor от первых 18ти 16ти битных слов золотой вы мой человек!!!! приду домой - прошерстю все накопленные массивы - это ведь будет просто счастье, если вы правы!!! я-то тупил на байте 12 перед 4-я последними - он всегда и во всех пакетах на одном и том же месте...
  13. Я хоть и в винде сижу, но свои 5 копеек в тему вставлю Пользуюсь Eclipse с его встроенными автогенераторами makefile. В настройках прописываю пути к разным версиям тулчейнов, и все прекрасно собирается. Беда только с тем, что утилита avr-size от версии к версии меняет свои свойства по умолчанию и команды в комстроке, в итоге иной раз не работает, либо выдает в неудобном виде. Эту проблему решил тупым копированием "удобной" версии во все версии тулчейна. Получилась в этом отношении каша, но все остальное достаточно удобно.
  14. Я умом понимаю сложность задачи... но надеюсь еще пока на успех. Не знаете какой-то софт, который бы позволял как-то автоматизировать хотя бы то, что вы посоветовали (а своих идей у меня тоже не мало)? Ну, например, быстро переводить HEX-строку в бинарный вид, инвертировать, XOR-ить и т.п. манипуляции делать? Основное время уходит именно на ручное преобразование и расписывание карандашиком... Для логического анализатора софт вроде как весьма помог, но почему разработчики этого софта не додумались делать "стек" захваченных сигналов, чтобы можно было визуально сравнивать "этот" и "тот" или "пред-предыдущий"? И экспорт тоже та еще беда: для одной программы надо строку в том виде, как я тут привожу, т.е. без префиксов 0x, а лог.анализатор пишет с префиксами, да еще в CSV-таблице... пока вручную переформатируешь... Я, конечно, что-то пописываю сам себе в помощь, но ведь на каждый случай утилитку писать тоже не самый оптимальный вариант по усилиям и срокам. Неужели ничего готового нет? Цитата(k155la3 @ Apr 12 2018, 13:27) Если ОН подразумевает шифрование (даже не пакета а только контрольного кода), то на мой взгляд разобраться не получится.Это, будучи в отрыве от реальности, безусловно верно. Но логическое размышление не находит причин, по которым идентификатор коровы должен передавать инфу о том, активно она жует или нет, в зашифрованном виде... Да и тот факт, что адрес передается полностью в "сыром" виде (правда, старшими байтами вперед), как-то с шифрованием уже не вяжется...
  15. Так там и нет изменения пары битов, там все 4 байта меняются. Цитата734F33656A 2000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 0199381C 734F33656A 4000 6C 7B7B7B7B7B7B7B7B7B7B7B000C0C0C0C0C0C0C0C0C0C0C0C000012 03D0387EXOR и суммирование я пробовал, естественно, но, т.к. вариантов много, либо не нашел правильный, либо это в принципе не то... Есть странная закономерность, но не могу понять, к чему она может привести: в последних 4 байтах всех пакетов одного и того же транспондера четные и нечетные байты слева направо связаны друг с другом. Поясняю примером ABCD - 4 последних байта. Так вот, любому значению байта А всегда будет соответствовать одно и то же значение байта C, а для В соответственно D. Но обратной связи нет, т.е. к одному и тому же байту С могут "приводить" разные байты А.