[Evgeny_CD 0]

Я как понял эти Петри - просто способ рисовать модели стрелочками, кружочками и квадратиками.

Потом изголяться и искать там какие-то закономерности. Это бред.

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

 

Сила матлаба не отменяет знание того, что лежит в его основе. Я бы не стал ставить один единственный инструмет во главу угла.

 

Как Вы верно заметили, самый сильный вариант - это комбинация обычной многопоточной ОСи и автоматного подхода.

[AlexandrY 3]

Ну и фиг с ними, с этими сетями.

Может они и не бред, но к делу их не пришьешь.

Ладно, я их уважаю.

 

Моделирование решает задачу когда о среде исполнения известно все и прогнозируете ее поведение при разных воздействиях.

 

А в жизни то решается обратная проблема, вы о своей среде исполнения пратически ничего не знаете и пытаетесь узнать ее проблемы пытая ее разными внешними воздействиями.

 

А вообще обычно толком не известна ни своя среда ни поведение внешнего мира.

 

В свете появления фреймворков как PhoneMy, Android, .Net embedded и т.д. среда исполнения становится полным черным ящиком.

Там, кстати, с фрагментацией памяти все схвачено.

Т.е. сведения о критичности фрагментации несколько подустарели.

 

 

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

 

Сила матлаба не отменяет знание того, что лежит в его основе. Я бы не стал ставить один единственный инструмет во главу угла.

 

Как Вы верно заметили, самый сильный вариант - это комбинация обычной многопоточной ОСи и автоматного подхода.

[Evgeny_CD 0]

В свете появления фреймворков как PhoneMy, Android, .Net embedded и т.д. среда исполнения становится полным черным ящиком.

Там, кстати, с фрагментацией памяти все схвачено.

Т.е. сведения о критичности фрагментации несколько подустарели.

То, на чем "крутится" PhoneMy, Android, .Net embedded пока, и еще долго будет так, не является SoC в истинном значении этого слова.

 

Да, вариант проц + внешний флешак + SDRAM 16 мбайт сейча стоит совсем не дорого. Но есть задачи, где SoC должна быть именнно SoC, а не SoB (System on Board).

 

Кроме того, вот смотрю я на всякие современные PIC32, AVR32 и тихо радуюсь за их создателей. Unix style эти чипы не потянут в чистом виде, без внешней памяти (на 64к ОЗУ сильно в "многопоточность" не наиграешься), "примитивное программирование" не позволит использовать эти чипы на всю катушку (вроятность ошибки при ручном описании сложных автоматов будет экспоненциально возрастать), а вот чего-то среднего в виде сформировавшейся идеологии я пока не вижу.

 

Собственно, за это и воюю. :)

 

А если посмотреть на сегмент Hi-End Low Power, где ATxmega, несомненно, будет королем, то опять-же разбазаривание набортных 8 или 16К под многопоточность является нерациональным. В этом плане искусство создателей Contiki вызывает уважение, а девайс (условно), который может прожить год на батарейке, и при этом может выполнять функции полноценного сетевого узла (с естественными ограничениями из-за батарейности) - очень даже коммерчески востребованная вещь!

 

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

[zltigo 1]

А если посмотреть на сегмент Hi-End Low Power, где ATxmega, несомненно, будет королем...

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

P.S.

В Риге 17 числа семинар Атмеловский, на котором XMEGA гвоздь программы....

09.00 - 10.00 ATtiny + ATmega (incl.Picopower) family

presentation

*

10 00 - 10.30 XMEGA Presentation

*

10.30 - 10.45 Coffee Break

*

10.45 - 12.00 XMEGA Continued

*

12.00 - 13.00 Coffee break

*

13.00 - 14.00 AVR32 UC3 Presentation

*

14.00 - 15.00 AT91 MPU Family Presentation

[vshemm 0]

Потому, что они обслуживают вполне себе одинаковые/равноправные каналы.

Почему бы тогда не реализовать обслуживание в одной нити? Как минимум, сэкономим немного ресурсов.

Также можно реализовать FIFO на одном приоритете (кооператив другими словами) без квантов. И для этого совсем не нужно вырубать таймер.

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

Причины отказа от использования time-slice Вы сами и же назвали (зачем усложнять систему без надобности).

 

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

