Как стать автором
Обновить
3
0

Пользователь

Отправить сообщение

Это конечно так, но опять же все зависит от задачи. AnalogRead в Due длится 5 мкс, в младших платах видел, что около 120 мкс. Если вы предлагаете заменить AnalogRead на что-то связанное с управлением АЦП через регистры, то это точно не для новичков.

Если считать не в микросекундах, а в тактах, то потери времени становятся значительно более весомыми. Так, например, в ДШ на ATmega328 говорится о том, что АЦП может выдать "Up to 76.9kSPS (Up to 15kSPS at Maximum Resolution) ". При тактовой частоте 20МГц вызов функции AnalogRead  будет стоить от 260 до 1333 тактов. 260 тактов это примерно 3-4 операции целочисленного деления - этого как раз хватит на простую обработку одного значения. Использование AnalogRead снижает производительность вашей системы более чем вдвое от потенциально возможной. Конечно, речь не идет про одиночные измерения с помощью АЦП. Но даже в приведенном вами примере про 50Гц - 128 точек на 50Гц = 6.4 КГц, треть времени ваш камень будет простаивать при использовании максимальной точности. А если нужно еще пару входов опрашивать?

В SAM3X8E имеется DMA. Там опрос АЦП вообще может не требовать ресурсов ЦП. Не знаю, есть ли вообще поддержка DMA в ардуинах.

Всеми этими словами я пытаюсь сказать, что инфраструктура Arduino очень сильно ограничивает разработчика, загоняет его в свои примитивные рамки, заставляя его использовать AnalogRead и вот это вот всё в камнях с DMA на борту. Начинающих пугают страшными регистрами. А это очень зря, особенно на таких простых вещах, как atmega. И тут надо отделать обучающие материалы от решений в стиле "и так сойдет". По крайней мере, подобные решения всегда нужно дополнять соответствующим текстом, про то, что это не оптимально, можно по другому и я так сделал, потому что у меня условия такие.

Рад, что вам понравился описанный в статье метод )

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

Вот знал, что будут до delay докапываться

Скажем так. Статья определенно для начинающих. Отсюда и основная претензия: такими статьями закладывается определенный подход к решению задач у неокрепших умов. Это потенциальная проблема на долгие годы. Опрос клавиатуры - классическая задача про неблокирующий подход к написанию программ. На этом примере можно и нужно учиться минимизировать использование делея. К тому же, во время делея процессор не делает ничего полезного, а только расходует электричество.

Решение всегда зависит от конкретной задачи, если delay будет чему-то мешать, значит будут другие варианты с неблокирующей фильтрацией.

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

А что не так с этим кодом?

Этот код не делает почти ничего. Основную часть времени он ждет установки флага о завершении преобразования АЦП. Это тот-же делей, только в другой форме. Если использовать прерывание и складывать там результат в массив, можно сильно высвободить время основного цикла программы. В это освободившееся время, например, обрабатывать результат измерений предыдущей пачки из 100500 измерений.

Такие простые мелочи сильно увеличивают отзывчивость программы на внешние раздражители. Думаю, мы все сталкивались с ситуацией, когда жмешь на кнопку, а она тебя игнорирует. Или результат приходит через две секунды. Это раздражает. А корень - вот он, в подходе к написанию программ.

Очередная статья про ардуину и включение светодиода без токоограничивающего резистора.

Про одновременное нажатие кнопок, диоды и резисторы. Решение крайне простое и удивительно очевидное: переводим неактивные пины выбора "столбцов" из выхода на вход с подтяжкой. В каждый момент времени на выход работает только один пин. Никакого КЗ не получится автоматически.

Про дребезг. Да, самый простой способ его отфильтровать - это задержка. Но использовать блокирующую задержку в программе - это отвратительное решение. Для неблокирующей фильтрации делаем опрос клавиатуры в две стадии. Первая - устанавливаем пины "столбцов". Вторая - читаем пины "строк". Это можно делать по прерыванию или вызывая функцию опроса из основного цикла. Главное, периодично. Это может выглядеть как-то так:

int key_state[ROW_COUNT][ROW_LEN];
int key_column = 0;
bool key_pins_set = false;
void AskKey() //Вызывать примерно раз в 10-20мс
{
	if(key_pins_set) //Если столбец выбран
  {
  	for(int i=0;i<ROW_LEN;i++) //Бежим по строке
  		if(ReadRow(i)) key_state[key_column][i]++; //Если кнопка нажата - инкремент по 
      else key_state[key_column][i] = 0; //Если не нажата - сброс в 0
      
    key_column++; //Для следующей итерации увеличиваем номер столбца
    if(key_column >= ROW_COUNT) key_column = 0; //Если прошли все столбцы - начинаем сначала
	}
	else
  {
  	SetColumn(key_column); //Если столбец не выбран - выбираем его
  }
  key_pins_set = ~key_pins_set; //Инвертируем флаг выбора столбца
}

Если присмотреться, то такой код позволяет не только считывать нажатия, но и определять их длительность. И все ценой нескольких команд на каждую итерацию, а не блокирующей задержки в 50 мс. Так же, этот код легко можно совместить с выводом на семисегментный индикатор.

И на последок, автору совет, никогда так не делайте так: "For (i=0; i<100500;i++) analogRead(A0);" Скажу по секрету, у АЦП тоже есть прерывания.

Проблема «специальных блоков» для выполнения конкретных задач — к ним нужно специальное ПО, привязанное именно к конкретным блокам. Через год выйдет процессор Apple M2+ с другим «декодером» или блоком DSP. И вот незадача: все ПО от M1 к нему уже не подходит. Именно по этой причине Intel и AMD не идут по такому пути. У них, кстати, очень большой набор специальных команд на все случаи жизни. Это тоже с натяжкой можно назвать «специализированными блоками», однако никто не заставляет их использовать. Это просто расширение для основного набора команд и от их наличия или отсутствия меняется только производительность в узком классе задач.
А бенчмарки для этих процессоров — вообще маркетинговая ерунда. Да, конвейерный DSP уделает обычный процессор в задачах, под которые заточен. Как и «декодер». Но в первую очередь, они требуют создания специальных условий для правильной работы — подготовленные данные, определенная последовательность действий и формат результата, во вторых — они имеют узкую специализацию. В задачах широкого профиля (а не задачах показывать кинчик очередному адепту яблочного культа) классический процессор будет быстрее и удобнее. Но ничего, я думаю, мессии из самой передовой компании человечества расскажут массам, как оно должно быть на самом деле и массы это схавают, конечно. Эта статья — яркий пример.
Как представитель молодого поколения от автоматизации, не могу не согласиться. Очень часто вижу, как именитые компании и опытные специалисты используют FBD или LD. Я же предпочитаю ST, хотя в нем очень просто выстрелить себе в ногу. Но доступна обработка в циклах, легко реализуются машины состояний, сложную математику нужно реализовывать только на ST (как самый распространенный пример — вычисление расхода по перепаду давления на сужающем устройстве — на ST это 4 строчки и формула читается сразу, на FBD — целый лист блоков с непонятными связями).
Тем не менее, FBD имеет ряд преимуществ. С помощью него очень наглядно можно представить логические схемы, которые не помнят своего предыдущего состояния. И отлаживать такие схемы легче в виде FBD. Но реальность такова, что все увиденные мной редакторы FBD (а это CodeSys, Schneider UnityPro, разное от Siemens) требуют какое-то нереальное количество кликов мыши и ужасно поддерживают размножение типовых кусков. Например, вызов одного и того-же блока, присоединенного к множеству разных входов/выходов контроллера станет головной болью в FBD.
LD же просто должен гореть в аду ))) Особенно, когда его лепят к аналоговым сигналам (Schneider это очень любит). Хотя это уже зависит от программиста больше.
Я работаю «автоматчиком» на малых турбинах (2,5 МВт). Поставила нам их достаточно крупная компания за плечами которой более 600 турбин малой и средней мощности. Не Сименс, конечно, но и не Николаевский турбинный завод. От себя скажу, что в такой системе присутствуют не только программные костыли и не качественное железо, но и куча ошибок проектирования.
Самая распространенная — неправильное использование нормально-открытых и нормально закрытых контактов и исполнительных механизмов. Например: датчик верхнего предельного уровня конденсатора. Служит для защиты лопаток турбины в случае подъема уровня конденсата в конденсаторе. Использован нормально-открытый контакт. Т.е, пока датчик не сработает — ток по цепи не течет, реле разомкнуты, входы ПЛК не активны. А это значит, что в случае обрыва кабеля, перегорания реле, да и просто винтика, раскрутившегося от вибрации, сигнал от датчика не дойдет до места назначения. Для таких датчиков допускается использование только нормально-закрытых контактов на всем пути следования сигнала.
Аналогичный случай и с аварийным стопорным клапаном. Пока на катушку этого клапана не будет подано напряжение — он не сработает. А функция этого клапана весьма значительна — остановить подачу пара в случае любой нештатной ситуации.
Зато заменить в ходу любой из аналоговых датчиков нельзя. Отключение любого из них вызывает остановку. Даже второстепенных. И нет никакой возможности ручного отключения этой защиты. Вот и приходится по 2-3 месяца работать с неисправными датчиками.
С нетерпением жду окончания гарантии для исправления всех этих косяков. Регулятор нагрузки уже переписал втихую, так как скачки по 200-300 кВт терпеть не было сил.
В том то все и дело, что теоретик был в восторге. Ошибка приводила к появлению в сигнале периодической составляющей всегда разной амплитуды и частоты (в зависимости от скорости потока данных, его «насыщенности» большими значениями и прочее). Это все отлично ложилось на теорию неких инфразвуковых колебаний в объекте исследования.
Я бы не хотел раскрывать больше деталей, так как ситуация деликатная, а тема очень узкая.
Сам побывал в неприятной ситуации с оборудованием. Но уж лучше я что-то испортил дорогое. Это хоть поправимо. Нет, никто не умер. На первом курсе меня пустили «дособирать» одну установку, работа которой была связанна с несложной обработкой средненького объема данных (25-50 Мбит/сек) в реальном времени. Старая начинка была собрана на логике и комплекте КР580. Программа сохранилась только в ПЗУ, скорость работы комплекта не позволяли установке двигаться дальше в научном плане. Я собрал новый блок обработки данных на Cyclone II, DRAM и ARM процессоре. Для научного это был просто фурор. Результаты пошли рекой. Научный защитился на этих результатах, его коллега, куча статей, конференции, ссылки. И вот, на 5-м курсе, перед защитой магистерской, я, лениво листая файлы vhdl, нахожу ошибку в работе с памятью. Именно она сгенерировала основную массу прорывных результатов.
Я не хочу сказать, что студентов нельзя допускать до оборудования. Просто у нас как-то стало не принято верифицировать результаты. Получили — сразу в печать. И такое НИИщебродство только усугубляет ситуацию. А студенту-то что? Ему в кайф сделать открытие. По себе знаю.
Обычно, для наиболее быстрой реакции используют «встречную запись» — HMI пишет в ПЛК, ПЛК пишет в HMI. Как физический уровень, Ethernet наиболее удобен в такой схеме. Он позволяет через одно физическое соединение гонять сколько угодно (ну, до 65535) логических. Скорость передачи гораздо выше, чем у конкурентов. Да и совокупность простоты и надежности тоже на уровне. Если передача значения привязана к изменению этого значения, то скорость реакции ограничивается только временем доставки пакета.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность