Возможна ли "система реального времени" на RTL?

[aloika]

Хочу задать в большей степени теоретический вопрос.

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

Можно ли принципиально реализовать такое на RTL? Если да, то какое гарантированное время можно получить между моментом превышения тока и моментом подачи сигнала на отключение? Будет ли оно примерно около дискретности планировщика RTOS (1 мc) или можно его как-то уменьшить? Каким образом лучше всего будет организовать программу?

Сейчас такая задача "почти реального времени" решена на связке ESP+Attiny. Attiny выполняет задачу "реального времени", а ESP коммуницирует с внешним миром. Между собой модуль и контроллер общаются по UART.

 

[Simon]

Аналоговый сигнал планируется со встроенного ацп читать?

 

[aloika]

Аналоговый сигнал планируется со встроенного ацп читать?

Не знаю ещё, может быть. А может, какой внешний поставить.

 

[pvvx]

Не знаю ещё, может быть. А может, какой внешний поставить.

У RTL8711AM у ADC есть сравнение и прерывание. Приоритет прерывания задается (как и для любого устройства в его структуре конфигурации - вы же не про Arduino говорите ).
Время реакции = приблизительно время оцифровки ADC и далее смотрите данные ARM Cortex на время входа в прерывание, с учетом периодов их запретов в вашей программе. В SDK и дровах WiFi они не большие - порядки = us.
Для многих задач всё равно это (программное) не подходит, а используют простой MCU со встроенными аппаратными компараторами или выводами с сигналами типа OE/CS, отключающие аппаратно внутренние устройства. Обычно это лежит в порядках к 10..80 нс...
К примеру простейшие ШИМ на PIC24 и типа имеют вход сброса - по нему он отключает выход драйвера ШИМ и заодно это отображается в его регистрах, а так-же есть варианты с выводом на I/O выхода компаратора с задаваемым уровнем срабатывания. Вот про эти времена срабатывания и описал - 10..80 нс. По этому для скоротечных процессов лучше ставить простой доп. MCU.

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

Такие задачи, если MCU не содержит блок программируемой логики, а должен управлять каким токовым ключом, то решал всегда установкой внешних триггеров с сигналом сброса. Выходит 2 I/O - один это управление включения ключом, второй - вход (и IRQ) на который подается сигнал отсечки по току с ключа...
Почему, "решал" - ныне драйвера и другие чипы с ключами сами сообщают что там у них - обрыв нагрузки, перегрев или превышение тока...

 

[pvvx]

Прикольно, но если не надо экономить питание то,
ESP решает эту задачу за 1 мс и без RTOS и без доп процессора.

У RTL это решается за 8 тактов (такт = 166МГц).
FIQ имеет более высокий приоритет, чем IRQ. У него есть 8-ти банковый регистр для уменьшения переключения контекста, что улучшает латентность прерывания.
У ESP за 0.8..2 сек, когда его драйвер WiFi пишет китай-цифири в консоль UART при запрещенных прерываниях.
Прикольно ваше незнание того, с чем сталкиваетесь, но пытаетесь сделать выводы...
Не все тут разбираются в RTOS, тем более вы их запугали своим непониманием его нашими долгими обсуждениями, что это не так и сложно, но дает свои преимущества. Вы же пришли к заключению, что RTOS – это ПОЛНАЯ операционная система и её вам не освоить из-сложности . Хотя это всего переключалка задач и не влияет на прерывания, а помогает разобраться с приоритетностью обработки событий. От туда у других и вопросы.
Так-же уже никто, кроме вас, не использует драйвера ключей в рассыпухе, как это было в том веке. Это дороже и ненадежно. В начале этого века выпущена масса драйверов хоть для светодиодов или клапанов и т.д. Управление у них преимущественно по SPI и они не требуют установки доп.элементов.
Пример - MCZ33996EK, для светодиодов есть другие (типа TB62706BN/BF), и с задаваемым программно током, и для диммеров/корректоров мощности так-же есть специализированные чипы...

 

[pvvx]

Возможно, у вас так,
Но у меня иначе.
Если будем спать, то реакция будет не более 350 мс.
А если спать не надо, то не более 1-2 мс.
При этом ничего "левого" лепить не надо.
Все делается исключительно на официальном SDK.
Не надо ни свалок, ни взломов и допиливания.
Скучно аж жуть.
---------------------------
Опять же - это для WIFI, а для уарт будет меньше полагаю.

Ну а тут, у RTL лучше, даже когда спим - пару us и ничего левого, кроме SDK не надо.
И главное такая ситуация сразу с анонсом чипа. Менее месяца с оф. объявы о продажах чипа (RTL871xBN), а у ESP - через годы, после работы тысяч энтузиастов и то - не всё и без исходников SDK Это сохраняется и в соотношении возможностей RTL871xBN и ESP8266. Сравнивать с RTL871xAx/8195 вообще нет смыслу - другая категория, превосходящая по всем параметрам ESP8266 в разы.
Та и с вами уже не интересно о чем-то говорить. У вас одна голословщина и реклама ESP - нет ни одного примера в подтверждение ваших слов

-----------
@aloika - почитайте внимательнее FreeRTOS: практическое применение, часть 3 (управление прерываниями) | arm | programming и сообразите, что прерывание, кроме того что в нем исполняется, может переключать исполнение на нужную задачу с учетом приоритетов, что задач, что прерываний. Если поставите максимальный уровень задаче обработки вашего события и его прерывания, то оно прервет практически всё и все остальные задачи будут ждать исполнения вашей задачи. Как это организуется и описано в ссылке...
Т.е. вы можете установить у вашей задачи уровень выше WiFi и всех других процессов в SDK, при опыте можно задать процессу уровень даже выше самой RTOS...
А пресловутые 1 мкс - это шаг переключения равноправных задач, а не реакции и выбора/переключения по приоритетам..

 

[=AK=]

Прикольно, но если не надо экономить питание то,
ESP решает эту задачу за 1 мс и без RTOS и без доп процессора.

ESP может жевать сопли до 700 мс, делая что-то "внутри себя" и не отдавая управление пользовательской программе. Я в этом убедился, когда отлаживал ESP под Ардуиной: менял состояние ESP пина раз в 1 мс и смотрел осциллом. Большую часть времени на пине наблюдается меандр 500 Гц, но иногда в нем промелькивают паузы в сотни миллисекунд. Таким образом, на ESP без RTOS расчитывать на реальное время с реакцией быстрее секунды не приходится.