jcxz

ТС сразу написал, что ему нужны 32-битные приложения. Так что - причём тут 64 бита? А насчёт инсталляции: Неужто кто-то ставит онлайн??? Всегда ставлю оффлайн и VS2005 и VS2008.

В гугле вас забанили? Ввёл в гугл "vs2005 iso" и первые же две ссылки из выдачи: https://archive.org/download/microsoft-visual-studio-2005-professional-edition-disc-1 https://archive.org/download/microsoft-visual-studio-2005-msdn-library-disc-2_202103

Не понял вопроса... Какие нужно, такие и ставьте. Нужен си - ставьте си.

Если цель - простое, к тому же консольное 32-битное приложение, то зачем тащить этих современных монстров??? На win7 для написания простых (и не очень) GUI-приложений успешно использую VS2005 и VS2008 (во втором чуть больше возможностей, но в 90% случаев хватает первого). Чего и вам советую для консольного приложения. И exe-шник будет раз в 10 меньше, чем от современных монстров.

Не выдумывайте. В исходном сообщении ничего про "QT в микроконтроллерах" не было. PS: Не понимаю - чего так все возбудились? Требования вполне нормальные, адекватные. Я например тоже - разрабатываю код для Cortex-M и использую QT. На ПК! Утилиты для отладки и настройки разрабатываемого оборудования. Причём тут "QT на микроконтроллерах" то???

А почему бы нет? Если у ТС-а 32 мотора, то кто мешает сперва всем сразу заслать новую прошивку, а потом по-очередно давать команды каждому контроллеру "обновить прошивку". Очередной обновил и стартанул - даём следующему. Если 32 тянут нагрузку, то какое-то время и без одного, в-31-однером справятся. И можно обновляться прямо "на лету". В прямом смысле слова.

Такое делается во всех нормальных компиляторах через встроенные макросы. Кейл не пользую, но и в IAR и в VisualStudio это есть. Наверняка в Кейл тоже должно быть. В IAR например такой макрос: $PROJ_DIR$ - указывает на папку текущего проекта. И можно хоть на одном компе в разных местах открывать несколько копий одного - мешать друг другу не будут. В VS аналогичное выглядит как: $(IntDir), $(OutDir), etc. Указывать абсолютный путь конечно - глупость.

Зачем контроллер? Просто выделяете в своём же контроллере 2 интерфейса: один для приёма прошивки, другой - для передачи её дальше. А можно сделать это и на одном интерфейсе (UART, ШИМ, etc.), если использовать его в симплексном режиме. Контроллер принимает прошивку, сохраняет её себе и передаёт дальше. И обновляется затем. Лучше конечно - посредством бутлоадера. Чтобы не окирпичиться если что-то пойдёт не так. PS: Кроме того - есть ещё топология "кольцо". Которую часто применяли раньше, но сейчас про неё почему-то все забыли. Тоже потребует только одного интерфейса. И на приём и на передачу дальше. От ESP пустить кольцо на одном UART-е или ШИМ-е. И прошить все разом.

Сделайте просто daisy-chain и все дела. На любом свободном интерфейсе. Я бы дважды подумал, прежде чем лепить такое. Посмотрите на нагрузочную способность - потянут ли выходные драйверы 32 нагрузки в-параллель? Плюс - подтяжки да общая ёмкость такого дерева проводов. И сколько там будет гулять помех. Особенно когда рядом множество таких источников помех, как моторы с ШИМ.

Нет. Это время декремента + минимальное время перехода. Так как переменная часть времени перехода неизвестна, то я добавил в цикл множество команд STR. Чтобы минимизировать ошибку он неучтённой части времени перехода. Не помню. Но точно APB1 работает на макс. допустимой частоте. Я делал тест на скорую руку. По идее надо сравнить его время выполнения со временем записи в ту же самую периферию, но в не-bitband область. Попозже сделаю, проверю. Сейчас я далеко от STM32F103, а на XMC4xxx bitband-а нет.

