Ленивые размышления... В котуинке ассемблер дает доступ к любому желанию (адресное пространство и независимая компиляция программ, каждого модуля в свою область с последующим использованием взаимных ресурсов)... К примеру функционал из биоса может быть использован любой из подгружаемых программ для расширения нужд той подгружаемой программы... А вот как такой же вариант под СИ и в АВРках провернуть? Да еще и под адуриньим СИ, в коем листинг по умолчанию не делается (есть возможность только hex файл для загрузки из программатора получить)... Собственно... Делается базовая программа ввода/вывода, индикации и собственного загрузчика определенной области свободного ПЗУ ("биос")... Далее отдельно компилируется прикладная программа, которая может использовать часть функционала того "биоса" в своих нуждах. Но размещение этой прикладной программки должно быть выполнено в области "свободного ПЗУ" МК (загрузчиком "биоса")... Как бы вот такое под СИ (тем более ардуино-варианте) исполнить? 1. Нужно получить адреса конкретного размещения функций в "биос" МК для их дальнейшего использования в модуле прикладной программы (желательно без опоры на листинг). 2. как при компиляции прикладной программы задать конкретный начальный адрес размещения кода? И третье - а как быть с ОЗУ, чтоб области, используемые "биос" и прикладной программой не "наехали" друг на друга? (программы пишутся и компилируются РАЗДЕЛЬНО друг от друга) Это же СИ, а не ассемблер, в котором "все просто решается"... (работу встроенного в "биос" загрузчика пока не трогаем) Вобшчемсс... Как то такие глуповопросы лениво посещают...
Нужно получить адреса конкретного размещения функций
Указатели на функции? Ведь в Си функции имеют вполне реальные адреса, и этот адрес можно получить через указатель на функцию, подобно как получается адрес переменной через указатель.
Если разговор идет о том, чтобы из хекс-файла получить адрес функции, то это только ручками, если дизассемблировать хекс и найти точку входа в функцию.
1. Нужно получить адреса конкретного размещения функций в "биос" МК для их дальнейшего использования в модуле прикладной программы (желательно без опоры на листинг).
В MS-DOS был INT 21h, а в регистре AH передавался номер функции. Из современного, в Pico есть ROM, потому что оттуда быстрее код выполняется, чем из внешнего флеша, и доступ к функциям получают следующим обоазом:
Код:
sf_clz_func = rom_func_lookup(ROM_FUNC_CLZ32);
Т.е. из таблицы по индексу, иначе в следующей версии "BIOS" адреса изменятся и придется перекомпилировать все модули.
(работу встроенного в "биос" загрузчика пока не трогаем)
А не мешало бы. Как вообще планируется на AVR модули подгружать? Там же из RAM код выполнять нельзя и самой RAM мало, внешнюю что ли прикручивать? Ну не прошивает же загрузчик модули во флеш? )
Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.
Для АВРок(ПИКовых) только загрузка во флэш ПЗУ... Однако там таки смутное дело с взаимосвязью двух (трёх, включая загрузчик) независимых программных модулей. Так что придётся пока этот вопрос "лениво отложить" до более чётко обозначенных "хотелок"...
Лень обуяла... Однако лежит на макетке символьный индикатор... ЖИРНЫЙ... https://img.radiokot.ru/files/20529/3j7oqqfki2.jpg Надо чегось придумать... или повторить ассемблерные Т9 из винной с гибридом К145... начну-ка с издевок над кнопами... вот под таку извратну схему https://img.radiokot.ru/files/20529/3lskuak1gs.GIF просто в старой макетке приходится резервировать аппаратный I2C (на том разъёме раньше мехкнопы стояли) да еще изврат с запуском сканера по прерыванию (скорее в реале движковый выключатель клавиатуры будет - по опыту эксплуатации с емкостными кнопами штука нужная...) Пока что "грязновик" сканера кноп вот так выглядит:
Вариант: подключаете ЖК-дисплей к одному PCF8574. Подключаете кнопки на другой PCF8574 по другому I2C адресу. Без сканирования кнопки в loop, а чтения - по прерыванием после изменения состояния PCF пина INT. Антидресбег не аппаратной (RS-тригер) а легко реализовать можно с чтения/паузы/чтения или нескольких последовательных чтений одно за другим. Возможно и LEDs к третьему PCF. Так будет много неиспользованных пинов для других приложений .
Почему макетная плата? Напр. на пластиковом бредборде соединения остаются достаточно стабильными месяцами. И даже годом . А менять конфигурацию можно непрерывно и очень быстро во времени: от идеи, через реализацию до успешного теста, от напр. 5 минут на занятия с МК в день, до напр. месяцев, с добавлением, напр. что-то каждый день. Потом рисуете схему, реализуете по другой монтаж.
Внешний регистр увеличивает время обработки и объём монтажа. В данном случае это не важно - подчищается вариант обработки кнопок, пригодный для работ с менюшечными пиктограммами. При условии, что у каждого из возможных автономных программных модулей самоделки свои субменюшки. В К145 слишком сложно получилось, да и селектор однократное нажатие/многократное исполнение при удержании плюс контроль "залипания" и "длительного простоя без нажатий" неплохо встроился. В остальном тот же принцип селектора по считанной комбинации и указателям на функции, изменяющими содержимое согласно задач, определяемых текущим программным модулем "устройства". Относительно макета - так леньки чего то дополнительно лепить всего лишь для проверки предположений и черновиков - использую то железо, что ранее сделано было.
Так в папке проекта те файлики находятся. Собственно пока черновик - пара файликов внутри проекта - удобнее редактировать и тесты добавлять. Ежли с основой кнопок все полностью ясно, то с дисплеем заметно потуманнее - в старой версии у меня был сдвиг экрана с сохранением работы использующего "теневой"(скрытый на время) экран. Но то ассемблер... А теперь надо или к правилам LiquidCrystal приспосабливаться или добавку ввода символов в произвольный адрес ОЗУ индикатора дошкарябать... Вобщем - стадия раздуми...
ФЫРШШ... Хороши обновления...НО... Из-за наличия огромадного количества мелких файлов (практически во все комплекты, включая 13ю тиньку, включен и urboot) обновление на USBфлешке может длиться до 3 часов!! Вобшчемссс на жесткий диск и/или SSD в ПК вполне себе шустренько обновляется, но на USBфлешке или при обновлении или при копировании представляет заметное "замедление", которое при некоторых условиях нервозности в ожидании завершения может привести к гибели флешки (попытки досрочного завершения работы программы установки). Имеем этот нюенс ввиду...
Ленюшшкиии.... Но таки возня с консолью ввода (четыре-пяток кноп)и вывода (дисплейчик на 1602) потихонечку продвигается. Скелетик базовый с простокнопами и пиктографическими менюшками таки продвинулся аж до простого теста базовой концепции. Теперь можно передохнуть, распечаточку соорудить да проанализировать чего еще замутить можно. И потихонечку несколько реальных прикладных модулей в тест дошкарябать... Собственно схемка теста https://img.radiokot.ru/files/20529/3mbgfvussy.GIF и прожка
сперва заставка и вывод в терминалку ПК сообщений с названием нажатой кнопы... при нажатии на + (UP) происходит перескок в пробный тест пиктограммной строки. Цифирки с курсором под оными работают с декрементом/инкрементом, курсор под F возвращает в предыдущее состояние (заставку и функционал при включении питания). И так "по кругу". Простой тест однако.Варианты уточнения/расширения не исключаются, но то уже под конкретику самоделок будет подгоняться.
Добавил чуток комментария насчет защит от повторного самовызова при активации консоли в случае длительного удержания кнопки. Это на случай, если в обеих консолях кнопка является и вызовом следующей в одной и возвратом в предыдущую в другой (чего таки предпочтительно по возможности избегать). И там же тестовые строчки для консоли ПК (тест-проверка) с демонстрацией разницы меду сработкой функции активации консоли (однократно) и фокус-возможностей у кнопки при продолжительном нажатии (печатается имя кнопы, пока ее не отпустить) с объяснением в описании функционала кнопки. Тот фокус для особых извратов...
Собственно это уже "максимально готовый" концепт скелета мультименю из консолей ввода/вывода для многофункциональных железяк. Возможность модификаций как по количеству клавиш, так и по смысловой структуре размещения данных на "стандартном" двустрочнике типа 1602 и стандартных адуриньих библиотек (без использования "теневой" части ОЗУ дисплея и сдвига панелей мало ли какая начинка в дисплейчиках попасться может - а этот вариант без излишеств в любом случае работать будет). Собственно самих консолей и уровней вложения также может быть достаточно много - лишь бы места в ПЗУ хватало, да ресурсов для оставшихся активно работающими программных модулей "устройств". Пока положу в запас для возможных в будущем всякоподелок. Можно малость и подремать...
Очередной "подарочек проХЕРеса"... Касается неприятных сюрпризов от ардуиноIDE версии 1.8.19... Ранее нечто подобное коснулось старой 1.8.9. Однако у 1.8.9 ограничения заметно большие. И так... Версия 1.8.19 работает под 7 кой/10кой, для ХР не допустима (более навороченная). Свежий выявленный ФАК: После обновления платформ Raspberry Pi Pico RP2040 выше 4.1.0 STM32 от STmicroelectronics выше 2.1.0 ESP32 от espressif systems выше 3.1.0 возможно и некоторых других, кроме "простой классики АВР(пока еще)" - не проверял все возможные по перечню, отмечено блокирование СОМ портового интерфейса... Для устранения достаточно отката на более ранние версии. Как профилактика рекомендуется отключать автоматическое обновление ардуиноIDE для версий 1.89 и 1.8.19. Частный случай для подобной ситуации - внезапно пропадающая возможность прошивки "стандартных" АВРок (нанки или про-мини). СОМ порт или не выбирается или невозможно сменить. ФАК пакостен тем, что причина явно не просматривается - компиляция проводится без замечаний, а работа прошивалки для нанки уж никак не ассоциируется с STM/ESP или RP2040 платформами.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 26
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
.
