Пруф:BOB51 писал(а):Линкер у ассемблера АВР?
это для ПИК, MCS51 (только не в варианте атмелевского c51asm!!!) линкер отдельной единицей и с некоторым описанием имеется.
В типовой авр-студии сей компонент иначе как "по умолчанию" не используется.
Может там чего в вариациях с СИ - эта область мне неведома.
c51asm.exe к примеруptr128 писал(а):...
Мне не ведомы случаи, когда ассемблер генерит сразу HEX для загрузки. Задача ассемблера сформировать объектный файл для компоновщика....
Это вы учитесь читать. Вопрос был не про сам аппаратный SPI, а о его примении с нестандартной реализацией SPI в ST7735:BOB51 писал(а):А к чему тогда вообще вопрос задавать, если в Вашем примере ИСКЛЮЧИТЕЛЬНО АППАРАТНЫЙ SPI используется?
Учите матчасть...
Я не утверждал, что таких нет. Я утверждал, что мне не ведомы. Может быть потому, что пользоваться ассемблером, формирующим только не перемещаемые объектные файлы я не хочу и не буду )BOB51 писал(а):c51asm.exe к примеруptr128 писал(а):...
Мне не ведомы случаи, когда ассемблер генерит сразу HEX для загрузки.
Да и тот же авр ассемблер из самой студии...
Похоже и впрямь, наиболее разумное решение. Спасибо!uk8amk писал(а): 1. Создать несколько вариантов функций обмена данных по числу портов.
Мне не жалко и все открытым оставлять. Меня смущает время сборки всего барахла из исходников.uk8amk писал(а): 2. uint8_t st7735_spi_send_byte(uint8_t data, uint8_t status)
оставить открытыми.
Тогда Ваше утверждени к любому коду на МК относиться ))) Софистика...BOB51 писал(а):Тогда это уже "гибрид" аппаратного модуля и программной "доработки" - по факту программный вариант исполнения.
Правильно. Есть рабочий код, который полностью удовлетворяет выставленным к нему условиям, но плохо приспособленный для публикации и не приспособленный к использованию в виде статической библиотеки. И я хочу решить именно озвученные вопросы, а не как полностью переписать с "невозможным ногодрыгом" уже рабочий код, только для удовлетворения последних двух озвученных условий.BOB51 писал(а): Ибо разговоры о "невозможном" ногодрыге при опоре на аппаратный функционал есть... как бы подипломатичнее...
Ведь для обсуждения выставлена не конкретная схема, а вопрос возможности проведения операций в принципе.
А "в принципе" - вполне и побитовая ШИМ манипуляция на высоких скоростях получается.
Вы сами себя хоть слышите ? Чем мой ответ - не ответ на Ваш вопрос ?Вопрос был:
"Как понятно для того, кто будет использовать твою библиотеку, подменять, например, номера битов операнда в конкретных машинных командах, в зависимости от желаний пользователя?"
А лишняя демагогия возникла как раз когда Вы написали "Как вариант - таблица с масками + лог. операции."
В себе проблему нужно искать, в первую очередь, а не в тех, кто Вас не понимает.Так что, ставьте правильно задачу, чтобы Вас понимали и не разводили лишних демагогий.
Воть как раз и ошибка - указанные компиляторы вполне успешно работают с перемещаемыми блоками.ptr128 писал(а):...
Я не утверждал, что таких нет. Я утверждал, что мне не ведомы. Может быть потому, что пользоваться ассемблером, формирующим только не перемещаемые объектные файлы я не хочу и не буду )
Вот только ручной компоновки кода мне не хватало еще )
А Вы себя слышите? На вопрос о том, как подменить номера битов в операнде команды Вы предлагаете от команд работы с битами отказаться.Аlex писал(а):Вы сами себя хоть слышите ? Чем мой ответ - не ответ на Ваш вопрос ?Вопрос был:
"Как понятно для того, кто будет использовать твою библиотеку, подменять, например, номера битов операнда в конкретных машинных командах, в зависимости от желаний пользователя?"
А лишняя демагогия возникла как раз когда Вы написали "Как вариант - таблица с масками + лог. операции."
Вам не кажется, что перемещаемые блоки в исходном коде и перемещаемые объектные файлы - это совершенно различные понятия?BOB51 писал(а):Воть как раз и ошибка - указанные компиляторы вполне успешно работают с перемещаемыми блоками.ptr128 писал(а):...
перемещаемые объектные файлы
Зависит от приоритетов. Ухудшать параметры производительности алгоритма я не намерен категорически. О чем уже писал не раз.BOB51 писал(а):Вполне логичное решение - сменить алгоритм для улучшения его функций и транспортабельности.
Жаль мне Вас, если вы не понимаете разницу между тремя совершенно различными вещами:BOB51 писал(а): Так это МИКРОКОНТРОЛЛЕРЫ, а в них перемещаемых *.hex прошивок (т.е одинаково прошиваемых в разные адресные участки ПЗУ) просто не бывает в принципе.
Тут каждая прошивка существует только для своей области адресов. Так что от перекомпиляции при изменении содержимого исходника уйти вряд-ли удастся.
Беда с этим началом в том, что с ним получается 17 тактов. На один такт больше, чем у меня есть. Потому так и не хочу. 13% потери в скорости (пропуск одного такта SPI) для меня много.BOB51 писал(а): воть собственно Ваше весьма здравое начало:
А это именно то, что и предложил uk8amk, за что и получил от меня "спасибо" )BOB51 писал(а):Тогда с потерей объёма ПЗУ и некоторой переделкой алгоритма - пишем несколько вариантов с жестким указанием того порта, а выборку текущего варианта выполняем условным векторным переходом по указателю - ijmp/icall.
Принцип подобно вот такому алгоритму http://radiokot.ru/forum/viewtopic.php? ... 7#p2858887
Вы, боюсь, будете смеятся, но задача на одной Ардуино сделать пример игры типа Арканоид детям, для дальнейшего изучения и развития. Попытка реализовать даже просто движение спрайта на стандартных библиотеках с треском провалилась. FPS в интервале 10-20 для игрушки не приемлем и читать фреймбуфер эти библиотеки не позволяют. А после переписывания и работы с SPI и работы с ST7735 я минимальный FPS получил почти 25. А сам спрайт могу гонять с FPS более сотни. На видео выше спрайт летает с задержкой по 2 миллисекунды между перемещениями. Причем в этом примере реализованы перемещения только по горизонтали и вертикали. Если добавить еще и диагональное перемещение, то задержку надо будет увеличивать.BOB51 писал(а):параллельно с аппаратным исполнением приема/передачи при ведущем МК?
Задача скорее методическая, чем практическая. Дети не раз жаловались, на то, какая Ардуино медленная. И когда я отвечал, что проблема не в Ардуино, а в коде, веры в глазах не видел. Но уже этот недоделаный пример оказал огромное влияние на детское восприятие возможностей 8-мибитного МК. Появилось желание учиться писать эффективные программы. Хочется зафиксировать результат )BOB51 писал(а):Тогда может лучше перейти к варианту "мозги + видеокарта" на основе пары МК, каждый из которых выполняет собственную задачу?
