Задумывая технологический стартап, вы совсем не обязаны быть асом в электронике, гораздо больше шансов на хорошую идею имеет узкий специалист со знанием основ маркетинга, но, даже заказывая кому-то разработку, ориентироваться в возможностях современной элементной базы и представлять цену решения необходимо обязательно. Иначе можно потребовать невозможного, либо получить устройство с завышенной себестоимостью на устаревшей элементной базе.
Под катом попытка кратко и просто рассказать о возможностях современных микроконтроллеров людям от них далёким. Для тех, у кого есть идея нового электронного устройства, но отсутствует представление о том, что такое микроконтроллер. Те, кто хочет сделать первый шаг от занимательных экспериментов с платформой ардуино к проектированию собственных устройств, также могут найти в ней простые, но полезные советы. Я старался, не останавливаясь на технических подробностях, для этого и книги не достаточно изложить суть и дать несколько простейших, но полезных советов по схемотехнике, чтобы предостеречь от элементарных ошибок начинающих.

Друзья, как вы уже знаете, мы на всех парах готовим новый гик-проект — «Сервер в облаках 2.0», или «Космический ЦОД». В двух словах: 12 апреля мы запустим самопальный сервачок на стратостате на высоту около 30 км, будем передавать на него данные через систему космической связи, а с сервера транслировать данные на Землю по радиосвязи.

И сегодня хотим рассказать о трёх системах космической связи, которые протестируем в своём проекте — Iridium, GlobalStar и «Гонец». Для этого мы смонтируем приёмную аппаратуру рядом с нашим заоблачным сервером.

Это продолжение первой статьи о LPCNet. В первом демо мы представили архитектуру, которая сочетает обработку сигналов и глубокое обучение для повышения эффективности нейронного синтеза речи. На этот раз превратим LPCNet в нейронный речевой кодек с очень низким битрейтом (см. научную статью). Его можно использовать на текущем оборудовании и даже на телефонах.

Впервые нейронный вокодер работает в реальном времени на одном процессорном ядре телефона, а не на высокоскоростном GPU. Итоговый битрейт 1600 бит/с примерно в десять раз меньше, чем выдают обычные широкополосные кодеки. Качество намного лучше, чем у существующих вокодеров с очень низким битрейтом и сопоставимо с более традиционными кодеками, использующими более высокий битрейт.

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

Итак, в предыдущей статье мы поговорили о линковке, загрузке файла ядра и первичной инициализации. Я дал несколько полезных ссылок, рассказал, как размещается загруженное ядро в памяти, как соотносятся виртуальные и физические адреса при загрузке, а так же как включить поддержку механизма страниц. В последнюю очередь управление перешло в функцию kmain моего ядра, написанного на Rust. Пришло время двигаться дальше и узнать, насколько глубока кроличья нора!

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

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

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

Мои цели — структурировать информацию у себя в голове, а так же помочь тем, кто идет похожим путем. Я понимаю, что аналогичные материалы и блоги уже есть в сети, но чтобы прийти к моему текущему положению, мне пришлось долго собирать их воедино. Всеми источниками (во всяком случае, которые вспомню), я поделюсь прямо сейчас.

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

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

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

В аэропорту он купит кофе, расплатившись часами, сделает видеозвонок дочери в Берлин, а потом запустит кинцо онлайн, чтобы скоротать час до посадки.

За это время тысячи MPLS-меток будут навешаны и сняты, миллионы обращений к различным таблицам произойдут, базовые станции сотовых сетей передадут гигабайты данных, миллиарды пакетов больших и малых в виде электронов и фотонов со скоростью света понесутся в ЦОДы по всему миру.

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь

Первые месяцы начинающего растомана как правило сводятся к ударам головой о концепцию времени жизни и владения. Некоторые на этом ломаются, но тем, кто смог пережить — это уже не кажется чем-то необычным или неправильным. Я опишу ключевые моменты, которые, как мне кажется, помогли быстрее и лучше адаптироваться к концепции лайфтаймов и владений.

Разумеется официальный растбук полнее и подробнее, но так же требует больше времени и терпения для полного понимания и впитывания всей информации. Я попытался избежать большого количества деталей и представить всё в порядке возрастания сложности, в попытке сделать данную статью доступней тем, кто или только начал смотреть раст, или же не очень понял начальные моменты из официального растбука.

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

Время жизни (lifetime)

