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

Кстати, про синтетические системы и реальное время. Все гораздо интереснее, чем кажется! Есть синтетический порт ОСи. Есть процессы, которые тусуются под ее управлением. Есть эмулятор обработчика прерывания, который шлет сигналы процессам под управлением ОСи. Есть процесс IDLE. В котором живет процессор, если все задачи в рамках системы отработаны. Т.е. если задача отработала свое, и передала управление ОСи, и ОСь не нашла, кому бы передать управление, все спит до возникнования какого-нибудь сигнала или очередного тика ОСи. За тупое ожидание в пользовательском цикле программеров надо лишать зарплаты. Есть дроччер. Который дает сигнал обработчику прерывания. Типа байт по UART пришел. Самое главное - не чистое реальное время, а как система будет реагировать на его нарушение. Например, если обработчик прерывания пытается нечто пропихнуть в буфер, а он полон - он должен не забыть взвести флаг. Недопустимую задержку прерывания нужно отрабатывать на аппаратном уровне - тут софт бессилен. Так вот. Легкие условия испытания. Дроччер ждет, когда система свалится в IDLE, и после этого взбадривает обработчик прерывания. Так по циклу. Усложняем задачу. Дроччер начинает взбардривать обработчик не дожидаясь IDLE сисемы. Со все ускоряющимся темпом. Все пишется в лог. Потом анализщируем, как у нас система вела себя при возрастании нагрузки. Меняем размеры буферов. Ну и добиваемся, чтобы все флаги коректно взводились. Народ, в ведь синтетическая система будет гораздо круче любого реального тестирования (как уже говорил, это не заменяет реальное тестирование) в части моделирования таких ситуаций. Только нужно очень грамотно синтетический порт писать. Кроме ОСи, нужно в рамках одного процесса(!), чтобы не париться с общим доступом к памяти из разных процессов, запускать еще несколько отладочных нитей. Правильно настроить приоритеты нитей. Везде прописать синхронизацию, чтобы ничего никуда не убежало. Большую память для дампа, SQL сервак для складирования, ну и пытонить до посинения. Синтетический порт нужно очень грамотно продумываь, это нифига не простая задача! Смотрите. По максимуму, при каждом обращении к ОСи мы можем делать дамп памяти нашей виртуальной системы! ну или хотя бы всех важных переменных Пусть у нас будет 10к таких переменных. по 4 байта. 40к на дамп. 1Г оперативки - 25к дампов. Если не при кажом обращении, а, например, при каждом тике, делать дамп, и тик=1мс в реальной системе, у нас памяти хватит на 25с реального трассинга (пусть хоть всю ночю симулирует, "вкалыват роботы"). Делаем охрененую таблицу SQL на 10к записей в строке (вероятно, проще на другой машине). В нити дроччера делаем кеширование. Например, туда складываем десяток дампов, а том этот кусок засовываем в SQL, чтобы экономить ресурсы. Либо так. Пишем наш дамп в файл по сетке на другую машину. Там он парсится и засовывается в SQL. Все. Потом тупо справшиваем SQL - в вот когда эта переменая (типа флаг переполнения) стала такой? А что у нас в этот момент происходило по логу дроччера? Ну и моте-карлить по черному. Включить буйную фантазию. Думаю, так можно сильно проредить "матрицу глюков" Все не выловишь, но зато станет понятно, как система себя ведет в реальной жизни. Потом, как мне кажется, будет гораздо понимать, что в реале происходит. Например, вроде выловили все глюки - а в рельности что-то да происходит. Не то:) В кристалле надо чуток ресурсов оставить. Чтобы хотя бы примерно фиксировать в каком месте программы мы в каждый момент находимся. Например, лог последних нескольких итераций. За счет этого становится понятно, в каком куске "что-то не то". Запускаем дроччер и этот кусок натягиваем со всей извращенной фантазией. Модифицируем код, выделям яркие точки, суем туда дополнительную диагностику, и вперед. Идея в том, что если реальный проект нагрузить всеми мыслимыми и немыслимыми проверками, "никогда не взлетит". Нужен только поверхностный логгер. Далее, если что-не то, начинаем "под лупой" исследовать кусок программы. Это уже потребует разумного оверхеда. Слушайте, народ, это же лично для меня снимает многие ограничения, существовавшие в голове. Т.е. получается линейный способ достижения целей даже при очень сложных задачах.