Долго думал, можно ли переопубликовывать статью на Хабре, проштудировал правила, вроде как сейчас это не возбраняется. Если ошибся — исправлюсь :)

Итак...

Какое-то время назад я писал код прошивки для грабберов Epiphan линейки AV.io:

• AV.io HD — наш пилот, на котором многое было отлажено и сформирована архитектура
• AV.io SDI — закрепляем позиции
• AV.io 4K — уже новое железо и новые подходы, теперь запускаемся практически мгновенно
• KVM2USB 3.0 — глубокое переосмысление AV.io HD. По сути, благодаря заложенному потенциалу для модернизации в базовую модель, практически без модификации железа, чисто софтом смогли сделать новый продукт.

Там был задействован Cypress FX3, а SDK был построен поверх ThreadX. В качестве JTAG отладчика можно использовать Olimex ARM-USB-OCD-H в связке с OpenOCD. К сожалению, OpenOCD ничего не знает про треды в RTOS и, хотя, базовая поддержка присутствует в коде, конкретно для нашего процессора использовалась схема стекинга регистров, которая отличалась от того, что было уже реализовано. Пришлось разбираться и дорабатывать. Профиты от использования JTAG для разработки трудно переоценить, как минимум в случае распределённой работы.

Итак, время идёт. Теперь очередь за FPGA от Xilinx и его софтовым процессором MicroBlaze, где можно запустить портированый FreeRTOS версии 10.x. Но проблема ровно такая же: поддержки тредов в отладчике нет!

Дано: есть устройство, с ARM926E-JS (Cypress FX3) на борту. Устройство находится на другом континенте. Устройство подключено (JTAG+USB+COM) к Linux компу. На комп есть SSH доступ (и больше ничего, только SSH порт).

Проблема: Устройство нужно отлаживать и писать под него код. И делать это, желательно, удобно.

Решение с использованием OpenOCD, GDB и Qt Creator, а так же описание пути к нему, под катом.

Данная заметка может оказаться полезной для людей, который пишут bare-metal код и используют ThreadX в своих задачах (по собственному выбору или по навязыванию SDK). Проблема в том, что что бы эффективно отлаживать код под ThreadX или другую многопоточную операционную систему нужно иметь возможность видеть эти самые потоки, иметь возможность посмотреть стек-трейс, состояние регистров для каждого потока.

OpenOCD (Open On Chip Debugger) заявляет поддержку ThreadX, но не сильно явно оговаривает её широту. А штатно, на момент написания статьи, в версии 0.8.0, это всего два ядра: Cortex M3 и Cortex R4. Мне же, волею судеб, пришлось работать с чипом Cypress FX3 который построен на базе ядра ARM926E-JS.

Под катом рассмотрим что нужно сделать, что бы добавить поддержку вашей версии ThreadX для вашего CPU. Акцент делается на ARM, но, чисто теоретически, вполне может подойти и для других процессоров. Кроме того, рассматривается случай, когда доступа к исходникам ThreadX нет и не предвидится.

День добрый,

CMakeProjectManager2 — это форк оригинального плагина Qt Creator для поддержки работы с системой сборки CMake. Вялая история развития этого проекта идёт с 2011 года (первая моя заметка в блоге: htrd.su/wiki/zhurnal/2011-03-24_14.49_qt_creator_i_cmake_-_prodolzhenie, второе обновление от 2012 года: htrd.su/wiki/zhurnal/2012/10/17/cmakeprojectmanager2_-_poslednie_izmenenija). С тех пор ничего нового не добавлялось. Обеспечивалась совместимость с последними версиями Qt Creator, репозиторий переехал на GitHub (в качестве эксперимента).

Но за вчера и сегодня добавилось ещё несколько изменений, что и стало поводом упомянуть проект на Хабре.

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

Чтобы сэкономить время в последующем, а также, чтобы лучше понять в ходе обучения, крайне помогает вести конспекты и делать наглядные шпаргалки. Шпаргалку можно повесить рядом на стену. Хороши шпаргалки в виде блок-схем, по которым можно легко, по шагам, получить нужный результат (например выбрать правильный контейнер).

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

Программируя на Си многие сталкивались с такими функциями как memcpy() и memmove(), по сути, функции делают одно и тоже, но вторая корректно отрабатывает ситуацию, когда области памяти перекрываются (на что появляются дополнительные накладные расходы).

В мире С++ никто не запрещает пользоваться этими функциями (часто эти функции используют различные механизмы оптимизации и могут статься быстрее своих собратьев из мира C++), но есть и более родное средство, работающее через итераторы: std::copy. Это средство применимо не только к POD типам, а к любым сущностям, поддерживающим итераторы. О деталях реализации в стандарте ничего не сказано, но можно предположить, что разработчики библиотеки не настолько глупы, что бы не использовать, оптимизированные memcpy()/memmove() когда это возможно.