> Фе. Ты писал под микроконтроллеры на C?И не только я. Но и еще легион писателей. А знаешь почему? Потому что это - работает. И работает довольно хорошо. Грабли за годы изучены, сюрпризов умеренно, а кому надо еще круче, читают про MISRA C всякие и настраивают проверки комитов в проект.
> Значит тебе приходилось заливать в mc кривую прошивку, а потом гадать, что происходит?
Да. И как меня от этого спасет этот твой Rust?
> Так вот rust отличается от C тем, что если программа скомпилировалась, то она работает.
Так вот, врать - не хорошо. Я могу с наскока написать программу на чем угодно, которая скомпилируется но работать (с точки зрения ведения осмысленной активности) не будет. А так если творится какая-то мистика и отладочный printf не помог, я прицеплюсь JTAGом и посмотрю где проц и чем занимается. От раста это не зависит. Более того - словить клин можно и на расте. Ну вот ждешь ты пока железо выставит битик в регистре, допустим, что кварц завелся. А кварц возьми и не заведись никогда. Мало ли какое дерьмо случается. И какая разница на чем ты будешь висеть? Это лечится не ЯПом, а логикой с таймаутом и общей паранойей что все вокруг сговорились программу испортить. Но чтобы знать про это - надо писать программы, а не разводить теоретические рассусоливания как ты, мегаэмбедер от академии.
> Отладка нужна крайне редко. И для микроконтроллеров, которые отлаживать сложнее, чем
> прикладные процессы, это очень полезный бонус.
У современных микроконтроллеров основная проблема - не с программой блин. А с ее взаиможействием с фичастой и навороченной периферией. И с тем что мнение программы о том что периферия должны была сделать не совпало с мнением периферии. И вот на этом стыке можно выкусить. У микроконтроллеров программы специфичные, управляющие. Координация работы периферии и проч.
А конкретно атмел на надежность класть хотел. У проца нет исключений, нет bad opcode, ни малейших намеков на привилегии или защиту памяти. Поэтому если в проц воткнется частица, или по питанию что-то проскочит и program counter влетит на середину программы, атмел будет до упора пытаться что-то выполнять. Конечно же выполнение программы с рандомного места не имеет смысла и не приведет к хорошему результату. Но с атмелкой это вообще можно заметить только сильно опосля, когда вачдог через кучу времени сработает. Может быть. Если ты с ним не очень глупо работаешь. От обслуживания вачдога в IRQ никакой раст не спасет - IRQ будет живым а основная прога может висеть сколько влезет, например. И програмеской глупостью победили даже аппаратный антизависатор.
>> баша мигать, даже клавиатурой блин :).
> facepalm.jpg
Ну это я доразвил твою идею. Мигать диодиком и из баша можно. Просто надежность и предсказуемость этого - г-но. И чем больше по пути умных рантаймов, компилеров и библ - тем менее предсказуемо получается. Си хорош тем что он уже не ассемблер и чистая математика портабельна, но по предсказуемости - почти как асм.
> У меня на все случаи жизни спаяна на макетке что-то типа dev-board.
Ну, круто, и чего? А у меня прямща есть нормальный девборд + пара прототипов запиленых ЛУТом. Без макеток - нарисовал в KiCAD, распечатал и протравил. Так прикольнее. При желании маску могу запилить, чтобы совсем как с фабы, но для ранних прототипов это пижонство.
> ней другую девборду под программу мигающую светодиодами, только потому, что аноним
> в интернете считает, что для мигания светодиодами атмега это оверхед.
Ок, убедил. Специально искать тиньку при наличии меги - изврат.
> При этом, ну если по-хорошему, любой микроконтроллер мигающий светодиодом -- это оверхед,
> потому что вообще-то такая задача легко решается на рассыпухе --
А тут смотря как считать. МК один корпус, рассыпуха - много корпусов. А то что внутрях кристалл более сложно обработан... ну вот лично ты врядли даже примитивный биполярный транзистор дома сделаешь. Эти технологии одинаково недоступны для повторения. Хотя какой-то маньяк хотел на дому травить микросхемы и добился кой-каких успехов вроде.
> что тогда я даже не подозревал о существовании микроконтроллеров.
Микроконтроллеры позволили делать сложные вещи проще. Ради именно мигания диодиком их обычно жмутся ставить, разве что сильно продвинутого. А аналог блоков меги на рассыпухе займет наверное целый контейнер. Удачи на рассыпухе хотя-бы UART с программируемым baud :)
> свой Core i7, потому что это оверхед, достаёшь МК-61 и считаешь на нём?
Нет :)
> рассуждения я совсем не понимаю каким образом производятся. Ведь, по идее-то,
> всё ровно наоборот: если вся работа с периферией -- это работа
> с памятью, то здесь самым ярким образом раскроется основной перк rust'а
Раскрывается извините основной перк программиста. Он или делает это правильно и понимает с чем имеет дело. Или наслаждается абы каким трэшом. Ну как, если ты например под работающим процом попробуешь тактирование передернуть или с выбором режима DVFS лоханешься, загнав камень за предел гарантированной стабильности, что будет дальше - unspecified, вообще независимо от ЯП. Запиши в регистр baud rate uart'а неверное значение - и останешься без коммуникаций. Независимо от ЯП. И такое везде.
> -- возможность организовать работу с памятью "безопасным" образом, то есть так,
> чтобы большинство ошибок отлавливалось бы на этапе компиляции.
Это например как? Работа с периферией априори опасна, половина операций могут заведомо положить чип, сорвать коммуникации, сломать логику и даже чего-нибудь выжечь в внешней цепи. Например управление 3-фазными движками. Как ты представляешь себе это в безопасном виде? Там любой срыв последовательности чреват как минимум расколбасом мотора, как максимум вылетом ключей и прочего. Индуктивность такая интересная штука что ток в ней зависит от времени. Если это будет неправильное время, ключ вовсе и не обязан столько выдержать, да и сами обмотки.
Там все операции опасны. Защищать почти нечего. И эти операции легитимны с точки зрения формирования логики поведения чипа.
> Можно например описать память таким образом, чтобы обращение к Rx/Tx приводило бы
> к ошибке компиляции, каким бы образом оно не происходило.
А смысл? Тогда RX/TX работать не будет. Ну и у более взрослых 32-битников есть MPU - если очень хочется, само железо даст exception при совании в некий регион памяти. При том даже если это обращение будет сформировано например глючным влетом на середину кода после тяжелого системного сбоя типа program counter runaway например.
> Таким образом можно получить гарантии того, что единственный кусок кода,
> который туда что-то пишет -- это код работающий с usb.
С другой стороны, это не гарантирует от глючного вызова этого кода. Или что например какая-то последовательность байтов в другом месте программы при влете на ее середину не сложится в запись в тот регистр. Ну и вообще, описывать такие правила можно заманаться.
> Гарантии того, что я ничего не запишу в portd _случайно_.
Только в сферическом идеальном вакууме. А если проц влетит на середину кода - компилер над этим вообще не властен. И это известный класс проблем управляющих систем. При том атмел в этом довольно плох - нет средств раннего обнаружения и он будет довольно долго пыжиться пытаясь что-то делать. Так что на бумаге все круто, а реальная система легко уйдет в аут.
> не смог дорасти до уровня мифического программиста на C/C++, который может
> работать с памятью вручную и не совершать ошибок. Я постоянно ошибаюсь,
А что помешает ошибаться в работе с регистрами rust? Если ты постоянно ошибаешься, что помешает например писать неверные значения в регистры?
> учился писать на C, так чтобы компилятор C проверял бы все
> эти вещи, но возможности C к проверке ограничены. Возможности rust'а, надо
> полагать, тоже ограничены, но я пока не нащупал границ.
Лично я предпочитаю проявлять внимательность что и почему я делаю в коде. Для меня это работает. И объяснить себе проще и быстрее чем компилятору. И если бы я был хронически не способен написать несколько строк без ошибок, стал бы с горя вебмакакой, там не так важно.
> ps. Что за фильтр на форуме... Дворец пиoнЭpoв не пропускает.
Он на пионЭров обиделся, это ругательство такое, как и кос-монавты... :\
