Open Logic Sniffer в действии

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

«Правильное» программирование, С vs Asm, стили и т.д. и т.п.
Прежде, чем приступить к практическому применению OLS, хочется затронуть извечную общую тему про программирование.
В моих экспериментах нет никаких табу. Я волен делать с программой все, что мне заблагорассудится. Впрочем, так ведет себя подавляющее большинство, с ограничениями по собственной квалификации. Другое дело, когда пишется код, соответствующий спецификациям MISRA, при этом, например, вы лишаетесь права использовать инлайновые ассемблерные вставки, они должны вызываться только в виде С-функции. Или же вынуждены следовать техническому заданию. Но мы будем придерживаться одного правила - «вот так, кажется, получше будет», что может быть в принципе хуже или неправильно с любых других точек зрения. Это простительно, так как я сам не являюсь программистом (хотя и не считаю таковыми многих, кто сам называет себя программистом и получает за это деньги).
Другими словами, «правильное» программирование призвано минимизировать потенциально возможный вред, так как считается, что человек — главная опасность при управлении машиной (любой) или написании для нее программы работы. Это считается вполне справедливо. Но именно поэтому большинство правил, законов и ограничений устанавливается на очень «средний уровень» квалификации и навыков. Применительно к программированию и нашему случаю — на выбранном аппаратном обеспечении и программируя на С «правильно» мы плавную полноэкранную анимацию никогда не увидим.
Конечно, проще всего такие нестандартные задачи решаются на ассемблере, там легко отбрасываются любые условности, парадигма единственного входа и выхода и прочие общепринятые приемы. К сожалению, число людей, которые могут внятно его использовать, постоянно уменьшается. Но как бы не говорилось о «вымирании» ассемблера без его знания не обойтись, если нужна самая эффективная по быстродействию программа. Если это может быть и не всегда так (вспомним слова Каспарова, утверждавшего, что машина никогда не переиграет человека в шахматы), то это знание нужно и для сравнения с тем, что натворил «самый эффективный компилятор» среды разработки.
Кроме того, ряд команд системного уровня не доступен через ANSI С, поэтому часто используются инлайновые вставки (на которые зачастую страшно смотреть и с точки зрения чистого «сишника» и с точки зрения ассемблерного синтаксиса). Часто процедуры инициализации целиком пишутся на ассемблере. Но эти кусочки, заботливо отделяя прикладного программиста от «неправильного» программирования, толкают его в направлении, которое требует все больше ресурсов — памяти, быстродействия и т.д. Создаются новые девайсы, которые еще сложнее, труднее в эффективном низкоуровневом программировании, и вымирающее поколение ассемблерщиков корпеет над новым компилятором, инициализацией и враппингом, чтобы помочь прикладникам. Но им опять чуть-чуть всего нехватает и из порочного круга просто нет выхода...
И еще один момент. Стиль программирования, одним из элементов которого является оформление программы, у каждого вырабатывается свой. В свое время я так и не принял венгерскую нотацию, константы по-прежнему пишу заглавными буквами, открывающая фигурная скобка всегда на новой строке (если не совсем короткое тело, тогда все в одну строку). Так, кстати, рекомендует делать официальная документация по GNU C. Но в наш век облегченного образования кого это волнует? На чтение документации у современного молодого поколения нет ни терпения, ни времени. (Так во все времена брюзжит старшее поколение, но все же деградация «постсоветского» образования видна невооруженным глазом).
Так как по ходу рассуждений будут небольшие фрагменты кода, добавлю, что в моем стиле макросы без параметров не имеют скобочных окончаний.
Переходим к практике. С помощью OLS посмотрим, какое быстродействие у параллельной шины 72MHz STM32 с учетом необходимости формирования управляющих сигналов для LCD (параллельно по отдельной шине). Все делается исключительно с иллюстративной точки зрения работы OLS, так как на самом достаточно обычного калькулятора, а инженеры старой закалки могут обойтись и вовсе без него.

Параллельное подключение LCD — определяем практический предел быстродействия
Многоканальный контроль цифровых сигналов дает возможность быстро определить оптимальные или предельные режимы при конструировании. Для примера, рассмотрим, что можно ожидать от связки LCD MI0283QT-2 и STM32F103C8 при 8-битном параллельном подключении. Вернее, если посмотреть на технические данные контроллера HX8347D, установленного в LCD, то задачу надо поставить так : «что можно выжать из связки STM32F103C8 и программной реализации?». LCD можно не учитывать, так как цикл записи у HX8347D при таком подключении 66нс с временами Thigh и Tlow пульса nWR по 15нс и, при программировании на «чистом С», выйти за пределы таймингов LCD на такте MCU 72MHz не получится.
Для такой задачи даже не нужно подключать LCD, так как он работает в режиме «пассивного потребителя данных» и никаких сигналов в электирическую цепь не возвращает, а влянием отсутствия RLС нагрузки на шину, соответствующей LCD, можно пренебречь.
Но «бездевайсное» исследование можно делать далеко не всегда, особенно если использовать только логический анализатор. Например, когда нелинейность цепей оказывает существенное влияние на форму сигнала - при наличии импульсных устройств (а ведь нужно контролировать и негативный выброс). Чтобы в этом убедиться, в простейшем случае можно посмотреть влияние входной емкости на интерфейсе I2C, манипулируя номиналом подтягивающего резистора шины. Да и никто не сказал, что пороги изменения логического состояния у FPGA и тестируемого оборудования совпадают, они наверняка будут различаться. Не надо забывать и о погрешностях округления при вычислении и представлении данных. Впрочем, современные САПР дают достаточно точную картину того, что будет твориться в цепях и без дополнительного оборудования.
В нашем случае задействуем все буферизованные входы OLS, 8-битная шина данных, пять управляющих сигналов и три линии запуска.
В качестве программного интерфейса с ПК будет выступать альтернативная версия клиентской программы OLS, http://www.lxtreme.nl/ols/, так как, несмотря на ряд недостатков (что бросилось в глаза за два дня, даже уже пообщался с автором), визуально она более выигрышна.
Начнем с простейшей тестовой программы. Инициализируем шестнадцатибайтовый массив числами от 0 до 15, а в непрерывном цикле будем считывать значения этого массива и выводить полученное значение в порт А микропроцессора. Поэтому четыре старших разряда порта будут нулевыми, управляющие линии пока не используются, запуск анализатора делаем по высокому уровню на линии TRIG1. Листинг программы приведен ниже:

int main(void)

{

GPIO_Config();

uint8_t buf[16];

uint32_t j;

for (j=0; j<16; j++)

{

buf[j]=j;

}

TRIG1H;

TRIG1L;

for(;;)

{

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[0];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[1];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[2];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[3];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[4];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[5];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[6];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[7];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[8];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[9];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[10];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[11];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[12];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[13];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[14];

  GPIOA->ODR = ((GPIOA->ODR) & 0xff00 ) | buf[15];

}

}

Сброс триггера нужен для того, чтобы его срабатывание происходило при нажатии кнопки сброса у МК. Триггер запуска может быть достаточно сложным, можно запрограммировать несколько уровней вложенности с дополнительными условиями. В нашем случае использован самый простой вариант.
Запись производится в младшие 8 битов порта, состояние старших битов сохраняется, для чего мы еще делаем вынужденную операцию чтения. Для максимального быстродействия операции записи развернуты на 16 штук в теле цикла, никаких дополнительных операций не производится, прерывания запрещены.В реальных программах вывода графики цикл может разворачиваться на 64 и более операци записи.
Запустив анализатор, получим следующую картинку: