От тысяч до миллиардов. Сколько строк содержат кодовые базы Google, Facebook, Twitter и других ресурсов
Ресурс World of Statistics привел данные по количеству строк кода, содержащему известные мировые программные платформы.
Текст: Вікторія Горбік Теги: код, google, facebook, twitter
Нашли ошибку в тексте — выделите её и нажмите Ctrl+Enter. Нашли ошибку в тексте — выделите её и нажмите кнопку «Сообщить об ошибке».
УЧАСТЬ В АЗАРТНИХ ІГРАХ МОЖЕ ВИКЛИКАТИ ІГРОВУ ЗАЛЕЖНІСТЬ. ДОТРИМУЙТЕСЯ ПРАВИЛ (ПРИНЦИПІВ) ВІДПОВІДАЛЬНОЇ ГРИ.
Ліцензія видана ТОВ «СЛОТС Ю.ЕЙ.» на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 15.09.23 (рішення КРАІЛ №245 від 31.08.2023); ТОВ «СЛОТС Ю.ЕЙ.» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 26.04.2021 (рішення КРАІЛ №150 від 12.04.2021); ТОВ «СПЕЙСИКС» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 08.02.2021 (рішення КРАІЛ №34 від 02.02.2021); ТОВ «ГЕЙМДЕВ» – на провадження діяльності з організації та проведення азартних ігор казино у мережі Інтернет від 16.02.2021 (рішення № 47 від 10.02.2021).
Google — это 2 миллиарда строчек кода
Издание Wired обратило внимание на выступление сотрудницы Google Рейчел Потвин «The Motivation for a Monolithic Codebase», которое состоялось в рамках конференции в Кремниевой долине. В своём докладе она оценила число строк кода, который отвечает за работу всех интернет-сервисов Google: выяснилось, что число равно примерно 2 миллиардам. Если провести некорректное сравнение и учесть, что Windows содержит примерно 50 миллионов строк кода, то получается, что с 1998 года в Google успели написать 40 операционных систем от Microsoft, которая разрабатывается с 1985 года. Мало того, весь этот «Google-код» находится в едином репозитории, которым ежедневно пользуются 25 000 сотрудников поискового гиганта.
Рейчел заметила, что такой принцип хранения исходников позволяет разработчикам Google «… чувствовать необычную свободу в использовании и комбинировании кода других проектов». Единственное существующее ограничение — это доступ к коду, реализующему алгоритмы ранжирования Google’s PageRank, которые являются основой бизнеса, критичного для поискового гиганта. К этим файлам имеют доступ только специально выделенные сотрудники. В целом для управления кодом в Google используется собственная VCS, которая называется Piper и которая в свою очередь опирается на серьёзную инфраструктуру, состоящую из 10 дата-центров.
Любопытна статистика, приведённая Рейчел. По её словам, Piper управляет 85 терабайтами данных «Google-кода», в который ежедневно 25 000 разработчиков делают примерно 40 000 коммитов. Таким образом за каждую неделю модифицируются 250 000 файлов и 15 миллионов строк кода. В сравнении с Linux, которая вся насчитывает примерно 40 000 файлов, работа программистов Google выглядит фантастической.Также Рейчел отметила, что сейчас Google и Facebook вместе работают над новой open source VCS, которую можно будет использовать на проектах любого масштаба, сравнимого даже с самой Google. Интересно, что основой будущей VCS является не модная среди разработчиков git, а Mercurial, которую пытаются масштабировать до уровня, с которым приходится иметь дело обоим интернет-гигантам.
В современном автомобиле строк кода больше чем…
Количество строк кода в современном автомобиле в 200 раз больше чем в Шаттле, в 60 раз больше, чем в истребителе F-22 Raptor, в 50 раз больше, чем в телескопе Хаббл, в 20 раз больше чем в марсоходе Curiosity, в 4 раза больше чем в истребителях пятого поколения, в 2 раза больше, чем в большом адронном коллайдере или Facebook, если распечатать весь код на бумаге, то стопка будет высотой 200 метров. (по данным на 2009-2012 год)
Данные по количеству строк кода в современном автомобиле вызвали бурные споры на Reddit. Вопросы на темы от «В каком месте эти строчки прячутся, если у микроконтроллеров ограничена память?» до «Разве количество строк кода хоть что-то значит?»
Сравнительные данные по количеству строк кода (SLOC) в различных проектах довольно интересные.
Маргарет Гамильтон и её исходники кода для посадки Апполон-11
Количество строк кода меньше миллиона
10.000 — Unix v 1.0 (1971) [пруф]
10.000 — простая игра для iOS app [пруф]
14.000 — Win32/Simile virus [пруф]
39.000 — iOS app — photo editing [пруф]
80.000 — электрокардиостимуятор [пруф]
120.000 — первая версия Photoshop v1 (1990) [пруф]
200.000 — браузер Camino [пруф]
310.000 — движок Quake 3 [пруф]
400.000 — Space Shuttle [пруф]
> миллиона
Билл Гейтс в 1994 году демонстрирует, что на компакт-диск вмещается больше информации, чем на высоченные стопки бумаги.
1.000.000 строк кода помещается на 18.000 страницах, 2 метра высотой (в 14 раз больше чем «Война и мир», в 25 раз больше чем «Улисс», в 63 раза больше чем «Над пропастью во ржи»)
1.000.000 — игра Crysis [пруф]
1.140.000 — геном бактерии, вызывающей сифилис [пруф]
1.200.000 — Age of Empires Online [пруф]
1.200.000 — модель климата планеты CESM [пруф]
1.700.000 — истребитель F-22 Raptor [пруф]
1.800.000 — Linux Kernel 2.2.0 (1999) [пруф]
2.000.000 — Космический телескоп «Хаббл» [пруф]
2.000.000 — движок Unreal Engine 3 [пруф]
2.500.000 — Windows 3.1 (1992) [пруф]
3.500.000 — управляющий софт в дронах [пруф]
3.500.000 — софт для управления петабайтами данных с адронного коллайдера ROOT [пруф]
4.500.000 — Photoshop CS 6 (2012) [пруф]
4.500.000 — Windows NT 3.1 (1993) [пруф]
4.700.000 — HD DVD Players on XBox [пруф]
5.000.000 — марсоход Curiosity [пруф]
5.200.000 — Linux kernel 2.6.0 (2003) [пруф]
5.500.000 — сервер World of WarCraft [пруф]
6.100.000 — Windows XP Service Pack 1
6.500.000 — авионика и online support systems на Boeing 787 [пруф]
6.700.000 — Google Chrome [пруф]
7.500.000 — Windows NT 3.5 (1994) [пруф]
9.000.000 — LibreOffice [пруф]
9.500.000 — Windows NT 3.51 (1995) [пруф]
9.700.000 — Firefox [пруф]
10.000.000 — электроавтомобиль Chevy Volt [пруф]
10.000.000 — бухгалтерский программный пакет Intuit Quickbooks [пруф]
11.300.000 — OpenOffice [пруф]
11.500.000 — Windows NT 4.0 (1996) [пруф]
12.000.000 — Android (включая 3 миллиона строк на XML, 2.8 миллиона строк на C, 2.1 миллиона строк на Java и 1.75 миллиона строк на C++) [пруф]
12.500.000 — библитотеки Mozilla Core [пруф]
12.500.000 — MySQL [пруф]
14.000.000 — весь софт Boeing 787 [пруф]
15.000.000 — Android (верхняя оценка)
15.000.000 — Linux 3.1 (2013) [пруф]
20.000.000 — Linux kernel pre-4.2 (2015) [пруф]
23.000.000 — Apache Open Office [пруф]
24.000.000 — истребитель-бомбардировщик пятого поколения F-35 Fighter [пруф]
25.000.000 — Microsoft Office (2001) [пруф]
29.000.000 — Windows 2000 (2000) [пруф]
30.000.000 — Microsoft Office for Mac (2006) [пруф]
37.600.000 — Symbian [пруф]
40.000.000 — Windows 7 [пруф]
40.000.000 — Windows XP (2001) [пруф]
45.000.000 — Microsoft Office (2013) [пруф]
50.000.000 — Large Hadron Collider [пруф]
50.000.000 — Microsoft Visual Studio 2012 [пруф]
50.000.000 — Windows Vista (2007) [пруф]
62.000.000 — Facebook (without backend code) [пруф]
68.000.000 — Debian 5.0 codebase [пруф]
86.000.000 — Mac OS X 10.4 [пруф]
100.000.000 — софт в типичном новом автомобиле 2013 года [пруф]
324.000.000 — Debian 5.0 (all software in package) [пруф]
2.000.000.000 — Google [пруф] стопка распечатанных страниц высотой 3.6 км
Большая картинка с инфографикой
Мы копнули первоисточники и выяснили, что первыми про 100 миллионов строк кода заявили в журнале IEEE Spectrum, сославшись на почетного профессора Мюнхенского технического университета Манфред Брой, который заслужил медаль Конрада Цузе (почти нобелевка в области computer science) в публикации 2009 «This Car Runs on Code»:
These are impressive amounts of software, yet if you bought a premium-class automobile recently, ”it probably contains close to 100 million lines of software code,” says Manfred Broy, a professor of informatics at Technical University, Munich, and a leading expert on software in cars. All that software executes on 70 to 100 microprocessor-based electronic control units (ECUs) networked throughout the body of your car.
- Публикация 2007 года Манфреда Броя «Engineering Automotive Software».
Подписывайтесь на каналы:
@AutomotiveRu — новости автоиндустрии, железо и психология вождения
@TeslaHackers — сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
Количество строк кода в разных приложениях, системах
А вы задумывались из чего состоят системы которыми вы пользуетесь? Ответ на этот вопрос с вашей стороны меня не волнует (извините за возможную грубость). Сегодня, именно сегодня, я в любом случае расскажу вам о количестве строчек кода в разных проектах.
Начинаем с разных «операционок» — без них никуда.
1. Windows NT 3.1 — появилась на свет в далеком 1993, уже тогда содержала в себе больше 4 млн. строчек на С и С++.
2. Windows NT 3.5 — родилась на год позже своего брата на С++ о котором мы говорили ранее.
Количество строк кода достигало 8 млн. Умный читатель может вычесть из этого количества 4 млн. — получить число на которое выросло число строчек кода за год.
3. А теперь вышедшая в 1996 году Windows NT 4.0, содержащая в себе 11-12 млн. строк.
4. Windows 2000. Просто молчу. целых 30 млн строк.
Стоит признать, это не предел, ведь дальше у нас Windows XP.
5. Windows XP — около 45 млн. строчек. Если я сказал, что предыдущие ОС содержали в себе много кода — прошу простить.
6. Windows 10 — более 60 млн. строк. По настоящему сложная сборка.
Что-то мы застряли на «Винде». Давайте перейдем к Linux.
1. Linux 0.1 — 10 239 строчек. Не стоит забывать, что выпуск этой версии состоялся в 1991 году.
2. Linux 1.0.0 вышедший спустя 3 года состоял из более чем 170к строк.
3. Linux 1.2.0 появившийся на свет в 1995 был создан при помощь 300к строчек.
4. Linux 2.0.0 — 777 956 строк.
5. Linux 2.2.0 — 1 800 847 строк.
6. 2001 год — рождается Linux 2.4.0 состоящий из 3 377 902 строк кода.
7. Linux 2.6.0 — 5 929 913 строк.
8. Linux 2.6.32 — 12 606 910 строк.
9. 2017 год на дворе — выходит Linux 4.11.7 основанный на 18 млн. строчках.
Android? 12 млн. строк.
Переходим к браузерам.
1. Google Chrome — 7 млн. строчек кода на C++.
2. Firefox — 18 млн. строк. В создании Firefox замешаны C++, C, Javascript, Rust, HTML, CSS, XUL.
Переход к обсуждению приложений, программ, фреймворков.
1. Photoshop CS 6 — 10 млн. строк кода. Величайшее изобретение, ежедневно помогающее дизайнерам, верстальщикам, разработчикам, блогерам.
2. 1C — 3 млн. строк.
3. MySql — 12 млн. строчек кода.
4. Unreal Engine 3 — около 2 млн. строк на C++. Движок для создания игр.
5. Bootstrap — популярный фреймворк для создания сайтов и веб-приложений. Состоит из 70к строчек.
6. React — популярный фреймворк от Facebook. Чуть меньше 160к строк.
7. Vue.js — популярный фреймворк для создания пользовательских интерфейсов.
Надеюсь вам понравилось!
4 года назад
На счет линукса — некорректно.
Когда вы приводилиипримеры винды, вы брали операционную систему. А линукс — это не операционная система — это ядро операционной системы. А операционная система с ядром линукс будет, например: linux mint, ubuntu, cent os, debian, fedora и много других. Поэтому количество строк в линукс-дистрибубутивах будет больше. Например в линукс минте браузером по умолчанию является фаерфокс, а это значит, что там в ядре линукса 18млн. строк + в фаерфоксе тоже 18млн. строк и еще много всякой хрени.
4 года назад
Для unreal engine взяли скриншот окна cinema 4d. Автор «потрудился» над статьёй как надо.
4 года назад
Игра «Посадка на Луну» на калькуляторе МК60: 1 (одна) строка кода.
4 года назад
А vue чем от всех отличается?
раскрыть ветку
4 года назад
Полный бред полного чайника.
Почти все сравнения некорректны типа кода в ЯДРЕ LINUX коим явлется Linux и ПОЛНОЙ СИСТЕМЕ где в 10 раз больше в GNU окружении даже уровня IceWM, а в полноценном DE ещё процентов 20 накинет как в ядре. А винда это полная система, ядро у неё к слову, достаточно простое и рядом с NET не стояло, так же начиная с 2000/xp винды не особо росло.
Похожие посты
16 часов назад
Когда на математике решил другим способом
Показать полностью 1
4 дня назад
Шпаргалка по кодам состояния ответа HTTP
4 дня назад
В эпоху киберпанка хочется простого человеческого киберпогулять
Поддержать
5 дней назад
Рукалицо + сочуствие этому разрабу
Показать полностью 1
5 дней назад
Будни программистов
Показать полностью 1
11 дней назад
Что общего у бабок и программистов?
Топовый автор
Подписаться
15 дней назад
2 браузера и тесты во время стрима/нагрузка на ПК/вопрос
Если что Процессор AMD Ryzen 2200, ОЗУ 8 гб, windows 10 pro
Поддержать
15 дней назад
Записал на YouTube бесплатный обучающий курс по инженерии данных, кому интересно — можете ознакомиться
IT, Python3, SQL, Linux, Data Engineering, разработка, Программирование, обучение, Войти в IT, Airflow
Меня зовут Александр.
В IT работаю уже почти 15 лет, большую часть этого времени что-то делаю с данными: от инженерии и аналитики — до машинного обучения.
И меня поразило: из 10 человек, которые пытались в IT вкатиться через Python, все 10 человек шли в Backend — разработку. Где вакансий не так уж и много, т.к. приходится конкурировать с разработчиками на PHP, Go, Node.js
Я подумал: «Странно, почему все в бекендеры пытаются пойти?». Дело оказалось в том, что про инженерию или аналитику данных люди даже не слышали (а там вакансий даже больше, чем на бекенд на Python. Сейчас просто дикая нехватка аналитиков данных).
А почему не слышали — потому что на русскоязычном ютубе об этом информации практически нет.
Я решил исправить это дело, набрал бесплатно группу в 12 человек и начал их учить на инженеров данных. Все снятые видео выкладывал на ютуб.
Почему стоит входить в IT через инженерию данных:
Бесплатный курс «С 0 на инженера данных» тут:
Записал 40 уроков — их реально пройти за 4 месяца со всеми ДЗ.
Рассказываю про Python, Linux, SQL, Airflow.
Видоса до 4-го бывают иногда проблемы со звуком, потом эти проблемы решил.
Записывал всё для людей, начинающих с 0 — так что не стоит на уроке с типами данных писать, что я не даю на 1-2 уроке людям сразу мутабельность — у меня была задача идти в таком темпе, чтобы новички всё поняли и не забили.
Надеюсь кому-то это поможет изменить свою жизнь и начать нормально зарабатывать.
Показать полностью 2
27 дней назад
Когда в первый раз используешь «плюсы»:
30 дней назад
Ревьюер
Моя мама сегодня увидела мой код и сказала:
«Получается твоя работа — писать текст, используя рандомные английские слова и символы причудливых цветов? Не знаю, почему тебе за это хорошо платят. Этот текст даже нормально не выровнен по левому краю»
Она была бы отличным ревьюером кода.
Показать полностью
Посты о ремонте и моддинге ретрогаджетов.
Подписаться
1 месяц назад
Мобильные экранчики в ваших проектах: большой и понятный о гайд о различных дисплеях!
Пожалуй, немалая часть моих читателей так или иначе интересуется DIY-тематикой. И в различных самодельных девайсах порой есть необходимость вывести какую-либо информацию на дисплей, будь это текст, графики или даже какая-то анимация! Для разных задач существуют самые разные дисплеи и в сегодняшнем материале я хотел бы систематизировать и собрать подробнейший гайд об использовании дисплеев с нерабочих мобильных телефонов: какие бывают протоколы и шины данных, как читать схемы устройств и определять контроллеры дисплеев, какие дисплеи стандартизированы, а какие придётся реверсить самому и как быть с подсветкой. В практической части статьи мы подключим дисплей используя протокол MIPI DBI к RP2040 с использованием DMA. Интересно? Тогда добро пожаловать в статью!
❯ Виды дисплеев и их протоколы
Пожалуй, ЖК-дисплеи с самого момента их появления стали основным инструментом для вывода информации и взаимодействия с пользователями. Первые ЖК-панели были монохромными и требовали отдельный драйвер, который занимался выводом изображения на экран и формированием необходимых для его работы напряжений.
Сейчас же всё гораздо проще и каждый любитель DIY-электроники может и сам подключить дисплейчик к своему проекту и использовать в необходимых ему целях. Ведь не зря написаны десятки библиотек по типу AdaFruit LCD, которые упрощают задачу программисту и дают ему возможность оперировать готовыми и простыми операциями по типу «вывести линию» или «отрисовать изображение». Однако, готовые библиотеки — это, конечно, здорово, но они не всегда дают понимание о том, как работают такие дисплеи на программном и аппаратном уровне. И первая часть статьи как раз и будет посвящена этому.
Всего в мире дисплейных матриц существует несколько общепринятых аппаратных протоколов. Некоторые из них можно легко использовать в собственных проектов с микроконтроллерами, с другими придется повозиться:
- Параллельная шина 8080 — одна из самых простых и понятных шин данных, как в теории, так и на практике. Суть её очень простая: на каждый бит отводится по одной сигнальной линии, плюс две дополнительные линии для сообщения статуса передачи: RD означает запрос чтения, а WR — запрос на запись. Большинство дисплеев использует девятый, неявный бит D/C, который сообщает контроллеру, задаём ли мы номер команды, или уже пишем аргументы для этой команды. Что самое приятное — шина по сути стандартизирована и во многих дисплеях команды на старт записи в видеопамять, а также получение ID-контроллера идентичны. Шина бывает 8-битной и 16-битной (её состояние задаётся битами IM0..IM2 и используется не только для подключения дисплеев, но и микросхем параллельной флэш-памяти, ОЗУ и т. д. Такие шины используются в дисплеях с разрешением до 480×320.
- SPI — шина, которая наверняка знакома большинству моих читателей. Достаточно простая — у нас есть две сигнальные линии с входным (MISO) и выходным (MOSI) битом, плюс сигнал тактирования, который согласовывает передачу данных. Таким образом, шина получается полнодуплексной. Фактически, каждый байт передаётся по одному биту через одну сигнальную линию, что, по сравнению с 8080, заставляет повышать тактовую частоту контроллера SPI, но при этом занимает гораздо меньше пинов самого МК или процессора. В программном плане, большинство дисплеев представленных в различных интернет-магазинах полностью совместимы с дисплеями 8080, ведь SPI — просто один из режимов работы. Единственный нюанс — из SPI дисплея не всегда можно вычитать ID-контроллера и вообще что-либо читать из регистров дисплея.
- I2C — относительно редко используемая шина для дисплеев из-за её невысокой производительности, однако, тем не менее, очень подходящая для МК (благодаря использованию только двух сигнальных линий — SDA для данных и SCL для тактирования. Даже чипселект здесь программный благодаря тому, что каждое устройство имеет собственный адрес!), однако её можно найти в дисплеях некоторых телефонов из самого начала 2000-х годов.
- TTL/параллельный RGB — тут, в общем-то, меня упрекали пару раз из-за того, что я продолжаю называть её TTL, но так сложилось исторически — даже в даташитах эту шину называют именно так. С логической точки зрения она очень простая: у нас есть 16/24 сигнальные линии, где 5 (или 8) бит используются для красного и синего канала и 6 (или опять же 8) бит используются для зеленого цвета (т. е. в 16-битном цвете у нас RGB565, а в 24-битном — RGB888). К ним идут сигналы HSYNC для горизонтальной синхронизации и VSYNC для вертикальной. Вообще, необязательно использовать все сигнальные линии предоставляемые дисплеем — можно использовать, например, RGB332 и использовать всего 8 сигнальных линий. Однако для отображения картинки, необходимо строго соблюдать тайминги синхронизации, иначе дисплей будет просто показывать белый цвет. Помимо цифрового варианта, бывает также аналоговый, очень похожий на телевизионный RGB или VGA. Такие дисплеи обычно используются для матриц до 1024×768 включительно.
- MIPI DSI — протокол, используемый для дисплеев высокого разрешения — от 480×800 и выше, его можно встретить в большинстве современных смартфонов и планшетов. Кроме того, такие дисплеи используют относительно мало пинов — по два на каждый канал LVDS (обычно в смартфоне около двух-четырех каналов) + две сигнальные линии на тактирование. Звучит всё хорошо? Как-бы не так: протокол дифференциальный и на каждый канал (т. е. логический бит) приходится по две сигнальные линии — одна с положительная, а вторая отрицательная. Затем одна вычитается из другой и получается окончательный сигнал, а сделано это для уменьшения помех от передачи данных по нескольким линиям с очень высокой тактовой частотой без увеличения битности шины.
- LVDS/eDP — Протоколы, используемые в матрицах ноутбуков, телевизоров и иногда планшетов. На физическом уровне близки к DSI, на программном — если честно, не знаю, но наслышан о некой стандартизации и высоком уровне совместимости. Даже «неродные» ноутбучные матрицы вполне «заводятся», максимум после перепрошивки родной EEPROM, даже если дисплей другого разрешения!
В списке выше, мы рассмотрели несколько популярных аппаратных шин для дисплеев. В данной статье, мы разберемся в программных особенностях таких дисплеев и узнаем, где взять по дисплею одного из следующих типов: SPI, I2C, а также 8080.
❯ Виды дисплеев и их протоколы
Пожалуй, писать статью, где были бы только готовые примеры без объяснения принципов работы «под капотом» было бы плохим тоном. Поэтому предлагаю немного разобраться в системе команд для самых распространенных контроллеров дисплеев в наше время.
У рассматриваемых нами дисплеев есть собственная видеопамять, благодаря чему нет необходимости соблюдать тайминги, а также общий набор команд (или аппаратных регистров), которые мы можем записывать и тем самым менять поведение дисплея. Если мы просто подадим питание на дисплей и попытаемся что-то вывести — у нас ничего не выйдет, поскольку при каждом аппаратном RESET’е, состояние большинства регистров, кроме SleepOn и PowerOn не определено и может содержать в себе любой «мусор». Для корректной работы дисплея, нам необходимо послать определенный набор команд, называемый инициализацией, который установит настройки драйвера дисплея, такие как контраст, параметры цветности, направление развертки изображения из VRAM и т. д. Пожалуй, стоит сразу отметить, что некоторые люди называют регистры дисплея командами — это означает одно и тоже!
Пример инициализации. На самом деле, не все люди делают такую простыню из вывозов функций чтения/записи регистров дисплея, поскольку это кушает драгоценный ROM. На AVR, например, команды инициализации можно хранить в ROM и читать из PROGMEM.
Если дисплей инициализирован неправильно, то мы можем наблюдать некорректную развертку, артефакты на дисплее и полосы: если вы когда-нибудь прошивали смартфоны прошивками других ревизий, то могли замечать подобный эффект сами.
Набор команд для контроллеров дисплеев частично стандартизирован спецификацией MIPI DBI, которая описывает и закрепляет некоторые конкретные адреса регистров, общие для всех контроллеров дисплея. К ним относится, например, установка «окна» для записи (0x2B и 0x2A), sleepout (0x11) и некоторые другие. Проприетарными командами остаются настройки питания, развертки, контраста и самого драйвера дисплея. Ну и всяческие LUT, а также палитровые режимы (если они есть) тоже проприетарные.
Пример одной из таких стандартизированных команд:
Почти во всех дисплеях есть разделение отправляемых байтов на команду (или выборка номера регистра для чтения/записи) и на данные. Как обработать текущий байт определяет отдельный пин (или бит, в зависимости от конфигурации дисплея), называемый D/C (Data/Command), иногда также можно встретить названиеRS. Обычно, при записи команды, D/C должен быть на низком уровне, при записи данных, соответственно, на высоком. Суть простая: записываем номер команды (или регистра) при низком D/C, а затем дописываем необходимые аргументы (или конфигурацию регистра) при высоком уровне D/C.
Примерно так:
Касательно сброса, то в дисплеях обычно существуют два вида этого процесса: аппаратный сброс через соответствующий пин и программный с помощью специальной команды. Пин RESET никогда нельзя оставлять в «воздухе» (т. е. не подключенным) в надежде что «да состояние пинов МК после ресета известно, мусора на шине явно не будет». Мусора может и не будет, а вот дисплей упадет в вечный ресет, поскольку ожидает перехода сигнала RESET в высокий уровень. Тоже самое касается и пина CS, отвечающий за выбор устройства на шине. Если вам не нужен CS и у вас висит только одно устройство на шине — просто притяните его к массе. Некоторые контроллеры (например, ILI9325) адекватно реагируют на CS «в воздухе», некоторые — нет. Только после того, как RESET оказался на высоком уровне, дисплей начнёт принимать команды:
Переходим конкретно в выводу данных. Для начала вывода изображения на дисплей, нам необходимо выполнить команду 0x2C, которая переведет контроллер дисплея в режим записи данных в видеопамять. После этого, нам остаётся лишь установить высокий уровень на пине D/C и просто слать непрерывный поток пикселей. Контроллер дисплея сам инкрементирует координаты на дисплее и после того, как координаты выйдут за границы нужной области, дисплей сам их переведет в изначальные. Таким образом, достаточно лишь один раз проинициализировать дисплей и просто гонять в него данные, например, с помощью DMA.
Всё просто и понятно 🙂
❯ Дисплеи с шиной 8080
Пожалуй, подобные дисплеи найти проще всего, поскольку они использовались в большинстве кнопочных телефонов из нулевых. Такие экранчики можно встретить во многих моделях Nokia, Samsung, LG, Fly, Sony Ericsson и большинстве китайских телефонов. С поиском распиновки и разводкой таких дисплеев всё относительно просто и одновременно сложно: на некоторые модели телефонов (например, почти на все Nokia) можно свободно найти схему в гугле и узнать распиновку коннектора дисплея… однако этот коннектор сначала надо сдуть и развести на breakout-плате, или под микроскопом вывести перемычки. В некоторых случаях (например, Siemens S-серии), дисплей просто прижимался к контактам на плате, а сами контакты имели более чем паябельный шаг.
Из схемы на Nokia N70. Этот дисплей применялся во многих Symbian-смартфонах Nokia тех лет: N-Gage/N-Gage QD, N70, N72, 6600 и некоторых других.
Но особо удобными можно считать дисплеи с паябельными шлейфами с большим шагом пинов — такие можно встретить в некоторых телефонах Samsung и большинстве китайских телефонов. Пытливый читатель спросит «так это ж китаец, где ты на него схему будешь искать?». И вот тут, китайские производители нас приятно порадуют, поскольку за редким исключением, такие дисплеи имеют стандартизированную распиновку: лично мне известны матрицы 37 Pin, 39 Pin и 44 Pin. Как найти для них распиновку? Пишем на «алике» или «таобао» 37 pin lcd tft и смотрим: в описании продавец частенько прилагает распиновку (правда учтите, что 37 pin не имеет пинов IM для настройки ширины шины, а 16-битный интерфейс может быть слишком прожорилвый по числу пинов):
В случае с китайцами, иногда можно найти и схему (нажимайте на зеленую стрелку) на устройство: например, почти на все модели Fly схемы лежат в свободном доступе, где почти всегда можно найти распиновку дисплея. Иногда производитель даже выводит тестпоинты на все сигнальные линии и дисплей с тачскрином можно использовать, не выпаивая его с платы!
Распиновка на Fly IQ239. На нижней части изображения, вы можете увидеть, что такие, безусловно, здоровенные дисплеи можно купить за копейки и сейчас 🙂
Но задумывались ли вы когда-нибудь, откуда на тачскринах в дисплеях с «али» взялись кнопки «домой», «сообщения», «телефон»? Это ведь те самые дисплеи, которые использовались в «ноклах», просто припаянные к удобной плате! 🙂 Кроме того, на китайские дисплеи без проблем можно найти даташит: обычно они используют контроллеры от ST или ILI, в зависимости от разрешения дисплея.
Кстати, про девайс на фото выше есть отдельная статья, где я рассказываю что такие девайсы необязательно дербанить но запчасти, ведь под них можно писать полноценные нативные программы!
Концептуально, аппаратная реализация протокола одновременно простая и понятна любому: программа устанавливает состояние каждого бита передаваемого байта на сигнальных линиях D0..D7 (либо D00..D15, если шина у нас 16-битная), а затем просто «дёргает» линию RD (Read или чтение), либо WR (Write или запись) по переходу из низкого уровня в высокий, благодаря чему контроллер дисплея понимает, что байт (или слово в случае 16-битного интерфейса) можно «забирать» с шины. По переходу из высокого уровня в низкий, контроллер снова переходит в режим ожидания следующего байта с шины.
Где взять такие дисплейчики? Да почти везде! Но лучше всего брать дисплеи с китайчиков, которые можно развести на вот таких breakout-платах, которые можно заказать на алике за пару сотен рублей.
Обратите внимание на то, как по свински припаивают подсветку на некоторых дисплеях. И это завод! Лучше сразу прозвоните прежде чем подавать питание. Я, вот, забыл, понадеялся на производителя и по итогу сжёг подсветку 🙁
Другой вопрос, где искать на них информацию? Помимо схем, можно просто поискать на алике «37 pin lcd tft», «39 pin tft lcd», «24 pin tft lcd» и т. п. Обычно продавцы сами выкладывают распиновку и даже прикладывают ID контроллера дисплея. Поскольку иногда различия в распиновках всё же попадаются, обращайте внимание на то, куда у вас идут дорожки от подсветки и от резистивного тачскрина (если есть), а также вызванивайте все пины с массой — это поможет подобрать правильную распиновку без логического анализатора. Вот, например, дисплейчик из китайской нерабочей реплики Nokia 130 с здоровым 2.4″ дисплеем… казалось бы, вообще не понятно что за дисплей, однако воспользовавшись смекалкой, мы находим его распиновку!
❯ SPI-дисплеи
SPI-дисплеи в телефонах встречались относительно редко. В основном, подобные дисплейчики можно было найти в моделях начала 2000х годов: сименсах, моторолах, ранних сонериках T-серии и Nokia на S40. Иногда SPI-дисплеи можно встретить в современных кнопочных телефонах — обычно они имеют шлейф с менее чем 15 пинами, как некоторые модели Fly. Обычно контроллер дисплея поддерживал сразу несколько аппаратных шин, а производитель телефона ещё на этапе установки шлейфа к контроллеру дисплея замыкал необходимые IM-пины выбирая необходимую шину, поэтому программный протокол фактически идентичен дисплеям с шиной 8080.
Несомненным плюсом SPI-дисплеев можно назвать малое число пинов для работы с матрицей: достаточно всего два (плюс сигнал D/C, если дисплей не 9-битный), если повесить RESET на VIO, либо три (четыре), если хотите управлять аппаратным RESET вручную. Но есть и, в некоторой степени, минусы: например, не все микроконтроллеры умеют работать в 9-битном режиме и возможно последний бит придётся досылать «ногодрыгом» (что ломает любую возможность реализации DMA).
Многие дисплеи с этим интерфейсом задокументированы ещё в начале 2000х годов на известных форумах и сайтах, таких как VRTP, Радиокот и easyelectronics, поэтому проблем с их подключением не возникнет даже у новичка. Даже такой крутой и уважаемый дядька, как @DIHALT, когда-то писал полезный материал об использовании FSMC в STM32.
Достать их новыми можно и сейчас: различные магазины запчастей для телефонов бывают продают их по 20-30-40 рублей… Я недавно себе целую коробочку накупил, в том числе и просто для ремонта смартфонов для будущих статей 🙂
❯ I2C-дисплеи
Дисплеи с такой шиной — настоящая редкость и обычно попадались в телефонах самого начала нулевых годов с низким разрешением дисплея. Из известных мне — Ericsson’ы и ранние Sony Ericsson T-серии, ODM Motorola (головастики например) и… пожалуй всё.
Казалось бы, разве I2C может быть полезен для работы с дисплеями, где требуется активный вывод графики? Ведь он совсем медленный! Однако, даже он может пригодится для некоторых проектов, а в большинстве МК частенько попадается аппаратный TWI.
Кроме того, I2C дисплейчики удобно отлаживать: благодаря тому, что периферийное устройство должно отрапортовать ACK (состояние успешности получения байта) мастер-устройству, можно сразу определить обрыв линий до дисплея. Но какой-то конкретной информации по ним я не смогу написать — они все совсем разные 🙁 Правда, полезным линком поделюсь, ребята с форума VRTP собрали хорошую таблицу с различными контроллерами дисплеев, где бывают и i2c!
❯ Подсветка
Отдельного радела стоит тема подсветки дисплеев. По первой может показаться, что тут всё просто: современным дисплеями достаточно 5В, а на старых можно замерить напряжение бустера на живом девайсе и смастерить свой DC-DC повышающий преобразователь, или взять, например, уже готовый драйвер, как известный в определенных кругах LTYN. На самом деле и тут есть свои нюансы.
Итак, каким образом реализована подсветка в том или ином устройстве? Обычно её реализация заключается в последовательном соединении двух и более светодиодов, которые формируют небольшую ленту под рассеивающей плёнкой. На современных китайских дисплейчиках, для работы в полную яркость достаточно всего лишь 5В источника питания + токоограничивающего резистора. Но что самое приятное, подсветка в таких дисплеях способна работать и при 3.3В, пусть менее ярко, но всё равно вполне читабельно.
Если вы делаете портативное маломощное устройство, работающее от одного Li-Ion аккумулятора, то достаточно лишь пустить 3.3В с линейного стабилизатора, который формирует напряжение VSYS для микроконтроллера. Таким образом, у вас будет стабильная подсветка среднего уровня яркости. В качестве альтернативного «бомж» варианта, когда нет возможности собрать нормальный драйвер подсветки, можно попробовать подключить светодиоды напрямую к АКБ, но при разряде дисплей будет потихоньку «тухнуть». Ещё один «бомж» вариант — разобрать дисплейный модуль, порезать дорожки на ленте и соединить пару светодиодов параллельно, выведя их через отверстие, откуда выходит шлейф дисплея, однако в таком случае, потребление подсветки заметно увеличится.
Правильным выходом будет взять с того-же телефона бустер подсветки с индуктивностью и иной необходимой обвязкой, и собрать бустер самому. Особой популярностью когда-то пользовались вышеупомянутые LTYN из телефонов Samsung (это маркировка известного драйвера LT1937). Уровнем подсветки на подобных бустерах телефоны управляют с помощью встроенного ШИМ-контроллера, чем можете воспользоваться и вы 🙂
❯ Запускаем дисплейчик на практике
В первой части статьи, я постарался ввести вас в курс дела и кратко рассказать о том, как работают такие дисплейчики «под капотом». Как видите — с теоретической точки зрения, ничего сложного нет: пересылаем данные на дисплей, да вовремя дёргаем пин D/C. Но какого же это на практике?
К сожалению, у меня на руках не нашлось подходящего дисплейчика от мобильного телефона (я ведь брал новые по уценке, не все заработали нормально), поэтому в качестве примера работы мы возьмём фактически такой же «китайский» дисплей с алика. Но будьте уверены — с большинством дисплеев, принцип работы будет идентичен (если мы говорим о дисплеях 2005г.в и моложе).
В качестве МК, мы возьмём мой любимый RP2040, который, по моему мнению, незаслуженно обделен вниманием. Время от времени я делаю всякие прикольные девайсы на базе этого МК, поэтому крайне рекомендую его всем моим читателям 🙂
Давайте же перейдем к практической части статьи!
Обычно при создании проекта, я просто клонирую с гита RPi сэмплы с уже готовыми файлами CMake, беру hello world, конфигурирую CMakeLists.txt и пишу свою программу. На малинке пока что нет такого удобного способа создания проекта, как idf.py create-project 🙂
Само собой, для удобства отладки я всегда включаю встроенную в чипсет эмуляцию UART через USB.
if (TARGET tinyusb_device)
add_executable(hello_usb
main.cpp
)
# pull in common dependencies
target_link_libraries(hello_usb pico_stdlib hardware_spi)
# enable usb output, disable uart output
pico_enable_stdio_usb(hello_usb 1)
pico_enable_stdio_uart(hello_usb 0)
# create map/bin/hex/uf2 file etc.
pico_add_extra_outputs(hello_usb)
# add url via pico_set_program_url
example_auto_set_url(hello_usb)
elseif(PICO_ON_DEVICE)
message(WARNING «not building hello_usb because TinyUSB submodule is not initialized in the SDK»)
endif()
И инициализирую USB-стек и биндинги stdout к нему:
Задержка здесь важна, иначе девайс отказывается определятся в системе. Переходим, собственно, к разводке дисплея. Для работы нам достаточно лишь питания, подсветки, общей массы и четырёх сигнальных линий: MOSI, CLK, DC, RESET. На CS я обычно ставлю перемычку с массой, т. к обычно не вешаю что-то ещё на одну шину с дисплеем.
Переходим к инициализации дисплея. Наш экранчик работает на базе контроллера ST7735R и имеет разрешение 128×160. Сначала, назначаем функции для пинов и дёргаем RESET:
gpio_set_function(LCM_SPI_CLK, GPIO_FUNC_SPI);
gpio_set_function(LCM_SPI_MOSI, GPIO_FUNC_SPI);
// HW reset
gpio_init(LCM_RESET);
gpio_set_dir(LCM_RESET, true);
gpio_put(LCM_RESET, false);
sleep_ms(400);
gpio_put(LCM_RESET, true);
Весьма негусто скажете вы? Ну, с минорными изменениями, здесь заработает дисплейчик любого разрешения, даже 480×320! Переходим к фактической инициализации:
void lcmCommand(unsigned char byte)
gpio_put(LCM_DC, 0);
spi_write_blocking(spi0, &byte, sizeof(byte));
>
void lcmData(unsigned char byte)
gpio_put(LCM_DC, 1);
spi_write_blocking(spi0, &byte, sizeof(byte));
>
lcmCommand(0xC5);//VCOM
lcmData(0x0E);
lcmCommand(0x36);//MX, MY, RGB mode
lcmData(0xC8);
lcmCommand(0x2B);
lcmData(0x00);
lcmData(0x01);
lcmData(0x00);
lcmData(0xA0);
lcmCommand(0x3A);//65k mode
lcmData(0x05);
lcmCommand(0x29);//Display on
// Set viewport
lcmCommand(0x2A);
lcmData(0 >> 8);
lcmData(0 & 0xFF);
lcmData(128 >> 8);
lcmData(128 & 0xFF);
lcmCommand(0x2B);
lcmData(0 >> 8);
lcmData(0 & 0xFF);
lcmData(160 >> 8);
lcmData(160 & 0xFF);
Прошиваем наш МК и смотрим что получилось. Видим шум на экране? Значит дисплей инициализирован верно!
После инициализации дисплея, мы можем выводить на него данные! Дабы дать возможность процессору заниматься другими делами во время передачи картинки на дисплей, мы настроим один из DMA-каналов. DMA-контроллер занимается пересылкой данных из ОЗУ в другой участок ОЗУ (аппаратный memcpy) или периферию. Как раз для второго случая, т. е. пересылки данных в контроллер SPI, мы и будем использовать DMA!
Аллокейтим фреймбуфер, куда мы будем выводить нашу картинку и настраивает DMA-канал:
int backBufSize = LCM_WIDTH * LCM_HEIGHT * 2 + 1;
backBuffer = (byte*)malloc(backBufSize);
printf(«LCM: Setting up DMA channel. \n»);
bulkDMAChannel = dma_claim_unused_channel(true);
cfg = dma_channel_get_default_config(bulkDMAChannel);
channel_config_set_transfer_data_size(&cfg, DMA_SIZE_8);
channel_config_set_dreq(&cfg, spi_get_dreq(spi0, true));
Переходим к выводу изображения на дисплей. Для того, чтобы просто установить цвет пикселя в любых координатах экрана, достаточно лишь посчитать смещение от начала указателя на фреймбуфер к определенным координатам экрана. Формула очень простая и понятная: ширина дисплея * Y-координата + x координата и результат предыдущих операций помноженный на число байт в одном пикселе.
__inline void pixelAt(short x, short y, short color)
if(x < 0 || y < 0 || x >= LCM_WIDTH || y >= LCM_HEIGHT)
return;
В функции есть валидация границ дисплея. Если уверены, что не зайдете за границы дисплея — можете убрать проверку, будет шустрее.
Теперь для вывода картинки, нам достаточно лишь скопировать изначальное изображение в наш фреймбуфер и попросить DMA-канал вывести изображение на дисплей. Для прозрачных картинок без альфа-канала (т. е. с цветовым ключом), функция будет выглядеть так:
А вот как с этим всем работать:
printf(«LCM test by monobogdan\n»);
Можно сделать чуть комплекснее, добавив альфа-блендинг и аффинные трансформации (возможность поворота и скейла картинок), но пока-что такой задачи не стоит. Ну что, всё очень просто и понятно? 🙂 Пример прошивки можно найти на моём GitHub!
Производительность такого способ на RP2040 можно увидеть вот в этом видосе (на Пикабу не смог залить из-за ограничения на число медиа-элементов). Обратите внимание, что подход предложенный выше больше подходит именно для динамического вывода изображения без dirty-регионов. Он подойдет для игровых консолей, камер, анимаций или устройств с выводом динамической информации по типу осциллографов. Если вам нужно обновлять картинку реже, например, если вы делаете умные часы с плеером, то нет необходимости занимать довольно большой объем ОЗУ фреймбуфером, ведь вы можете писать напрямую в видеопамять. Тут уже решать в зависимости от конкретной ситуации именно вам 🙂
❯ Заключение
Вот мы с вами и систематизировали информацию о том, как использовать дисплеи с мобильных телефонов в своих проектах. Надеюсь, информация была достаточно полезной для вас!
Однако, у меня к вам просьба: пожалуйста, не «дербаньте» рабочие девайсы «на запчасти» 🙁
Это будет не очень гуманно по отношению к нашему «технобалдежу», где мы наоборот стараемся найти применение стареньким девайсам 🙂
Был ли для вас материал полезен? Пишите в комментариях.
Полезный материал? Всего голосов:
Какие дисплейчики подключали? Всего голосов:
❯ Важное объявление для читателей касательно будущей рубрики
Друзья! Я, как и многие мои читатели, помимо программирования и железа обожаю тачки! Особенно те тачки, где что-то нужно доделывать самому… и речь, конечно-же, о ТАЗах! Я долго думал, но всё же решился: сейчас я коплю на будущий интересный проект, связанный с ультрабюджетным электронным дооснащением автомобиля, который старше меня в полтора раза — скорее всего, речь пойдет о ВАЗ 2108/2109/21099, причём не исключено что карбюраторной! В планах довольно крутой проект, заключающийся в следующем: мы спроектируем очень дешевый бортовой компьютер (т.е панель) для управления автомобилем на базе дешевого Б/У планшета за пару сотен рублей. Планшет будет связан с управляющим МК через UART (о подобной коммуникации через хардварные протоколы я уже писал целых две статьи: сам себе Linux смартфон, превращаем планшет с нерабочим тачскрином в игровую консоль), и с планшета мы сможем не только управлять основными системами машины (стеклоподъемники, центральный замок и соленоид багажника), но и собирать и пытаться примерно посчитать некоторую информацию о расходе, километраже и стабильности работы двигателя на карбюраторной(!) машине без электронных систем с завода!
Если вдруг двигатель машины будет живенький и заводиться с полтычка, то может и удаленный прогрев постараюсь реализовать 🙂
В наши задачи будет входить не только проектирование аппаратной части такого оснащения, но и разработка симпатичного интерфейса для самой панели, дабы было не хуже чем в BMW 😀 Всеми схемами, исходным кодом и инструкциями я буду делится с вами в каждой статье и, как обычно, расскажу обо всех деталях реализации во всех подробностях! У меня уже есть некоторые идеи и наработки. Собственно, почему-б и не попробовать? Будет новая рубрика в блоге: апгрейд автомобилей глазами электронщика и прожженного программера.
Фото не моё, из интернета
Если вам нравятся мои статьи, вас интересует развитие такой рубрики и у вас есть желание и возможность — можете помочь проекту копеечкой с помощью формы доната ниже. Пикабу позволяет остаться анонимным и донатить даже без регистрации. Сейчас у меня есть 40 тысяч рублей личных накоплений, на покупку самой машины планирую выделить 70-80 тысяч рублей (я живу в Краснодарском крае, так что здесь ещё есть шансы найти что-то +- живое за такие деньги), так что остаётся собрать около 30-35 тысяч рублей. За каждую копейку я готов отчитаться (по факту покупки машины я сделаю пост с фотографиями авто, ДКП, а также оглашу фронт будущих работ и сразу начну заниматься проектом).
Интересный проект с тазиком? Всего голосов:
Показать полностью 25 3
Поддержать
2 месяца назад
Ответ на пост «Названия для носителей языка»
Показать полностью 1
2 месяца назад
Знания массивов множат боль
2 месяца назад
«Если крадешь код, то кради как художник»
Показать полностью 2
2 месяца назад
Вместо алерта об ошибке будет просто ссать в тапки
Показать полностью 1
3 месяца назад
Достойный сын программиста:
Показать полностью 1
4 месяца назад
Кусочек абстрактного искусства
9 месяцев назад
Junior KOSька в 18 годиков
Раз уж тут публикуют разные истории успеха (или неудачи), пришло и моё время рассказать историю. Историю чего – решайте сами. И да, месяц рождения – август 2004, не нашёл, куда вставить.
Предыстория
Закончил 11 классов по системе РФ, последние три в физико-математическом классе лицея. Потом поступил на специальность «Прикладная математика и физика» в ФРКТ МФТИ. То есть сейчас закончил второй курс института. Из интересного у нас в вузе сохранилась классическая схема преподавания информатики и читаются курсы Дединского И. Р. и Владимирова К. И. (того самого, который выступает на «C++ Russia»).
Когда-то в сентябре второго курса одна подписчица (да, я веду блог) предложила попробоваться в отборе на стажировку АО «Лаборатория Касперского» – SafeBoard. Попытка не пытка, тем более нашлись интересные лично мне направления. В конечном счёте остановил свой взор на направлении «Разработка C» как самом близком и родном мне.
Отбор
Пройдя первичный отбор в виде тестирования на Stepik, стал ждать. И получил «письмо счастья» с проходом на новый этап и ссылками на тестовое задание и видеоинтервью. Сильным стрессом была проблема с платформой для аидеоинтервью, которая не позволяла мне с моим оборудованием его полностью записать, но и это было решено, не без участия нашего прекрасного менеджера образовательных программ (да, это довольно очаровательная девушка). Сдав всё это, я стал ждать и грустить заранее.
И вот, уже подзабыв об этом, я решал аналитическую механику, коротая время до занятия Дединского. Вдруг раздался звонок. Это был рекрутер Лаборатории. Попросил связаться в Telegram. Списались. У меня попросили резюме и согласовали слот для встречи с командой. Сказать, что я был рад – ничего не сказать. Настолько, что потратил оставшееся время на написание резюме, которое не подготовил предварительно по собственному разгильдяйству. И вот, когда всё было готово, снова началось ожидание.
Пройдя собеседование с Development Group Manager и Senior Developer, которое прошёл в целом хорошо, о чём, забегая вперёд, даже читал потом на Confluence. «И ожидание, красною строкой, когда секунда тянется как вечность. Не зря восьмёрка кажется порой похожей формою на бесконечность.»
Оффер и первый рабочий день
Однажды в понедельник после курса Владимирова по C++ (буквально только что вышел из аудитории), принял звонок рекрутера. Рассказал о своих впечатлениях от отбора и услышал, что мне хотят сделать оффер. Взял таймаут, подумал, согласился, попросил минимум нагрузки по рабочему времени (20 часов). Затем через какое-то время мне предложили гибридный режим работы и.. Всё, я начал готовить документы, которые были запрошены.
И вот день подписания. 13 декабря, вторник, 11 часов. Пройдя все формальные процедуры, получив технику и подарочки, отправился в Аркус. Это здание, в котором базировались команды, связанные с KasperskyOS. Там меня встретил менеджер, показал рабочее место и подсказал, к кому обращаться по каким вопросам. И вот, до конца рабочего дня я занимался установкой Linux на рабочую станцию и настройкой в соответствии с политиками безопасности. С небольшим перерывом на kick-off и экскурсию по этажу (тогда это был один этаж).
Перевод в штат
И вот, после onboarding я начал делать задачи. Интересные, иногда сложные. Не скучал, одним словом. Но в штат месяца через три резко захотелось. Так, в свободное от работы время прошёл (успешно) все собеседования на junior-позицию в Яндекс (но в последний момент она закрылась) и даже почти получил (в самом конце отказался, о чём позже) оффер в VK (команда Tarantool, сумма оговаривалась как 150+k₽/мес* на руки, после всех вычетов).
И вот, в один прекрасный день, написал менеджеру в Teams о том, что хочу в штат. Оказалось, что для этого практически всё готово и надо обсудить детали. И правда, через денёк-другой после обсуждения получил известие, что с 1 июня (дело было в середине мая) перехожу на позицию Junior Developer, KasperskyOS.
И вот перевели. Увидев на внутреннем портале зарплату в чуть больше 200k₽/мес* на руки «после всего», тут же отклонил предложение VK и принялся заниматься рабочими делами, уже совсем не думая о желании перевода/повышения, что однозначно повысило продуктивность.
*) Все суммы указаны в эквиваленте к 40-часовой рабочей неделе, я во всех вариантах получал бы за 20 часов, то есть ровно половину от них.
Не только лишь всё
Кроме всего вышеперечисленного было много всего интересного. Встреча интернов, первая взрослая любовь, день рождения компании (точнее, два в одном). И ежедневная приятная рутина, конечно же. И да, KOSька я потому, что KasperskyOS у нас сокращается до KOS и произносится как «кось», а кое-кто догадался сделать из этого «коську». Не пропадать же ассоциативному ряду.
Кстати, могу порекомендовать вас по реферальной программе, если покажитесь достаточно компетентным. Пишите автору указанного выше канала, там решим.