Проблема с FSCM

[Марк]

Сообщение от besogon

Я думаю, что все, здесь присутствующие так или иначе работали с ОС.

Очередное Ваше заблуждение.
Если круг решаемых задач подразумевает постоянную необходимость в РТОС (например телематические мониторы и т.п.) то ЕСТЕСТВЕННО, что нанимают специального программиста, который пишет код, а схемотехникой занимаются специально обученные этому люди.
А если продукция В ОСНОВНОМ представляет из себя радиотехническое изделие и алгоритмы обработки сигналов - это практически весь код, то никакой ОСРВ для этого не требуется. Латентность переключения контекста может потребовать В РАЗЫ увеличить быстродействие ядра, а значит сменить платформу МК. И не факт, что аналоговый фронтэнд требуемый задачей будет устраивать в этой новой платформе. И всё становится с бюджетом изделия совсем плохо.
Такшта я повернулся спиной к столу стоящему в углу и посмотрел на своих соратников по борьбе, которые весьма успешно создают коммерческие продукты. И не нашел среди них специалиста по РТОС, такого как Вы. Себя я к таким специалистам не отношу. Я сразу сказал, что дилетант, но имеющий некоторый опыт.
ЗЫ. Так, к слову. Семейство dsPIC33C и одноядерное и двухядерное имеет в ядре (ядрах) ПЯТЬ аппаратно переключаемых контекстов. Полного набора регистров ядра, кроме регистра WREG15 в котором сидит TOS.
Очень неплохая, хоть и специальная платформа для создания на ней достаточно простой вытесняющей RTOS с ограниченным количеством задач. При этом задачи могут содержать и несколько функций. Просто эмуляция четырех ядер на каждом физическом.

[Greg]

Сообщение от Марк

Нет, Greg, бесогон как раз о том, что поллинг делается по событиям кнопок, даже если не надо просыпаться. А с пробуждением по IOC как бы никто и не спорил. Всегда можно обозначить для батарейного устройства таймаут опроса и уходить в сон при бездействии. Спор был скорее о методах защиты от дребезга, я бы сказал...

ну, я на себя примерял - если совсем мертво спать, то надо как-то для начала пробудиться, а там уже что-то опрашивать. Когда всё устаканилось - опять в сон.

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

[besogon]

Марк
Вы 2 страницы назад писали, что у Вас есть опыт работы с ОС, сейчас пишете что у я заблуждаюсь относительно опыта работы с ОС у присутствующих здесь. Как это объяснить кроме как тем, что Вы меня задираете я не могу. Я всё. Ума не приложу как я еще раз купился на Ваши трюки.

[Марк]

Сообщение от besogon

В ОС обычно ядро спит, если нет готовых к выполнению задач.

Все дело в том, что большинство задач с сетевым питанием не требуют выключать тактирование ядра, вешая задачи на прерывания. А есть ПОСТОЯННО РАБОТАЮЩИЕ задачи, которые к тому же, чаще всего, жестко синхронны и только обмены по внешним коммуникациям нарушают эту идиллию. Но обмены сидят на ДМА и спокойно врезаются в FSM без малейших намеков на блокировки.
Возьмите, например, какой нибудь частотник. Или мои противокражные системы (по сути радиолокаторы). Или измерительные датчики на технологическом оборудовании с единственным работающим интерфейсом, сколько бы их не было в наборе.
Как то так. Ваш мир - это только Ваш мир. У других он совсем другой.

[Марк]

Сообщение от besogon

Марк
Вы 2 страницы назад писали

Приведите цитату, где я об этом писал. Но прежде чем отправить сообщение, ПРОЧИТАЙТЕ ЦИТАТУ ВНИМАТЕЛЬНО и подумайте, есть высокая вероятность того, что Вы слышите не то, что Вам говорят, а то, что Вы желаете услышать... Приступайте.

[Марк]

Сообщение от Greg

ну, я на себя примерял - если совсем мертво спать, то надо как-то для начала пробудиться, а там уже что-то опрашивать. Когда всё устаканилось - опять в сон.

