caxapa.ru :: PT_WAIT_UNTIL(&pt, event_a() && event

SciFi (30.07.2013 17:14, просмотров: 388) ответил fk0 на Приемлемый ответ в виде "вложенного автомата" есть у Шалыто. А у прототредов есть проблема -- как ожидать более одного события одновременно.

PT_WAIT_UNTIL(&pt, event_a() && event_b());

ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้

Ответить

- && должно вычисляться каждый раз. Проблема protothreads -- отсутствие "планировщика" понимающего, что если произошёл event_a, то нужно запустить поток такой-то. См. ответ Скрипачу. Я не прав таки. В protothreads множествнное ожидание не проблема. fk0^{легенда}(222 знак., 30.07.2013 22:44)
  - прототридсы просто совсем не планировщик - Vit(31.07.2013 10:03)
    - Кстати, да, нахлобучить планировщик поверх protothreads должно быть совсем не сложно. - SciFi(31.07.2013 10:11)
      - так и делаю. а переменную состояния объявляю внутри функции - Vit(31.07.2013 11:10)
  - А чО такое event? Не подскажешь неразумным? - Гyдвин^{волшебник}(30.07.2013 23:08)
    - Это когда кто-то говорит планировщику, что он наступил. И планировщик начинает запускать процессы ожидающие оного event. - fk0^{легенда}(31.07.2013 00:48)
      - Бу-га-га... Я как раз об этом: этот "кто-то" должен, как минимум, поместить событие в очередь, планировщик должен выполнить извлечь из очереди, провести "тупую проверку" кучи событий, запустить процессы. Накладные расходы на переключение Гyдвин^{волшебник}(119 знак., 31.07.2013 13:58, ссылка)
        
        Вот эти накладные расходы, они меньше, чем тупая проверка условий в цикле. Потому, что они возникают только при возникновении события, а не существуют постоянно в каждом цикле. - fk0^{легенда}(31.07.2013 14:02)
        
        Вот я и просил, чтобы ты подробнее разъебеснил, что есть "событие" применительно к железке с малыми ресурсами в твоей интерпретации. - Гyдвин^{волшебник}(31.07.2013 14:22)
        
        Мы (!под свой круг задач!) реализовали так - в main крутится диспетчер (да, это big loop без всякого вытеснения, ибо не требуется), просматривающий приоритетные очереди. Источники событий - обработчики прерываний, в т.ч. и от таймера(ов). Источник Chum_A(348 знак., 31.07.2013 18:34)
        
        Цитата: "Теоретически диспетчер мог бы при пустых очередях скомандовать в sleep, но не пробовали за неактуальностью". Спасибо, отличная шутка про батареечные решения :о) - Cкpипaч^пророк(31.07.2013 18:38)
        
        Именно так, похожим образом, и делается... - fk0^{легенда}(31.07.2013 20:00)
        
        Ни секунды не сомневаюсь :-| Cкpипaч^пророк(219 знак., 31.07.2013 20:50 - 20:54)
        
        Я же сказал, частный случай. Вот я включаю контактор (380В/100А), обмотка от 30В кушает ~300 мА, а таких (или чуть пожиже) десятка два и ещё всякого добра (например, ШИМ 30В/30А), ну и нафига мне экономить электроэнергию. - Chum_A(01.08.2013 10:56)
        
        Я сам использую big loop со sleep'ом... - fk0^{легенда}(31.07.2013 21:24)
        
        Какая разница, какая железка? - fk0^{легенда}(31.07.2013 14:24)
        
        Ну-ну... - Гyдвин^{волшебник}(31.07.2013 14:36)
        
        Нуну. Не надо рассказывать, мол контроллеры программируются вот так-то, а я дурак, пришёл из мира ПК, ассемблера не знаю. Я по крайней мере видел с двух сторон как оно и могу судить. - fk0^{легенда}(31.07.2013 14:46)
        
        Ну-ну. Разведем пальцы веером, хвост павлином... Нах аргументировать. Если че, я так вообще ни сколько не программист. Хотелось конкретного примера - так сказать, для постижения... - Гyдвин^{волшебник}(31.07.2013 14:54)
        
        Примера чего? Научись чётко формулировать мысли. Мои тезисы выше по треду следующие: 1) Big loop (protothreads) не эффективен, особенно для больших программ, ввиду большой вычислительной сложности бесконечного вычисления всех условий, RTOS и/или fk0^{легенда}(466 знак., 31.07.2013 15:02)
        
        1) не нужно, мля, отождествлять биглуп и прототридсы, и тогда не будет левых рассказок об неэффективности. 2) коронный зал у нас справа - Vit(31.07.2013 15:36)
        
        1) таки это одно и то же. loop там есть тот самый. - fk0^{легенда}(31.07.2013 15:53)
        
        Значит у кого-то таки одно и то же, только это обобщение ошибочно. Учитематчастьнах - Vit(31.07.2013 22:27)
        
        Отрываем исходник с protothreads и видим while (1) { thread1(); thread2(); thread3();... } -- так же? И чем это отличается от big loop? Научись, ёпты, аргументировать свои ответы, нах. - fk0^{легенда}(31.07.2013 23:53)
        
        да, можно прототридсы и в биглупе запустить. но никто не требует выключить моск и только в биглупе их юзать. пешиесчёнах - Vit(01.08.2013 00:09)
  - Вас гринпис подкупил? Зелёные процы, батарейное питание и фсё такое? Ви таки удивитесь, но очень многие запитываются от розетки. И банальный кондиционер сожрёт столько же, сколько 1000 ваших зелёных девайсов :-) - SciFi(30.07.2013 22:49)
    - В автомобильной тематике актуально, сколько проживёт машина на стоянке с твоим прибором, 2 недели до полного разряда или успешно заведётся через месяц, например. - fk0^{легенда}(30.07.2013 22:57)
      - Если ток потребления - 10% от саморазряда батареи, то пофиг. Подозреваю, что уложиться можно без особого труда. - SciFi(30.07.2013 23:02)
        
        5% в мес от ~50А*Ч -- 3.4мА (саморазряд). 0.34mA -- сделай. Только проц при 100% cpu load съест минимум 20мА, и dc/dc с кпд сильно ниже 50% (только Iq до 5mA), и ещё прочие накладные расходы. Я тебе практический пример приведу. pic18 -- ~1mA при fk0^{легенда}(681 знак., 31.07.2013 00:47)
        
        что бы не въехать в 340 uA в дежурном режиме на любом мейнстримовом контроллере, это нужно очень "постараться". Должны быть какие то дополнительные, не озвученные ограничения. - Nikolay801_(31.07.2013 09:45)
        
        Элементарно. PLL + генератор на кварце, плюс периферия -- уже сходу более 4мА (3.3v). Потом dc/dc с малым собственным потреблением и большим выходным током (до единиц ампер) -- вообще фантастика, с приемлемым КПД при таких токах -- тоже. И таки fk0^{легенда}(372 знак., 31.07.2013 11:11)
        
        половина проблем пропадает если поставить эмэспе вместо некрочипа - Nikolay801_(31.07.2013 11:59)
        
        Для MSP430 нет возможности писать ПО более 64к. С бесплатным компилятором. Да и ценник на сами чипы не гуманный. А самое главное -- мальчиков с мамой, папой, квартиркой и знанием MSP430 -- нет. - fk0^{легенда}(31.07.2013 12:15)
        
        есть у мсп и возможность влить более 64к и чипы дешовые, тока не одновременно, да и мальчики с мамой-папой-квартирой под них найдуться. - Nikolay801_(31.07.2013 13:45)
        
        у MSP430 узкая ниша сверхэкономичных приложений. а там рееедко требуется более 64к. - Mahagam(31.07.2013 12:21)
        
        Сверхэкономичные -- не требующие высоких затрат на программирование что-ли? А за что я зарплату получать буду? Точно, остаётся только большое программирование. - fk0^{легенда}(31.07.2013 12:28)
        
        только пользователи MSP не убеждены как-то. постоянно на нехватку памяти жалуются и в жизни и на форумах, глупые - Snaky(31.07.2013 12:22)
        
        Пользователям MSP430 обычно не хватает ОЗУ, а не памяти вообще. Flash-памяти как раз хватает всегда. - reZident(31.07.2013 16:36)
        
        Меня всегда волновало - из каких высших маркетинговых соображений они ставят так мало ОЗУ? Или это результат технологических ограничений - в 6 транзюках ОЗУ утечки больше, чем в других компонентах? - Evgeny_CD^{Архитектор}(31.07.2013 22:38)
        
        General как то вызывался поинтересоваться у самих авторов. Ждем'c ;) - Гyдвин^{волшебник}(31.07.2013 22:42)
        
        Там застой. Они считают что это станет возможным с другими технологиями памяти, например FRAM. А вообще, есть же EFM. - General^изверг(31.07.2013 22:54)
        
        Уже обсуждали. МК от EnegryMicro по совокупности характеристик и периферии не заменяет полностью MSP430 . - reZident(31.07.2013 23:09)
        
        Ну я же обхожусь. Использую те и другие. Приведите пример использования. - General^изверг(31.07.2013 23:21)
        
        Вроде этот топик => - reZident(31.07.2013 23:25, ссылка)
        
        Скорее всего, стеки всяких зигби, либы/шрифты для графических дисплеев (ЖКИ) много весят - amusin(31.07.2013 12:26)

Средства и методы разработки