> деле не знаю, насколько rust полезен для embed'а. Я уверен, что
> полезен, но вот насколько -- не знаю. ADA тоже была полезна для космической техники. И все-же Arian 5 упал. А Элон Маск клепает бортовые компьютеры из ширпотреба который даже не rad hard и линуха.
Надежность многогранная штука, нет одного правильного способа. Когда вопрос на миллион, никто не верит в 1 сверхнадежный юнит. Вместо этого ставят несколько и делают кросс-чек. Переход к распределенным системам где корректное поведение формируется более глобальной логикой. Это покрывает многие классы глюков независимо от root cause. Даже сбои в железе.
Если открытие ключа вышибает схему за миллион - пустим 3 проца. Заведем их GPIO на AND и ключ откроется только если все три согласны что ключ надо открыть. В допущении что с закрытым ключем остаться в случае чего менее катастрофично. Можно также определить кто именно сбойнул и перезагрузить его, а если не помогло, выключить совсем.
> из того или иного куска C'шного кода, то что получится из
> куска кода на rust'е, я не всегда знаю.
Си тоже иногда подкидывает сюрпризов в кодогенерации. Но он по крайней мере относительно простой и предсказуемый. Тех кто плюсы юзает я уже не понимаю, там все становится сложнее.
> ассемблерные дампы, а вот при решении embedded задач придётся разбираться и
> это будет гораздо веселее.
Мне еще си оказался удобен тем что я перепер на мк часть либ с x86. Часть кода внаглую протестил сперва в "десктопной" программе а потом пересобрал под мк. На асме это не катит.
> на циклах -- это вещи, которые можно переупорядочить, то есть сначала
> вывести всё, а потом отработать все задержки.
Прикольно :). С memory mapped периферией в 32-битниках на си достаточно сказать volatile и компилер отвалит с потугами оптимизнуть это. Как в атмеле на си я уже и не помню, они ж гарвардец с несколькими адресными пространствами и разным доступом к памяти, там это как-то вкостылено.
> И с учётом этого, как лучше проектировать API -- когда передавать
> по значению, когда ссылкой, когда вешать на тип трейт Copy, а
> когда лучше оставить его жить в move стратегии.
Это как-то слишком сложно для меня. И объекты мне не надо. Я понимаю указатели и фактические значения. Мне этого более чем. А если что-то менять нельзя я напишу const. Я накатал макросы, в них readonly хардварные регистры заявлены const, прописана ширина регистров и проч и компилер на явно левые операции замечательно вопит. Я договорился сам с собой: трогать HW через функции и макросы. Макросы дают 0 оверхеда, так по скорости можно с асмом зарубиться.
> нет конкретных примеров использования тех или иных фичей языка. Но, если
> тебе хочется поспорить, мы тем не менее можем это сделать.
Много не обещаю, backlog вырастет.
> Твоя аргументация сводится к тому, что а) "мы всегда так делали"
Если нечто было и хорошо работало а грабли изучены, технология работала, ей можно пользоваться. Если круглыми колесами пользовались тысячелетиями, это не значит что это плохо и надо срочно придумать квадратные. И даже реактивные двигатели не обязаны оказаться лучше колеса во всех применениях.
> ты никогда не дождёшься, потому что серебряной пули не существует и быть не может.
Вот я и удовольствовался чем-то типа C99, работает и на pc и на мк, удобно. Можно в принципе что угодно, от bare HW до системных вещей и прикладух.
> При этом "мы всегда так делали" в современном мире -- это путь в небытие.
И все-таки мы тысячелетиями делали колеса круглыми и это неплохо работало для нас. Если кто-то считает что теперь колеса должны стать квадратными, пусть обоснует, чтоли.
> То есть в прошлом было то же самое, но там этот путь был дольше и мог
> растянутся на несколько поколений. Если ты хочешь чтобы твои знания и
> навыки оставались актуальными, или ещё лучше становились бы более ценными, то
> тебе надо непрерывно учиться.
Ты в чем-то прав. Но учится имеет смысл тому что дает какие-то новые качества и преимущества при умеренных затратах. Вот Linux-у например учиться на мой вкус перспективно и воздается. А если научиться дружить микроконтроли с Linux, можно научиться делать крутые многоуровневые системы. По этому паттерну много что делается. Уметь так же даже в один фэйс... мм... :)
> Если ты не учишься, то через десять лет ты будешь старпёром, который хорошо умеет
> выполнять два технологических действия и ни на что больше не годен.
Да. Поэтому у меня есть несколько идей, за которые старперы отвинтили бы мне голову, если бы могли. Но это не значит что абсолютно все идеи и опыт старперов плохи. У них тоже есть чему поучиться. Надо просто отсеять то что хорошо работает от того что себя исчерпало. И вот круглые колеса и си на мой вкус себя совсем не исчерпали. А то что с квадратными колесами может стать меньше ДТП - может быть, конечно, но...
А еще мне нравится когда знания долгоиграющие. Моя цель не только учиться, но и сделать что-нибудь прикольное, позажигать. Если все время изучать новые трюки, есть шанс что на "позажигать" времени не останется. Поэтому долгоиграющие знания приветствуются, если дают разумную эффективность. Знания си или линукса выглядят именно так.
> Если тебе повезёт уметь выполнять такие технологические действия, которые будут
> востребованы до конца твоей жизни, то будут неплохие шансы оставаться трудоустроенным
Говоря начистоту, я боюсь этого больше смерти. Это способ стать живым мертвецом.
> до тех пор, пока ты не умрёшь от скуки выполняя десятилетиями одни и те же технологические
> действия. Если не повезёт, пойдёшь работать дворником.
По степени унылости примерно одинаково. Дворником на свежем воздухе даже приятнее, да и для здоровья полезнее, пожалуй.
> Вот это вот как раз установка "меня всё устраивает, менять что-либо я
> не собираюсь". Не любое изменение -- это улучшение, но любое улучшение -- это изменение.
И тут ты прав. И вот тут мне становится интересно. Возможно зря я тебя хипстером считаю, ты все-таки пытаешься мыслить рационально. Не уверен что это всегда получается, но...
> Если ты хочешь стать лучше, то тебе надо меняться. У твоей внимательности есть границы,
Да. Поэтому я подыгрываю себе. Я стараюсь чтобы внимание не подвергалось стресстесту. Критичные операции делаются в небольшом числе мест, где я их ожидаю. Rust для этого не требуется. Прочекать вхождение наиболее опасных вещей по файлам я могу и так. Если меня это будет напрягать, могу автоматизировать даже. Но это не было идентифицированно как значительная проблема.
Если я понимаю что внимание подвергается стресстесту, значит я продолбался. На дележе проекта на части, понимаемые по отдельности. Это ключевая причина по которой софт декомпозируют на модули. Это же дает начало Test Driven Development, суть которого в том чтобы модули проверить. Это же делает проекты масштабируемыми. В том числе и больше чем на одну голову. В случае логически самодостаточног модуля програмеру не обязательно знать детали реализации.
> Ты можешь оставаться в этих границах, и отказываться от задач требующих выхода за них,
> либо ты можешь развиваться и учиться работать в областях, где не хватает
> интеллектуальных возможностей.
Есть еще опция: "хакнуть жизнь". Как с разбиением на модули. Развивать себя - круто, но налетев на квадратичную сложность даже сверхчеловек забуксует. А если проект декомпозировать до линейной сложности, и обычный человек справится.
Вывод? Если задача кажется большой, надо разделить на части. Заодно можно распараллелить на несколько человек.
> Это не аргумент нисколько. Если программист нацеленно пишет нерабочую программу, то мне
> совершенно неинтересен этот случай.
Конечно специально софт не ломают, это лишь пример. Я к тому что серебряная пуля здорово приукрашена. А программы окаазываются нерабочими не по тем причинам которые теоретики (и не только) ожидали. Именно работа с памятью в МК довольно ограничена. А в MISRA C - бан на адресную арифметику, например. Но хорошо когда бан опционален. Случаи бывают разные. Поэтому назвать работу с памятью ключевой проблемой в мк - хз, не факт это.
А первый вопрос который при создании надежного апи возникает: если есть критичная функция, которая ведет к дестрою, апи должно быть устроено так чтобы случайный вызов и даже влет в ее середину не вызывал дестрой. Это очень интересное соображение, важное в плане надежности. Есть много факторов которые не подконтрольны програмеру, но влияют на надежность. А есть ли в чипе код который может стереть флешку? Даже если програмер у себя все сделает правильно? А что чип делает если питание просело? Приветы атмелу, их разрушение флеша и еепрома при севших батарейках наводило ужас на поколения микроконтроллерщиков. По старой памяти половина до сих пор ссыкует 0-ю ячейку еепром использовать, кривой у атмеля BOR по жизни был :).
> Всё же мы рассуждаем о программмисте, который хочет написать рабочую программу,
> и более того, прилагает к этому всякие разные усилия: пишет код; думает о том,
> что пишет; он думает о ещё ненаписанной программе в целом,
....
Я не вижу 1 важной вещи: думания об архитектуре и декомпозиции. Чем раньше об этом подумано тем меньше потом мучительно больно. Хотя можно и как жабисты, 20 раз реfuckторить конечно. Все и сразу не предусмотришь, конечно, но все же.
> дебаггер, работая с rust'ом в прикладном программировании. Дебаггер не нужен, потому
> что все ошибки типа "я вносил десяток изменений в разных частях
Знаешь, мне тоже обычно не требуется. Как максимум в интересных местах плюю в uart сообщения о интересных событиях. Скорее для понимания общей логики, как фоновый main играет с irq handler'ами на пару и проч. Или мне интересно "а сколько намерялось?". Ты наверное согласишься что шестое, седьмое и i++'е чувства это прикольно. Бывает интересно сколько вокруг вольт и миллиамперов, процентов влажности, градусов, mm hg...
> это стратегия, которая плохо работает в C, и почти совсем не
> работает в асме.
Я бы сказал что на си эта стратегия работает "средне". Если обвесить макросами и следовать нехитрым правилам - не ощущаю проблемы с которой ты борешься.
> мк begin_panic -- это вечный цикл, ничего более осмысленного в голову
> пока не приходит,
Как вариант восстановления системы - вкатить RESET? С быстрым восстановлением состояния в нечто осмысленное и выход на режим заново. Если МК будет висеть и прошляпит критичное событие, нехорошо. Но это зависит от того чем управляем и как безопаснее. Если опрос педали газа встрянет и ECU будет фигачить на том что задано ранее, юзер обделается. А если проц быстро ребутнется и возобновит работу, юзер и не заметит, только сервисник который лог прочитает. А в лог записать reset cause и что там еще известно. Если по нормальному делать, долговременный failure analisys штука полезная для улучшения надежности.
> так что у меня будет возможность оценить насколько
> важную роль играют эти паники и бектрейсы в процессе разработки.
По хорошему можно крахлог писать. Если инфраструктура позволяет это сделать без гимора при сильно порушенной сиситеме, не убив систему. Если в флеху или еепром писать, маленькая ошибочка в значении протрет нафиг фирмвару или конфигурацию. И в этот момент лучше быть уверенным в системе. Иногда железо может подыграть локом критичных секторов, но это зависит от. Вообще, кладут крахлог в "scratch RAM" (некий оговоренный адрес), ребутаются, и из корректной системы логгят. Буфер, переживающий ребут. Но это продвинутости для больших долговременных проектов где можно позволить себе крутую и правильную инженерию для долговременного failure analisys. К сожалению есть такая штука как technical debt...
> Основной перк программиста -- это автоматизация всего, что можно автоматизировать,
Я думаю что основной перк программиста - сделать задуманное. А автоматизировать есть смысл то что дает хороший выигрыш при минимуме усилий. А если выигрыш от автоматизации меньше чем затраты на нее, это завал теста на разумность существа.
> Ну, например, ты упоминаешь регистр baud rate, почему бы не создать глобальный
> объект нулевого размера, дать ему доступ к этому регистру, не давать никому другому
> туда доступа.
А что это для меня глобально изменит? Я и так могу дергать его в 1-2 местах и легко замечать обращения из иных мест. Завести себе правило: работа с железкой - только из функции.
> Затем к этому объекту приделать ровно один pub метод set_baud_rate, который будет проверять
> входное значение на попадание в заданные границы.
Можно договориться и без объектов звать функцию "set_baud_rate()" в которой проверять... Юзать ее просто удобнее чем регистры, проблема отпадает сама :). И объекты мне не уперлись, честно говоря.
> написать одну ассемблерную инструкцию,
Даже ассемблерщики пишут subroutine'ы, и даже они могут делать проверки валидности baud.
> я легко смогу отмести гипотезу о том, что выставлена неверная скорость передачи.
Все это можно и на си и даже на асме сделать. Но там тоже не все так просто. А что есть верная скорость? Ну а вот захотели мы по ходу пьесы к MIDI интерфейситься. А там какие-то 31200 bps чтоли левые. Если железка не будет умничать, согласится на это и в лучшем случае заюзает совместимый baud (ошибка в 2% ок). А в слишком умной железке придется фирмварь патчить. Это называется горе от ума.
> Но, я говорю, я не готов пока приводить конкретные и реальные примеры.
Вот это меня как раз и смушает. Никак не могу отделаться от ощущения борьбы с ветряными мельницами. Если забахаешь какой-нибудь крутой проект на этом, будет интересно почитать реальный опыт.
> Тебе не приходилось читать о верификации кода? Если нет, то почитай обязательно:
Я об этом довольно много чего читал. В том числе и с неожиданных для тебя сторон.
Смотри, раз: http://www.st.com/resource/en/application_note/cd00004479.pdf
И два: http://www.st.com/content/ccc/resource/technical/document/us...
Как тебе такой взгляд на мир? Они повернуты на надежности и на это есть причины - ответственные применения.
> В частности вывод оттуда: если ты пишешь код под мкк так, чтобы
> он работал и на другом мкк, то твой код становится надёжнее.
ИМХО это зависит от того что за код и насколько разные камни. Может и наоборот выйти из-за усложнения кода.
> ЛУТом?! Ох да нифигажсебе! Круто!
Мне всегда хотелось научиться делать "как заводы". Я и подумал - чего бы не реализовать мечту. Теперь тоже так могу. Химлужение - просто и красиво. Маска ("зеленка" и "синька") - плата симпатичнее, удобнее паять SMD. SMD современен и крут, не только для роботов, если готовить правильно. И горячий воздух. Разложил детальки, пыщ-пыщ, готово. Клево. Можно QFP с шагом 0.5, 0603 и даже QFN. Мои технологии хороши для маленьких плат. Достаточно плотных, под SMD. Не люблю сверлить. CAD дает готовые слои. Фольгу лутом, маску литографией. Самый писк - фотошаблон из скотча, спер идею из чьего-то бложика. Печатается на бумаге, клеится скотч, бумага смывается с скотча как при луте с платы. Фотошаблон из спичек и желудей готов! Пленка для лазерника лучше, но ее искать специально надо и она дорогая, а скотч и хреновая бумага под рукой и проверка показала - номер катит.
> А я всё через дырку, так проще припаять/отпаять, что-то добавить или убрать.
Если я ожидаю сильные эксперименты, оставляю эн контактных площадок к которым можно допаять что-то. Но обычно я сносно представляю себе что хочу и рисую "схему устройства" которая в лучшем случае и будет делать то что я задумал. А для совсем абстрактного у меня есть девборд с кучей всего.
> А вообще, думаю, купить макетку, которую не надо паять. А то
> тут на макетке периодически такая путаница из проводов случается из-за неверных
> исходных посылок, а перепаивать влом. Если же просто перетыкивать, то может
> быть реже придётся тонуть в соединениях.
У макеток и клубков проводов есть ограничения. На них решительно невозможно делать скоростные цепи и/или что-то сильноточное. И мелкие детальки недоступны. Я себе запилил многое из того что давно хотелось. Преобразователи питания, вспомогательные модули типа cut-off разряженного лития и прочие мини-ништячки. На макетке оно не имело бы смысла в силу ненадежности или не заработало из-за сильных токов с частотой 100+ кГц, клубок проводов будет дико излучать и сглючит от своего же излучения. Мне так не интересно.
Вариант для распечатки
(ok) on 15-Янв-18, 20:21 
