Эта статья представляет собой ознакомительный материал о написании загрузчика на С и Ассемблере. Сразу скажу, что здесь я не буду вдаваться в сравнение производительности итогового кода, созданного на этих языках. В этой работе я просто вкратце изложу процесс создания загрузочного флоппи-образа путем написания собственного кода с последующим его внедрением в загрузочный сектор устройства. Все содержание будет разделено на цикл из трех статей, так как сразу сложно изложить всю нужную информацию и о компьютерах, и об устройствах загрузки, и о написании самого кода. В первой части я поясню наиболее общие аспекты компьютерной науки и суть процесса загрузки, а также обобщу значение и важность каждого этапа, чтобы упростить их понимание и запоминание.

fn main() {
  println!("Hello, Rust!");
  println!("... Goodbye!");
}

Синтаксис — это первое, на что обращают внимание разработчики, впервые столкнувшись с кодом на Rust. И сложно найти что-то другое, что вызывало бы больше негодования у новичков, и при этом такое, к чему совершенно спокойно относятся уже "понюхавшие пороха" Rust-программисты. Посмотрите, например, сколько эмоций вызывает синтаксис Rust у комментаторов одной из типичных новостей про Rust на OpenNET:

Я начал писать код в моей комнате родительского дома, когда мне было 14. Помню, как читал всё, что мог достать с помощью своего медленного соединения с Интернетом. Затем, когда мне было 20, я подписал первый контракт, став веб-разработчиком и изучая PHP и JavaScript. Мне потребовалось 18 лет, чтобы осознать, что кодинг — только часть профессии. Заметьте, я по-прежнему наслаждаюсь кодингом. Не думаю, что когда-нибудь перестану программировать, даже если это станет просто моим хобби, но есть нечто гораздо большее, чем код. Вот почему я хочу поделиться своим опытом. Я думаю, что иногда разработчики усваивают эти уроки слишком поздно.

Всем привет!

В этой статье я хочу рассказать про реализацию алгоритма сверхдлинного быстрого преобразования Фурье на ПЛИС. Написать эту статью меня побудило желание поделиться личным практическим опытом, который не хотелось бы потерять, оставив информацию только у себя в голове. А поскольку я больше не занимаюсь задачами цифровой обработки сигналов на ПЛИС, то я просто обязан передать доступные мне знания.

В этой статье показана невозможность реализации «классической» схемы очень длинного БПФ даже на самых современных кристаллах ПЛИС и предложен алгоритм, позволяющий это сделать. Также пошагово рассмотрена основная идея алгоритма: от математической составляющей до создания законченного решения на базе ПЛИС с использованием внешней DDR-памяти. Статья затронет тонкости проектирования многоканальных систем обработки для подобного класса задач и, в частности, опишет мой практический опыт.

В сети огромное количество площадок формата Q&A где задаются вопросы из разряда:

• Предложите С++ логер? (C++ logging framework suggestions)
• Какой наиболее эффективный потоко-безопасный С++ логер? (What is the most efficient thread-safe C++ logger)
• Библиотека логирования для игр (Logging library for c games)
• Асинхронный потоко-безопасный С++ логер? (Asynchronous thread-safe logging in C++)

Люди делятся своим опытом и знаниями, но формат таких площадок позволяет лишь показать личные предпочтения отвечающего. К примеру, одним из самых производительных логеров чаще всего называют Pantheios, который даже по тестам производителя тратит больше 100 секунд на запись 1M строк лога, на современном железе это около 30 секунд, быстро ли это?

В этой статье я сравню наиболее известные и заслуженные логеры последних лет и несколько относительно молодых логеров по более чем 25 критериям.

В одной из предыдущих заметок автор пытался рассуждать о том, что при программировании микроконтроллера простой переключатель задач будет полезен в ситуациях, когда использование операционной системы реального времени — это слишком много, а всеобъемлющая петля (super loop) для всех требуемых действий — это слишком мало (Сказал, прямо как граф де Ла Фер). Точнее говоря, не слишком мало, а слишком запутано.

В последующей заметке планировалось упорядочить доступ к общим для нескольких задач ресурсам с помощью очередей на основе кольцевых буферов (FIFO) и специально отведенной для этого отдельной задачи. Разбросав по разным задачам те действия, которые не связаны друг с другом, мы вправе ожидать более обозримый код. А если при этом мы получим некоторое удобство и простоту, то почему бы и не попробовать?

Очевидно, что микроконтроллер не предназначен для решения любой мыслимой задачи пользователя. Тогда, возможно, такого переключателя задач окажется вполне достаточно во многих ситуациях. Короче, небольшой эксперимент вряд ли повредит. Поэтому, чтобы не быть голословным, ваш покорный слуга решил кое-что написать и подвергнуть тестированию свои каракули.

В первой части статьи рассматривается классическая идиома Pimpl (pointer-to-implementation, указатель на реализацию), показываются её преимущества и рассматривается дальнейшее развитие идиом на её основе. Вторая часть будет сосредоточена на том, как уменьшить недостатки, которые неизбежно возникают при использовании Pimpl.

