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

Для записи на курс

заполните анкету на сайте и пройдите онлайн-тест, Прием заявок заканчивается 23 октября, результаты будут объявлены участникам 28 октября. Стартуем 1 ноября.

Обучение бесплатное, студенты могут выбрать любое количество курсов.

Программа обучения

Основы программной инженерии

Основы программной инженерии. Проектная деятельность.
Записаться

Программирование микроконтроллеров STM32

Работа с интерфейсами USB, GPIO, I2C. Прерывания и таймеры.
Записаться

Разработка для FPGA

Введение в программирование под FPGA. Большую часть курса занимает изучение и написание модулей с использование языка Verilog/SystemVerilog.
Записаться

Системное программирование в Linux

Обучение системному программированию. Изучение основ ядра Linux. Введение в разработку драйверов для Linux.
Записаться

Измерение качества телекоммуникационных каналов

Измерения качества телекоммуникационных каналов Ethernet, E1, оптическая рефлектометрия. Большое количество информации о физике и теории сигналов.
Записаться

Расписание

Тестер-анализатор Беркут ЕТ предназначен для тестирования линий связи, скорость тестирования передачи данных — 10/100/1000 мегабит в секунду, тесты по методике RFC2544, BER-тестирование, тесты определения состояния медных линий. Прибор незаменим для операторов связи.

Сегодня инженеры центра существенно расширили функционал :)
Встречайте DooM! Запуск игр на платформе позволяет немного отвлечься
от рутинной работы, а заодно и продемонстрировать функционал новой
разработки. Не смотря на то, что концепция прибора была создана в 2008
году, прибор постоянно обновляется и имеет несколько
ревизий.

Немного фотографий процесса и результата:

Пришла пора и нашему отделу технической поддержки «выйти из сумрака». :)

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

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

1. b3et-rev3.1-files_0.3.9-17.urom — для ревизии 3.1
2. b3et-rev2.1-files_0.3.9-17.urom — для ревизии 2.1.
3. Для самой старой ревизии 1.1  необходимо два файла прошивки, т.к. прибор обновляется в два этапа:
   b3et-rev1.1-mcu_0.3.4-2.bin
   b3et-rev1.1-files_0.3.4-2.urom

Версия ревизии указана в приборе во вкладке «Информация» -> пункт «HW».

Данные версии, а также инструкцию по обновлению вы сможете найти на нашем сайте, по ссылке.

читаем статью на Хабре.

ps. на сайте компании срочно пришлось сделать специальную страницу с описанием платы, на которой Денис проводил свои эксперименты. там теперь есть спецификации, картинки и функциональная схема.

Для решения поставленной задачи нам потребуется:

• STeameR
• Дека с ADC
• Гребенка Pogo pin
• терминальная программа, понимающая Esc-последовательности (например — minicom)
• немного попрограммировать.

STeameR + плата расширения с ADC — это не только ценный мех куча измерительных каналов на двух ADC, на которые можно завести сигналы с Pogo pin. После этого — все что нам потребуется — раз в секунду по I2C считывать данные с ADC и выводить их на USB-консоль. Получаем мониторинг в режиме реального времени, причем сразу всех источников. При этом в прошивку STeameR вбиты допустимые значения для каждого из напряжений и если какой-либо источник ведет себя плохо — это сразу видно в таблице:

Все напряжения в норме

один источник выдает заниженное напряжение

А вот и само железо:

Предположив, что сия идея не мне первому пришла в голову, я залез в man ssh_config и наткнулся на поле ProxyCommand :)
Вроде, то, что надо!?

Прописываем в .ssh/config:

Host KnockedHost
HostName knocked.host.com
ProxyCommand /bin/sh -c "/usr/bin/knock %h 1111 2222 3333 && sleep 10 && nc %h %p"


И тогда перед вызовом ssh KnockedHost не нужно будет вручную делать knock knocked.host.com 1111 2222 3333, так как это будет происходить автоматически!

Таким образом можно вызывать любую команду перед подключением по ssh к какому-то хосту.

Полезная инфа (на самом деле, её гораздо больше, юзайте Google!):

• knock-сервер
• knock-клиент
• man ssh_config

Перед началом сборки почитайте README: в нем есть список пакетов, которые должны быть установлены в системе.

Для сборки просто запустите summon-arm-toolchain и подождите когда он закончит.

После окончания сборки по пути ${HOME}/sat будет лежать свеженький тулчейн, готовый к употреблению.

Данный тулчейн подойдет для большинства Cortex-M3 устройств. Но из библиотек для работы с перефирией там только libopencm3.

 Построен на базе:

• binutils-2.23.1
• newlib-2.0.0
• gcc-4.7.2 или gcc-4.7-2013.01 от Linaro
• gdb-7.5.1 или gdb-7.5-2012.12-1 от Linaro
• OpenOCD-0.6.1
• libcmsis-v1.10-4
• libstm32-v3.0.0-2
• libstm32usb-v3.0.1-1
• libopencm3

Но если стандартные настройки нас не устраивают…

summon-arm-toolchain поддерживает следующие конфигурационные параметры:

• TARGET — arm-none-eabi по умолчанию. Можно сменить на arm-elf если очень хочется, но arm-elf уже устарел и его обещают убрать.
• PREFIX — ${HOME}/sat по умолчанию. Путь, куда будет установлен тулчейн.
• DARWIN_OPT_PATH — /usr/local. Путь к MacPorts или Fink. Используется при сборке под Mac OS
• SUDO — по умолчанию не установлен. Но если надо установить тулчейн туда, где прав обычного пользователя не хватает — впишите «= sudo»
• USE_LINARO — Использовать или нет патчи от Linaro. По умолчанию — использовать.
• OOCD_EN — собирать или нет OpenOCD. По умолчанию — собирать. Но если у вас нету JTAG адаптера — сборку OpenOCD можно отключить
• OOCD_GIT — пусто по умолчанию. Служит для выбора конкретной версии исходников OpenOCD
• LIBSTM32_EN — по умолчанию 0. Если включить — будет собрана библиотека от ST
• LIBOPENCM3_EN — по умолчанию 1. Включает/отключает сборку опенсорсной библиотеки libopencm3 для Cortex-M3
• DEFAULT_TO_CORTEX_M3 — по умолчанию 0.
• CPUS — по умолчанию пусто. Но если хочется распаралелить make не на все процессоры — можно указать количество CPU, которое можно использовать.

Но в большинстве случаев можно ничего не настраивать и использовать out-of-the-box.

Такой подход позволяет использовать стандартные средства ping и traceroute.

Для реализации сетевого интерфейса (как собственно и консоли карты) использовался любимый нами USB-шный класс CDC (Communication Device Class). В этот класс входят подклассы позволяющие реализовать интерфейсы к телефонным линиям, модемы и сетевые карты (проводные и беспроводные). Большим плюсом использования стандартного класса USB-устройства, является отсутствие необходимости писать драйвера (в Linux/*nix, Windows всё равно требует хотя бы .inf файл).

Так вот сетевых устройств в классе CDC может быть несколько видов. Это подклассы ECM,EEM, NCM и вариации на тему ACM (вместе с rndis), которые так любит windows. Устройства отличаются степенью поддержки операционной системы, степенью документированности и некоторыми другими особенностями.

Итак:

• Rndis — нестандартная вариация на тему ACM. Вообще-то подкласс ACM — это последовательный порт или модем, но microsoft, традиционно наплевав на все имеющиеся стандарты создала собственный. Rndis, по своей сути, представляет собой реализацию ndis API поверх usb. Используется microsoft-ом и в КПК под windows mobile для синхронизации и связи с компьютером. Так как этот класс не полностью документирован, да и не стандартен — это не наш путь.
• ECM — Ethernet Control Model — это реализация сетевой карты (в стандарте есть поддержка проверка состояния линка, мак-адрес карты хранится в дескрипторе и тд). Данный стандарт требует двух интерфейсов: для передачи данных и управляющего. За терминологией обращаться на usb.org или сюда: http://www.beyondlogic.org/usbnutshell/usb1.shtml. Вторая ссылка намного короче и более просто расписана :).
• EEM — это Ethernet Emulation Model — в этом случае USB используется исключительно как транспорт ethernet пакетов. Состояние линка не передаётся, скорость не настраивается и так далее. Зато интерфейс просто и для него нужно только 2 endpoint-а.

Отсюда мы и подходим к выбору варианта сетевого интерфейса. Тут всё оказалось совсем просто — для реализации ECM нам просто не хватило доступных endpoint-ов в контроллере. Так что выбор остановился на EEM. Даже с ним, доступные 6 endpoint-ов, разделились полностью, и пришлось слегка обмануть реализацию консоли, указав в дескрипторе несуществующий endpoint.

Так вот, в stm32f105 есть 6 доступных endpoint-ов, не считая нулевого (по 3 IN и OUT). В итоге хватает впритык и резерва не остаётся. Для ECM уже endpoint-ов не хватает, так как под эту модель требуется по 3 endpoint-а на интерфейс.

Передача данных в модели EEM, или как же это заставить работать….

Для того, чтобы сетевое устройство с классом EEM зарегистрировалось в системе, достаточно правильно написать USB дескриптор. Создаётся интерфейс состоящий из двух bulk endpoint-ов, одного IN и одного OUT, ему приписывается класс CDC (0x02), подкласс EEM (0x0c), и протокол EEM (0x07). На этом все тонкости и заканчиваются. Пакеты в EEM передаются как есть, в виде ethernet фреймов, с дописанным в начале двухбайтным заголовком.

Выглядит он так:

Пятнадцатый бит определяет — является ли этот кадр данными идущими в интерфейс или служебной командой EEM. Всего есть 6 команд, из которых обязательными являются только Echo и Echo response. (Хотя как выяснилось, линуксовый драйвер, даже без реализации разбора этих команд вполне нормально работает).

Четырнадцатый бит определяет, используется ли реальный подсчёт CRC, или на месте CRC передаётся последовательносьт 0xdeadbeef.

Оставшиеся биты кодируют длину фрейма следующего за этими двумя байтами заголовка.

После реализации разбора заголовков, приём и передача заработали без проблем, за исключением того, что USB-шная библиотека от ST не позволяет реализовать USB-transfer длинее чем размер FIFO в stm32, а ethernet пакеты в EEM нельзя разбивать между transfer-ами.
Таким образом, сейчас реализован приём и передача пакетов до 254 байт длиной. Пропускная способность не измерялась.