Давненько что-то не было публикаций… Нужно было собрать все в единое целое. Теперь все настройки подключения находятся в заголовочнике. И все варианты подключения находятся в одном архиве. Причем варианты уже не только подключения к amtege. Почти всё завелось и под STM32. Причем без всяких HAL и CMSIS. Библиотека требует один из заголовочников, но лишь для определения. На самом деле это намного проще. Есть регистры, есть их адреса, есть даташит (manual reference). А что еще надо. Но для запуска требуется включение тактирования SPI и вспомогательных пинов (Data Command и CS) в основной программе. Это проще сделать средствами HAL, через CubeMX. Просто у меня есть сомнения что еще и эту часть нужно вносить заголовочник. Потому как там набегает много если, с remap SPI на другие пины и пр. Но некоторые новые возможности, такие как анимированые (типа gif) изображения пока под STM32 работать не будут. Нужно запилить аналог millis(). А для подключения по GPIO, необходим еще и delay() для старта дисплея. Конечно же все это необходимо в том же виде что и подключение, через непосредственную адресацию. То есть пока всё едет на SPI, да и честно говоря и этой скорости более чем достаточно. И это еще реализация передачи без DMA. А использование DMA, это уже почти как двухядерная система. Пока ядро рассчитывает фигуру, DMA отправляет не маленький массив экранной памяти в SPI. Но тут надо еще подумать.
Сильно пока не углублялся, но в карте тактирования CubeMX не дает поднять скорость SPI выше 18Мбит, предлагает использовать предделитель. А когда значение предделителя становится выше самого минимального /2, SPI перестает работать. В то же время в структуре можно поднять множитель тактирования вплоть до 16, и SPI отлично работает.
Запуская один и тот же код на атмеге и на STM, визуально, судя по выполнению, скорость более чем в 4 раза выше. Но здесь ничего странного. А странность оказалась в размере кода. Размер инструкций STM32 Thumb2 16 и 32 разряда, против 16 разрядных у AVR, а размер одной и той же программы, на STM почти в 2 раза меньше. Но это конечно с включенной оптимизацией на размер, что потребовало установки атрибута запрета на транспортные функции и методы, работающие в цикле с регистрами МК. Что было ожидаемо.
Многое было дописано, добавлены семисегментные цифры в оконный режим, добавлена возможность объектам становится невидимыми. Пока в отсутствии возможности их удалять. Счетчики.. еще что-то… Всё это еще до НГ писалось. Запарно здесь другое, решил изменить метод Move_In_ Direction, теперь он в базовом классе и виртуальный, чтобы он одинаково «звучал» для всех объектов. Но теперь нужно изменить примеры где он используется. А может изменить на Move_In_Dir так более лаконично и достаточно понятно. Но если сейчас не изменю, в следующей версии опять примеры менять.
Грохнул счетчики, которые я писал когда только начинал писать на С++. Они мне давно не нравились, но работали шустро и они были в примерах. CubeIDE забрыкался на их реализацию, и более тянуть я не стал.
Хотел запустить изначально на 1921ВГ015, это RISC-V от НИИЭТ, но моя самоспаянная плата не завелась. Я решил что это не правильный маршрут движения и решил вернуться к изначально запланированному STM32.
Что по итогу. Крутится конечно оно реально быстрее. Другое дело, что где те проекты, в которых понадобится эта скорость? Если отложить все те, в которых идет видео ряд или большой поток данных, как в каком-нибудь коммутаторе, то у меня пока есть лишь один пример, это достаточно динамичный график, размерностью что-нибудь 256х256, чтобы удобно результаты масштабировать, и чтобы не микроскопическим был, и со скоростью обновления более 0.3 сек. Либо это изображение большого стрелочного индикатора, который хотелось бы чтобы двигался столь же плавно, как на экране смартфона.
Конечно я знал, что есть возможность привычный Arduino IDE раскачать, для работы с STM32, но я все же решил использовать официальные решения. И я был весьма удивлен теми решениями… Чтобы включить UART, я привык писать Serial.begin. А для настроек пина: pinMode. Но немного разобравшись, я понял причины их подхода. Во-первых можно переназначить выходы SPI, I2C и прочих модулей. Во-вторых модули имеют более широкие возможности, которые стало быть требуют настроек. Другое дело что мне это не надо. Особого труда не составляет написать свой Digital_Write. И Pin_Mode. На край можно просто обернуть что там HAL предлагает, Transmit чего-то там. Ехать так становится сразу намного удобнее, тем кто привык кататься на Ардуино :)
Примеров нет, будут позже.