Skip to main content

[WiP] Работа с iPhone|iPad|iPod в Линукс

Подготовка

Что из пакетов есть:

Устанавливаем только необходимое:

!Если собирать из свежего среза заявлена совместимость up to iOS 10!

(далее…)

читать...

Работа со шрифтами в CentOS 7

Установка шрифтов в CentOS 7

Установка GUI-оболочки над fontconfig’ом (можно будет назначать произвольные шрифты в качестве дефолтных системных):

Установка майкрософтовских шрифтов из репо: 

Поиск нужных шрифтов в репо:

Установка сторонних шрифтов

Если  нужных шрифтов нету в репо, их можно добавить в систему сладующим образом:

1. скачать и помесить в папку ~/.fonts/:

2. дать команду на обновление (пересборку кэша) шрифтов:

или если надо, чтобы не только на текущего пользователя распространялись устанавливаемые шрифты:

Также полезной будет добавить опцию -f для того чтобы зафорсить перезачитывание каталога шрифтов.

Манипуляции с установленными шрифтами

Вывести списком все установленные шрифты:

либо только названия установленных шрифтов:

либо только имена файлов (с путями) установленных шрифтов:

либо доступные стили установленных шрифтов:

 

Можно сделать сортировку выведя только доступные шрифты с кириллическим набором символов:

либо более сложную сортировку:

 

Также полезным будет просмотр какие шрифты в системе установлены как дефолтные:

Свободные шрифты

Ниже — каталог свободных шрифтов,  которые удалось собрать по крупицам:

Font Awesome (также доступен к установке через yum): https://fortawesome.github.io/Font-Awesome/ (также доступен из репа)

 Кириллические шрифты

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

Paratype PT Sans и PT Mono: http://www.paratype.ru/public/

PT Mono Bold: http://www.fontstock.com/public/PTMono.zip

PT Astra Sans и PT Astra Serif: http://astralinux.com/fonts.html

ROSA Arion и ROSA Verde:  http://www.rosatype.ru/

Шрифт «Берёзки» с  кириллическим алфавитом: http://mishapanfilov.ru/font_beryozki.html

Бесплатные кириллические шрифты: http://russianfonts.ru/fonts/gora/goratypeface.html

Ссылки

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/configure-fonts.html

читать...

[CV]: Резюме эмбеддер-инженера: специфика составления и продвижения

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

Итак, каким же должно быть «идеальное» резюме цифрового дизайнера? Ниже представлены опробованные на практике советы (из личной копилки или копилки коллег-единомышленников).

Очевидные вещи

Начну с таких неспецифичных для отрасли и очевидных вещей как то:

  • Имя кандидата должно быть написано крупно, как и должность, на которую он претендует
  • Указывайте опыт работы и работодателей в порядке от нового к старому
  • Лучший формат файла для CV — это PDF со встроенными шрифтами, иначе все ваши красивости и форматирования улетят в тар-тарары

Краткость — сестра таланта, но не в CV

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

Также не стоит пытаться замаскировать опыт и навыки, врядли потенциальный наймодатель — сертифицированный чтец между строк. Опыт и навыки — это те вещи, которые должны быть написаны явно и ясно, а не подразумеваться и вытекать из списка предыдущих наймодателей и должностей. «Обладает ли соискатель конкретными навыками и опытом?» — этот вопрос меньше всего хочет задавать себе наймодатель.

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

Проекты

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

  • В качестве разработчика ПЛИС реализовал:
    • СФ-блок интерфейса CAN
    • СФ-блок интерфейса LIN
  • В качестве верификатора написал комлект тестов для проверки:
    • СФ-блока UART
      • в т.ч. в режиме работы LIN-master & LIN-slave
    • СФ-блока WDT
    • а также освоил методологию UVM
  • В качестве сетевого инженера занимался:
    • Поддержанием бесперебойной работы серверной инфраструктуры
    • Администрированием хранилища git
    • Балансировкой нагрузки серверов

В начале карьеры при отсутствии опыта можно на волонтерских началах поучавствовать в опенсорцном проекте или даже организовать свой DYI-проект формата «сделай сам» (нелишним будет перечислить выполненные стадии проекта и извлеченные уроки), а еще круче — принести на собеседование объект творчества и рассказать о процессе создания. При прочих равных предпочтение в найме отдаётся самомотивированным и увлеченным кандидатам.

Помимо проектов строго обязательным является список с перечислением навыков (опять же — избегайте принуждения наймодателя читать между строк и выводить формулу ваших навыков на основе опыта работы). В этот же раздел полезно отнести навыки работы с конкретным типом измерительного оборудования, известные архитектуры процессоров/семейства ПЛИС, коммуникационные интерфейсы/протоколы, владение EDA/CAD-тулами, скриптовые и языки программирования (таки-удержался, чтобы дописать сюда же — фреймворки 😉 ).

Позиционирование

Чётко определите для себя область, в которой хотите работать и профессионально развиваться и исходя из этого подавайте себя. Не стоит писать: «по чётным дням разработчик, по нечётным — верификатор«, или «в тёплое время года готов писать драйвера устройств,  для которых разрабатывал PCB«. Дайте прежде всего сами себе честный ответ на вопрос в чём вы сильны и в чём хотите развиваться дальше — быть может это будут два разных ответа, не критично. Критично что ваше резюме должно быть пронизано духом развиваться и заниматься интересной вам сферой деятельности. Вычистите резюме от белого шума, слабо коррелирующего с этим стремлением.

Заключение

В заключении хочется дать совет, ценность которого легко недооценить: полезно обновлять резюме раз в несколько месяцев, установите себе конкретные даты в календаре, когда будете делать это; например, ежеквартально — хорошая частота для того чтобы сесть и обновить резюме новыми проектами и навыками. Редкие обновления обычно приводят к пробелам в информации или её искажению из-за забывания того, что было сделано. Помните: самое худшее время для обновления резюме — это когда Вы ищете работу. 

