Есть некий типовой контроллер. 512к FLASH,32к RAM. Такое распределение памяти вызвано объективными технологическими особенностями. И, вероятно так будет долго. Скоро станет 4M FLASH и 256 К SRAM, суть не изменится.

Есть вариант unix идеологии. Когда в памяти живет куча процессов и потоков, различных дискрипторов и структур, и все это в RAM занимает просто мегабайты места. Для однокристальных систем эта идеология слабо подходит.

Пусть есть несколько потков данных. Для каждого из который выделяются некие буфера.

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

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

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

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

Более того, при запуске такой своебразной задачи, ей можно выделить максимальный квант времени. Она сама смотрит, сколько у нее времени осталось, и если обработка не завершена, она ставит флаг (который ей потом сохранится, он static), чистит стек за собой, и отдает управление системе. Разумеется, алгоритм должен допускать такую возможность дробной обработки.

Также задача может заказать, через сколько ее надо вызвать.

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

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

Комбинация вытесняющего и невытесняющего механизмов была бы, IMHO, очень эффективной.

Вопросы:

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

Как по мне, большую часть ваших идей покрывает технология стейт машин. Типа рапсодии и вижуалстейта. А планировщик можно реализовать теми же средствами, по крайней мере пока весь дизайн остается синхронным.
Смущает возможная узкая напраленность такого подхода. Хотя я бы с удовольствием использовал uIP или lwIP (равно как и другие сущности) в виде диаграммы состояний, включенную в мега-каркас приложения

Из осей вроде OSEK и контики имеют возможность использовать смешанный механизм многозадачности.

- Ну у меня в принципе все "темы" где-то такие.
- FreeRTOS и кооперативные задачи и задачи одного уровня приоритета.
- Как уже писалось выше, многое решает просто задача с конечным автоматом.

Самое главное в конечных автоматах - найти способ удобной работы с большими автоматами. Пока, IMHO, стандартного общепринятого решения нет, а жаль Есть такое. Contiki - это вообще очень интересная ОСька. http://www.sics.se/contiki Adam Dunkels заложил туда массу интересных идей. Есть некий парадок - вроде ОСька маленькая, но она вявляется целыми миром, который изучать можно долго.

Про Contiki я помнил, про FreeRTOS тоже, просто интересно, что еще есть на тему.

Есть еще такая штука, как сети Петри. Мне как-то уже указывали на них. Но тогда я не понял, что это такое и как его надо использовать.

Как водится, спустя много времени, потраченного на уединенные размышления, теперь я понимаю, что это!

Подборка информации.

Экспериментальная версия транслятора сетей Петри в испольняемый код.
http://www.iacp.dvo.ru/lab_11/otchet/ot2000/readme.html

10.24 Сети Петри Семенов Ю.А. (ГНЦ ИТЭФ)
http://book.itep.ru/10/petri.htm

Отечественный проект!!! VisualPetri is Petri net editor for Windows platform based on GDI Plus library with an integrated simulator. Note: a Petri net is one of several mathematical representations of discrete distributed systems.
http://sourceforge.net/projects/visual-petri/
Поставил. Запускается и работает.

Дока от этой софтины
http://www.caree.narod.ru/vpdocs/_content.html


http://listlib.narod.ru/vichteh2.htm - много интересной литературы. Там найдено:

Котов В.Е. Сети Петри.— М.: Наука. Главная редакция физико-математической литературы, 1984.— 160 с.
http://listlib.narod.ru/vichteh/Kotov.djvu

Питерсон Дж. Теория сетей Петри и моделирование систем: Пер. с англ.— М.: Мир, 1984.— 264 с.
http://listlib.narod.ru/vichteh/Piterson1.djvu
http://listlib.narod.ru/vichteh/Piterson2.djvu

Более близкие к народу (к практике) - IEC61131 - язык SFC

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

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