Что начинается? Решать недостаток денег подобными способами (архитектурой системы) просто глупо. Когда аналитически получается загрузка 1.5 ничего не поделаешь :) Но система должна работать, хоть и с худшими параметрами ;)

Приходилось проектировать системы как с абсолютно достаточными ресурсами, так и штатно работающими в перегрузке. Но это редко приходилось (2 раза), обычно нечто среднее.

 

Разговаривал я тут по душам с разработчкиком одного телемаического сервака. Который принимает данные от 1к+ GSM девайсиков. Первое действие его сервера при запуске - отожрать у ОСи кучу памяти (задается) и запустить поток собственного менеджера памяти

Именно. Только у многих эмбеддед осей это можно сделать на этапе компиляции. Т.е. задать карту памяти :) А если нельзя - отжираем, лочим и т.д.

 

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

Так ничего стартовать не должно вообще. А вот макс загрузку тут заранее нельзя знать, только оценить.

 

Формальные способы верификации есть, только на практике удобнее делать ее [верификацию] мозгом и другими вероятностными методами :)

 

Я как понял эти Петри - просто способ рисовать модели стрелочками, кружочками и квадратиками.

Потом изголяться и искать там какие-то закономерности. Это бред.

Квадратиками! :) Впрочем, если Вы действительно так поняли, то это бред, да. Кстати, CD/DVD диски Вы используете? Знаете что там применяются коды Рида-Соломона для исправления ошибок? И рассчитываются они в полях Галуа. Только не гуглиле на предмет этих полей, ибо они абстрактнее чем 100 сетей Петри ;)

 

В ваших же книжках написано, что эти сети в основном только для анализа применяются.

Т.е., допустим, уже когда ось готова и хреново работает.

Анализ должен проводиться до того, как ось началА писАться, имхо.

 

В MATLAB SIMULINK более 1000 функциональных блоков на все случаи жизни. И c дискретным времененм, и с непрерывным, и со смешанным и без времени и вообще че хош.

Это инструмент, который, как не странно, базируется на матаппарате. Т.е. на бреде (?)

 

А про ресурсы же мы вроде договорились.

Для продвинутой RTOS надо 8 Meг RAM-а и 1/4 от этого для FLASH-а.

Для Линукса на порядок больше.

Не договорились. Правильнее, имхо, так: Для Линукса в эмбеддед обычно надо 8 Meг RAM-а и 4 Meг FLASH-а. Для продвинутой RTOS бывает достаточно на порядок меньше.

Хотя тут есть нюанс; вопрос на засыпку - Windows XP Professional SP2 являтся RTOS?

[Evgeny_CD 0]

Хотя тут есть нюанс; вопрос на засыпку - Windows XP Professional SP2 являтся RTOS?

Посольку "атом шагает по планете", то скоро ее "отембеддят" Microsoft Windows Embedded Quebec http://soft.compulenta.ru/359394/

:07:

[vshemm 0]

Атом тут не причем.

Просто лицензия на ХП запрещает ее встраивать, поэтому появилась ХП эмбеддед (а до этого NT и 2000 эмбеддед - посмотрите в свои осциллографы :)). Выглядит это как большая база данных компонентов обычной ХП из которой можно делать свой дистрибутив/образ без лишнего.

Так что Quebec - это виста эмбеддед, что и следовало ожидать :)

[zltigo 1]

Почему бы тогда не реализовать обслуживание в одной нити? Как минимум, сэкономим немного ресурсов.

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

Наконец, можно назначить разные приоритеты даже одинаковым каналам.

Многе, что можно и многое "и так сойдет". Вопрос в том, зачем делать "криво", если можно сделать "прямо".

Что начинается? Решать недостаток денег подобными способами (архитектурой системы) просто глупо.

Отлично, давайте не будем смотреть на деньги и, например, свяжем каждого жителя земли с другим жителем земли 10G Ethernet каналом. Хорошая "идея"? А практически все комуникационные задачи, начиная с банальной телефонии коей более 100 лет и по сей день именно живут и преодолевают такие "недостатки", как ограниченность пропускной способности каналов.

Когда аналитически получается загрузка 1.5 ничего не поделаешь :) Но система должна работать, хоть и с худшими параметрами ;)

Ну а теперь эта полуторократная перегрузка встречается 15 минут в год.

