Бег по граблям

В предыдущей статье были фотки плат так называемых доменов «AB» и «MN». Ниже пара фоток отладочной платы процессора.

DSC00455 DSC00458

Из-за проблемы гальванического влияния цепей друг на друга пришлось изменять схему МЭК. Легкая коррекция схемы, на которую рассчитывали изначально, не удалась. В старой схеме АЦП был интегрирован в МК и получение аналоговых замеров сводилось в общем-то к переключению каналов мультиплексора и запуску АЦП. По окончании преобразования АЦП выставлял прерывание. Оставалось только в обработчике прерывания забрать результат оцифровки и поместить его в нужное место в буфере пакета для передачи в РКС.

Поскольку задача изменилась, причем с точки зрения схемотехники — изменилась совершенно кардинальным образом. Гальваническая развязка цепей подразумевает либо передачу данных в микроконтроллер двумя способами.

1. Передача аналогового сигнала из одной гальванически-развязанной цепи в другую, где и будет производиться оцифровка.

2. Оцифровать аналоговый сигнал в изолированном домене и передавать через оптопару уже готовый результат.

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

Из двух способов решения я выбрал второй.

Теперь вместо управления регистрами периферийных устройств микроконтроллера, программа должна сама перебирать бит за битом обращение к внешним АЦП. Ни о каких прерываниях по готовности результата уже говорить не приходится. Свободного времени у МК практически не будет.

А поскольку вся схемотехника и всё программное обеспечение МЭК разрабатывается почти с нуля, то я грешным делом подумал, что будет более правильно вместо дорогого и медленного МК ATMEGA328P заложить в изделие более продвинутый STM32F030.

К сожалению и здесь меня постигла неудача. Оказалось, что сформировать из выхода UART-а код Manchester-II на базе STM32 не получится.

Если выразиться более точно, то STM32 предоставляет такую возможно, но лишь частично. Микроконтроллеры TINY и MEGA выдают тактовый сигнал XCK независимо от того, есть или нет на выходе TX информация. А STM32 формирует тактовый сигнал SCLK только для информационных битов: когда UART выставляет на выходе TX информационные биты, то тактовый сигнал SCLK формируется как обычно. Но ни для стартового бита, ни для стопового STM32, а так же во время паузы между передачей байтов, STM32 не формирует тактового сигнала. Только для информационных битов.

Вот, ни хрена себе! Вот это поворот! И что сейчас делать?

А ничего!

Но я точно помню, что ARM7 были способны к формированию кода Manchester-II. Как же так? Я начал рыться в своей памяти и листать pdf-ки.

Я нашел ответ на этот вопрос. Оказывается по истечение 5-7 лет моя память немного исказила представление об этой теме. Да, AT91SAM7Sxx способны были качественно сформировать Manchester-II.

Но AT91SAM7S — это же ARM7, а не Cortex! Что-то как-то не тянет меня на эти подвиги… Пусть уж тогда остается ATMEGA328P в качестве процессора.

Поэтому, на плате вы видите AVR, а не Cortex. К сожалению, так просто расстаться с AVR-ками не получилось.

Честно говоря, есть ещё одно направление решения этой проблемы. Я имею в виду формирование Manchester-II не из TX и тактового сигнала UART-а, а из сигналов MOSI и SCK SPI.

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

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

Совсем другое дело SPI. Здесь каждый бит информации обязательно должен сопровождаться тактовым импульсом. Синхронная работа приёмника и передатчика обеспечивается как раз передачей этого тактового сигнала.

Таким образом для SPI наличие тактового сигнала SCK является жизненно необходимым условием для приема. А с другой стороны наличие битов синхронизации: стартового бита и стопового бита уже не имеют никакого значения, поэтому их и нет в этом протоколе.

Иначе говоря, передача по SPI на той же тактовой частоте будет теоретически быстрее (за счет исключения битов синхронизации), чем передача по UART, но потребует двух проводков: для информационного сигнала и для синхросигнала.

Сформировать Manchester-II на основе сигналов SPI легко. А вот восстановить из Manchester-II и информационный сигнал, и сигнал синхронизации моя приёмная аппаратура не готова. Точнее так — приемник в РКС способен из Manchester-II выделить только информационный сигнал. Синхросигнал, без которого SPI не будет работать — не кому.

— Дурак твой геолог! Смотри, опять к берегу пришли!

Не-е, теоретически я могу доработать схему приёмника РКС, переписать программу под SPI, но ведь это надо дорабатывать. Это опять-таки время.

Поэтому, как ни крути, но из колеи очень сложно выпрыгнуть.

Advertisements

8 responses to “Бег по граблям

  1. Это жизнь, а не рекламный букет новых микроконтроллеров, где всё хорошо и отлично работает. Похоже что такое везде встречается, не только в электронике.

    Я для обмена данными между блоками (модульной клавиатуры) выбрал I2C, в котором так же используется синхролиния (мне всё равно ещё и питание тащить, поэтому 3 или 4 провода это не важно, отлично подходит телефонный провод в хорошей изоляции), поэтому могу делать модули без кварцевого резонатора, используя внутренний генератор, это упрощает конструкцию. И использую AVR со встроенным аппаратным I2C, чтобы не было потом сюрпризов с работоспособностью всей схемы.

    Удивляет, что некоторые говорят, что AVR уже считай что умер, а когда приводишь пример того, что есть в AVR и нет на других платформах, начинают придумывать, что это можно сделать самому, или это никому не надо.

    • Ну почему сразу — «умер»? Не умер. И не умрёт, точно так же как и не умерло в ноль 51-е ядро. Объем рынка AVR — сократится существенно, да. Но в ноль никогда не выродится.

      AVR-ки хороши для простых решений, небольших проектов. Очень хороши как ногодрыгалки. Но если взять задачу чуть по-сложнее, то лучше ориентироваться на Cortex-ы.

      Моя же задача (по сбору геофизических данных и передаче их по кабелю) находится где-то на грани между тем и другим. Поэтому можно применять как AVR, так и Cortex-M0.

      Поскольку я знаю Cortex-ы фирмы ST-Microelectronics, но толком жаде не работал с Кортексами от ATMEL, NXP, TI, Energy Micro и более экзотических производителей, то я естественно ориентировался на STM32. А в нём, как на беду, USART работает иначе в том экзотическом режиме, который нужен мне.

      Ведь у каждого производителя микроконтроллеров на базе Cortex своя периферия. И не факт, что периферийные устройства разных производителей должны совпадать. Они, конечно, совпадают в «стандартной» части, а в опциональной — каждый производитель «лепит» своё.

      Мой случай — это не показатель. Это всего лишь единственный частный случай. Более того, пройдет немного времени, и я всё-равно переделаю МЭК на STM32. Просто не возможно одновременно наступать по всем фронтам.

      Переход от AVR к Cortex — тенденция, однако.

  2. А что мешает из AVR сделать сопр для декодирования?

    • (сопр — в смысле со-пропроцессор)

      Принципиально ничего не мешает, но…

      1. Есть небольшие трудности с габаритами. Плата должна располагаться в трубе диаметром 22 мм. Не хотелось бы иметь слишком длинную плату (более 250 мм) или иметь несколько плат. Допустимо, но не хотелось бы.

      2. Несколько повысится энергопотребление устройства. По моим грубым оценкам — процентов на 20. Тоже допустимо, но как-то не хотелось бы.

      3. AVR-ка должна иметь на борту UASRT. Это либо tiny2313, либо любая Mega.

      Если передатчик сигнала в кабель выполнять на Tiny, то нужно озаботиться что бы она работала в жестких рамках реального времени с основным процессором — передача пакета передачи данных не должна прерываться. Пауза более 1.5 байтовых интервалов приемником воспринимается как окончание одного пакета и начало передачи второго. То есть если возникнет пауза, то будут отброшены обе половинки пакета.

      Другими словами, Tiny должна принимать от основного процессора байты и тут же их отправлять. В принципе тоже реализуемо, хотя слегка и немного гемморно.

      Если передатчик выполнять на Mega, то лучше сразу взять Mega с объемом памяти, куда может целиком поместиться весь пакет данных. Размер пакета данных 832 байта.

      А если мы берем Mega с оперативной памятью 1-2 килобайта, то какой смысл в основном процессоре? Пусть вся функциональность будет реализована на этой Mega.

      Как-то так.

      Спасибо за вопрос. Пока отвечал на него, ещё раз подумал — а правильно ли я делаю. Вроде правильно.

      • Ну вот тут как раз и появляется второй вопрос: а так ли уж хорош STM, чтобы настырно совать его ну прям совсем-совсем везде? Вполне возможно, что AVR (Mega) тут подошли бы лучше.

      • Вот именно, а то складывается впечатление, что STM слишком уж разрекламирован, а как доходит до практики, то одного в нём нет, то другого, то просто не удобно использовать, и тут на выручку приходит AVR, который просто работает, без пафоса.

      • Не-е, пацаны! Не валите всё в одну кучу. В моем конкретном случае есть исторические корни. Не будь их, мой выбор микроконтроллера был бы на стороне STM32.

        Я ж говорю: пройдет время, и я переведу систему с AVR на Cortex. Потому что в моем случае это даст небольшие преимущества.

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

      • Мне кажется, ответ очевиден — каждому процессору своя ниша. Как-то так.

        Другое дело, что ниши ATMEGA и STM32 перекрываются, и получается, что в каких-то проектах можно ставить хоть то, хоть другое — разница лежит «ниже уровня шумов».

        Вот этот — конкретный пример выбора МК для МЭК, показывает, что в данном случае особой разницы нет. Есть разница в цене (ATMEGA328P стоит около 150 рублей, а STM32F030F6 — около 50), но эта разница «утонет» в зарплате разработчика, и ее никто не почувствует. Прибор изготовляется штучно, о серии нет и речи.

        Есть, конечно, разница в удобстве работы с тем или иным МК. Но это очень индивидуально. Я лично комфортно работаю и с тем, и с другим.

        А то обстоятельство, что USART у STM32 не может нормально создать Manchester-II — ну это не критерий для отбраковки STM32.

        Если вместо USART ипользовать SPI, то будет тоже самое, даже быстрее на 20%, но для этого мне нужно слегка переделать РКС. Но ведь всё сразу не изменишь! Поэтому, сейчас — да, пусть будет ATMEGA328. Но завтра я в очередной раз изменю мир.

        А что касается отладки программного обеспечения, то STM32 мне нравится больше, чем AVR. Но это опять же — всё чисто индивидуально.

        У каждого своя «религия», будь то Линукс или Виндовс, будь то Mega или STM32.

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s