Вот Людмила Михайловна внесла изменение и сразу прямо в документе видно, кто поменял, как было, как стало.
При условии, что она не выключила сохранение правок по той или иной причине. Если вы отправили документ в ООО «Весёлый АИ», то я бы на вашем месте забыл, что «режим правок» вообще существует и воспользовался сравнением документов. СКВ+diff изначально не будет требовать доверия к тому, что та сторона включила сохранение правок. Сравнение документов в Word, если я правильно помню весь опыт использования, всегда генерирует мусорные изменения в стилях. И запускается дольше. И требует двух документов с разными именами файлов.
Я знаю, что такое режим правок. У нас им пользуются. Он менее удобен, чем встроенные в любую приличную СКВ средства работы с изменениями для кода — в основном из‐за мусора, вылезающих иногда багов и некоторых особенностей взаимодействия этого режима с таблицами (если бы их не было, был бы не хуже), пока речь идёт о работе только с двумя версиями. Он, возможно, не хуже, чем эти же средства для документов на LaTeX/Markdown/…, а не кода, но у нас на них документы, к сожалению, не пишут, так что я не могу сказать, насколько эти средства хуже или лучше. Но в любом случае если бы вы обменивались документами в тексте, то для использования СКВ вами достаточно того, что СКВ есть у вас. Ничто не мешает взять чужую версию и самому сделать коммит у себя.
И это вы про другое. В ветке выше вас два комментария:
Нет ничего лучше Office для работы с текстами. Ни слова про взаимодействия с другими людьми, за исключением «подготовки публикаций».
Markdown + продвинутый текстовый редактор удобнее. Ни слова про взаимодействие с другими людьми, за исключением публикации.
Вы: режим правок — это отлично. Речь уже о работе над документами нескольких людей.
Речь идёт о сравнении функциональности работы с изменениями в тексте vs Word. Diff/СКВ также дают возможность сравнения с предыдущими версиями (в отличие от Word — со всеми, альтернатив blame для Word, не полагающихся на то, что все включили запись изменений я не знаю) и другую форму записи изменений, так что не вижу ничего странного.
Конкретные люди часто не будут менять Word, потому что их клиенты/… работают с Word, даже если альтернатива лучше во всём, кроме возможности работы с документами Word. Без этого, если альтернатива достаточно хорошая, можно попробовать уговорить на переход.
У тех, кто работает с кодом всё это не хуже (если есть СКВ или хотя бы старая версия для diff). Для текстовых файлов с текстом (== длинными абзацами и изменениями вида «удалено слово в середине абзаца», что для кода нехарактерно) вроде тоже что‐то есть, но я не проверял, насколько удобно.
В режиме правки Word имеет тенденцию иногда генерировать мусор: иногда какие‐то лишние изменения стилей, <C-a><F9> отметит все обновлённые поля как изменённые, даже если ничего не изменилось. Лучше, чем ничего, но я бы предпочёл всех коллег с Word загнать на LaTeX и mercurial (не люблю git, но git тоже лучше, чем ничего). Тем более, что очень много правок документов у меня — это требования вроде «сделай как там», LaTeX позволил бы это «там» импортировать и менять централизованно.
Не знаю, как реально принято переводить fly-by-wire в индустрии, но multitran предлагает «электродистанционное управление», а не «управление по проводам». Там есть ещё «наведение по проводам» в возможных вариантах перевода, но «наведение» вызывает совсем другие ассоциации. Именно «управления по проводам» в списке возможных переводов у multitran нет.
Но с тем, что речь идёт о fly-by-wire, а не об автопилоте я согласен.
Я не уверен, что кто‐то всерьёз думает, что это именно защита: при наличии документации всё понятно по разводке платы. С микросхемами в корпусе «капля» и без документации немного сложнее, но не сильно, если есть достаточное представление о том, что должно быть на Flash.
Но вообще если есть какая‐нибудь память с интерфейсом вида «подал адрес на параллельную шину, зажал CS и OE, подождал, получил результат на параллельной шине», и эта память имеет как минимум 2^n «слов» (шириной в параллельную шину данных), то у неё можно свободно переставить n нижних бит адреса (как правило — все биты, мне пока не встречалась такая память с объёмом‐не степенью 2) и все биты данных, чтобы упростить разводку. Я сам так как‐то с SRAM делал. (С SRAM это может быть особенно просто: если данные туда пишет сам микроконтроллер, то не нужно даже думать о каких‐либо перестановках при программировании. У меня было не так, но проблемной частью было «как перебить подключённый микроконтроллер», а не «как переставить биты».)
Про удаление лишнего припоя с ножек: тут уже рекомендовали оплётку, но есть ещё одна особенность: если лишнего припоя мало и вы не можете ткнуть в него паяльником или оплёткой — и, главное, он где‐то за ножками и паяльником с нормальной температурой не нагревается, иногда имеет смысл добавить больше припоя. Огромная капля удаляется оплёткой с ножек без проблем, мелкая капля едва касающаяся чего‐либо паяльником не удаляется без добавления припоя в принципе: либо вы поглощаете её лишним припоем, либо можно попробовать много флюса и фен. Нагревать паяльник выше той температуры, при которой вам комфортно паять ножки, для удаления мелкой капли не нужно. При использовании оплётки, если вы паяете на минимальной комфортной температуре, придётся добавить 20—30 ℃.
Я обычно паяю большим топориком (K) с 240 ℃ для микросхем с ножками, 250 ℃ для ёмкостей/… 0603—0805, подключающихся к огромным полигонам, 260—280 ℃ для танталовых конденсаторов и THD. Выше в специальных случаях. Если жало — не большой топорик, температура может потребоваться выше.
А относительно BGA: по‐моему вы ухудшили себе жизнь, не купив ИК станцию вместо столика с подогревом. У нас в компании BGA паяют без трафаретов и пасты: берём нормальный флюс (сейчас — Mechanic SD-360), мажем его очень тонким и ровным слоем по всем площадкам, ставим схему и греем ИК станцией. Работает как с золотым финишным покрытием (иммерсионное золото), так и с ПОС‐63 (или остатками шариков), но если ПОС‐63 появился после выпайки микросхемы, а не после завода, то его нужно аккуратно выровнять оплёткой (в плохих случаях: сначала паяльником смахнуть остатки шариков, а потом уже оплёткой), при этом не убрав этой оплёткой маску (что тем легче сделать, чем горячее паяльник) и не сорвав случайно площадки (что тем легче сделать, чем холоднее паяльник). Трафарет понадобится, если нужно будет перенакатывать шарики. Или если вы всё же решите поставить по одному 0402 конденсатору под каждый шарик питания и у вас есть ИК станция.
В качестве бюджетной ИК можно брать Puhui T-962, но её придётся доработать (у нас это запасная станция на случай поломки основной). Доработать — это обклеить термоскотчем, изменить прошивку, добавить дополнительный температурный сенсор.
Такие костыли я видел. Они хорошо заметны, и они точно не могут привести к идентичным $dir-fe (выводам git fast-export).
И в любом случае, напомню, что ветка началась с того, что я указал возможность сохранения информации о перемещениях в СКВ, хранящей слепки, и hg-git — это просто пример хранения этой информации в СКВ, хранящей слепки. Какими костылями он это делает неважно — это просто пример, что это сделать возможно, соответственно из «в гите как раз слепки хранятся» не может следовать, что гит «не умеет трекать перемещения» — он не умеет трекать перемещения, потому что его авторы решили не добавлять сохранение перемещений, а не потому что он хранит слепки.
Ваша ссылка относится к commit’ам, сделаным в git. У меня commit’ы, сделанные в mercurial, в которых уже есть информация о переименованиях и она должна быть частью commit’а и на стороне mercurial, и на стороне git, чтобы hg-git вообще работал: хэши commit’ов должны сохраняться при конвертации в любую сторону, чтобы можно было нормально работать, а не постоянно решать проблемы рассинхронизации. Можете проверить, например, так:
Скрипт
#!/bin/sh
set -e
# set -x
TGT=$1 ; shift
if test "$TGT" = "--help" ; then
echo "Usage: $0 NEWDIR"
exit 1
fi
export SCREENDIR="$(realpath "$TGT")/screen"
mkdir -p "$TGT"
mkdir -m 0700 -p "$SCREENDIR"
cd "$TGT"
for dir in mv nomv ; do
hg init "$dir"
cd "$dir"
echo abc > a
hg add a
hg commit -m 'Add a' --date=2000-01-01 --user=test
hg rm a
echo def > b
hg add b
if test "$dir" = mv ; then
hg mv -A a b
fi
hg commit -m 'Move a to b' --date=2000-01-01 --user=test
hg bookmark master
hg gexport
cd .hg/git
git fast-export master > "../../../$dir-fe"
git bundle create "../../../$dir-bundle" master
git log > "../../../$dir-log"
screen -d -m -S git-daemon git daemon --export-all --base-path=.
hg clone "git://127.0.0.1/" "../../../$dir-clone"
screen -X quit
cd ../..
hg log --follow b > "../$dir-log-follow"
cd ..
cd "$dir-clone"
hg log --follow b > "../$dir-clone-log-follow"
cd ..
diff --report-identical-files "$dir-log-follow" "$dir-clone-log-follow"
done
Здесь я клонировал репозиторий git «по сети» и сравнил вывод hg log --follow оригинального и склонированного репозитория. Они совпадают.
Вообще‐то хранение слепков/разностей и возможность сохранения информации о перемещении файлов несколько ортогональны. Git вполне мог сохранять информацию о факте перемещения отдельно от самих слепков. Более того, hg-git отлично сохраняет куда‐то информацию о перемещениях. Я у себя проверил вот таким скриптом:
#!/bin/sh
set -e
TGT=$1 ; shift
if test "$TGT" = "--help" ; then
echo "Usage: $0 NEWDIR"
exit 1
fi
mkdir -p "$TGT"
cd "$TGT"
for dir in mv nomv ; do
hg init "$dir"
cd "$dir"
echo abc > a
hg add a
hg commit -m 'Add a' --date=2000-01-01 --user=test
hg rm a
echo def > b
hg add b
if test "$dir" = mv ; then
hg mv -A a b
fi
hg commit -m 'Move a to b' --date=2000-01-01 --user=test
hg bookmark master
hg gexport
cd .hg/git
git fast-export master > "../../../$dir-fe"
git bundle create "../../../$dir-bundle" master
git log > "../../../$dir-log"
cd ../..
cd ..
done
Разница в том, что оказалось в git видна только в файлах $dir-bundle, $dir-log содержит только различающиеся хэши второго commit’а, а $dir-fe идентичны, так что как достать эту информацию из git и как она вообще сохраняется мне не очевидно. Возможно, hg-git просто нашёл какой‐то способ хранения своих метаданных и git понятия не имеет, что они означают. Код [hg-]git я сейчас как‐то смотреть не хочу. Но факт тот, что в git вполне возможно сохранять информацию о переименованиях, хранение слепков этому не мешает.
Смысла в исправляющих кодах тогда ещё меньше. Я не решаю вычислительные задачи, я чем‐то заполняю память. Если вычисление эталонного содержимого памяти занимает меньше времени, чем подсчёт и коррекция ошибок с использованием кодов коррекции ошибок, то при проверке его можно просто вычислить ещё раз. Если больше, то мне и так сложно понять, зачем тратить время на вычисление кодов коррекции при инициализации, сложные вычисления собственно содержимого памяти увеличат время инициализации ещё больше.
Кстати, ещё в копилку, почему писать программную реализацию ECC в моём случае — плохая идея: вообще‐то начальное заполнение памяти происходит во время облучения — т.е. когда в памяти активно появляются новые ОС, мешая всему подряд, но особенно любым операциях, использующим большие куски ОЗУ. Точнее, это не всегда так, только почти всегда — если в схеме возникают только ОС в памяти, память инициализируется только до облучения, но помимо одиночных сбоев в микроконтроллерах часто есть ещё такие интересные вещи как функциональные сбои, требующие произведения сброса (скорее всего, те же одиночные сбои, но просто где‐то внутри) и тиристорные эффекты, требующие выключения и включения питания.
---
Хотя я сейчас подумал, что какая‐то программная коррекция ошибок может пригодиться в тех случаях, когда я храню в ОЗУ саму исполняемую программу, что происходит, когда flash просто нет. У меня было, кажется, что‐то вроде одной такой схемы когда‐то давно и ОС смотреть там было сложно (и то, что никакой коррекции ошибок, кроме сброса при зависании, я не добавил, не помогло).
Но, я думаю, если только интерфейс, по которому в ОЗУ загружается программа, не будет очень медленным и безальтернативным, вместо кодов коррекции ошибок я скорее сделаю что‐то вроде перезаписи ОЗУ с программой данными, полученными повторно по этому же или более быстрому интерфейсу. А если он будет — то можно просто записать в ОЗУ три/пять/семь/… копий программы и использовать мажорирование, полагаясь на малую вероятность получить один и тот же сбой в двух/трёх/четырёх/… далеко расположенных местах сразу — не так сбоеустойчиво (в худшем случае) и экономно по памяти, как, скажем, коды Рида‐Соломона, но зато коррекция ошибок требует меньше времени и меньше иструкций.
И в любом случае, коррекция ошибок в таких схемах будет работать только если ошибка возникла в том коде, что должен быть выполнен после коррекции ошибок, и в тот момент времени, когда коррекция ошибок ещё не произошла. Нужно будет подумать, как её вставить так, чтобы увеличить вероятность, что инструкции с ошибками не будут выполнены, с учётом того, что больше инструкций и больше времени — больше ошибок.
Вообще не понятно как вы фиксируете-отлавливаете ошибки с памятью если такие коды не используете.
Если содержимое памяти — это функция от адреса (или, тем более, константа), то нужно просто запихать во flash‐память эту функцию (константу) и сравнивать содержимое памяти с ней. Если использовать исправляющие коды и случайные данные, то, во‐первых, код проверки и, соответственно, цикл ФК будет занимать больше времени. Во‐вторых, инициализация памяти будет занимать больше времени. В‐третьих, как я написал, сбоев будет много, но при этом заранее не известно, сколько в одном регионе накопится за цикл ФК — сколько сбоев должны выдерживать исправляющие ошибки коды — тем более, учитывая, что в схемах, где об ОС не думали при разработке могут найтись и множественные логически близко расположенные сбои (когда одна частица сбивает сразу несколько бит).
Исправляющие ошибки коды позволяют формировать с одной стороны как бы псевдо случайные данные близкие к данным используемым в реальной работе, а с другой стороны локализовать ошибку если она вдруг появится, ну и техника работы с такими кодами очень проработана - известна.
Знание, что именно должно лежать в памяти работает не хуже для локализации. И в реальной работе в памяти будет так же не случайный шум, а почти наверняка что‐то вроде массивов каких‐нибудь объектов и у каждого объекта схожий префикс. (К примеру, ASCII текст имеет бит 7 равный 0, а цифры конкретно вообще имеют четыре одинаковых наиболее значащих бит, у чисел с плавающей точкой в наиболее значащих битах расположены знак и экспонента.)
Обычно сбои там или приводят к функциональному сбою (== что‐то не работает, но почему именно мы не знаем) и написание прошивки на ассемблере никак с ними не поможет, либо тестирование сбоев в них на ассемблере и на C особо не отличается и соответственно не входит в список причин, по которым я использую ассемблер.
Если оно присутствует в железе, то приходится. Если нет, то не имеет смысла, содержимое памяти, в которой проверяется наличие ОС — это всегда какая‐то простая функция вида f(адрес), во многих случаях даже f(_) = const. Исправляющие ошибки коды будут использовать разработчики аппаратуры, после расчёта вероятности получения сбоя. С ECC в данном случае работать не удобно. Дело в том, что в космосе вам, в зависимости от орбиты, может прилетать одна частица в месяц/неделю/день/… — ECC с таким легко справляется. На испытаниях в сторону микросхемы может лететь до несколько десятков тысяч частиц в секунду (в саму микросхему попадёт, если я не ошибаюсь, порядка на два—три меньше, пропорционально её площади) — чем больше, тем меньше мы стоим на ускорителе и меньше платим за его время. Если память без ECC, то увеличение числа частиц в разумных пределах мало что качественно меняет — вероятность пропустить сбой из‐за того, что в одном месте произошло два сбоя за цикл ФК низкая, а несколько сбоев рядом никак не отличаются от нескольких сбоев далеко друг от друга. Если же память с ECC, то подача слишком большого числа частиц приведёт к неизбежному заключению «ECC не работает», что, возможно, не соответствует реальности. Но при этом ECC действительно может не работать — одна частица вполне может сбить одновременно пачку ячеек; разработчики схемы должны позаботится о том, чтобы это было не проблемой, сделав логически близкие адреса физически не такими близкими, но мы — испытательный центр — должны как‐то проверить, что они действительно это сделали. Схемы с такой памятью также могут по‐разному реагировать на сбои — не все, к примеру, предоставляют счётчик скорректированных ошибок. В общем, я скорее рад, что микросхемы со встроенным ECC мне приходят нечасто.
Что Вас удивляет? Ускорители ЛЯР ОИЯИ вполне себе живут и здравствуют, можете поискать, где — именно они используются для испытаний на воздействие ТЗЧ. Есть медицинский ускоритель протонов в Обнинске. А если вам всего лишь нужно ускорить электроны и потом превратить их в гамма‐излучение, то такие устройства в принципе относительно часто встречающиеся, небольшие — могут поместиться в вашу комнату (если не считать свинца, из‐за которого ваша комната рухнет на соседа снизу или подвал ещё до установки в неё ускорителя и того, что размещать ускоритель в жилом помещении вам наверняка нельзя) — и некоторые даже используются для промышленной дезинфекции.
Я работаю в испытательном центре, занимающемся испытаниями на радиационную стойкость, а не разрабатываю аппаратуру. Т.е. мне нужно предоставлять данные для ответа на вопросы вида «насколько вероятно, что прилетевшая в схему частица вызовет сбой в определённом блоке» (блоки в основном ограничиваются разными видами памяти), а не собственно как‐то компенсировать результат этого сбоя.
Соответственно, всё, что мои прошивки делают — это крутят определённый набор тестов, в то время как сама схема стоит с открытым кристаллом и подвергается бомбардировке тяжёлыми заряженными частицами (ТЗЧ), обычно ионами благородных газов из ускорителя. (Или ещё чем и не обязательно с открытым кристаллом, но конкретно одиночные сбои интересны при испытаниях на ТЗЧ.)
Потом, на основе моих данных, кто‐то будет решать, что всё‐таки нужно делать, чтобы его изделие нормально работало в космосе. Но это вопрос не ко мне.
Если вы будете писать как я, то прилетающие частицы вас не особо будут беспокоить — но у меня для стабильности работы тестовой прошивки есть по сути одно и не очень полезное (для реальных прошивок) правило — не используйте никакую память, кроме flash, а если очень нужно — используйте мало памяти и не держите там ничего долго. Ну и по возможности не оставляйте в прошивке код для перезаписи flash, результат случайного прыжка туда вам не понравится.
Это не самый оптимальный код, какой может быть¹, но он работает.
Вообще на хабре где‐то была хорошая статья про ARM ассемблер, но я что‐то не могу её найти. Поисковик, тем не менее, находит достаточно статей про ARM ассемблер, в том числе упоминающий инструкцию it… (ne|…): кроме сей инструкции ассемблер для меня особо ничем не примечателен. (В примере выше, насколько я знаю, я мог бы её и опустить, но вот, например, в макросе проверки памяти на ОС есть кусок вида
eors r1, r1, \tmpreg3
itt ne
strne \tmpreg3, [\tmpreg1]
blne count_ones
, где с ней просто удобнее.)
¹ Особенно учитывая, что .else ветка существует исключительно чтобы я мог ради интереса посмотреть на diff между результатом дизассемблирования почти одной и той же прошивки, скомпилированной под разные STM’ки и не получить 100500 отличий в адресах инструкций.
Я свои прошивки вообще на ассемблере часто пишу. Это позволяет мне делать интересные вещи вроде контроля одиночных сбоев в регистрах общего назначения: попробуйте убедить компилятор C в том, что ему нужно поместить глобальную переменную в регистр. Последний раз как я пытался это сделать, прошивка почему‐то не заработала, хотя компилятор вроде поддерживал привязку переменной к регистру.
Результат также быстрее, чем -O0. (Про остальные -O такого не скажу, но мои прошивки не делают некоторые вещи, которые делает startup: не копируют в ОЗУ значения разных переменных, обычно не инициализируют стэк.)
Так «ссылка на объект или функцию» — нормальное определение. Вы не можете посмотреть на него и сказать «если я прибавлю к этой ссылке 10, то я попаду в соседний объект». Интереснее вопрос «а что такое объект»: если я правильно понимаю логику компиляторов, это будет что‐то вроде «кусок памяти, выделенный для одного экземпляра типа».
При условии, что она не выключила сохранение правок по той или иной причине. Если вы отправили документ в ООО «Весёлый АИ», то я бы на вашем месте забыл, что «режим правок» вообще существует и воспользовался сравнением документов. СКВ+diff изначально не будет требовать доверия к тому, что та сторона включила сохранение правок. Сравнение документов в Word, если я правильно помню весь опыт использования, всегда генерирует мусорные изменения в стилях. И запускается дольше. И требует двух документов с разными именами файлов.
Я знаю, что такое режим правок. У нас им пользуются. Он менее удобен, чем встроенные в любую приличную СКВ средства работы с изменениями для кода — в основном из‐за мусора, вылезающих иногда багов и некоторых особенностей взаимодействия этого режима с таблицами (если бы их не было, был бы не хуже), пока речь идёт о работе только с двумя версиями. Он, возможно, не хуже, чем эти же средства для документов на LaTeX/Markdown/…, а не кода, но у нас на них документы, к сожалению, не пишут, так что я не могу сказать, насколько эти средства хуже или лучше.
Но в любом случае если бы вы обменивались документами в тексте, то для использования СКВ вами достаточно того, что СКВ есть у вас. Ничто не мешает взять чужую версию и самому сделать коммит у себя.
И это вы про другое. В ветке выше вас два комментария:
Нет ничего лучше Office для работы с текстами. Ни слова про взаимодействия с другими людьми, за исключением «подготовки публикаций».
Markdown + продвинутый текстовый редактор удобнее. Ни слова про взаимодействие с другими людьми, за исключением публикации.
Вы: режим правок — это отлично. Речь уже о работе над документами нескольких людей.
Речь идёт о сравнении функциональности работы с изменениями в тексте vs Word. Diff/СКВ также дают возможность сравнения с предыдущими версиями (в отличие от Word — со всеми, альтернатив blame для Word, не полагающихся на то, что все включили запись изменений я не знаю) и другую форму записи изменений, так что не вижу ничего странного.
Конкретные люди часто не будут менять Word, потому что их клиенты/… работают с Word, даже если альтернатива лучше во всём, кроме возможности работы с документами Word. Без этого, если альтернатива достаточно хорошая, можно попробовать уговорить на переход.
У тех, кто работает с кодом всё это не хуже (если есть СКВ или хотя бы старая версия для diff). Для текстовых файлов с текстом (== длинными абзацами и изменениями вида «удалено слово в середине абзаца», что для кода нехарактерно) вроде тоже что‐то есть, но я не проверял, насколько удобно.
В режиме правки Word имеет тенденцию иногда генерировать мусор: иногда какие‐то лишние изменения стилей,
<C-a><F9>отметит все обновлённые поля как изменённые, даже если ничего не изменилось. Лучше, чем ничего, но я бы предпочёл всех коллег с Word загнать на LaTeX и mercurial (не люблю git, но git тоже лучше, чем ничего). Тем более, что очень много правок документов у меня — это требования вроде «сделай как там», LaTeX позволил бы это «там» импортировать и менять централизованно.Не знаю, как реально принято переводить fly-by-wire в индустрии, но multitran предлагает «электродистанционное управление», а не «управление по проводам». Там есть ещё «наведение по проводам» в возможных вариантах перевода, но «наведение» вызывает совсем другие ассоциации. Именно «управления по проводам» в списке возможных переводов у multitran нет.
Но с тем, что речь идёт о fly-by-wire, а не об автопилоте я согласен.
Я не уверен, что кто‐то всерьёз думает, что это именно защита: при наличии документации всё понятно по разводке платы. С микросхемами в корпусе «капля» и без документации немного сложнее, но не сильно, если есть достаточное представление о том, что должно быть на Flash.
Но вообще если есть какая‐нибудь память с интерфейсом вида «подал адрес на параллельную шину, зажал CS и OE, подождал, получил результат на параллельной шине», и эта память имеет как минимум 2^n «слов» (шириной в параллельную шину данных), то у неё можно свободно переставить n нижних бит адреса (как правило — все биты, мне пока не встречалась такая память с объёмом‐не степенью 2) и все биты данных, чтобы упростить разводку. Я сам так как‐то с SRAM делал. (С SRAM это может быть особенно просто: если данные туда пишет сам микроконтроллер, то не нужно даже думать о каких‐либо перестановках при программировании. У меня было не так, но проблемной частью было «как перебить подключённый микроконтроллер», а не «как переставить биты».)
Про удаление лишнего припоя с ножек: тут уже рекомендовали оплётку, но есть ещё одна особенность: если лишнего припоя мало и вы не можете ткнуть в него паяльником или оплёткой — и, главное, он где‐то за ножками и паяльником с нормальной температурой не нагревается, иногда имеет смысл добавить больше припоя. Огромная капля удаляется оплёткой с ножек без проблем, мелкая капля едва касающаяся чего‐либо паяльником не удаляется без добавления припоя в принципе: либо вы поглощаете её лишним припоем, либо можно попробовать много флюса и фен.
Нагревать паяльник выше той температуры, при которой вам комфортно паять ножки, для удаления мелкой капли не нужно. При использовании оплётки, если вы паяете на минимальной комфортной температуре, придётся добавить 20—30 ℃.
Я обычно паяю большим топориком (K) с 240 ℃ для микросхем с ножками, 250 ℃ для ёмкостей/… 0603—0805, подключающихся к огромным полигонам, 260—280 ℃ для танталовых конденсаторов и THD. Выше в специальных случаях. Если жало — не большой топорик, температура может потребоваться выше.
А относительно BGA: по‐моему вы ухудшили себе жизнь, не купив ИК станцию вместо столика с подогревом. У нас в компании BGA паяют без трафаретов и пасты: берём нормальный флюс (сейчас — Mechanic SD-360), мажем его очень тонким и ровным слоем по всем площадкам, ставим схему и греем ИК станцией. Работает как с золотым финишным покрытием (иммерсионное золото), так и с ПОС‐63 (или остатками шариков), но если ПОС‐63 появился после выпайки микросхемы, а не после завода, то его нужно аккуратно выровнять оплёткой (в плохих случаях: сначала паяльником смахнуть остатки шариков, а потом уже оплёткой), при этом не убрав этой оплёткой маску (что тем легче сделать, чем горячее паяльник) и не сорвав случайно площадки (что тем легче сделать, чем холоднее паяльник).
Трафарет понадобится, если нужно будет перенакатывать шарики. Или если вы всё же решите поставить по одному 0402 конденсатору под каждый шарик питания и у вас есть ИК станция.
В качестве бюджетной ИК можно брать Puhui T-962, но её придётся доработать (у нас это запасная станция на случай поломки основной). Доработать — это обклеить термоскотчем, изменить прошивку, добавить дополнительный температурный сенсор.
Такие костыли я видел. Они хорошо заметны, и они точно не могут привести к идентичным
$dir-fe(выводамgit fast-export).И в любом случае, напомню, что ветка началась с того, что я указал возможность сохранения информации о перемещениях в СКВ, хранящей слепки, и hg-git — это просто пример хранения этой информации в СКВ, хранящей слепки. Какими костылями он это делает неважно — это просто пример, что это сделать возможно, соответственно из «в гите как раз слепки хранятся» не может следовать, что гит «не умеет трекать перемещения» — он не умеет трекать перемещения, потому что его авторы решили не добавлять сохранение перемещений, а не потому что он хранит слепки.
Ваша ссылка относится к commit’ам, сделаным в git. У меня commit’ы, сделанные в mercurial, в которых уже есть информация о переименованиях и она должна быть частью commit’а и на стороне mercurial, и на стороне git, чтобы hg-git вообще работал: хэши commit’ов должны сохраняться при конвертации в любую сторону, чтобы можно было нормально работать, а не постоянно решать проблемы рассинхронизации. Можете проверить, например, так:
Скрипт
Здесь я клонировал репозиторий git «по сети» и сравнил вывод
hg log --followоригинального и склонированного репозитория. Они совпадают.Вообще‐то хранение слепков/разностей и возможность сохранения информации о перемещении файлов несколько ортогональны. Git вполне мог сохранять информацию о факте перемещения отдельно от самих слепков. Более того,
hg-gitотлично сохраняет куда‐то информацию о перемещениях. Я у себя проверил вот таким скриптом:Разница в том, что оказалось в git видна только в файлах
$dir-bundle,$dir-logсодержит только различающиеся хэши второго commit’а, а$dir-feидентичны, так что как достать эту информацию из git и как она вообще сохраняется мне не очевидно. Возможно, hg-git просто нашёл какой‐то способ хранения своих метаданных и git понятия не имеет, что они означают. Код [hg-]git я сейчас как‐то смотреть не хочу. Но факт тот, что в git вполне возможно сохранять информацию о переименованиях, хранение слепков этому не мешает.Смысла в исправляющих кодах тогда ещё меньше. Я не решаю вычислительные задачи, я чем‐то заполняю память. Если вычисление эталонного содержимого памяти занимает меньше времени, чем подсчёт и коррекция ошибок с использованием кодов коррекции ошибок, то при проверке его можно просто вычислить ещё раз. Если больше, то мне и так сложно понять, зачем тратить время на вычисление кодов коррекции при инициализации, сложные вычисления собственно содержимого памяти увеличат время инициализации ещё больше.
Кстати, ещё в копилку, почему писать программную реализацию ECC в моём случае — плохая идея: вообще‐то начальное заполнение памяти происходит во время облучения — т.е. когда в памяти активно появляются новые ОС, мешая всему подряд, но особенно любым операциях, использующим большие куски ОЗУ. Точнее, это не всегда так, только почти всегда — если в схеме возникают только ОС в памяти, память инициализируется только до облучения, но помимо одиночных сбоев в микроконтроллерах часто есть ещё такие интересные вещи как функциональные сбои, требующие произведения сброса (скорее всего, те же одиночные сбои, но просто где‐то внутри) и тиристорные эффекты, требующие выключения и включения питания.
---
Хотя я сейчас подумал, что какая‐то программная коррекция ошибок может пригодиться в тех случаях, когда я храню в ОЗУ саму исполняемую программу, что происходит, когда flash просто нет. У меня было, кажется, что‐то вроде одной такой схемы когда‐то давно и ОС смотреть там было сложно (и то, что никакой коррекции ошибок, кроме сброса при зависании, я не добавил, не помогло).
Но, я думаю, если только интерфейс, по которому в ОЗУ загружается программа, не будет очень медленным и безальтернативным, вместо кодов коррекции ошибок я скорее сделаю что‐то вроде перезаписи ОЗУ с программой данными, полученными повторно по этому же или более быстрому интерфейсу. А если он будет — то можно просто записать в ОЗУ три/пять/семь/… копий программы и использовать мажорирование, полагаясь на малую вероятность получить один и тот же сбой в двух/трёх/четырёх/… далеко расположенных местах сразу — не так сбоеустойчиво (в худшем случае) и экономно по памяти, как, скажем, коды Рида‐Соломона, но зато коррекция ошибок требует меньше времени и меньше иструкций.
И в любом случае, коррекция ошибок в таких схемах будет работать только если ошибка возникла в том коде, что должен быть выполнен после коррекции ошибок, и в тот момент времени, когда коррекция ошибок ещё не произошла. Нужно будет подумать, как её вставить так, чтобы увеличить вероятность, что инструкции с ошибками не будут выполнены, с учётом того, что больше инструкций и больше времени — больше ошибок.
Если содержимое памяти — это функция от адреса (или, тем более, константа), то нужно просто запихать во flash‐память эту функцию (константу) и сравнивать содержимое памяти с ней. Если использовать исправляющие коды и случайные данные, то, во‐первых, код проверки и, соответственно, цикл ФК будет занимать больше времени. Во‐вторых, инициализация памяти будет занимать больше времени. В‐третьих, как я написал, сбоев будет много, но при этом заранее не известно, сколько в одном регионе накопится за цикл ФК — сколько сбоев должны выдерживать исправляющие ошибки коды — тем более, учитывая, что в схемах, где об ОС не думали при разработке могут найтись и множественные логически близко расположенные сбои (когда одна частица сбивает сразу несколько бит).
Знание, что именно должно лежать в памяти работает не хуже для локализации. И в реальной работе в памяти будет так же не случайный шум, а почти наверняка что‐то вроде массивов каких‐нибудь объектов и у каждого объекта схожий префикс. (К примеру, ASCII текст имеет бит 7 равный 0, а цифры конкретно вообще имеют четыре одинаковых наиболее значащих бит, у чисел с плавающей точкой в наиболее значащих битах расположены знак и экспонента.)
Обычно сбои там или приводят к функциональному сбою (== что‐то не работает, но почему именно мы не знаем) и написание прошивки на ассемблере никак с ними не поможет, либо тестирование сбоев в них на ассемблере и на C особо не отличается и соответственно не входит в список причин, по которым я использую ассемблер.
Если оно присутствует в железе, то приходится. Если нет, то не имеет смысла, содержимое памяти, в которой проверяется наличие ОС — это всегда какая‐то простая функция вида f(адрес), во многих случаях даже f(_) = const. Исправляющие ошибки коды будут использовать разработчики аппаратуры, после расчёта вероятности получения сбоя.
С ECC в данном случае работать не удобно. Дело в том, что в космосе вам, в зависимости от орбиты, может прилетать одна частица в месяц/неделю/день/… — ECC с таким легко справляется. На испытаниях в сторону микросхемы может лететь до несколько десятков тысяч частиц в секунду (в саму микросхему попадёт, если я не ошибаюсь, порядка на два—три меньше, пропорционально её площади) — чем больше, тем меньше мы стоим на ускорителе и меньше платим за его время. Если память без ECC, то увеличение числа частиц в разумных пределах мало что качественно меняет — вероятность пропустить сбой из‐за того, что в одном месте произошло два сбоя за цикл ФК низкая, а несколько сбоев рядом никак не отличаются от нескольких сбоев далеко друг от друга.
Если же память с ECC, то подача слишком большого числа частиц приведёт к неизбежному заключению «ECC не работает», что, возможно, не соответствует реальности. Но при этом ECC действительно может не работать — одна частица вполне может сбить одновременно пачку ячеек; разработчики схемы должны позаботится о том, чтобы это было не проблемой, сделав логически близкие адреса физически не такими близкими, но мы — испытательный центр — должны как‐то проверить, что они действительно это сделали.
Схемы с такой памятью также могут по‐разному реагировать на сбои — не все, к примеру, предоставляют счётчик скорректированных ошибок.
В общем, я скорее рад, что микросхемы со встроенным ECC мне приходят нечасто.
Что Вас удивляет? Ускорители ЛЯР ОИЯИ вполне себе живут и здравствуют, можете поискать, где — именно они используются для испытаний на воздействие ТЗЧ. Есть медицинский ускоритель протонов в Обнинске. А если вам всего лишь нужно ускорить электроны и потом превратить их в гамма‐излучение, то такие устройства в принципе относительно часто встречающиеся, небольшие — могут поместиться в вашу комнату (если не считать свинца, из‐за которого ваша комната рухнет на соседа снизу или подвал ещё до установки в неё ускорителя и того, что размещать ускоритель в жилом помещении вам наверняка нельзя) — и некоторые даже используются для промышленной дезинфекции.
Я работаю в испытательном центре, занимающемся испытаниями на радиационную стойкость, а не разрабатываю аппаратуру. Т.е. мне нужно предоставлять данные для ответа на вопросы вида «насколько вероятно, что прилетевшая в схему частица вызовет сбой в определённом блоке» (блоки в основном ограничиваются разными видами памяти), а не собственно как‐то компенсировать результат этого сбоя.
Соответственно, всё, что мои прошивки делают — это крутят определённый набор тестов, в то время как сама схема стоит с открытым кристаллом и подвергается бомбардировке тяжёлыми заряженными частицами (ТЗЧ), обычно ионами благородных газов из ускорителя. (Или ещё чем и не обязательно с открытым кристаллом, но конкретно одиночные сбои интересны при испытаниях на ТЗЧ.)
Потом, на основе моих данных, кто‐то будет решать, что всё‐таки нужно делать, чтобы его изделие нормально работало в космосе. Но это вопрос не ко мне.
Если вы будете писать как я, то прилетающие частицы вас не особо будут беспокоить — но у меня для стабильности работы тестовой прошивки есть по сути одно и не очень полезное (для реальных прошивок) правило — не используйте никакую память, кроме flash, а если очень нужно — используйте мало памяти и не держите там ничего долго. Ну и по возможности не оставляйте в прошивке код для перезаписи flash, результат случайного прыжка туда вам не понравится.
Я написал ответ на вопрос «зачем» в той части предложения, что вы почему‐то решили не цитировать.
Для CA это, кажется, будет
при условии, что вы заранее знаете, где стэк.
Я для заполнения памяти использовал следующие макросы:
Это не самый оптимальный код, какой может быть¹, но он работает.
Вообще на хабре где‐то была хорошая статья про ARM ассемблер, но я что‐то не могу её найти. Поисковик, тем не менее, находит достаточно статей про ARM ассемблер, в том числе упоминающий инструкцию
it… (ne|…): кроме сей инструкции ассемблер для меня особо ничем не примечателен. (В примере выше, насколько я знаю, я мог бы её и опустить, но вот, например, в макросе проверки памяти на ОС есть кусок вида, где с ней просто удобнее.)
¹ Особенно учитывая, что
.elseветка существует исключительно чтобы я мог ради интереса посмотреть наdiffмежду результатом дизассемблирования почти одной и той же прошивки, скомпилированной под разные STM’ки и не получить 100500 отличий в адресах инструкций.Я свои прошивки вообще на ассемблере часто пишу. Это позволяет мне делать интересные вещи вроде контроля одиночных сбоев в регистрах общего назначения: попробуйте убедить компилятор C в том, что ему нужно поместить глобальную переменную в регистр. Последний раз как я пытался это сделать, прошивка почему‐то не заработала, хотя компилятор вроде поддерживал привязку переменной к регистру.
Результат также быстрее, чем -O0. (Про остальные -O такого не скажу, но мои прошивки не делают некоторые вещи, которые делает startup: не копируют в ОЗУ значения разных переменных, обычно не инициализируют стэк.)
Так «ссылка на объект или функцию» — нормальное определение. Вы не можете посмотреть на него и сказать «если я прибавлю к этой ссылке 10, то я попаду в соседний объект». Интереснее вопрос «а что такое объект»: если я правильно понимаю логику компиляторов, это будет что‐то вроде «кусок памяти, выделенный для одного экземпляра типа».