читать...

asciidoc: полезные дополнения

Парсер ASCII-art рисунков с сохранением в SVG

Скрипт установки asciitosvg-install.sh:

Использование:

где -s масштаб сетки в пикселях. Хорошо дополняет этот конвертер онлайн-рисовалка ASCIIART’a http://asciiflow.com

(далее…)

читать...

Коллекция советов и подсказок по работе с Xilinx Vivado в командной строке TCL

Советы

Note!: Все команды вводятся в интерпретаторе TCL в интерактивном или пакетном режимах.

Включение мультипроцессорности

можно задавать значение от 1 до 8 ядер.

Справка по командам выбранной категории

Справка по командам

Мониторинг параметров среды

Изменение подробности вывода лога/выключение лога 

 Note!: делаем осторожно — важное не выключаем!

— установка глобального лимита сообщений по умолчанию

— в данном случае полностью выключается вывод информационного сообщения с ID типа «INFO: [Synth 8-5544]«

— в данном случае вывод информационного сообщения с ID типа «INFO: [Synth 8-3331]» ограничивается выводом первых 10-ти сообщений

— для интерпретации проверки на DRC c ID «LUTLP-1» как предупреждения, вместо критического предупреждения (позволяет получить битстрим, если вы действительно уверены, что в дизайне необходимы комбинационные петли)

Выключение некоторых DRC-проверок

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

вот мой полный список отключенных проверок:

Добавление временной метки в битстрим 

 — для добавления таймштампа в примитив USR_ACCESS 

Использование внешних переменных среды в TCL

— обращение к переменной $USER в shell

— проверка существования переменной $USER в shell

 Вызов одного скрипта из другого

Выполнение shell-команды из скрипта

— копировать с перезаписью, если файл уже существует

 

 

читать...

Тулчейн для STM8 под линукс на базе SDCC

Установка

SDCC

Есть соблазн установить из репозитория:

но, поскольку там довольно старая версия (для такой новой для sdcc архитектуры, как stm8), то рекомендую ставить последний снапшот отсюда: находим нужную нам архитектуру i386 или AMD64 и качаем предскомлиленный архив бинарников:

 Проверить корректную установку можно командой: 

hex2bin

 Аналогично устанавливаем последнюю версию hex2bin, которой получаем бинарь, который в свою очередь будем кормить программатору:

stm8flash

Есть такой замечательный программатор stm8flash, который позволяет зашивать STM8 через стандартный st-link (или его китайские клоны) по интерфейсу SWIM; скачиваем и устанавливаем:

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

Альтернативные инструменты

Справедливости ради, отмечу существование stm8flasher — утилиты, которой можно шить по UART старшие STM8, имеющие встроенный загрузчик, но в силу того, что не работаю с «жирными» STM8 эту утилиту не пробовал.

Также, начиная с весны 2016г, стал подностью бесплатным французский компилятор Cosmic, к сожалению, версия для линукса хоть и существует, но недоступна свободно и поставляется на отдельных условиях (с демоном лицензий flex lm).

Использование

Пример

Компиляция проекта из одного файла-исходника:

Конвертация в bin:

Зашивка:

Разбор примера

sdcc

 Основные опции sdcc, которые скорее всего потребуется использовать:

  •  -c для компилирования в объектник (типичный проект с несколькими исходными файлами,  линковка будет запущена отдельной командой)
  • —std-c99 для компиляции согласно стандарта C99 (в действительности, C99-фичи поддержаны только частично, но на моих исходниках необходимо указывать эту опцию, инача sdcc вылетает с ошибкой)
  • —opt-code-size для оптимизации выходного байт-кода по размеру

 hex2bin

  • -p [value] — значение (в hex), которым будут заполняться пустые ячейки (0х75 — недопустимый опкод для архитектуры stm8, его выполнение приводит к переходу в процедуру reset)
  • -s [address] — также есть опциональная возможность задания стартового адреса  (в hex, фактически — смещение)

stm8flash

Общий формат команды:

Note!: В последней версии появилась поддержка формата hex и возможность программирования OptionBytes.

 

читать...

Автовставка истории изменений в техническую документацию на AsciiDoc

Задача

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

Решение

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

Примем, что для истории ревизий нам необходима следующая информация:

  • дата изменения
  • имя автора изменения
  • суть изменения

Для формирования таблицы с историей ревизий используем замечательную команду git log:

— как видим на выходе отличная заготовка для asciidoc-таблицы.

Подробнее об опциях команды:

  • —max-count= — указываем желаемое число последних коммитов
  • —branches= — если интересуют только конкретные ветки (например release/production), указываем тут
  • —tags= — аналогично с тегами, можно задавать паттерн типа rev*.*, v?.?.? и т.п.
  • —no-merges — не выводить в лог слияния веток

У меня установлен гит довольно старый (v1.8), в новых версиях появилась кудо более гибкая кастомизация даты. Тонкую настойку на славянский формат даты «19.2.2015» в новом гите можно осуществить следующей командой:

Также в зависимости от того хранится ли документация отдельно либо является частью репозитария СФ-блока будет различаться git log, возмодно потребуется указывать конкретный исходник документа или группу исходников, например:

или: 

Итоговый скрипт

Получившийся скрипт выглядит следующим образом:

Вызов скрипта: 

В сборочном .adoc-файле включаем сгенерированный файл в соответствующую секцию: 

Также будет полезно добавить revhist.adoc в .gitignore (как файл, генерируемый автоматически); и в мейкфайл — как зависимость при сборке конечного PDF.

 

 

читать...