Скажем, в тех же Микрочипах, выход из сна может осуществляться двумя путями- продолжить через 2 машцикла исполнение от точки слипа, либо уйти на обработчик по событию разбудившему ядро. То есть задержка практически нулевая, особенно если тактирование без PLL. Для такого ленивого дела, как кнопка, вообще мгновенно. Если событий от кнопки нет, то по разумному (2...10 сек) таймауту валимся в сон. Но защита от дребезга именно поллингом по фиксированному интервалу. А не вычурным запуском таймера с запретом-разрешением прерываний. И уж точно не клацая затвором шедулера в прерывании по кнопке, когда систики следуют в 30 раз чаще, чем требует защита от дребезга ПРИ ЛЮБОМ РАСКЛАДЕ.

[Марк]

Сообщение от SergP01

а как вы интервал то то будете делать, шедулером

Вообще то шедулер - это систик. В его функции входит, в том числе, администрирование очередей. И если на поллинге кнопок стоит 30 клоков, то нужно только активировать эту задачу. И всё, Карл. Все остальное в самой задаче.

Сообщение от SergP01

у меня вообще складывается впечатление

Вот только твоих впечатлений нам не хватало...

[Марк]

Сообщение от SergP01

ешё раз считали... сравнили...

Сравнивать вообще ничего не надо. Обычный D триггер является идеальным фильтром дребезга. То есть при интервале опроса больше, чем дребезг, дребезга вообще не будет. Без какого либо сравнения. Тупо задвигаем считанное состояние кнопки в ее статическую переменную и маскируем два последних разряда. Обычный Switch-case дает два события и дефолт - без событий. Вот и весь код.

[Марк]

Сообщение от SergP01

да ладна...
у меня нету вашего любимого модуля в МК....

Причем тут модуль? D триггер не нужен. Это просто модель поллинга. Опрос кнопки идентичен записи в D триггер в момент чтения порта.
Как ты вообще работал инженером - ума не приложу. Такое ощущение, что я говорю с полным ламером.

[SergP01]

Сообщение от Марк

Скажем, в тех же Микрочипах, выход из сна может осуществляться двумя путями- продолжить через 2 машцикла исполнение от точки слипа, либо уйти на обработчик по событию разбудившему ядро. То есть задержка практически нулевая, особенно если тактирование без PLL. Для такого ленивого дела, как кнопка, вообще мгновенно. Если событий от кнопки нет, то по разумному (2...10 сек) таймауту валимся в сон. Но защита от дребезга именно поллингом по фиксированному интервалу. А не вычурным запуском таймера с запретом-разрешением прерываний. И уж точно не клацая затвором шедулера в прерывании по кнопке, когда систики следуют в 30 раз чаще, чем требует защита от дребезга ПРИ ЛЮБОМ РАСКЛАДЕ.

где тут про rtos ?



или это, когда вы писали, в голове подразумевалось ?

[Марк]

Сообщение от SergP01

где тут про rtos ?

Читай по слогам пять раз.

И уж точно не клацая затвором шедулера в прерывании по кнопке, когда систики следуют в 30 раз чаще, чем требует защита от дребезга ПРИ ЛЮБОМ РАСКЛАДЕ.

[ATAMAN]

Марк добрый день.
Не стоит перед свиньями бисер метать.

[ATAMAN]

Для dsPIC33FJ32GP регистр CNPU1 и CNPU2 определяет прерывание на вывод. То есть можно группу выводов задействовать ну допустим кнопки подключу на несколько выводов и эти не сколько выводов на каждую кнопку своё прерывание?

[pal1222@yandex.ru]

Сообщение от besogon

pal1222@yandex.ru
И тут на помощь приходят проц. на 400MIPS с >64K RAM под стеки и RTOS с адовым оверхедом на который мы вежливо не обращаем внимания? - для просто задачи 256B вполне хватит на стек, для сложной задачи обычно нужен не стек, а рабочий буфер какой-то. Если графика, то будет кадровый буфер большой. Если звук - то звуковые буферы какие-то. Часто лично Вам нужно было много стека? мне нет. Наверное самое большое было, когда celt декодировал на pic32mx.

