STM32F103C8T6 — делаем осциллограф. Часть 3

Третья часть (первая и вторая) про то как я делаю осциллограф из отладочной платы ценой менее $3. Демонстрационное видео работы:

А описание некоторых ключевых особенностей под катом.

Аналоговая чать

Почти всё как было описано во второй части, кроме источника двухполярного питания. ОУ потребляют значительный ток (порядка 10 мА) и как не пытался схемами умножителей напряжения на диодах и конденсаторах получить приемлемых результатов — не удалось. Поэтому для положительного напряжения поставил вот такой модуль на основе МТ3608:

настроенный на 10 В выходного напряжения. А отрицательное напряжение получаю путём инвертирования положительного с помощью LT1054.

Про размер кода

В первой части я писал, что памяти потребляется очень много. Теперь я дошёл до того, что программа не влазит в память и изучил этот вопрос подробней.

CooCox CoIDE выводит информацию о размер программы в таком виде:

      text	   data	    bss	    dec	    hex	filename
     60224	   2500	  10540	  73264	  11e30	projectName.elf

где

• text — размер сегмента с кодом, векторами прерываний и константами только на чтение;
• data — размер сегмента с инициализированными не нулём переменными;
• bss — размер сегмента с неинициализированными и инициализированными нулём переменными.

Вся программа занимает:

• флеш — text + data + 10..50 байт
• ОЗУ — data + bss + 10..50 байт

Теперь посмотрим на что тратится память. Делаем новый проект и компилируем:

      text	   data	    bss	    dec	    hex	filename
       364	   1080	     32	   1476	    5c4	test-size.elf

Чтобы использовать макросы типа GPIO_BSRR_BS9 надо подключить файл stm32f10x.h.
Чтобы подключить файл stm32f10x.h надо в репозитоях добавить компонент STM32F10x_MD_STDLIB, который подтягивает за собой cmsis_core. В итоге для программы, записывающей одно значение в регистр получаем:

      text	   data	    bss	    dec	    hex	filename
      1316	   1104	     32	   2452	    994	test-size.elf

Далее меня интересуют функции типа sprintf и sscanf. Чтобы их использовать надо определить некоторые функции типа _sbrk и возможно некоторых других. Я взял готовый файл (есть в архиве с проектом). Добавляем 1 вызов sscanf и получаем:

      text	   data	    bss	    dec	    hex	filename
     39312	   2264	     96	  41672	   a2c8	test-size.elf

Режимы работы

Реализовал 3 режима по принципу действия: непрерывный, пакетный и логический и 3 по количеству каналов: 1, 2 и 4-х канальный.
МК имеет 9 аналоговых входов, но я не представляю когда мне может понадобиться больше 4-х каналов.

Непрерывный

Тут всё просто: в главном цикле МК считываем данные АЦП и передаём их на ПК, где можем строить непрерывный график. Недостаток — ограничение скорости со стороны канала МК -> ПК. Чтобы его обойти реализовал ещё 2 режима.

Пакетный

В этом режиме МК вначале набирает данные, потом пачкой передаёт на ПК. Опционально его можно разгонять. Про разгон подробно писал в предыдущих частях.

В этом режиме возможна синхронизация. Причём можно анализировать сигнал до выполнения условия. Для реализации такого функционала пришлось изменить режим работы DMA на кольцевой, использовать прерывание заполнения половины буфера и использовать буфер вмещающий в 2 раза больше данных, чем в передаваемом пакете.

В отличие от проекта baghear у меня триггер программный. Преимущества такого решения:

• Меньше деталей, а значит меньше цена и проще монтаж;
• Возможность в будущем реализовать более сложные триггеры, а не просто «сигнал в A канале стал больше Х».

В одноканальном режиме оба АЦП по очереди преобразуют значение одного канала.
В двухканальном — каждый АЦП преобразует свой канал запускаясь одновременно с другим.
В 4-х канальном — у каждого АЦП есть 2 канала, которые он преобразует. Старт обоих АЦП одновременный.
Очевидно, что скорость частота преобразования канала обратнопропорциональна количеству каналов.

Логический анализатор

Самый быстрый режим. Примерно 20 MSPS на каждом канале. Самый быстрый код для этого режима выглядит так:

u32 i = 0;
dataBuffer.u8[i] = GPIOA->IDR;
dataBuffer.u8[++i] = GPIOA->IDR;
dataBuffer.u8[++i] = GPIOA->IDR;
dataBuffer.u8[++i] = GPIOA->IDR;
dataBuffer.u8[++i] = GPIOA->IDR;
dataBuffer.u8[++i] = GPIOA->IDR;

и так далее на весь буфер.
Значение переменной i в этом случае вычисляются на этапе компиляции и в итоге из dataBuffer.u8[++i] = GPIOA->IDR; получается всего 2 операции — загрузить данные в регистр из порта и сохранить данные в память по заранее посчитанному адресу. Никакими циклами такой производительности достичь не получилось.

Программа для ПК

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

Итог

Проект не завершён, есть глюки, допиливать ещё много чего, но каких-то прорывов уже не предвидится. Для более быстрых систем нужно другое железо, например, отдельный АЦП + ПЛИС + память — а это уже будет гораздо дороже и сложнее монтировать.

Почитав комментарии к статье «История одного осциллографа на stm32» сразу отвечу на некоторые вопросы:

• Дисплей прикручивать не собираюсь т.к.:
  • Он стоит денег, а комп есть.
  • По качеству будет хуже, чем на большом экране ПК.
  • Создавать и изменять пользовательский интерфейс на C# проще, чем паять и перепаивать.

• Я не планирую его доводить коммерческого продукта и продавать.
• Делал для 2-х целей: освоить МК и сделать себе цифровой осциллограф.

Архив с проектом
Если у кого появятся вопросы, а тут не зарегистрированы, пишите в почту: adefikux на gmail точка com.

Автор: xedas

Источник