Для начала нам надо освоиться с двумя вещами — конец блока и перемещение значения в другой блок. Позже мы начнём усложнять, добавив "одалживание", "мутабельность" и "скрытую мутабельность".

В этой статье объясняется, как ядру операционной системы получить доступ к фреймам физической памяти. Изучим функцию для преобразования виртуальных адресов в физические. Также разберёмся, как создавать новые сопоставления в таблицах страниц.

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи здесь.

Введение

Из прошлой статьи мы узнали о принципах страничной организации памяти и о том, как работают четырёхуровневые страничные таблицы на x86_64. Мы также обнаружили, что загрузчик уже настроил иерархию таблиц страниц для нашего ядра, поэтому ядро работает на виртуальных адресах. Это повышает безопасность, но возникает проблема: как получить доступ к настоящим физическим адресам, которые хранятся в записях таблицы страниц или регистре CR3?

В этой статье представляем страницы, очень распространённую схему управления памятью, которую мы тоже применим в нашей ОС. Статья объясняет, почему необходима изоляция памяти, как работает сегментация, что такое виртуальная память и как страницы решают проблему фрагментации. Также исследуем схему многоуровневых таблиц страниц в архитектуре x86_64.

Этот блог выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий запрос.

Где-то в конце 1983 — начале 84 года, японская компания Seiko начала продавать первые в истории компьютеризированные часы — Seiko Data-2000 и Seiko UC-2000. Data-2000 имели возможность хранить 2КБ заметок, их нужно было вводить с помощью специальной компактной клавиатуры, которая шла в комплекте. UC-2000, по сути, те же Data-2000 с корпусом другого цвета, но они уже позиционировались как часть Наручной Информационной Системы, которая, среди прочего, включала терминал UC-2200, представляющий из себя компьютер с Z80-совместимым процессором, интерпретатором Бэйсика и термопринтером, но без экрана, в качестве которого использовались часы (как это не странно). Среди прочего, терминал давал возможность загружать на часы приложения со специальных картриджей. Подробнее о линейке ранних умных часов Seiko можно почитать, например, в этой статье. В этом же посте я расскажу, как написал (возможно) первую, за более чем 33 года, программу для этих часов.

Мексиканский наркобарон Хоакин Гусман Лоэра (Эль Чапо)

Не так давно в СМИ промелькнула статья о том, что мексиканского наркобарона Эль Чапо арестовали из-за того, что его IT-шник слил криптоключи в ФБР, а те в свою очередь смогли расшифровать и прослушать его телефонные переговоры.

Давайте пофантазируем и представим, что наркобарон, IT-шник и все, все, все жили бы в России…

Представили? А теперь разберем, какими законами и как регулировалось бы применение криптозащиты в данном фантасмагорическом случае.

Я уже перестал вздрагивать и удивляться, когда звонит телефон и в трубке раздается жесткий уверенный голос: «Вас беспокоит капитан такой-то (майор такой-то), вы можете ответить на пару вопросов?» Почему бы не поговорить с родной полицией…

Вопросы всегда одни и те же. «У нас есть видео с подозреваемым, пожалуйста, помогите восстановить лицо»… «Помогите увеличить номер с видеорегистратора»… «Здесь не видно рук человека, пожалуйста, помогите увеличить»… И так далее в том же духе.

Чтобы было понятно о чем речь — вот реальный пример присланного сильно сжатого видео, где просят восстановить размытое лицо (размер которого эквивалентен примерно 8 пикселям):


И ладно бы только русские дяди Степы беспокоили, пишут и западные Пинкертоны.

Raspberry Pi — невероятно популярное устройство, известное своей доступностью, универсальностью, возможностями и активным сообществом. Легко найти фанатские сайты и статьи, но большинство людей не знают о его слабых местах, пока сами не пострадают от них и не поищут информацию на форумах.

Постараюсь рассказать о некоторых вопросах, с которыми я столкнулся лично, а также о некоторых типичных проблемах, которые чаще всего появятся у людей, ничего не подозревающих об этом. И, наконец, почему я не рекомендую Pi для некоторых приложений, в частности, NAS-услуг, таких как NextCloudPi и Open Media Vault. Надеюсь, это сэкономит мне время, чтобы не повторять всё это на форумах.

Авторы — Джон Хеннесси и Дэвид Паттерсон, лауреаты премии Тьюринга 2017 года «за новаторский систематический и измеримый подход к проектированию и проверке компьютерных архитектур, оказавший долговременное влияние всю отрасль микропроцессорной техники». Статья опубликована в журнале Communications of the ACM, февраль 2019, том 62, № 2, стр. 48-60, doi:10.1145/3282307

«Те, кто не помнит прошлого, обречены повторить его» — Джордж Сантаяна, 1905

Свою лекцию Тьюринга 4 июня 2018 года мы начали с обзора компьютерной архитектуры, начиная с 60-х годов. Кроме него, мы освещаем актуальные проблемы и пытаемся определить будущие возможности, которые сулят новый золотой век в области компьютерной архитектуры в следующем десятилетии. Такой же, как в 1980-е, когда мы проводили свои исследования по улучшению в стоимости, энергоэффективности, безопасности и производительности процессоров, за что и получили эту почётную награду.

Ключевые идеи

• Прогресс программного обеспечения может стимулировать архитектурные инновации
  
• Повышение уровня программно-аппаратных интерфейсов создаёт возможности для инноваций архитектуры
  
• Рынок в конечном итоге определяет победителя в споре архитектур

by Niklaus Wirth
Professor (retired)
Swiss Federal Institute of Technology (ETH)
Zurich, Switzerland

В 1988 году мы с Юргом Гуткнехтом завершили и опубликовали язык программирования Оберон [1, 2], который являлся преемником двух других языков, Паскаля и Модулы-2, разработанных мной ранее. Язык Оберон был спроектирован нами изначально как более рациональный и эффективный, чем Модула-2, что облегчило студентам академической системы образования освоение компьютерной науки. Не останавливаясь на достигнутом, в 1990 году мы построили современную операционную систему (ОС) Оберон для рабочих станций, использующую окна и возможности для обработки текстов. Затем мы опубликовали книгу, раскрывающую детали как компилятора Оберона, так и одноимённой ОС. Книга, названная «Проект Оберон», включала в себя исходные тексты системы.

Несколькими годами позднее мой друг Пол Рид предложил мне издать репринт книги, в силу её значимости для изучения системной архитектуры и дающей хорошую стартовую точку для желающих строить надёжные системы c нуля.

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

Привет, Хабр!

Почитал я некоторые ранее опубликованные статьи о том, как жить славному молодцу, перед которым встала задача спаять 10-50-100 устройств из резисторов и микросхем, и взгрустнул, ибо во всех в них советы были даны если не вредные, то и не сильно полезные.


А вот, например, совет держать включённый паяльник за ручку — полезный!

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

• регулярно надо делать 5-10-50-100 плат с SMD-компонентами
• по возможности быстро
• по возможности дёшево

Если вы можете позволить себе — что по срокам, что по деньгам — услуги «Резонита» или «Компэла» (сотрудничающего, впрочем, с «Резонитом») по сборке модулей под ключ, то текст ниже в общем и целом не для вас. Однако, на практике даже в достаточно крупных компаниях люди, занимающиеся опытными образцами, часто собирают их сами — потому что это занимает пару дней вместо недели, потому что всегда можно на ходу что-то подправить, потому что не надо бегать между начальством и бухгалтерией со счетами и актами… В мелких же вопрос упирается попросту в деньги.

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

1. Блокчейн

Сейчас, когда я пишу эту статью курс Bitcoin упал более чем в 5 раз относительно максимального значения и рассказывая о том, что я делал что-то связанное с блокчейн первое, что я слышу это нескрываемый скепсис — “кому теперь нужен весь этот ваш блокчейн”.

Да, действительно хайп вокруг блокчейна прошел. Но технологии лежащие в основе остались, они развиваются и будут продолжать развиваться и использоваться в определенных нишах.

На картинке ниже фото двух версий платы интернет-радиоприемника WOLNA-1 Слева до того, как я осознал как оптимизировать себестоимость, и справа после. Для сравнения: 120 точек пайки против 300, 20 компонентов против 80, 14 пунктов в BOM вместо 31. И при этом функционал стал шире- появился контроллер питания литиевых аккумуляторов. Кому интересно как это произошло и сколько помогло сэкономить, добро пожаловать под кат. Так же этот материал будет полезен неопытным заказчикам разработки, обращающимся к фрилансерам.

Часть 5. В масштабе Вселенной

Предыдущая часть. Краткое содержание предыдущей части.

Для нас выход на околоземную орбиту очень дорог. А как обстоят дела с этим вопросом у других цивилизаций — если они, конечно, есть?