с адовым оверхедом - по сравнению с чем? Если в fsm запихали те задачи, которые были расчитаны на ОС, то как бы у FSM не был больше оверхед на проверки, когда тупо нужно продолжить выполнения с какой-либо точки.

Осторожно, много букв
Мне как-то раз было лень резать по узлам чужую "библиотеку", поэтому смастерил обертку... На входе сохранял контекст вызова обертки, а периодически встречающиеся WaitInterruptTiming заменил на setjmp с последующим выходом сразу в loop а возвращался по условию (благо их всего два - таймаут и нибудь какое прерывание от периферии, какое - "библиотека" разбирает) "на шесть уровней вложения" longjmp-ом. Благо ждала она подолгу но не часто, стек, как не в себя, жрала только при декодировании ответа а полезный выхлоп этого ожидания был байт двести. Получилась имхо какая-то херня, не... как "демонстратор технологии" вполне себе, но я вообще хреновый программист, мне тупо не везёт всегда И если я не понимаю как работает модуль это обязательно вылезет в релизе. Ну а если понимаю - нахрена мне эта "библиотека".
Слава богу "не одни мы дураки" у Cisco например, тупо портированный линух по разному обрабатывает пакеты от четных и нечетных MAC, а групповую адресацию по дефолту не пропускает вовсе(а может и вообще на пропускает х.з.) но где я и где Cisco К ним претензий быть не может - иди на курсы и вообще RTFM, а у меня "ниииработает"

[besogon]

ATAMAN
То есть можно группу выводов задействовать ну допустим кнопки подключу на несколько выводов и эти не сколько выводов на каждую кнопку своё прерывание? - на все change notice один вектор. внутри вектора можете самостоятельно сделать разбиение на дальнейшие обработчики, однако тк. вектор один, то и приоритет у вот этого вот всего всё равно будет один.

Если по какой-то причине на каждую кнопку нужен вектор, то можете использовать external interrupt.

[besogon]

pal1222@yandex.ru
Мне как-то раз было лень резать по узлам чужую "библиотеку" - декомпозиция чего-либо вполне может показать, что по другому собрать сложно/невозможно в разумные сроки.



Получилась имхо какая-то херня, не... как "демонстратор технологии" вполне себе - PoC от релиза часто отделяет, как кажется, немного. Однако бывает и этого хватает, чтобы утонуть. не помню чтобы setjmp/longjmp хорошо кончались.



Алгоритм, сделанный для ОС переделать под fsm та еще задача и скорее всего это будет работать хуже, чем если бы была ОС. тк. в fsm будет тупо кусок функциональности, который выполняла до этого ОС, только в разы хуже сделанный.

[Марк]

Сообщение от ATAMAN

Для dsPIC33FJ32GP регистр CNPU1 и CNPU2 определяет прерывание на вывод.

Эти регистры определяют включение подтяжки. Включение прерываний CN - CNEN1 и CNEN2.
Но лучше откройте отдельную тему. Тут слишком шумно для частных вопросов.

[Марк]

Сообщение от besogon

Алгоритм, сделанный для ОС переделать под fsm та еще задача и скорее всего это будет работать хуже, чем если бы была ОС. тк. в fsm будет тупо кусок функциональности, который выполняла до этого ОС, только в разы хуже сделанный.

Сильно зависит от глубины погружения в задачу. Вы, бесогон, отчего то изначально полагаете, что "изобретать велосипед" - дело не только бесперспективное, но и непрофессиональное.
Но я как то постеснялся задать Вам вопрос про РТОС, которую Вы портируете на свои устройства.
Какую РТОС Вы портируете?

[besogon]

Марк
Я написал ОС, ее и использую.
Если Вас интересуют какие-то фрагменты, АBI или что-либо еще, то могу поделиться фрагметом реализации той или иной фукнциональности.