Введение от автора поста

Имея опыт разработки ПО для ответственных систем более чем 8 лет, хочу познакомить сообщество с некоторыми материалами, связанными с разработкой и верификацией ПО для ответственных систем (аэрокосмическая область, медицина, транспорт и промышленность). Получив согласие на перевод и адаптирование ряда интересных статей у зарубежных коллег решил воспользоваться данным ресурсом. Буду рад, если статья заинтересует наше сообщество. В статье использованы материалы фирмы Vector Software, Inc. и рассматривается пример использования автоматизированного верификационного инструментария VectorCAST.
В статье мы акцентируем внимание на стандартах DO-178B/C (КТ-178В), но данная статья актуальна и для применения в соответствии со стандартами: EN 50126, IEC 61508, ISO 26262, FDA, IEC 62304.
На вопросы отвечу в комментариях или в личку.

Введение

В этой статье, мы рассмотрим каким образом платформа тестирования встроенного программного обеспечения (ПО) VectorCAST может быть использована для достижения целей процесса верификации ПО, определенного в разделе 6.0 стандартов DO-178B и DO-178C (КТ-178В) «Требования к программному обеспечению бортовой аппаратуры и систем при сертификации авиационной техники». В документе также освещаются различия между двумя стандартами в части раздела 12 «Процесс квалификации инструментального ПО».

_{Рис. взят с сайта www.extremetech.com/wp-content/uploads/2016/07/MegaProcessor-Feature.jpg}

Всем доброго здравия!

В прошлой статье я рассмотрел вопрос о проблеме доступа к регистрам микроконтроллера с ядром CortexM на языке С++ и показал простые варианты решения части проблем.

Сегодня я хочу показать идею как можно сделать безопасным доступ к регистру и его полям без ущерба эффективности, используя сгенерированные на основе SVD файлов С++ классы.

Всех кого заинтересовал, добро пожаловать под кат. Кода будет много.

Wine — программа для запуска приложений Windows на компьютерах под Unix.

Запуск Wine на Windows был мечтой фанатов, которые следуют зову сердца «Мы делаем то, что должны, потому что не обязаны это делать», по крайней мере, с 2004 года, когда кто-то попытался скомпилировать Wine в Cygwin и сломал реестр хост-системы.

Оправдание: «А как же старые приложения, которые не работают должным образом в последних Windows?». Но мы-то понимаем, что истинная причина — «Я долго страдал за своё искусство, теперь ваша очередь».

Привет, Хабр! Представляю вашему вниманию перевод статьи "Pointers Are Complicated, or: What's in a Byte?" авторства Ralf Jung.

Этим летом я снова работаю над Rust фуллтайм, и я снова буду работать (помимо прочих вещей) над "моделью памяти" для Rust/MIR. Однако, прежде чем я заговорю о своих идеях, я наконец должен развеять миф, что "указатели просты: они являются просто числами". Обе части этого утверждения ошибочны, по крайней мере в языках с небезопасными фичами, таких как Rust или C: указатели нельзя назвать ни простыми, ни (обычными) числами.

Я бы также хотел обсудить часть модели памяти, которую необходимо затронуть, прежде чем мы можем говорить о более сложных частях: в какой форме данные хранятся в памяти? Память состоит из байтов, минимальных адресуемых единиц и наименьших элементов, к которым можно получить доступ (по крайней мере на большинстве платформ), но каковы возможные значения байта? Опять же, оказывается, что "это просто 8-битное число" не подходит в качестве ответа.

Судя по комментам habr.com/ru/post/460831/#comment_20416435 в соседнем посте и развернувшейся там дискуссии, на Хабре не помешает статья, как правильно передавать аргументы в конструктор или сеттер. На StackOverflow подобного материала полно, но тут что-то я не припомню.

Потому что пример в той статье полностью корректен, и автор статьи абсолютно прав. Вот этот пример:

// Хорошо.
struct person {
  person(std::string first_name, std::string last_name)
    : first_name{std::move(first_name)} // верно
    , last_name{std::move(last_name)} // std::move здесь СУЩЕСТВЕНЕН!
  {}
private:
  std::string first_name;
  std::string last_name;
};

Такой код позволяет покрыть все (ну ладно, почти все) возможные варианты использования класса:

Мы собрали книги, которые рекомендуют своим коллегам по цеху резиденты Hacker News. Здесь нет справочников или руководств по программированию, зато есть любопытные издания о криптографии и теоретической информатике, об основателях IT-компаний, есть и научная фантастика, написанная разработчиками и о разработчиках — как раз то, что можно взять в отпуск.

Введение

После прочтения названия может возникнуть закономерный вопрос: зачем в наше время изучать программную реализацию low-speed USB, когда существует куча дешевых контроллеров с аппаратным модулем? Дело в том, что аппаратный модуль, скрывая уровень обмена логическими уровнями, превращает протокол USB в своеобразную магию. Для того же, чтобы прочувствовать как эта «магия» работает, нет ничего лучше, чем воспроизвести ее с нуля, начиная с самого низкого уровня.

С этой целью попробуем изготовить на основе контроллера ATmega8 устройство, прикидывающееся USB-HID'ом. В отличие от распространенной литературы, мы пойдем не от теории к практике, от самого нижнего уровня к верхнему, от логических напряжений на выводах, и закончим «изобретением» той самой vusb, после каждого шага проверяя, работает ли код как ожидалось. Отдельно отмечу, что не изобретаю альтернативу этой библиотеке, а напротив, последовательно воспроизвожу ее исходный код, максимально сохраняя оригинальную структуру и названия, поясняя, для чего служит тот или иной участок. Впрочем, привычный для меня стиль написания кода отличается от стиля авторов vusb. Сразу же честно признаюсь, что помимо альтруистического интереса (рассказать другим сложную тему) имею и корыстный — изучить тему самостоятельно и через объяснение выловить для себя максимум тонких моментов. Отсюда же следует, что какой-то важный момент может быть упущен, или какая-то тема не до конца раскрыта.

Для лучшего восприятия кода я постарался выделить измененные участки комментариями и убрать оные из участков, рассмотренных ранее. Собственно, исходный код и будет основным источником информации, а текст — пояснением что и для чего делалось, а также какой результат ожидается.

Также отмечу, что рассматривается только low-speed USB, даже без упоминания, чем отличаются более скоростные разновидности.

Посты серии:
8. Управляем с телефона-ROS Control, GPS-нода
7. Локализация робота: gmapping, AMCL, реперные точки на карте помещения
6. Одометрия с энкодеров колес, карта помещения, лидар
5. Работаем в rviz и gazebo: xacro, новые сенсоры.
4. Создаем симуляцию робота, используя редакторы rviz и gazebo.
3. Ускоряемся, меняем камеру, исправляем походку
2. Софт
1. Железо

Начав изучать ROS (Robotic operation system), сначала поражаешься, как тут «все сложно», от количества информации про топики, ноды,actions голова идет кругом. И, первое желание — вернуться в управлении роботом на старые добрые скрипты. Но нет. Каждый взрослый мужчина должен собрать для мужчины поменьше что-то, что бы ездило, мигало, пищало. В качестве платформы была выбрана ROS, так как все же это следующий шаг в развитии роботов в мире бездушных ардуино. Предлагается собрать ROS «тележку», которая будет не только дешевая, но и функциональная: сможет поехать по линии на полу, вашим котом, вашим телом :) Первые шаги будут такие:

На написание данной статьи меня вдохновила статья об анализе Сишного printf. Однако, там был пропущен момент о том, какой путь проходят данные после того, как они попадают в терминальное устройство. В данной статье я хочу исправить этот недочет и проанализировать путь данных в терминале. Также мы разберемся, чем отличается Terminal от Shell, что такое Pseudoterminal, как работают эмуляторы терминалов и многое другое.

На русском языке довольно мало информации про то, как работать с ELF-файлами (Executable and Linkable Format — основной формат исполняемых файлов Linux и многих Unix-систем). Не претендуем на полное покрытие всех возможных сценариев работы с эльфами, но надеемся, что информация будет полезна в виде справочника и сборника рецептов для программистов и реверс-инженеров.

Подразумевается, что читатель на базовом уровне знаком с форматом ELF (в противном случае рекомендуем цикл статей Executable and Linkable Format 101).

Под катом будут перечислены инструменты для работы, описаны приемы для чтения метаинформации, модификации, проверки и размножения создания эльфов, а также приведены ссылки на полезные материалы.

На картинке Linux kernel шлёт вам привет через GPIO.

В этой части истории с портированием RISC-V RocketChip на китайскую плату с Cyclone IV мы всё-таки запустим Linux, а также научимся сами конфигурировать IP Core контроллера памяти и чуть подредактируем dts-описание аппаратуры. Эта статья является продолжением третьей части, но, в отличие от изрядно разросшейся предыдущей, она будет довольно короткой.

Многие виды растений и сельхозкультур до сих пор собираются только вручную.

Инженеры из Кембриджского университета (Великобритания) создали рабочий прототип роботизированного сборщика урожая, способного самостоятельно распознавать готовые к срезанию неповрежденные кочаны салата, а также аккуратно их обрабатывать и собирать.

Вот цитата из Линуса Торвальдса за 2006 год:

Я огромный сторонник разработки кода вокруг данных, а не наоборот, и я думаю, что это одна из причин, по которой git был довольно успешным… По сути, я утверждаю, что разница между плохим программистом и хорошим заключается в том, считает ли он более важным свой код или свои структуры данных. Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимоотношениях.

Что очень похоже на «правило представления» Эрика Реймонда от 2003 года:

Сверните знания в данные, чтобы логика программы стала глупой и надёжной.

Здесь просто резюме идей, подобных мысли Роба Пайка от 1989 года:

Доминируют данные. Если вы выбрали правильные структуры данных и всё хорошо организовали, то алгоритмы почти всегда будут самоочевидными. Структуры данных, а не алгоритмы, играют центральную роль в программировании.