Форум РадиоКот

Доброго времени. Стал недавно осваивать МК, используя данную программу и взял, в качестве платы Ардуино. Всё шло, можно сказать отлично, пока в большой программе( по сути первой ) не потребовалось измерить длительность интервала времени с длительностью от 1,33сек до 2сек. Обычный частотомер - пошёл(включая Протеус) - без заминок и вопросов. Чем только не пытался заполнить период: внутренним таймером и внешними прерываниями по INT....Результат выводил( для уменьшения действий преобразования, в <числе импульсов заполнения>).Результат был абсолютно неадекватен(непропорционален) длительности периода относительно длительности заполнения. Потом взял за основу вариант с YT(Андрей ник RADIOSOFT урок №24 )....Период задаётся "0-1 на выводе ПОРТа", соответственно идёт подсчёт времени "единичного" интервала времени на выводе. До, этого, сам делал выделение периода по прерыванию INT( в макросе суммирование переменной до 2 -> выход из бесконечного цикла суммирования эталонных импульсов заполнения). Получались "левые" цифры числа заполняющих импульсов....
Ну, и во варианте из урока YT. При периоде подаваемого импульса в 1,81сек, имеем правильный результат 1/2 = 0,905сек и так вплоть до периода импульса в 1,5сек, где ПЕРВОЕ выводимое значение 0,749сек(верно), а все последующие = 0,691сек. При 1,33сек первое значение 0,664сек(верно), а дальше 0,521сек...и самое наглядное при 1сек периода: Первое показание 0,499сек, а потом 0,191сек!!!??? Математические действия в программе не вносят данную ошибку, да и частота эталонных импульсов - тоже...При задании максимальной частоты импульсов таймера....Протеус( комп) вообще может "встать"...
Поэтому, в чём проблема и есть ли она ПРИНЦИПИАЛЬНО в программе-коде или только в симуляции - не знаю, а хотелось бы удостовериться в работе в Протеусе, такой, по сути, элементарной программы. Частотомер, по крайней мере, вплоть до 20КГц - работает чётко. Может у кого-то, вообще заработает в том виде, как есть, тогда - ясно, что не работает симуляция. Если, кто подскажет - буду рад
Файлы в архиве.

Вы неправильно начали МК AVR изучать. Покупаете отладочную плату. Толковую книжку с примерами программ. Рекомендую Вольфганг Трамперт "AVR-RISC микроконтроллеры фримы ATMEL". В качестве отладочной платы рекомендую STK-500. На борту есть 8 кнопок, 8 светодиодов, UART преобразователь уровней. Либо 2 ардуинки. Одна будет в качестве программатора, вторую смело стираете и экспериментируйте.

FLOW неплохая задумка. Но это FBD блоки. Соответственно, все заточено на логику работы, а не алгоритмы. В вашем же случае нужен АЛГОРИТМ работы устройства. С FLOW не работал, подозреваю, что не сохраняется контекст в прерываниях.

Можно и с ардуинки начинать.
Только там два варианта
1. плата используется как макетка с интегрированной микросхемой а программа пишется как для автономного МК
в этом случае можно писать хоть под ассемблером хоть под Си хоть под чем другим.
Все ресурсы МК доступны для автора устройства (в рамках имеющейся схемотехники применяемой платы)
программирование ведется стандартным для АВР программатором
2. платка используется именно как АРДУИНО.
в таком варианте программа предпочтительно пишется именно в ардуино IDE в рамках тех средств, которые заданы/заявлены в референс ноте к IDE (https://www.arduino.cc/reference/en/ или https://doc.arduino.ua/ru/prog/ или использовать офлайн референс в самой IDE)
плата представляется разработчику как "черный ящик" с набором выводов, обладающих определенным функционалом.
программирование ведем через штатный бутлоадер средствами IDE.
Что в то же время не исключает и "глубококопания" в возможностях используемого средой компилятора по мере освоения предмета.

Иногда встречается и третий вариант - разработку ведут в рамках ардуино IDE, но плату используют самодельную (за основу берется минимальная обвязка МК) при этом программа компилируется средой в *.hex файл без бутлоадера для загрузки с помощью "стороннего" программатора.

Относительно работы с самой IDE...
Данный инструмент по отношению к самостоятельному программисту весьма жестокий ибо...
нет ни листинга компиляции, ни программного дебаггер-отладчика ни симулятора.
Контроль с возможностью распечатки сообщений существует только для явных ошибок, в случае вармингов сообщения можно лишь прочесть (и то, если включен соответствующий режим).
Отладка программ или макетом или макетом плюс возврат контрольных точек в виде сообщений на встроенный терминал.

В принципе вполне солидный продукт как с точки зрения создания ПО, так и с точки зрения аппаратной базы.
Но в то же время это и "ловушка для начинающих" (о том отдельная тема).

Додумался. Причина в наличии цикла индикации = 0,8сек. Выход из него ( при уменьшении длительности) измеряемых периодов, может прийтись на уже начавшийся момент "1" и часть измеряемого интервала оказывается пропущенной. Поэтому, после цикла отображения приходится вновь задать цикл "нахождения в моменте 1", чтобы потом начать всё, в прямом смысле с "0" и уже после чётко зафиксировать момент целого периода присутствия "1". Короче, въехал
Было
http://pixs.ru/showimage/Flowcode1D_719 ... 380433.jpg
Правильно так

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

[uquote="BOB51",url="/forum/viewtopic.php?p=3399524#p3399524"]Предпочтение внешнему контроллеру регенерации дисплея.
Тогда дисплей сам-по -себе, а измерение и обработка сама-по-себе.
Сброс обновленной информации только по завершении замера.
Поскольку дисплей внешний, то затраты времени только на пересылку данных, самого процесса замера более ничего не касается. [/uquote]
Да, это именно так. Режим вывода на 7ми сегм. даже в ПРОТЕУСЕ работает, при дополнительных подстройках(добавление пауз и специальный цикл). Использовать специальный(контроллер-память), куда отправляются данные - несомненно удобнее. С ЖК, вроде так и происходит, но у меня физически в устройстве, уже всё под "7ми" заделано....даже спец. и доп. символы на них приходится выводить( типа END, OUT, tESt и пр)

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

Так МАХ7219 и есть 7-сегментник на 4-8 позиций (именно под ардуинку заточен)
http://img.radiokot.ru/files/20529/1jhm9ip0gk.jpg
там эта платка вверху. Особое удобство - режим дешифратора. В этом случае достаточно тетрады двоичного значения (0х00-0x0F) -сегментный код генерируется контроллером дисплея.
Яркость... приходится сразу до половины понижать.
Интерфейс - 16 разрядный SPI.



Насчет "настраиваеш таймер" - в "чистой" ардуино данный режим может нарушить внутренние связи/зависимости псевдо ОС (ибо там уже таймеры задействованы - применение любой функции вида delay , milis и еше некоторых предусматривает использование таймеров по усмотрению системы).
Зато есть функции генерации частоты, захвата значения системных часов и измерения интервала импульса на избранном входе.
Да и дополнительно целая куча весьма удобных "добавок" которые по сути есть спецфункции СИ для удобства пользователя.
Программа и алгоритм для ардуино и для Си под МК будут заметно отличаться.
Хотя в сути своей практически тот же базовый AVR GCC.