Есть програма для Kinetis K10.
В ней есть глобальный счетчик милисекунд который инкрементируется каждую милисекунду в прерывании.И на основе этой переменной строятся таймауты и периодические циклы.
Это очень удобно и работать с переменной просто но мне не нравиться парадигма прерывания програмы каждую милисекунду.
У Kinetis есть аппаратный таймер (FlexTimer Module (FTM)) 16 бит - это дает нам 65536 милисекунд до переполнения что конечно очень мало для нормальной работы.
Что поинтересней можно придумать для Cortex-M4?

Ничего страшного.
Я обычно делаю 10 мс, но при помощи SysTick. В Cortex именно этот таймер используется для этих целей.


А что значит "нормальная работа"? Переполнения конечно же нужно обрабатывать.
При 32-битном счетчике переполнения будут каждые 49 дней, но их тоже нужно обрабатывать.

ничего страшного если управляем елочной гирляндой.
раз в 49 дней это не каждую минуту.

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

Только счет регулярных интервалов времени тут, само собой, отпадает. См. также tickless systems.

а как я устанавливаю период тика в SysTick? я что то не нашел никаких прескайлер регистров

Может, поискать в документации? Там все очевидно: и источник, и делитель.

покажите где тут делитель
http://infocenter.arm.com/help/index.jsp?t...a/Babieigh.html

Перевожу: есть 24-битный вычитающий таймер. Когда он досчитает до нуля, то перегружается значением из SYST_RVR.
Таким образом можно получить периодические прерывания, а в них уже работать с софтовыми интервалами.
Обращаю внимание на бит CLKSOURCE регистра SYST_CSR. Он выбирает источник тактирования.
У STM32, например, можно тактировать от HCLK или HCLK / 8 за счет этого бита.

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

извиняюсь - милисекунд.

Дык, микро- или мили- секунд?

милли-

У ТС именно "мили". Нужно понять что это значит.

все так грустно? только мне на планете Земля нужны временные метки в проекте?

Миля - единица длины, секунда - времени. Даже как-то затрудняюсь вот так ставить между ними знак '-'.


С точки зрения физики: значение разницы расстояния и времени пока не исследовано


нет. Только у Вас это вызывает трудности

У Kinetis есть 64-х битный lifetimer на базе PIT. Так что хватит на всю жизнь с точностью в 16 ns

PIT не имеет пределителя. его невозможно настроить на 1 милисекундный тик.

можно через второй таймер но второй таймер генерирует прерывание - а я этого хочу избежать.

2 AlexandrY: неужто у супер-пупер кинетиса нету таймера с хотя-бы 20-битным прескалером? или возможности использования в качестве такого прескалера другого таймера (concatenating)?

Что мешает считать в тиках таймера?

Допустим, тактовая частота процессора 120 МГц. На вход в прерывание и выход тратим по 12 тактов. На инкремент счетчика, пусть, еще 12 тактов. Итого:
36 / 120 000 = 0,0003
Вы боитесь потерять производительность на 0,03%?

Так это и есть после конкатенации. Но при этом атомарное чтение.

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

это типа шутка?

Как может мешать нечто с нагрузкой 0,03%?
Из-за неоптимального кода можно потерять куда больше.
Прерывание лишнего тока не ест, помех не создает. Все ОС используют прерывание от системного таймера.

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

Jenya7, вы по все видимости начинающий разработчик - прислушайтесь к советам опытных МК-программистов.

Зачем вам аппаратный таймер, если вы от него даже прерываний боитесь? Это две крайности.
Нужно сделать аппаратный таймер для счета программного счетчика с интервалом 1 или 10 мс.
Затем все миллисекундные задержки и выше делать программно. Только так.
Если у вас какая-то неприязнь к такому решению, то вы в чем-то заблуждаетесь - можете высказать свои "фи", и мы вас переубедим.
Повторюсь, у Cortex-ов есть специальный таймер SysTick, и 99% проектов использует его
для миллисекундных и выше задержек, с программным отсчетом времени.
Задержки на микросекунды и ниже уже могут потребовать аппаратный таймер.
Использование аппаратного таймера жестко привязывает проект к данной архитектуре и данному камню - проект будет
слабо переносимым и склонным к аппаратным конфликтам с другими библиотеками и т.п.

Насколько я понимаю, ТС хочет сделать некую инициализацию, чтоб потом вычитывать из некого регистра число, равное числу миллисекунд.
Желательно, чтоб регистр был 32-битным. Вроде, у LPC17xx таймеры были 32 битными с 32-битным предделителем.


У Cortex-M есть NVIC, который может делать вложенные прерывания с приоритетами.
Если 32-битная переменная выровненная, то доступ к ней будет атомарным.
Но я так понял, что из счетчика миллисекунд бы будете только вычитывать.

Такие критические, что 0,3 мкс не могут подождать? Не верю.

Можете подробнее рассказать о них?
Это не норма, такие вещи нужно делать аппаратно и/или подбирать соответствующее аппаратное решение.
Я уже 10 лет не пользуюсь запретом/разрешением прерываний, а проектов сделал очень много. ЧЯДНТ?

adnega так что вы предлагаете? я честно говоря так и не понял.
по моему вот этогоя и пытаюсь добиться.

Не шутка. Так все и делают... кроме вас почему-то...


Ага, уже лет N как начинающий и всё не могущий начать

Дык, настраиваете SysTick на генерацию прерываний с интервалом 1 мс, а в обработчике прерывания делаете

, где maintimer - 32-битная переменная, в которой будут лежать миллисекунды.

мда... ну вобщем тему можно закрывать. признаюсь был не прав.

Раньше, тоже делал счет миллисекунд из прерывания, но последнее время стал использовать такой способ
http://we.easyelectronics.ru/Soft/samyy-pr...nyy-taymer.html
Только максимальное значение миллисекунд, которое можно задать зависит от таймера.
А для сильно большой задержки, использую RTC, настроил что бы счетчик работал по секундам и считываю его, также. (только это относиться для stm32f1x, для stm32f4x RTC совсем другая )

у меня таймера не хватало. в Кинетесе они кривые. кроме LPTM. освободил LPTM. он 16-битный приходиться приращивать в прерывании

А почему SysTick не используете?

Этого мало? Это позволяет делать/контролировать задержки до 65 секунд без какого либо контроля переполнения, в лоб, без бубнов и танцев. Если нужно делать задержки измеряемые в секундах (например 1000 секунд, или 10000000 секунд), то можно отдельный таймер аппаратный завести с тактом 1 мс и переполнением после 1000 мс, в прерывании ++globalSec . Или вообще использовать RTC.

В K10 4-канальный 32-битный PIT (программируемый интервальный таймер) есть - делай счётчики интервалов какие хошь (; Впрочем, ТС сознался, что был не прав.

объяснил это в первом посте.



у него нет пределителя - я не могу создать тик с периодом и 1 миллисекунду.





то же самое - у него нет пределителя - я не могу создать тик с периодом и 1 миллисекунду.


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

Вы опять за старое.
У него есть период, и за счет периода вы создадите 1 мс.
С периодом 1 мс у вас будет шагать не таймер, а вызываться обработчик прерывания, в котором будет to_1ms++.
Для этого подойдет любой таймер, но есть же специальный SysTick. Почему его не используют некоторые?

Писал же ТС, что у него сейчас так и есть, но он не хочет раз в 1 мс падать в прерывание, а хочет сделать аппаратный миллисекундный таймер.


vsкак это? 16 битный таймер дает переполнение через 65536 милисекунд, но тик у этого таймера не равен 1 мс???
Проблема решена, и слава богу!!!

ТС не умеет задавать такое значение в SysTick таймер, чтобы тот перезагружался с периодом 1 мс. Учиться, учиться и еще раз...

вы вообще читали тему? первый мой пост? ради чего была создана тема?

Я НЕ ХОЧУ ГЕНЕРИРОВАТЬ ПРЕРЫВАНИЯ КАЖДУЮ МИЛЛИСЕКУНДУ.

все. эту руку я сбрасываю.

То есть, мои аргументы, что вы теряете 0.03% производительности, вам не понять?

да хрен с ней спроизводительностью. хоть 5%. дело не в ней. у меня бегут важные таски. критические можно сказать. и я не хочу прерывать их каждую миллисекунду.может ничего страшного не произойдет. но зачем мне дополнительные, неоправданные как я считаю, риски?

Вы можете объяснить почему? Это вполне естественная вещь для МК, но вы категорически ее отвергаете.
Вы бы поменьше секретничали, а то нам в соседних ветках достается, что за вас додумывают недосказанное.

зачем это объяснять? ТС и так уже всё объяснил. У меня было такое.... сделал таймер с тиком в 1 мс и отрубил прерывания. Полностью аппаратный миллисекундный таймер.

А через каждые 10 мс прерываться рискнете? Тоже нормальный период для RTOS.

А если бы не отрубил прерывания, то что?

А они мне зачем? У меня есть полностью аппаратный таймер, зачем мне программный таймер и обработчик прерывания? Вы наверно аппратный RTC(или UART/SPI/PWM/...) не будете пользовать, т.к. можно сделать программный, с календарем, с кучей будильников, ведь программный RTC займет всего 0,003% ресурсов!!!

Допускаю, что есть эксклюзивные задачи, в которых одного таймера до 65 мс достаточно, но в общем случае вариант
с 1мс-прерыванием гораздо универсальнее.
В некоторых библиотеках я вообще пришел к двум/трем функциям
on_init() - один раз при инициализации МК
on_mainloop() - внутри mainloop`а
on_timer() - внутри 10мс-таймера
Решение гибкое, воспроизводимое на множестве камней и архитектур. Никаких дополнительный аппаратных требований,
типа таймер с предделителем таким-то и т.п.
Я не против исключений из правил, но их не стоит выдавать за правило.
Я на atmega8 вообще без аппаратных таймеров делал программный UART-TX тупо nop-ами формировал задержку,
и работало-ведь, но я же объявляю это нормой. Сделать софтовый 1мс таймер настолько просто, что грех от этого отказываться.
И мне не понятно зачем? ТС говорил, что у него какие-то критические секции есть... думаю, больное место там.

Я думаю - там весь код одно сплошное больное место. Судя по постам ТСа...

65536 мс. не 65 мс, а 65 ТЫСЯЧ мс, это 65 секунд. И таймер один, но одновременно всяких интервалов и периодов можно задавать хоть сотню (как и на программном). Решение гибкое, воспроизводимое на множестве камней и архитектур. Никаких дополнительный аппаратных требований программных обработчиков, программного кода, настроек NVIC и т.п. Если зашли в критическую секцию (остановили прерывания), то таймер продолжит считать.

опечатка?

Не знаю как объяснить? зачем в МК аппаратная перефирия? можно всё программно сделать, без таймеров, на ноп-ах и ногодрыгах.