Ну и теперь расскажите, как с этой проблемой будете на голых каруселях разбираться, или ресурсы раздувать в полтора раз будете. А почему собственно в полтора, а если в аналитике ошиблись и это не 1.5 а 1.99? А 1.5 это, если система исправна, а если нет и ситуация на соседней системе нештатная? Системы с очередями и отказами в обслуживании есть совершенно обыденная вещь в современном мире c ограниченными ресурсами.

[vshemm 0]

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

Нагрузка сверху ограничена, если наблюдается дисбаланс - тогда сам бог велел не назначать одинаковые приоритеты. Но, если в дедлайн укладываемся - нагрузка вообще непричем. Тоже самое с резервом. А неисправность - из другой оперы, мы же рассматриваем логические сущности :)

Многе, что можно и многое "и так сойдет". Вопрос в том, зачем делать "криво", если можно сделать "прямо".

Именно. Только либо мы говорим о том и том же, либо понятия "криво" и "прямо" у нас диаметрально противоположны :)

Отлично, давайте не будем смотреть на деньги и, например, свяжем каждого жителя земли с другим жителем земли 10G Ethernet каналом. Хорошая "идея"? А практически все комуникационные задачи, начиная с банальной телефонии коей более 100 лет и по сей день именно живут и преодолевают такие "недостатки", как ограниченность пропускной способности каналов.

Не передергивайте, я о совершенно другом говорил...

Ну а теперь эта полуторократная перегрузка встречается 15 минут в год.

Ну и теперь расскажите, как с этой проблемой будете на голых каруселях разбираться, или ресурсы раздувать в полтора раз будете. А почему собственно в полтора, а если в аналитике ошиблись и это не 1.5 а 1.99? А 1.5 это, если система исправна, а если нет и ситуация на соседней системе нештатная? Системы с очередями и отказами в обслуживании есть совершенно обыденная вещь в современном мире c ограниченными ресурсами.

Поведение системы меняется скачком при переходе с 0.(9) до 1.(0). Далее оно не должно принципиально меняться. В теории. На практике это можно проверить, хотя и не всегда. Кстати, я не сторонник каруселей :)

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

 

Оффтоп: неплохо было бы завести IRC канал, много не кушает, а форум иногда в чат превращается...

[Evgeny_CD 0]

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

:bb-offtopic: конечно, более подробно это описано в соотвествующей ветке.

Мега уже король!

http://electronix.ru/forum/index.php?s=&am...st&p=425627

 

 

Народ, а для бесстековых нитей типа Protothreads http://www.sics.se/~adam/pt/ никто никогда не пробовал делать визуализатор для анализа структуры кода?

[zltigo 1]

Мега уже король!

:). Быстро-же Вы меняете прадигмы программирования в угоду самоcотворенным кумирам :(.

[Evgeny_CD 0]

:). Быстро-же Вы меняете прадигмы программирования в угоду самоcотворенным кумирам :(.

Не понял, о чем Вы?

 

Все происходит постепенно. Когда-то давно я освоил АSM. Помнится, даже на листочке бумаги ассеблер в коды переводил. И ничего, работало! :)

 

Потом я начал осваивать С. И достаточно долго не мог понять всего, что стоит за ОСями и многопоточным программрованием. Т.е. я что-то чувствовал, но толком не понимал.

 

В какой-то момент в голове что-то замкнуло, и я осознал классическую парадигму многопоточного программирования.

 

Параллельно с этим я осознал много всего по синтетическим портам и вирутальной разработке.

 

Сейчас я совершенно четко представляю, как вести разработку в родной мне коммуникационной области, полностью отвязанную от специфики конкретного железа. Причем если когда-то это было на уровне функций-ориентированного HAL (все обращение к железу только через вызовы функций драйвера), то теперь я понимаю, как такую же виртуальную разработку делать уже с асмовой эффективностью!

http://electronix.ru/forum/index.php?showtopic=48931

 

Понятно, что за громкими словами об осознании истины стоят, в общем-то, простые вещи - но все embeded программирование состоит из очень простых вещей. Просто их ОЧЕНЬ много :)

 

Теперь, вооружившись этими знаниями, я решил посмотреть назад, и понять, а как изящество многопоточного программирования втиснуть в ограниченные ресурсы.

 