А что подразумевается под вытесняющей многозадачностью? Если вытеснение одной задачи другой, - тогда понятие "приоритет" теряет смысл, ибо более приоритетная задача должна вытеснять менее приоритетную; так проще применять матаппараты, которые аналитически позволяют строить подобные системы, например, небезызвестный ЧМА (http://mike.qnx.org.ru/files/articles/rms/rms.doc).

"Ресурсный" вопрос тоже должен решаться на этапе проектирования (мы же не рассматриваем высоконагруженные сервера или базы данных, верно? хотя тут просто используются другие методы). В идеале, динамической памяти вообще быть не должно, или, на худой конец, должны быть раздельные пулы для задач, причем размер пулов должен позволять обрабатывать данные при заданной их интенсивности и производительности вычислителя. В противном случае система просто захлебнется, и никакие стейт машины не спасут.

Так или иначе, возлагать на ОС (планировщик) архитектурные задачи - плохая идея, имхо. Это должен делать человек, в рамках модели ОС, разумеется.

Сети Петри - хорошая штука Жаль, только, задача достижимости в общем случае нерешаема. Плюс разные эффекты, связанные с асинхронностью и недерминированностью.

А задачи одного приоритета (или разного, но имеющие на данный момент времени одинаковый приоритет) должны выполняться "параллельно".

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

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

Чтобы что-то облегчить, надо что-то нагрузить. ;-)

Чесно не понял как вы Евгений предлагаете облегчить разработку приложения под RTOS.

А вообще хотелось бы рассмотреть проблему на конкретных примерах.
Действительно ли там такие проблемы с фрагментацией и ресурсами?

Сети Петри не рассматриваю серьезно, так как уже давно есть Simulink, LabView , Systemview ... который "рвут" эти сети, как говориться, простым брутфорсом.
Плюс в книгах по этим сетям рассматривают такие частные и примитивные приложения, что смешно.

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

Собственно, это и есть "карусель" (хоть и с квантами), которую тов. rezident отделил от "вытесняющей многозадачности".
К тому же, у задач одинакового приоритета дедлайна не должно быть, иначе зачем им назначать одинаковый приоритет? Динамически менять его тоже не очень хорошая идея, а если Вы намекаете на инверсию (которой, по идее, тоже не должно быть ), так там все кроме одной задачи заблокированы по определению.

У каналов связи бесконечная пропускная способность, и из них непрерывно сыпятся данные, которые обязательно нужно обработать? С т.з. контроллера - возможно, но с т.з. архитектора - это не так, всегда можно найти верхнюю оценку загруженности исходя из задачи и предметной области. Грубо говоря, из серийного порта на 115200 мегабитного потока не дождешься, а, зная протоколы более высокого уровня, можно еще сильнее конкретизировать загрузку. Еще бывают рилтаймовые потоковые данные, для которых валидно последнее значение(я). И т.д и т.п...

Хмм... Про серверы я специально сказал, чтобы разделить эти классы (см. "вариант unix идеологии" в первом посте). Как правило, в узкоспециализированных девайсах можно (и нужно, имхо) избавится от неконтролирумых malloc/free, особенно когда куча/память общая для задач. Только делать это должна не ОС

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

Я реалист, а не идеалист

Как-раз с точностью до наоборот. Для "бесконечных" и "непрерывных" нужено взять бесконечно большие ресурсы и никаих проблем . А вот в реальности, когда обеспечить абсолютно достаточные ресурсы за разумные деньги просто невозможно, тогда и начинается. А c чем-нибудь типа "котроллера светодиода" или на самом деле принципиально от него не отличающегося, например, "MP3 плеера" - проблем в этом смысле нет - ресурсы для них просто обязаны быть достаточными.

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

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

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

Видимо, ситуация по памяти выглядит так:
* при инициализации проиходит обращение к malloc
* при норамальной работе задача (задачи) сами занимаются управлением собственной памятью (ОСь не обладает телепатическими способностями, чтобы понять, как и когда можно дефрагментировать память конкретного приложения)
* free вызывается только при глобальном завершении процесса на Сервере или типа когда контроллер сдох

Еще есть труды Шалыто А.А., в том числе знаменитый

Switch-технология. Алгоритмизация и программирование задач логического управления
http://is.ifmo.ru/books/switch/2

Есть алгоритм решения задачи. Он живет сам по себе.

Есть способы реализации этого алгоритма: структурное, функциональное, логическое, и еще 1001 программирование.

Есть железяка, которая, на самом деле, понимает только один язык - машинные коды.

И вопрос только в том, как корректно преобразовать алгоритм в машинные коды, чтобы:

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

* они должны это гарантированно делать за заданное время.

Сила "обычных" языков программировнаия в том, что они неплохо ложатся на мозги программеров. Но соотнесение их с алгоритмом не так-то просто.

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

Есть паллиативы. Которые ресурсы среды исполнения разменивают на сложность программирования.

Парадигма многозадачности удобная для восприятия человеком. Она позволяте разбить код на куски, и четко отследить связи между этимми кусками. Что и дают все эти потоки, сигналы, семафоры, m-box, пайпы и сокеты.

Язк программирования + ОСь гарантируют в таком случае изоляцию этих кусков программ. Это возволяет осуществить декомпозицию задачи.

Но плата за это - расход ресурсов среды исполнения.

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

Вот теперь самый главный вопрос - как всю эту систему вызова "миллиона" функций сопоставить с решаемым алгоритмом?

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

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

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

Вопрос - кто какие системы работы с конечными атвоматами знает - кроме iSTATE и Rapsody?

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

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

А че мы обсуждаем?
Я что-то нить потерял.
Наличие каких-либо проблем никто так и не подтвердил.

А про ресурсы же мы вроде договорились.
Для продвинутой RTOS надо 8 Meг RAM-а и 1/4 от этого для FLASH-а.
Для Линукса на порядок больше.
Кто-то добрый выложил Integrity от GreenHills. Там лишний раз подтверждается оценка для RTOS.
Дальнейшая оптимизация и ужимание особой экономии не принесет.

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

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

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

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

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

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

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

В свете появления фреймворков как 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), но сложность алгоритмов там уже требует какого-то системного подхода, хотя бы в виде генератора автоматов.

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

Почему бы тогда не реализовать обслуживание в одной нити? Как минимум, сэкономим немного ресурсов.
Также можно реализовать FIFO на одном приоритете (кооператив другими словами) без квантов. И для этого совсем не нужно вырубать таймер.
Наконец, можно назначить разные приоритеты даже одинаковым каналам. Да, среднее время реакции на них будет разное, но если оно укладывается в дедлайн - какая разница?
Причины отказа от использования time-slice Вы сами и же назвали (зачем усложнять систему без надобности).


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


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


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

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


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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

конечно, более подробно это описано в соотвествующей ветке.
Мега уже король!
http://electronix.ru/forum/index.php?s=&am...st&p=425627


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

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

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

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

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

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

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

Сейчас я совершенно четко представляю, как вести разработку в родной мне коммуникационной области, полностью отвязанную от специфики конкретного железа. Причем если когда-то это было на уровне функций-ориентированного HAL (все обращение к железу только через вызовы функций драйвера), то теперь я понимаю, как такую же виртуальную разработку делать уже с асмовой эффективностью!
http://electronix.ru/forum/index.php?showtopic=48931

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

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

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

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

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

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

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

Визулизировать смысл - это в графической форме представить все сущности кода
* функции
* блоки кода {}
* машины состояний
* потоки

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

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

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

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

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

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

Вы тут концептуально что-то не понимаете или делаете вид.
Речь идет о создании эффективного приложения. На оси или без.
Но никак не о моделировании оси.
А, может у вас есть опыт моделирования осей?
Вот это будет грандиозная находка, мне просто очень интересно знать кто это делает и для чего.
И дейстительно ли там используется аппарат сетей Петри или каких других сетей.
Еще ни у одного разработчика осей не видел даже намеков на моделирование. Максимум симуляция.

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

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

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

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

Тут гляньте
http://blog.not-a-kernel-guy.com/2007/08/16/221Нда, недешевая шняга, но интересная!Нащупался. До одурения. В виде кучи (теперь уже устаревших!) исходников от разных проектов, разработанных разными людьми для разных задач. Там реализована куча интереснейших алгоритмов, но достать их от туда невозможно.

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

caxapa::Vit подсказал еще вот какие интересные проекты:

TinyTimber
http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.pdf
http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.h
http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.c

TinyTimber, a very small and lightweight run-time kernel for event-driven embedded systems.

А тут целая куча интересного:
http://www.nilsenelektronikk.no/neprod.html
proc Real-Time Kernel
nemon Boot and Debug Monitor
nesos Finite State Machine Operating System - вот это интересно в контексте рассматриваемых задач.
Embedded Web Servers