Мощным относительно исходного 80188. Вроде как очевидно, не? Приведите пожалуйста ссылку на этот самый "Pixel buffer" в 80188. Или причём он здесь? Под "эмуляцией графики", я имел в виду эмуляцию графики рисуемой исходно 80188. Точно такое же, как приведённая вами игрушка к этой теме. Я их привёл как раз для демонстрации бессмысленности вашей ссылки на игрушки никак не относящиеся к 80188. Я это уже давно сделал. Попробуйте прочитать тему несколько сообщений выше. Я уже ранее приводил код эмуляции одной из самых тяжёлых для эмуляции команд 80188 на Cortex-M. Попробуйте посчитать сколько она занимает тактов на 80188 и сколько - её эмуляция на Cortex-M4/M7. И подумать.

PS: Протестил. Код: PUBLIC TestBB THUMB TestBB: LDR R2, =42220194h MRS R12, PRIMASK CPSID I MOVS R3, #100 MOVS R0, #0 MOVS R1, #1 TestBB_01: SUBS R3, R3, #1 STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] STR R0, [R2] STR R1, [R2] BNE TestBB_01 MSR PRIMASK, R12 BX LR На STM32F103VE выполняется из ОЗУ за 23790 тактов. Адрес 42220194h - это область bit-band GPIO. Получается, что одна STR занимает = (23790-2*100)/100/30 = ~7.86 тактов! Если адрес 42220194h заменить на адрес обычной ОЗУ, то выполнение длится уже всего = 5900 тактов. Т.е. одна STR = (5900-2*100)/100/30 = ~1.9 такта. Можно сделать вывод, что значительно большее время в первом случае - результат выполнения операций чтений-модификаций-записей "буфером записи".

Такое есть не только в STM32, но и во множестве других МК. И не только для GPIO, но и для многих других регистров периферии. Вроде как не во всех МК bit-band регион-ы покрывают всю периферию и ОЗУ. Не знаю как именно там реализовано, но вряд-ли это чтение-модификация-запись через ядро. Проверил сейчас на STM32F103VE: запись в bit-band регион занимает == 1 такт (по показаниям J-Link). Либо в пакете записи, отправляемом по шине к контроллеру ОЗУ, указывается сразу и битовая маска; либо это всё-таки "чтение-модификация-запись", но каким-то образом укладывающаяся в 1 такт. Например: саму операцию "чтение-модификация-запись" может выполнять "буфер записи", через который идёт запись в ОЗУ. А "буфер записи" может работать частично параллельно с выполнением инструкций. Ещё как вариант: На время bit-band "чтение-модификация-запись" ядру может выставляться halt-сигнал, и поэтому счётчик тактов не инкрементируются, хотя в реале вся операция занимает несколько тактов. PS: Тоже ранее уже задумывался не раз над этим вопросом (о реальной длительности и механизме bit-band), но всё никак не доходят руки разгуглить этот момент..... PPS: Склоняюсь скорее к тому, что запись в bit-band регион - это функция "write buffer"-а.

К чему эта сентенция? Ваша исходная игрушка работала на 80188? (посмотрите на заголовок темы) Если да, то почти 100%-но не составит труда запустить её в режиме эмуляции на современном, достаточно мощном CPU. Потому как эмуляция графики - это будет (скорее всего) как раз самая простая из задач эмуляции периферии. Проще только эмуляция собственно выполнения команд CPU. Если она работала не на 80188 (или чём-то подобном), то тогда какое она имеет отношение к обсуждаемой теме? Я могу привести ссылки на ресурсы с сотнями игрушек для старых ПК, которые прекрасно работают на современных ПК в режиме эмуляции. Код которых выполняется в режиме интерпретатора на современном CPU. Вот например: http://caglrc.cc/scalar/categories/all/ Это - достаточное доказательство реализуемости задачи в режиме эмуляции?

Не очень понятно - о каких "релокейшенах" речь? DOS-овский EXE-файл, насколько помню - мог содержать описания нескольких сегментов (в отличие от COM). Которые ОС грузила в память как ей удобно. И настройку (релокацию) ОС проводила только сегментных адресов. И описаны все эти сегменты были конечно в заголовке EXE. А где же иначе? И в COM думаю можно было преобразовать только такой EXE, общий размер сегментов которого не превышал 64КБ. PS: И кстати - не вижу никакой проблемы преобразовать EXE-файл DOS-формата в .bin для МК. Просто нужно выполнить ту работу, которую делает DOS при старте EXE. Скорее всего существововали готовые инструменты для МК на ядре x86, которые умели прожёвывать EXE-формат: или транслировать в что-то своё и потом прошивать в МК; или напрямую - выполнять работу ОС для EXE-файла при каждом старте МК.