Про protothreads, switch технологию и пр. я слашал давно. И даже что-то пытался понять. Но не вышло. Не понимал я, зачем оно нужно, когда есть uCOS :) Зачем нам что-то там экономить, когда у нас целых 64К ОЗУ на кристалле :)

 

Теперь вдруг я понял, что в этом что-то есть. И дело не только в пямяти. Но и в быстродействии.

 

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

 

В решении сложной задачи есть две крайности:

* поставить цель все сделать на асме и здохнуть в таком проекте

* портировать какую-нибудь вирутальную машину на контроллер (Lua|Java|Pyhon|...), и целевой код написать на очень высоком уровне.

 

Но я чувствую, что можно пройти по лезвию ножа. Сделать некую надстойку над С, которая позволяет:

* быстро визуализировать "смысл кода"

* композитный код

 

Визулизировать смысл - это в графической форме представить все сущности кода

* функции

* блоки кода {}

* машины состояний

* потоки

 

и взаимосвязь между ними.

 

После долгих размышлений и изучения моря всяких проектов, я понял, что это не сложно, и потихоньку двигаюсь к написанию ТЗ на такой визуализатор.

 

Что касается композитного кода - это некое обобщение С++ и идеологии обобщенного программирования. Когда код разбивается на составные части, все интерефейсы между ними четко специфицируются, а для этих составных частей пишутся разные варианты для разныз реализаций.

 

Идею с кодогенератором для драйверов уже описал, точно также можно сделать кодогенератор для работы с ОСью (и тогда будет в значительной степени безразлично, под какую ОСь писать).

 

Теперь осталось эффектвино научиться работать с КА - и новая высота будет взята.

 

А ATxmega - это не кумир. Честное слово, мне безразлично, для какой платформы писать. Просто по факту xmega - хорошая плаформа для батарейных вещей.

[AlexandrY 3]

Вы тут концептуально что-то не понимаете или делаете вид.

Речь идет о создании эффективного приложения. На оси или без.

Но никак не о моделировании оси.

А, может у вас есть опыт моделирования осей?

Вот это будет грандиозная находка, мне просто очень интересно знать кто это делает и для чего.

И дейстительно ли там используется аппарат сетей Петри или каких других сетей.

Еще ни у одного разработчика осей не видел даже намеков на моделирование. Максимум симуляция.

 

Че за Линукс такой в 4-мега лезет?

Можете дать координаты или намек кто делает.

Крайне маловероятно, что некоммерческий Линукс такого объема будет сопоставим с возможностями коммерческой оси типа Integrity.

 

Для ясности будем считать что RTOS это ROMable ось способная работать как с MMU так и без него.

 

 

Анализ должен проводиться до того, как ось началА писАться, имхо.

Не договорились. Правильнее, имхо, так: Для Линукса в эмбеддед обычно надо 8 Meг RAM-а и 4 Meг FLASH-а. Для продвинутой RTOS бывает достаточно на порядок меньше.

Хотя тут есть нюанс; вопрос на засыпку - Windows XP Professional SP2 являтся RTOS?

[_Pasha 0]

В решении сложной задачи есть две крайности:

* поставить цель все сделать на асме и здохнуть в таком проекте

* портировать какую-нибудь вирутальную машину

.................................................

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

 

Есть мысли поиграться с YACC.

Есть еще Cinderella SDL

 

А Вам лично удалось пощупать грань "жизни и смерти" проектов в асм? ИМХО, это вещи эфемерные, поскольку определяются остановкой в развитии макросредств в угоду сишному абстракционизму :).

[Evgeny_CD 0]

Есть мысли поиграться с YACC.

Тут гляньте

http://blog.not-a-kernel-guy.com/2007/08/16/221

Есть еще Cinderella SDL

Нда, недешевая шняга, но интересная!

А Вам лично удалось пощупать грань "жизни и смерти" проектов в асм? ИМХО, это вещи эфемерные, поскольку определяются остановкой в развитии макросредств в угоду сишному абстракционизму :).

Нащупался. До одурения. В виде кучи (теперь уже устаревших!) исходников от разных проектов, разработанных разными людьми для разных задач. Там реализована куча интереснейших алгоритмов, но достать их от туда невозможно.

 

С тех пор и стал изучать способы структуризации исходников.