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 под ассемблером (с листочками бумаги и карандашиком в качестве компилятора) возможностей хватит (даже ежли другого не будет).
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения