0
Прямо сейчас на столе у меня лежит устройство, которое генерирует именно такой сигнал на одном канале таймера 1 в STM32F030F4P6.
Увы, не понимаю за счёт чего в этом примере формируется двухфазный сигнал. На всякий случай уточню что я под ним понимаю…



Пожалуйста, уточняйте, о каком кристалле идет речь…
F1. Да, в данном случае уже исправили. Молодцы.

И сколько оно занимает в памяти МК?
Скомпилировал такую заглушку под STM32F1.
int main() {
    time_t test = 1515251301;
    gmtime(&test);
    return 0;
}
Объём test.bin вырос на 1800 байт где-то. А какая нафиг разница? Если проект — простые часики, то флеша с избытком и из-за этих несчастных полутора килобайт за лимит никак не вылезешь. Если задача хоть на миллиграмм сложнее, от конвертаций всё равно ни за что не отделаться. Любая работа со временем (кроме вывода на семисегментники в часиках) не в скаляре крайне неоптимальна. Потому и используется time_t в линупсе, FILETIME в винде…
-1
Вы немного не поняли. Таймер, о котором я говорю, немного более продвинут, чем вы себе представляете. :)
Таймеры в хвалёном стм я более-менее себе представляю. Но продвинутым назвал бы, например, TC1 в ATtinyX61A. А таймеры у стм скорее вполне обычные…

В STM32 описанное реализуется одним каналом сравнения.
Не совсем описанное. Когда я говорил про ATtiny5/10, я имел в виду двухфазный сигнал, т.е. типа пуш-пулл — симметричный с регулировкой коэффициента заполнения. Не получишь его на одном канале в хвалёном стм…

Здесь есть искушение попросить какой-нибудь стоящий пример. Скажем, ваши варианты FFT на Си и на ассемблере.
Что касается AVR, я не вижу смысла писать FFT на Си, т.к. заранее знаю что получится тормозное кошмарище. Я сразу пишу на ассемблере. Си не способен работать с фикседпойнтом, на этом можно остановиться (а в хвалёном стм8 и асм не поможет). То о чём я говорю — статистика, набранная на различных случаях из практики. Написал критичный кусочек на Си, посмотрел на убожество полученного кода и время его выполнения (в AVRStudio это зачастую можно быстренько сделать в симуляторе, а в стм32 — видимо только бенчмарки в железе — скажем, в иаре в симуляторе я так и не нашёл счётчика тактов), понял что дофига не оптимально — переписал на асм, поразился результату. Запомнил что такое надо писать сразу на асме. Даже простое прерывание, скажем, системного счётчика микросекунд и миллисекунд при тактировании от кварца на 14.7456 на асме получается раза в 2.5 раза быстрее. Более заковыристые куски запросто дают 4 раза и более…

Когда я ловил резкие скачки значений с датчика тока
Кстати, банального компаратора в стм тоже не положили. Чем они думали? Иногда очень полезно для быстрой реакции на аварийные события. Скажем, в упомянутой мной ATtinyX61A компаратор даже можно использовать совместно с TC1 для защиты — видно, что люди думали прежде чем делать…

а дальше по прерываниям half transfer/full transfer быстро их усреднять и уже тогда, в прерывании, делать вывод
Кстати, эти half transfer/full transfer — то ещё убожество… Работа с буферами в DMA меня разочаровала, от хвалёного продвинутого МК я ожидал поддержку полноценного кольцевого буфера с гистерезисами заполнения.

Это не технический аргумент.
Правильную декомпозицию систему на уровни я ценю и для меня это вполне технический аргумент. Она сильно облегачает жизнь, позволяет строить систему легко и непринуждённо. Время в системе не скаляром — как раз архитектурно неверное решение… Многие простейшие и базовые действия превращаются в неотпимальный кошмар. При том, что особого выигрыша нет. В Си есть стандартная библиотека sys/time.h, которая тебе спокойно распакует time_t в struct tm. Говорить тут про объём кода смешно.

Вы же смотрели то видео, ссылку на которое я давал? :)
Догадываюсь о том чего там расскажут. Только едва ли аппаратный RTC в стм умён как библиотека на десятки килобайт.
0
Кстати защитный интервал там тоже можно настраивать по вкусу.
Не могу сказать что это хорошо, можно и самому ограничивать коэффициент заполнения. Больше сложность периферии — больше ошибок в ней, а пользы особой нет… Не люблю когда в железе лепят то что элементарно, без всяких издержек делается программно в пару операторов или строк просто чтоб оно было. Заканчивается это «много всего» потерей гибкости, более громоздким кодом и ерратой.

Стоили бы они по 30 — 50 р., как серия F030, было бы интереснее.
Много говорят про дешёвый стм, но не видел я чтобы они были намного дешевле. В компэле ATtiny10 — 33р, в чиде — 43р. Не так уж это много. Для радиолюбителя, собирающего несколько устройств в год для себя это даже копейками назвать нельзя. Нужно изготавливать много тысяч экземпляров чтобы эта несчастная разница в цене могла хоть в малейшей мере проявиться.

Мне рассказывали инсайдерскую информацию насчет того, что после F100 в ST просто разогнали дизайн-отдел и набрали его заново.
Это супер! Бывает в мире справедливость — хоть иногда, но гоняют тех кто делает такие вещи. Но по большей части МК остались теми же, в следующих сериях часть убожеств исправили, но с нуля всё не переделали… Им бы ещё тех кто документацию пишет разогнать, да переписать по человечески. Документация очепятками пестрит (типа TIMM1_BK1N вместо TIM1_BKIN), не говоря уж про остальное…

Так что здесь действительно правильно оставить ручную генерацию ассемблерного кода и просто надеяться, что компилятор и система выполнения кода выжмут максимум. Чаще всего оно так и будет.
Скорее всего не будет. Компиляторы неплохо справляются с тривиальными линейными кусками, там где ещё надо постараться сделать неоптимально. И неплохо вытягивают на учёте особенностей исполнения. Но когда структура кода становится маломальски разветвлённой, изучение выхлопа компилятора вызывает лишь уныние и желание всё переписать самому. С алокацией регистров компиляторы тоже не особо сильны. Это те вещи где нужно видеть картину в целом и кучка правил зашитых в компиляторы не вытягивают — тут нужна работа интеллекта. До полноценного ИИ компилятором далеко. Что касается avr-gcc, его выхлоп от любого кода, даже самого примитивного вызывает непрекращающийся фейспалм. Написанный вручную код как правило 4 и более раз быстрее и гораздо компактнее. Может отсюда у меня тяга к переписыванию критических участков на ассемблере. Впрочем, и на x86 это давало результат (и более акуратный код в случае с SIMD — не люблю мешанину Си с интринсиками, уж лучше кусочек написать на асме).

Сила этих чипов — мощная периферия, которая может делать многое просто сама по себе (как, например, АЦП, автоматически проверяющий преобразованное значение на попадание в диапазон).
Это мне тоже не особо нравится. Я бы результаты АЦП сперва через медианно-усредняющий фильтр пропустил. Тут также как с RTC — очень большая потеря гибкости. Хотя в отличие от RTC хотя бы маломальски оправданная если нужно делать быстро.

Ну, это все же субъективно. Удобно — это как когда. Чем тащить в контроллер библиотеку, которая будет корректно обрабатывать все это (сколько десятков килобайт она займет?), проще иметь аппаратный модуль RTC с календарем…
Удобно — практически всегда. Сравнить, отсортировать, вычислить интервал, компактно сохранить, передать, преобразовать в любой формат. Просто правильнее. Библиотеки есть. Функциональнасть аппаратного RTC не та, чтобы для его замены требовалась программная библиотека на десятки килобайт.

Если говорить про F0, то там ошибка совершенно смешная. Кому может понадобиться программно выключать tamper detection, если уж ее включили? Обычно в таких случаях функционал конфигурируется раз и надолго.
Не помню точно, вроде было аж две ошибки связанные с тампер-детектом. Что в F0, что в F4…

Ломать голову не надо. Теневое копирование уже реализовано за вас, аппаратно.
Но открываем еррату — и, сюрприз, оно не работает. О чём я и говорю. Бессмысленные навороты в аппаратных блоках «чтоб было» ведёт к еррате и раздутому коду. Причём без особой пользы для кого-либо.
0
Конкретно ATtiny13 — вообще чип-чемпион по соотношению параметров «цена-корпус-возможности». Аналогов ему у ST я не видел.
tiny13 — супер. Можно ещё глянуть tiny5/10 — похожи на tiny13, но на борту большой 16-битный таймер, с которого можно брать двухфазный сигнал, менять его частоту и коэффициент заполнения в широких пределах (причём коэффициент заполнения — это не дедтайм, его можно менять от 0 до 100/50%). Правда программирование TPI, а не SPI. Но собрать программатор не проблема, протокол описан в даташите.

Очень мощная штука DMA.
Да, STM32 несмотря на всю свою уродливость вывозят за счёт быстрых команд, тактовой частоты и DMA. Правда и здесь есть по хорошему ушату помоев. В DMA — реквесты фиксировано замаплены на несколько источников, и включив один источник остальные уже использовать нельзя. Только в F3+ исправлено. Что до быстрого ядра — впечатление портит тормозной флеш. SRAM тоже не решает проблему — её мало и к ней нужно обращаться за данными (в F3+ правда есть немножко CCM, да). Также очень большой минус — кривой и неудобный ассемблер. Без ассемблера не раскроешь мощь ядра по полной, что бы там не вопили любители ЯВУ.

Я бы, к слову, не сказал, что он такой уж дурацкий. Если нужны именно часы — очень удобно.
Я уже сделал простые часики, если буду делать ещё — будет синхронизация по NTP и ещё что-нибудь. Да и в простых была коррекция хода, прилепить её к RTC геморно. Да и вообще подход с календарным RTC — отстой. В технике время — это линейно нарастающая скалярная величина, именно так с ней работать удобно и правильно. Астрономическое время нужно только для ввода-вывода в интерфейсах, именно там оно и должно преобразоваываться в/из этот формата. ДОС хранил астрономическое время, но от того давно отказались. В линуксе используется скаляр time_t (который правда должен перепониться в 2032-м, но все давно уже перешли на time64_t). В винде время изначально 64 бита, причём разрешение аж наносекунда. Но СТ зачем-то решили выкопать труп древнего календарного RTC.

Кстати, в состав модуля RTC входит область SRAM, питаемая от батареи, которая может быть сброшена по сигналу с определенной ножки.
Насколько я помню еррату, оно не работает. По крайней мере, в тех семействах, которые я смотрел (F0, F4). То ли сбрасывается самопроизвольно, то ли не сбрасывается когда надо…

И главное: модуль RTC не везде одинаковый. Например, в STM32F100 он именно что представляет собой тридцатидвухбитный счетчик, тактируемый через конфигурируемый делитель от линии RTCCLK (ее можно подключить к нескольким источникам). Это то, что вам требуется? :)
Это безусловно плюс. Хотя именно на мелких сериях календарный RTC может быть хоть как-то оправдан (примитивные чясики без ЦКХ?), но календарный RTC стоит как раз на сериях пожирнее. Который в соответствующих жирных задачах любом случае придётся конвертировать в нормальный скаляр при чтении и в календарь при записи. И ещё ломать голову как сделать это атомарно…

Они фон-Неймановские, можно писать прямо во FLASH, в любое место, куда понравится. Так что EEPROM теряет смысл.
Флешка стирается только страничками. Что уже не очень удобно само по себе. И ресурс у флеша меньше в 10 раз, а переписывать нужно большую страницу на любое изменение.

STM8 тоже хороши (в основном ценой, конечно)
Вот именно, что лишь ценой. В остальном одно уныние. И ядро и периферия и элекртические параметры и как всё это сделано. Посмотреть хотя бы на время выполнения команд и количество регистров, какой-то простенький пик напоминает. Нет моих любимых умножений с длинным результатом. Это только один пример из большого множества.
0
Хороший коммент. Редко от пользователей стм можно увидеть хоть что-то по делу…

Идея с калибровкой мне нравится, если конечно разрешения калибровки хватает для приличной точности…

можно аппаратно подключить выход MCO ко входу почти любого (кроме самых простых из имеющихся внутри) аппаратного таймера
Снаружи соединять ножки — можно, конечно. Но как-то это не особо изящно и непринуждённо. Что им мешало завести выход LSE на какой-нибудь таймер? Есть множество задач где это может быть полезно. Дурацкий RTC прилепили, а простых и нужных вещей не сделали, даже еепрома нет.

который достаточно близок по характеристикам к серии ATmega
Смотря по каким характеристикам… Скажем, по характеристики «количество страниц ерраты» они весьма далеки.
0
Возможно, согласование лучше. Да и по заявленным характеристикам часовые точнее — 20ppm, а ВЧ — 30ppm. Это если говорить о стандартных кварцах, которые и продаются в шаговой доступности. Мои чясики врут на 1.1сек в сутки (такое значение подобрал для коррекции хода), что всего около 12ppm.
0
Если ты говоришь о компиляторах и ЯВУ
Даже не столько о них, сколько о дури, которую привносят сами разработчики. Типа хранения времени в формате RTC. Геморно на аппаратном уровне (дикой сложности блок, который реализует календарь), дико геморно в программе (сравнить два времени). И всё потому что какой-то идиот решил что раз время в формате RTC удобно выводить, значит в нём и хранить будем. Типичный пример перекладывания «лишней работы» на железо, в итоге всегда мусор на одном уровне зеркально переходит в мусор на остальных…
0
Если оно висит в главном цикле — значит оно уже не требует такой точности времени отклика.
Я говорил не о точности, а о скорости. Для точности есть прерывания, но всегда полезно чтобы главный цикл имел хорошее время отклика, пусть оно и далеко не будет детерменированным.
0
Ну, уже лучше чем 1000мс разрешения unix time.
Ты опять отвечаешь не на коммент, а на то что сам хочешь. Причём тут юникстайм? GTC — это счётчик времени с запуска и комент был о том что систик для его реализации тоже годится хреново. Систик — это прерывание, которое железо дёргает через определённые интервалы времени и в котором ОС решает свои дела. А для GTC хотелось бы чего то попроще, чтобы счётчик инкрементился аппаратно…
0
Там было «влияние которых можно уменьшить до нескольких тактов». Что уже недетерминированность сравнимая по порядку с нестабильностью кварца.
Чтобы несколько тактов (абсолютную ошибку) сравнивать с нестабильностью кварца (которая в долях), неплохо бы сперва привести их к общему знаменателю, а то сравнивание малость некорректное…
У anakost-а интервал секунда, тактовая частота 8 МГц, хандлеры явно уложатся тактов в 20. Это даёт ошибку в 5ppm. С нестабильностью кварца оно в принципе сравнимо, но слабым местом оказывается всё таки кварц.
Сильно зависит от задачи.
Ну вот я и хочу чтобы в зависимости от задачи можно было выбирать — тратить такты на сохранение или нет.
И только при условии что оно такое одно…
Вовсе не обязательно. Можно прерывания делать неблокирующими. Можно выделять окна времени. Иногда бывает такое что прерывание не одно, но вызваться одновременно они никак не могут.
видимо, на то есть причины
Если и есть причины хранить время в чудовищно неудобном формате в котором чудовищно геморно его хотя бы сравнить, да и вообще что-то сделать, то причины эти явно не забота о пользователе…
0
Ну GTC-то в винде на систике и сделан, на самом деле.
Потому разрешение его — убогие 15мс с копейками… Для МК это никуда не годится.
0
1000 тактов это немало. Всё, что блокирует главный цикл — уменьшает время отклика на время своего выполнения. Даже если в среднем оно 0.0001% тактов занимает.
0
Это который переполняется в 2038-м
И ты уверен что имеенно с этим явлением нужно бороться хранением времени формате RTC, а не time64_t (который, кстати, давным-давно уже используется)?
0
Напротив, крайне характерны. Можешь сам проверить — поищи самые дешманские наручные часы
Имеют место взаимоисключающие параграфы. «Характерны» и «поищи». У меня дома с десяток часов и я не могу найти такие, которые нужно было бы подводить чаще чем раз в несколько месяцев.
Важна не абсолютная длительность (на нее можно внести поправку — как и на погрешность кварца, кстати), а ее детерминированность.
Ну вот я и написал про детерминированность как раз после слов «плюс задержка», на которых ты отсёк цитату.
уже успела регистры схоронить, а не только PC передвинуть.
И что с того. Регистров море, ничего не мешает несколько отдать прерыванию, чтобы ничего не сохранять. Да и есть множество прерываний, состоящих из одного SBI/CBI, но которые должны выполниться как можно скорее.
Это который переполняется в 2038-м и к которому нужно примерно полкило кода на декодирование его в пригодный для вывода на дисплей формат? В системе он не особо нужен даже при использовании ФС, в ФАТ32 все равно таймштамп в другом формате. А для отсчета интервалов, где и удобно иметь время в виде счетчика — во-первых, точка отсчета времени не важна, а во-вторых — желательно иметь разрешение получше, чем секунда.
Время нужно иметь в виде счётчика, с которым можно работать. Вычислить интервал, сделать коррекцию хода, сменить таймзону, компактно сохранить и т.д. В формате RTC всё это дикий гемор. Даже атомарно загрузить/сохранить время в RTC гемор. Для отображения нужна качественная библиотека, которая переводит системный формат в любое нужное представление, а всякие аппаратные календари — перекладывание с больной головы на здоровую.
0
Техническое изделие может иметь множество уровней представления. Верхний — алгоритм работы устройства, который видит пользователь, затем код, который реализует этот алгоритм, затем командочки которые выполняются на процессоре, в которые выливается этот код и т.д. Тебя волнует только код, а большинству вообще кроме верха нафиг ничего не надо. Инженер же смотрит на весь пирог в целом, чтобы все уровни были без дурных излишеств, а не только избранные. Сущности каждого уровня должны логично и просто, без лишних фендибоберов переходить в сущности нижележащего… Потому что для чистоты реализации она должна быть во всех уровнях, иначе её не будет ни в одном. Именно на этом и построен Си, кстати… Любители же чистого кода никогда никакого чистого кода не получат. Потому что заметание мусора под ковёр не равно чистоте.
0
Твои 40с нехарактерны. Такие часы практически невозможно использовать. Типичная ошибка — до пары секунд. В советских часах обычно есть крутилка — подстроечный конденсатор, настроенный на заводе. У таких часов ошибка порядка полсекунды.
если у тебя непредсказуемая задержка входа в прерывание
В AVR вход в прерывание — 4 такта (не 12, как во всякой хрени) плюс задержка, которую может внести атомарный блок или другое прерывание. В принципе, при необходимости влияние и того и другого можно уменьшить до нескольких тактов или вообще исключить…
Мы таки о RTC или о счетчике секунд с запуска?
Причём тут секунды с запуска? прочитай внимательно фразу, которую ты комментишь. Речь про аппаратный RTC-календарь, дурной пережиток, от которого только гемор, который нафиг не нужен. А нужен вместо нормальный монотонный счётчик секунд с начала эпохи. Впрочем, что касается SysTick, для вещей наподобие GetTickCount() он тоже мало пригоден.
0
Думаю, речь о чистоте (отсутствии лишних телодвижений, мусорного кода, дурного выхлопа компилятора).
0
Это бы имело смысл, если бы индикация была не на светодиодный дисплей, а данные таймера захватывались аппаратно, а не в прерывании.
Мне нравится идея использовать часовой кварц для точных интервалов времени, детали реализации уже не суть. Можно и на прерывании точно считать, если оно единственное — никакого джиттера не будет.
Да и дешевые часовые кварцы та еще гадость с точностью порядка 10^4.
Дешёвые — это из китайских часов? Хотя 10^-4 — это 9 секунд в сутки, такое найти ещё надо сильно постараться… Кварцы, купленные в магазине или снятые с материнки вполне дают 20ppm.
Для этого в пафосных стм-ках есть SysTick.
Теряюсь в догадках какое он вообще отношение может иметь к подсчёту реального времени.
0
Обычно часовые кварцы идут на 20ppm, высокочастотные — на 30ppm. Можно, конечно, найти более точные, но с вероятностью 99,9% в радиолюбительской конструкции будут стоять самые распространённые стандартные…
Думаю, цифровая шкала вполне может быть измерительным прибором если оценить и указать её погрешность.
0
Понравилась идея использовать часовой кварц с асинхронным таймером, обычно в таких вещах тыкают кварц на основную тактовую частоту… А часовой покомпактнее, меньше жрёт и вроде даже точнее.
Меня в очередной раз радует AVR, где от часового кварца работает полноценный таймер, на котором можно сделать что угодно. А не тупо RTC-календарь как во всяких пафосных стм-ках (который, кстати, только мешает, т.к. время в системе всё равно необходимо в нормальном формате скалярного счётчика секунд)…