Естественно, что я поверхностно знаком с freertos, tnkernel и linux.

В силу того, что ОС сугубо коммерческая - весь код открывать не буду.

что "изобретать велосипед" - дело не только бесперспективное, но и непрофессиональное - за это не платят. по опыту многих - увольняют. приходит время сдавать проект, а сдавать нечего. Зато есть велосипед.

[Марк]

Сообщение от besogon

Марк
Я написал ОС, ее и использую.

Тогда странно слышать от Вас по поводу как делают в ОС, а как нет.
На основании чего Вы назвали глупостью вызов шедулера из прерывания систикТаймера?
И чем отличается У ВАС вызов шедулера из любого прерывания от простой обработки задач в прерываниях с простым управлением приоритетами? То есть от условного "варианта СергП01"...

[besogon]

Марк
На основании чего Вы назвали глупостью вызов шедулера из прерывания систикТаймера? - вызовы делают не каждую 1ms, а тогда, когда нужно.
составляется очередь допустим спящих из тех, кто ожидает и вызывается только тогда, когда нужно.
Вызывать что-либо просто чтобы совершить вызов - так не делают.

И чем отличается У ВАС вызов шедулера из любого прерывания от простой обработки задач в прерываниях с простым управлением приоритетами? -
1. контекстом - каждый поток выполняется в своем контексте и имеет свой стек.

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

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

4. в прерывании нельзя уступить исполнение. в задаче можно - нужно сделать, чтобы задача сперва захватила мутекс, потом подождала какое-то время, или подождала прерывания какое-то время, или что-то еще - пожалуйста.

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

[besogon]

Марк
Скорее интересно, как Вы до такого дошли - вызывать кнопки, когда ничего не происходит, вызывать прерывание таймера, когда от него скорее всего ничего не нужно, не отправлять с сон ядро, когда нет задач.

Вот есть описание архитектуры системы - в ней прямо так написано что-ли? - будет каждую 1ms вызывать диспетчер на всякий случай.

[Марк]

Сообщение от besogon

вызовы делают не каждую 1ms, а тогда, когда нужно.

Тут ошибка множественного числа. Не "вызовы делают", а "я вызовы делаю". Ибо даже первый попавшийся мне пример RTOS (FreeRTOS) вызывает шедулер по систику (каждую 1 мс или иное заранее определенное время). Естественно, что спящие задачи он не вызывает. Методы арбитража очереди задач в шедулере я не рассматриваю. Это отдельный вопрос.

Сообщение от besogon

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

Далее я буду опускать множественное число в Ваших объяснениях.
Но! Есть реальный прибор в котором есть 10 задач. Каждая из них активируется своим событием или комбинацией общих. В общем самая громоздкая из задач выполняется, допустим, 1 секунду. Другая 200 мс. Ну и по спадающей. Если мы будет постоянно прерывать тяжелую задачу, то она может не успеть к своему времени. А одновременно активными, например, могут быть 7...9 задач из 10. Кто будет переключать задачи, обеспечивая их псевдопараллельное исполнение?

[petrd]

Сообщение от besogon

Марк
Скорее интересно, как Вы до такого дошли - вызывать кнопки, когда ничего не происходит, вызывать прерывание таймера, когда от него скорее всего ничего не нужно, не отправлять с сон ядро, когда нет задач.

Вот есть описание архитектуры системы - в ней прямо так написано что-ли? - будет каждую 1ms вызывать диспетчер на всякий случай.

А почему собственно нужно НЕ опрашивать кнопки по таймеру, так делают многие, но для Вас это почему-то стало откровением. И почему обязательно нужно отправлять ядро в сон, так делают когда надо батарейки экономить, но не всегда работают на батарейках и тогда на сон вообще плевать. У меня сложилось впечатление, что для Вас существует всего два мнения: одно Ваше и второе - неправильное.

[HHIMERA]

Сообщение от petrd

И почему обязательно нужно отправлять ядро в сон, так делают когда надо батарейки экономить

Не обязательно... так ещё повышают реакцию на событие...