ARV, кстати, а что вы имели ввиду под "подразумевающимися фичами" бесконечного цикла for(;;) ? Бесконечный цикл иногда удобная штука же.... У меня иногда получается, что проще выйти из бесконечного цикла через break, нежели возиться с флагом, который проверять потом в do {} while Правда, for(;;) для бесконечности никогда не применяла... В основном while(1) {}
а вас не удивляет, что for(;;) - это бесконечный цикл, а while() - это ошибка синтаксиса? т.е. пустой операнд ;; в условии цикла for трактуется, как true, в то время как пустой операнд в условии цикла while недопустим? это я и называю фичами стандарта, когда тут играем, тут не играем, а тут рыбу заворачивали... я такое не использую в целях гигиены.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
(тот же GCC хоть для аврстудио, хоть для адуринки) имеется множество заголовочных файлов описания ресурсов АВРок... Те же заголовочники *.h с теми же #define плюс редко, но встречающимися комментариями... Найдите там хоть один, нарушающий те правила, что я в самом начале указал (однострочный простой комментарий после #define до конца строки).
#define OCD 7 // The datasheet defines this but IMO it should be OCDR7.
То же саме в iom165p.h - строка 368
Да, я допускаю, что это исключение, поскольку я нашла такой дефайн только в трех файлах - два этих и еще в util\delay.h, строка 49:
Код:
#define F_CPU 1000000UL // 1 MHz
но оно там в блоке комментария, как пример.
Т.е. авторы заголовочников старались следовать самому старому стандарту, где // нету. Но в каком то месте провтыкали. И раз за все года это не поправили, значит проблем нету и оно работает. Или никто не компилит в режиме совместимости C89/C90...
Седьмая студия вообще то уже давно в "микрочип студио" превратилась. Но те монстры весьма избыточны и довольно тяжелы для простых компов по требуемым для нормальной работы ресурсам. Проекты с простым комментарием после #define работают, но лучше таки иметь перестраховку. Спокойнее будет насчет исключения теоретически вероятных ошибок. (Тех ошибок и без того в достатке попадается). Кстати... на один вариант проблем с "разнообразием стандартов" я уже нарвался при работе в ардуино IDE с МК от LGT... Похоже именно из за разнотипных подходов к написанию от разработчиков. Ранее уже тут обсуждался сей момент - но тогда особо никто внимания не обратил... (viewtopic.php?p=4766580#p4766580) пришлось самому "методом научного тыка" исправлять... Не факт, что правильно, но таки работает (образец с другой платформы списал)...
Простое очередное обновление превращает атмел студии в микрочипов. Обновление, а не скачивание. Это еще до "всяко блокировок" - позже обновления уже не выполнялись. А сегодня и ардуино уже "недоступно" (если без "ухищрений").
BOB51, 1. не вижу смысла обновлять, оно и так работает. Равно как и десятка винда с продленными на 4 года обновлениями. 2. про недоступность - мое мнение не будет совпадать с мнением администрации, поэтому промолчу. Мне - доступно.
Обновления добавили новые семейства МК. Но смысла при отсутствии таковых в наличии особо нету. Касательно доступности - речь о доступе без всяких заморочек. Остальное не считается (хотя и существует) . В микрочип студии похоже постарались от GCC уйти в пользу микрощипьего варианта... А для пенсионной забавки мне и старой 4.19 да АВРкиных платформ в ардуино 1.8.19 достаточно.
Пока делать нечего слепил из подручных средств полевичек "нижнего ключа" для прикладных адуриньих тестов... Спойлер Что то много у народа вопросов на данную тему, а конкретно перепроверить особо нечем ...
Там просто очепятка. Вместо y=cube(x) должно быть y=cube(3) очепятки и от "цензуры" порой специально вводили - чтоб самообразованием народ не мог заниматься и шпионы не разобрались.
ОЧЕРЕДНЫЕ ПЕЧАЛЬНЫЕ РАЗМЫШЛЕНИЯ НА ТЕМУ АРДУИНО ... Навеяно этими темами: viewtopic.php?f=66&t=200578 и больше этой viewtopic.php?f=66&t=200625 Ранее для АВР платформ при загрузке через программатор (по SPI) было принято, что прошивка фузов и бутлоадера идет при запуске "инструменты -> записать загрузчик" А прошивка программ делается при "скетч -> загрузить через программатор"... Однако при разборе случая с аттини13 под платформой MicroCore v2.5.1 от MCUdude появилось нечто новое и неожиданное... Выполнение опции "инструменты -> записать загрузчик" вызывает вот такую ошибку: Спойлер
Код:
D:\Arduino\portable\packages\MicroCore\tools\avrdude\8.0-arduino.1/bin/avrdude -CD:\Arduino\portable\packages\MicroCore\tools\avrdude\8.0-arduino.1/etc/avrdude.conf -v -pattiny13a -cstk500v1 -B32 -PCOM5 -b19200 -e -Ulock:w:0xff:m -Uhfuse:w:0xfb:m -Ulfuse:w:0b00111010:m Avrdude version 8.0-arduino.1 Copyright see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is D:\Arduino\portable\packages\MicroCore\tools\avrdude\8.0-arduino.1\etc\avrdude.conf
Using port : COM5 Using programmer : stk500v1 Setting baud rate : 19200 Setting bit clk period: 32.0 us
Error: cannot get into sync Error: cannot set Parm_STK_SCK_DURATION Error: unable to open port COM5 for programmer stk500v1
Avrdude done. Thank you. Ошибка при записи загрузчика.
Это при условии, что программатор ардуиноISP подключен к ПК и правильно определен как СОМ5 В то же время, и при сохранении того же подключения, выполнение опции "скетч -> загрузить через программатор" мало того, что прекрасно выполняется, так еще и содержит добавку в виде записи фуз битов для заданной в проекте конфигурации МК!... Вот такой отчет IDE: Спойлер
Код:
Скетч использует 704 байт (68%) памяти устройства. Всего доступно 1024 байт. Глобальные переменные используют 18 байт (28%) динамической памяти, оставляя 46 байт для локальных переменных. Максимум: 64 байт. D:\Arduino\portable\packages\MicroCore\tools\avrdude\8.0-arduino.1/bin/avrdude -CD:\Arduino\portable\packages\MicroCore\tools\avrdude\8.0-arduino.1/etc/avrdude.conf -v -pattiny13a -cstk500v1 -PCOM5 -b19200 -Uhfuse:w:0xfb:m -Ulfuse:w:0b00111010:m -Uflash:w:C:\Users\9532~1\AppData\Local\Temp\arduino_build_595068/tn13gat.ino.hex:i Avrdude version 8.0-arduino.1 Copyright see https://github.com/avrdudes/avrdude/blob/main/AUTHORS
System wide configuration file is D:\Arduino\portable\packages\MicroCore\tools\avrdude\8.0-arduino.1\etc\avrdude.conf
Using port : COM5 Using programmer : stk500v1 Setting baud rate : 19200 AVR part : ATtiny13A Programming modes : SPM, ISP, HVSP, debugWIRE Programmer type : STK500 Description : Atmel STK500 v1 HW Version : 2 FW Version : 1.18 Topcard : Unknown Vtarget : 0.0 V Varef : 0.0 V Oscillator : Off SCK period : 0.0 us XTAL frequency : 7.372800 MHz
AVR device initialized and ready to accept instructions Device signature = 1E 90 07 (ATtiny13, ATtiny13A) Auto-erasing chip as flash memory needs programming (-U flash:w:...) specify the -D option to disable this feature Erased chip
Processing -U hfuse:w:0xfb:m Reading 1 byte for hfuse from input file 0xfb in 1 section [0, 0] Writing 1 byte (0xFB) to hfuse, 1 byte written, 1 verified
Processing -U lfuse:w:0b00111010:m Reading 1 byte for lfuse from input file 0b00111010 in 1 section [0, 0] Writing 1 byte (0x3A) to lfuse, 1 byte written, 1 verified
Processing -U flash:w:C:\Users\9532~1\AppData\Local\Temp\arduino_build_595068/tn13gat.ino.hex:i Reading 704 bytes for flash from input file tn13gat.ino.hex in 1 section [0, 0x2bf]: 22 pages and 0 pad bytes Writing 704 bytes to flash Writing | ################################################## | 100% 1.44s Reading | ################################################## | 100% 0.59s 704 bytes of flash verified
Avrdude done. Thank you.
Причем одни платформы могут работать по старым правилам (та же DIY ATtiny версии 2023.4.19-gcc7.3 к примеру), а другие уже по новым - в зависимости от версий установленных в IDE платформ (и , вероятно, версий самой IDE)... Так что при работе через программатор по SPI необходимо быть весьма внимательным и осторожным... В вышеприведенном примере использовалась тестовая игрушка по схеме https://img.radiokot.ru/files/20529/3zktmtki1p.GIF и с этой программой Спойлер
Предложил одному котейкину проверить его предположение практикой viewtopic.php?p=4790174#p4790174 А в ответ -"... viewtopic.php?p=4790178#p4790178 "... К сожалению, давно не пишу для АВР, поэтому показать в сравнении на АВР не могу. Но могу привести пример для любимого многими нынче STM32 ..." Так любой вариант программы только на единой базе проверить можно. Тем более мне пока те АРМы особо не требовались. Может "не доросли задачи", а может отсутствие свободно-бесплатных компиляторов (включая ассемблер) для стародохлых ПК не слишком нравится. Плюс необходимость детального изучения огроменных даташитов (без практического приложения/применения). Разве что попробовал под адуринкой чуток да и забросил... Тудыть же и ESPшки - но у них другое - надо по сетевым технологиям и соответствующим компиляторам приличный объём перечитать (ежли чего своего нашкрябать, а не примерами баловаться). Да вот ещё: viewtopic.php?p=4790188#p4790188 Хотелось только замечание сделать: чтобы оценить результат работы с МК под ассемблером необходимо до мелочей знать документацию на тот МК и его систему команд. Ежли работу с компилятором (ассемблер и/или Си или еще какой ЯВУ) освоить достаточно легко, то изучение документации современных "систем на кристалле" при скоростях "устаревания" моделей/типов тех МК делает подход к работе под ассемблером практически весьма затратным. Работа с АРМ и "системами на кристалле" принуждает к переходу на различные варианты применения ЯВУ (языков высокого уровня). Но одновременно с тем и создает полную зависимость разработчика устройств от авторов сред разработки, что не всегда учитывается "на перспективу".
Последний раз редактировалось BOB51 Вт фев 17, 2026 19:47:14, всего редактировалось 1 раз.
А что я мог еще ответить, если я действительно НЕ пишу для АВР Последний раз, когда я держал АВР в руках, как раз примерно совпадает с годом вашей регистрации на этом форуме Ну и что вы от меня хотите то? Да, меня в то время тоже не очень обрадовали тысячестраничные доки на тогдашний STM32F100. Ну а че делать то, нужда заставила, напрягся и освоил. В прочем, я никого не заставляю и не убеждаю никуда переходить и менять привычное.
Добавлено after 4 minutes 12 seconds: Скетчи для Ардуины же никогда не были быстрыми, поскольку в них использовался максимально унифицированный подход, жертвуя производительностью ради единообразия и упрощения программной части.
Добавлено after 6 minutes 9 seconds: Поэтому при сравнении сгенерированного из Ардуино-скетчей асмового кода с асмом, написанным человеком, Ардуино-скетч будет проигрывать и в производительности, и в размере кода. Потому как написаны на Си неоптимально, избыточно. Это вы еще не бывали на форумах ардуинщиков. Вы бы смеялись от их проблем, как они, не понимая разницы между аппаратным и программным I2C, пытаются состыковать различные скетчи в один кусок, именуемый "программой"
Так там есть и проект GCC в авр студии... Но ежли у меня для АВРок ленивый пример - попробуйте у себя соответственно сделать и чистый ассемблер и СИ - только вот где для АРМов компилятор ассемблера "в чистом виде" раскопать... Все среды под минимум Си вроде ... Помимо того еще и заставлять изучать документацию в избыточном объёме (я что то не замечал проектов для АРМ под ассемблером - хотя бы для примера) как то это не в моем стиле... Но поскольку у нас разные базовые МК - смысл вступать в спор абсолютно теряется (зачем бы АРМовцу лезть в споры с оценками в тему с АВР?). Ардуино - всего лишь ИНСТРУМЕНТ (один из многих), коим просто надо корректно пользоваться.
Компилятор ассемблера уже встроен в среде разработки. Из стареньких и бесплатных можете поискать Atollic. Ранее это была официальная бесплатная среда разработки для АРМ. Позднее её перекупили ST Microelectronics, а затем трансформировали в новый продукт CubeIDE.
У меня подход к ассемблеру слишком старомодный. С другой стороны как раз именно ардуиноIDE может рассматриваться как наиболее удачное средство для работ с различными семействами МК. К сожалению с недавних пор сайт ардуино перешел в разряд "подсанкционных", что ограничивает перспективы использования определенным набором того, что можно хранить в архивной форме (с возможностью быстрого восстановления). Что будет более перспективным на будущее - предсказать довольно сложно (может простая палка-копалка к примеру ). Пока что наиболее удачны платформы на основе АВРок под ардуино IDE по представленному перечню МК, возможностям самостоятельного изготовления железа программатора и возможностям компилятора плюс широкая доступность в продаже. Опять же что будет дальше - удел шаманов. С меня на крайний случай и MCS51/INTEL8080/Z80 под ассемблером (с листочками бумаги и карандашиком в качестве компилятора) возможностей хватит (даже ежли другого не будет).
Ардуина попала под ссанкции? Хм. Походу, это уже наши тормозят. Есть немало примеров, когда доступ к безобидным материалам закрывают с нашей стороны по формальным признакам, находя какие-то древние и неактуальные материалы, в которых чето там "усматривают". Очень у нас уж любят всё запрещать из-за собственного страха. А что будет дальше - да и так примерно понятно, запретят всё забугорное (в первый раз чтоль?) и принудительно влепят какой-нить условный Миландр по цене десять тысяч шкурок енотов за штучку. И покупать разрешат только при наличии справки из комендатуры. Да у них уже несколько лет так и сделано.
Касательно затронутой темы Асм/Си. Сделал вот такой синтетический пример на Си. Вычисление среднего арифметического в массиве чисел. Функция Average() вызывает функцию Sum() для подсчета суммы элементов и этот результат делит на число элементов в массиве.
Спойлер
Код:
int Sum(int const* array, uint32_t n) { int result = 0; while(n--) result += *array++; return result; }
Подробно каждую строчку описывать не буду, это долго. Скажу лишь что здесь при генерации компилятор использовал самый простой и избыточный шаблон, сохраняя все вызовы функций вместе с передачей параметров через стек и самые простые алгоритмы математики и логики, даже несмотря на более оптимальный сишный код. Кароч, компилятор исполняет роль тупого студента.
Ладно. Теперь включаем оптимизацию компиляции на уровень -O3 и получаем: Спойлер
Здесь уже задействуются более эффективные шаблоны. При этом вызовы функций Average и Sum с их накладными расходами полностью исчезают. Компилятор учитывает короткую сишную запись while(n--) и *array++ и применяет соответствующие совмещенные инструкции. Первые три строчки задают начальные условия, следующие четыре строчки выполняют суммирование элементв и последние четыре строки выполняют деление суммы на число элементов и сохренение результата в ОЗУ.
Таким образом, при включении оптимизации компилятора на выходе генерируется фактически то же самое, как если бы вы писали это вручную на ассемблере. Возможно, кому-то покажется быстрее написать этот текст на ассемблере. Конкретно этот пример несложен и на ассемблере писать даже меньше букв, чем на Си. Но чтобы писать такой же эффективный код на ассемблере в рамках всей программы, нужно помимо логики приложения всегда держать в голове логику и ограничения инструкций, помнить все их варианты и ограничения параметров. А во-вторых, изменение такого текста под изменившиеся условия будет выполнить намного сложнее. В разных сериях ядра АРМ используется разный набор инструкций. В лучшем случае, если замените Cortex M3 на Cortex M7 вы просто ограничитесь базовым набором, не используя специфические для M7 инструкции. А вот при обратном переходе, если использовали расширенный набор для M7, придется убирать их и искать упрощенный эквивалент на наборе M3. В противовес этому, когда пишите на Си, один и тот же код без изменений будет работать на любом Кортексе. Я не имею ввиду аппаратные различия периферии, а вот такую прикладную задачу.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
..."
