SciFi (30.07.2013 17:14, просмотров: 381) ответил fk0 на Приемлемый ответ в виде "вложенного автомата" есть у Шалыто. А у прототредов есть проблема -- как ожидать более одного события одновременно.ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้
-
- && должно вычисляться каждый раз. Проблема 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)
- Кстати, да, нахлобучить планировщик поверх protothreads должно быть совсем не сложно. - SciFi(31.07.2013 10:11)
- А чО такое event? Не подскажешь неразумным? - Гудвин(30.07.2013 23:08)
- Это когда кто-то говорит планировщику, что он наступил. И планировщик начинает запускать процессы ожидающие оного event. - fk0(31.07.2013 00:48)
- Бу-га-га... Я как раз об этом: этот "кто-то" должен, как минимум, поместить событие в очередь, планировщик должен выполнить извлечь из очереди, провести "тупую проверку" кучи событий, запустить процессы. Накладные расходы на переключение Гудвин(119 знак., 31.07.2013 13:58, ссылка)
- Вот эти накладные расходы, они меньше, чем тупая проверка условий в цикле. Потому, что они возникают только при возникновении события, а не существуют постоянно в каждом цикле. - fk0(31.07.2013 14:02)
- Вот я и просил, чтобы ты подробнее разъебеснил, что есть "событие" применительно к железке с малыми ресурсами в твоей интерпретации. - Гудвин(31.07.2013 14:22)
- Мы (!под свой круг задач!) реализовали так - в main крутится диспетчер (да, это big loop без всякого вытеснения, ибо не требуется), просматривающий приоритетные очереди. Источники событий - обработчики прерываний, в т.ч. и от таймера(ов). Источник Chum_A(348 знак., 31.07.2013 18:34)
- Цитата: "Теоретически диспетчер мог бы при пустых очередях скомандовать в sleep, но не пробовали за неактуальностью". Спасибо, отличная шутка про батареечные решения :о) - Скрипач(31.07.2013 18:38)
- Именно так, похожим образом, и делается... - fk0(31.07.2013 20:00)
- Ни секунды не сомневаюсь :-| Скрипач(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)
- Ни секунды не сомневаюсь :-| Скрипач(219 знак., 31.07.2013 20:50 - 20:54)
- Именно так, похожим образом, и делается... - fk0(31.07.2013 20:00)
- Цитата: "Теоретически диспетчер мог бы при пустых очередях скомандовать в sleep, но не пробовали за неактуальностью". Спасибо, отличная шутка про батареечные решения :о) - Скрипач(31.07.2013 18:38)
- Какая разница, какая железка? - fk0(31.07.2013 14:24)
- Ну-ну... - Гудвин(31.07.2013 14:36)
- Нуну. Не надо рассказывать, мол контроллеры программируются вот так-то, а я дурак, пришёл из мира ПК, ассемблера не знаю. Я по крайней мере видел с двух сторон как оно и могу судить. - fk0(31.07.2013 14:46)
- Ну-ну. Разведем пальцы веером, хвост павлином... Нах аргументировать. Если че, я так вообще ни сколько не программист. Хотелось конкретного примера - так сказать, для постижения... - Гудвин(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)
- 1) таки это одно и то же. loop там есть тот самый. - fk0(31.07.2013 15:53)
- 1) не нужно, мля, отождествлять биглуп и прототридсы, и тогда не будет левых рассказок об неэффективности. 2) коронный зал у нас справа - Vit(31.07.2013 15:36)
- Примера чего? Научись чётко формулировать мысли. Мои тезисы выше по треду следующие: 1) Big loop (protothreads) не эффективен, особенно для больших программ, ввиду большой вычислительной сложности бесконечного вычисления всех условий, RTOS и/или fk0(466 знак., 31.07.2013 15:02)
- Ну-ну. Разведем пальцы веером, хвост павлином... Нах аргументировать. Если че, я так вообще ни сколько не программист. Хотелось конкретного примера - так сказать, для постижения... - Гудвин(31.07.2013 14:54)
- Нуну. Не надо рассказывать, мол контроллеры программируются вот так-то, а я дурак, пришёл из мира ПК, ассемблера не знаю. Я по крайней мере видел с двух сторон как оно и могу судить. - fk0(31.07.2013 14:46)
- Ну-ну... - Гудвин(31.07.2013 14:36)
- Мы (!под свой круг задач!) реализовали так - в main крутится диспетчер (да, это big loop без всякого вытеснения, ибо не требуется), просматривающий приоритетные очереди. Источники событий - обработчики прерываний, в т.ч. и от таймера(ов). Источник Chum_A(348 знак., 31.07.2013 18:34)
- Вот я и просил, чтобы ты подробнее разъебеснил, что есть "событие" применительно к железке с малыми ресурсами в твоей интерпретации. - Гудвин(31.07.2013 14:22)
- Вот эти накладные расходы, они меньше, чем тупая проверка условий в цикле. Потому, что они возникают только при возникновении события, а не существуют постоянно в каждом цикле. - fk0(31.07.2013 14:02)
- Бу-га-га... Я как раз об этом: этот "кто-то" должен, как минимум, поместить событие в очередь, планировщик должен выполнить извлечь из очереди, провести "тупую проверку" кучи событий, запустить процессы. Накладные расходы на переключение Гудвин(119 знак., 31.07.2013 13:58, ссылка)
- Это когда кто-то говорит планировщику, что он наступил. И планировщик начинает запускать процессы ожидающие оного event. - fk0(31.07.2013 00:48)
- Вас гринпис подкупил? Зелёные процы, батарейное питание и фсё такое? Ви таки удивитесь, но очень многие запитываются от розетки. И банальный кондиционер сожрёт столько же, сколько 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 ;) - Гудвин(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, ссылка)
- Ну я же обхожусь. Использую те и другие. Приведите пример использования. - General(31.07.2013 23:21)
- Уже обсуждали. МК от EnegryMicro по совокупности характеристик и периферии не заменяет полностью MSP430 . - rezident(31.07.2013 23:09)
- Там застой. Они считают что это станет возможным с другими технологиями памяти, например FRAM. А вообще, есть же EFM. - General(31.07.2013 22:54)
- General как то вызывался поинтересоваться у самих авторов. Ждем'c ;) - Гудвин(31.07.2013 22:42)
- Меня всегда волновало - из каких высших маркетинговых соображений они ставят так мало ОЗУ? Или это результат технологических ограничений - в 6 транзюках ОЗУ утечки больше, чем в других компонентах? - Evgeny_CD(31.07.2013 22:38)
- Скорее всего, стеки всяких зигби, либы/шрифты для графических дисплеев (ЖКИ) много весят - amusin(31.07.2013 12:26)
- Пользователям MSP430 обычно не хватает ОЗУ, а не памяти вообще. Flash-памяти как раз хватает всегда. - rezident(31.07.2013 16:36)
- Для MSP430 нет возможности писать ПО более 64к. С бесплатным компилятором. Да и ценник на сами чипы не гуманный. А самое главное -- мальчиков с мамой, папой, квартиркой и знанием MSP430 -- нет. - fk0(31.07.2013 12:15)
- половина проблем пропадает если поставить эмэспе вместо некрочипа - Nikolay801_(31.07.2013 11:59)
- Элементарно. PLL + генератор на кварце, плюс периферия -- уже сходу более 4мА (3.3v). Потом dc/dc с малым собственным потреблением и большим выходным током (до единиц ампер) -- вообще фантастика, с приемлемым КПД при таких токах -- тоже. И таки fk0(372 знак., 31.07.2013 11:11)
- что бы не въехать в 340 uA в дежурном режиме на любом мейнстримовом контроллере, это нужно очень "постараться". Должны быть какие то дополнительные, не озвученные ограничения. - Nikolay801_(31.07.2013 09:45)
- 5% в мес от ~50А*Ч -- 3.4мА (саморазряд). 0.34mA -- сделай. Только проц при 100% cpu load съест минимум 20мА, и dc/dc с кпд сильно ниже 50% (только Iq до 5mA), и ещё прочие накладные расходы. Я тебе практический пример приведу. pic18 -- ~1mA при fk0(681 знак., 31.07.2013 00:47)
- Если ток потребления - 10% от саморазряда батареи, то пофиг. Подозреваю, что уложиться можно без особого труда. - SciFi(30.07.2013 23:02)
- В автомобильной тематике актуально, сколько проживёт машина на стоянке с твоим прибором, 2 недели до полного разряда или успешно заведётся через месяц, например. - fk0(30.07.2013 22:57)
- прототридсы просто совсем не планировщик - Vit(31.07.2013 10:03)
- && должно вычисляться каждый раз. Проблема protothreads -- отсутствие "планировщика" понимающего, что если произошёл event_a, то нужно запустить поток такой-то. См. ответ Скрипачу. Я не прав таки. В protothreads множествнное ожидание не проблема. fk0(222 знак., 30.07.2013 22:44)