caxapa:: Рэйлвэй Каген {

При всём богатстве выбора, альтернатив, как всегда, две
А именно - есть алгебраисты и алгоритмисты.

Первым ближе сети, графы и автоматы. К перечисленным средствам могу добавить только
CPN Tools http://www.daimi.au.dk/~cpntools . Впрочем, это уже было здесь: http://caxapa.ru/110159.html
Для генерации в плюсАх можно посмотреть gsmsuite http://www.boutell.com/lsm/lsmbyid.cgi/000341

Вторым - Дракон http://wiki.oberoncore.ru/index.php/%D0%94...%B7%D0%BE%D1%80
Дракон-редактор http://narod.ru/disk/55428000/DRT.rar
По сути - очередная реинкарнация блок-схем с полуавтоматической генерацией кода.
Паронджанов В.Д. Как улучшить работу ума. Алгоритмы без программистов — это очень
просто!(Новые средства для образного представления знаний, развития интелекта и
взаимопонимания). М.: Дело, 2001. — 360 с. — Илл.: 154.
http://www.transhumanism-russia.ru/documen...tu_uma_Word.rar
Недавняя дискуссия здесь http://forum.oberoncore.ru/viewtopic.php?f=62&t=493 ,
в том числе и по общим подходам к визуализации программ.

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

Мне добавить нечего

Кое-что добавлю.

Лично мне генерация кода из графиеского представления кажется очень привлекательной! Решать обратную задачу мы не будем, не ученые-теоретики, а вот верификатор - проверять кода на соотвествие блок схеме - это очень нужно! Вот только где бы такое взять?

Но меня удивляет то, что нет толковых общепринятых тулзов для этого. С/С++ компилеров и их вариантов вон сколько наплодили, а такого генератора/верфикатора нет. Или это жутко конкурентная область, и все заныкали свои наработки под матрасами??? -

Нет, просто результат такой работы располагается не под матрасом, а под плинтусом. Какие-то верификаторы, рабочие имеются, а вот после генераторов типичная задача - надо ускорить в 10 раз...
Всей цепочки одной из охременных компаний не наблюдал, поскольку она размазана по штатам-германиям-бангалорам и окраинам европы, но то, что в конце-концов после всего этого десяток человек в восточной европе правят-верифицируют-правят-верифицируют-... переписывают на ASM, блин, правят верификатор , преписывают.. и так далее, дабы влезть по производительности наблюдаю лично.

Есть такое. Меня удивляет, что никто не сделал "полуавтоматический" инструмент. (Полностью автоматический инструмент - утопия, тут и спорить не о чем).

Есть изначальный граф - описание алгоритма. Генерируем код.

Код разбиваем на блоки (хоть чезер маркеры в каментах, хоть еще как).

В кажом блоке описываются его характеристики:

* export - чем из этого блока можно пользоваться снаружи
* import - чем он сам пользуется
* config - заивсимость от параметров конфигурации
* OS - какие средства ОСи блок использует.

Все связи между блоками прописываются на уровне графа и только так!

Далее на уровне блока проверятся - блок соотвествует своему дескриптору или нет?

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

Далее берем блок кода и начинаем глазками/ручками/мозгами доводит его до совершенства.

Полной автоматической кодогерации делать смысла никакого нет.

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

Блоки могут быть вложенными.

Далее верификауция идет в два этапа.

На уровне формальной верификации проверяем, что блок соотвествует дескриптору.

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

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

Вот и вся автоматизация. Никакого "искусственного интеллекта" и пр. шняг не предвидится. Все просто и тупо, в моем понимании на год неспешной работы пары толковых программистов.

Вопрос в том, почему так никто не сделал???

"Остапа несло..."

Быть может. Это отражение моих старых идей.

Продолжайте, продолжайте.. Мы с трепетом внимаем..

Кстати, допускают ли Ваши блоки изоморфное погружение гомеоморфное сфере с положительной Гауссовой кривизной?

Я рад, что Вы когда-то изучали дифференциальную геометрию. Можете освежить свои знания. и подумать над тем, что Вы тут написали.

(ссылки для желающих)

гауссова кривизна
http://ru.wikipedia.org/wiki/%D0%9A%D1%80%...%B7%D0%BD%D0%B0

Гомеоморфизм
http://ru.wikipedia.org/wiki/%D0%93%D0%BE%...%B8%D0%B7%D0%BC

Изоморфизм
http://ru.wikipedia.org/wiki/%D0%98%D0%B7%...%B8%D0%B7%D0%BC

А по существу можете чего добавить?

По существу...

"Суха теория, мой друг, а древо жизни вечно зеленеет."

Начали за здравие (см. топик), а кончили за упокой

Подкину дровишек: UML.
http://en.wikipedia.org/wiki/UML_tool
http://www.altova.com/features_code_generation_umodel.html
...



Да, похоже на то.


Например, http://www.freesco.org/

Или вот в моем ADSL момеде крутится линух. Причем держит 4портовый свитч, вайфай, веб интерфейс для настройки, немерянное количество опций, НАТ ессно, шейпер, даже выкусыватель рекламы из хтмл потока и DDNS клиент. Правда, там 8м флеш и 16м RAM, но на менее навороченных моделях стоит 4 и 8 соответственно. Аптайм обычно несколько месяцев, все ок. И досил я его, тоже справился

В цисках крутится IOS, основанный на BSD. Там требования поболее (но и нагрузка тоже).

Если захотите, найдете еще примеры... А сравнивать "некоммерческий Линукс" с "коммерческой осью типа Integrity" не очень корректно, ибо чтобы они продавались, нужно превосходство хотя бы по некоторым параметрам.

Это бывший Linux Router что ли?

Честно говоря, не в курсе
http://en.wikipedia.org/wiki/List_of_Linux...l_distributions

Сайт проекта Linux Router уже закрылся, но вот тут что-то можно узнать
http://www.linuxjournal.com/article/5826

Когда в описании freesco увидел ядро серии 2.0 - то подумал, что это из тех времен, когда Linux Router рулил. Но увы, проект закрылся.

В моей конторе юзался Linux Router - очень хорошо показал себя.

У меня как раз такой - Acorp Lan420 - 8 мегабайт, "Linux version 2.4.17_mvl21-malta-mips_fp_le" - зашел по telnet-у.Забавно подобное слышать - где сейчас найдешь NAS, беспроводную точку, adsl-модем с коммерческой осью?

Ну.. , роутеры это не серьезно.
Эт мы проходили, и вообщем известно, что роутерное ядро как таковое много софта не требует.
Я сам вам могу показать наши 3G - Wi-Fi - Ethernet роутеры с парой метров FLASH-и и 8 Мег RAM-а
Но это не платформы для создания многофункциональных приложений.
А уж как там создают софт я вообще молчу.
Там входишь в отдел тестирования и чувстуешь жар.
Так жарят там чуть ли не сотни тестовых систем которые день и ночь долбят по Ethernet-у эти роутеры чем только в голову взбредет в надежде так нахаляву обнаружить хотябы еще один программный баг.

Мои роутеры вообще Линукса не требуют, имеют все тоже, что ваш ADSL модем и помещаются в 512 Kб причем программа вообще в RAM не грузится.


Вот Android я бы посчитал за полнофункциональную платформу.
Или дистрибутивы MontaVista для FreeScal-ов с QTopia
Ну так они еле втискиваются в те параметры, что я указал.

Мысль про некорректность сравнения вашу вообще не понял.

Некоммерческий Линукс и RTOS-s класса Integrity я привел как два крайних идеологических полюса.
Поэтому доморощенные проекты типа http://www.freesco.org/ в расчет не берутся, как умаляющие возможности Линукса.

А TDD там нет в принципе? Запустить тесты над куском кода, посмотреть и их результат, затем другой кусок протестить т.д.

А затем уже снаружи устройство тестами мучить - чтобы понять, что в ТЗ было упущено.

А можно ссылочку?
И как продаются, сколько стоят?
И сколько все-таки памяти, несколькими строками выше Вы писали:

Ну собственно наши роутеры и без меня есть кому рекламировать, а сайт непосредственно разработчиков платформы: http://www.wilibox.com/

Вы занимаетесь несерьезными вещами

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

Какой там TDD! Разработка роутера это сплошняк тупая интеграция и ловля багов в хардваре.

Но вот скажу такое наблюдение.
Даже первая спецификация ZigBee была очень формализованной.
Она вся была написана на SDL.
Не вызывало даже тени сомнений, что она точно промоделирована и просимулирована во все щели.
Однако они здорово облажались, когда народ реально попытался включить в сеть тысячи дивайсов.

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

Другое наблюдение такое:

Как только в конторе появляется молодой специалист, через некоторое время видишь как он начинает возится с UML или выдумывать свои блоксхемки в Visio, или ковыряет по старинке LabView если он недавний студент.
Причем работа начинает заметно тормозиться.
Как правило потом он увольняется.
Вывод я делаю такой: UML и проч графическая визуализация и формализация придуманы депресивными девелоперами (даже не молодыми, а просто теми кого скоро уволят или переместят на другой проект) и подерживаются исключительно этим контингентом. Уж причинно следственные связи определять не берусь.