Ну это снова Я со своими вопросиками...
Наверное уже все знают, что все программирование суть есть построение автомата с большим числом состояний... и кучей ошибок...
Кто не знает - продолжайте изучать свою рабочую область и применяемый в ней мат.аппарат - там все сведется к тому что описано...
И так ситуация.
Система на PICе - т.е. ресурсов - мало, процессов - достаточно (для PIC-контроллера) много.
В текущей ситуации нужно контролировать нажатие нескольких кнопок, обмен с SD Card и вывод на дисплей. В дальнейшем - усложнится - добавится еще обмен по сети.
Требования - система должна давать отклик в приемлемое время и быть неубиваемой.
Про неубиваемую систему - понятно - автомат, учитывающий все возможные состояния и коминации сигналов...
4 автомата - по одному на процесс - Я слепил. Вроде все работает. Но... не устраивает.
Дело в том, что это именно 4 автомата. Изменения/добавления в одном другие вроде не затрагивают, но когда изменяется продолжительность цикла одного из автоматов - остальные выходят из синхронизации и начинается бардак с головной болью...
В общем - надо сливать все в один автомат и смотреть что там получится.
Вопросик такой - какие есть тулузки для:
- быстрой эмуляции автомата
- слияния 2-х и более автоматов
- дампа приличного Си-шного кода автомата.
З.Ы. Lex, FLex, Yacc & Ragel - знаю, не устраивают.

>> - слияния 2-х и более автоматов
а как ты себе это представляешь, если у каждого автомата своё собственное состояние?

А как ортогональное произведение...
Проблема в том, что оно не влезет в PIC...

попробуй RTOS..например мы используем TN Kernel..
на офицальном сайте даже есть документация, как запустить TN Kernel на PIC24..
OC работает на ура, синхронизация tasks посредством симафоров, мютехов, различные event-системы , управление памятью и многое другое
наши контроллеры успевают в 10 раз больше сделать , чем то что описал ты и всё работает суперски синхроно и без сбоев:
сама программа , два CAN контроллера, Ethernet, UART, IO , SPI два канала по нескольку clients на канал, I2C, ADC и прочее

Нее, не буду... Просто некогда все это изучать...
Все, что требуется - слить автоматы...

П.С. Я не очень хочу писать код с семафорами и прочим - предпочту имплементировать именно автомат и потом доопределять состояния и переходы...

Не проблема - продолжай изучать используемый мат.аппарат...

попробуй в этом плане Proteus. Сложную систему конечно сложно симулировать, но часто именно в плане синхронизасии железяк на этапе проектирования мне и помогает.

Всё успевает если обрабатывать внешний сигнал через прерывания. Хоть 10 кнопок одновременно. Я на пике 16f877A разную блудь в последнее время собираю, так он на кварце в 20 мегов такую скорость обработки выдаёт... Только писать на низком уровне нужно, а то стек в стену упрётся, если не проконтролируешь его.

Ты, я так понял, хочешь некоторую пародию на ModBus состряпать и какую-нибудь визуализацию повесить, типа скады да ещё чтоб и како-нибуть лог вести??? Никак теплицей какой-нибудь порулить захотел???

Хотя, сейчас глянул - ты ведь на 18-ом PICе будешь делать, всё что тебе нужно аппаратно реализовано начиная с 18-х. там стека 31 уровень. Пиши на чём привык. Только внешний сигнал через прерывания обрабатывай. Можешь ещё и индикацию на него повесить, если капыт у него хватит, всё равно успеет!!!

PIC Simulator IDE - просто и соответствует реальности. Не найдёшь - пиши адрес, скину архив.

Про <Proteus> Я слышу давно, но руки не доходят посмотреть... да и работы по железу слишком мало что бы новую систему изучать - <PCAD>а хватит...

У меня - <PIC24FJ64GB108>... работодатель думает об замене на <PIC24FJ256GB108>... по мне так лишнее - под то что надо слепить хватит и маленького...
если обрабатывать внешний сигнал через прерывания.
-----
Хорошо бы что бы кто-то сказал это прозводителю - там практически нет прерываний в библиотеках... а писать всю обработку <FAT> на <SD Card> мне совершенно не хочется...
писать на низком уровне нужно
-----
Писаться все будет на <Pure C> - опыта более чем достаточно.
Производительность - устраивает - главное не писать явные глупости... и иногда проверять критичные места... последня оптимизация дала сокращение времени закраски экрана с 10.0 до 1.5 сек... дадут больше времени - сделаю и 0.3 сек.

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

<PIC Simulator IDE>
-----
Симулятор - это хорошо. Вопрос в том поддерживает ли он мой <PIC> и что меня больше всего сейчас интересует - ремапинг пинов...

В PCADе есть симуляция работы схемы? первый раз слышу.
Для отрисовки схем и плат использую Eagle. Там библиотек много и свои библиотеки за пару часов можно делать. Но это дело вкуса.
А вот симуляция работы более менее сносно тольков в протеусе идет. Цепляеся скомпилированный файл (будет отладда в асме) или elf(наСильные) и можно по строчкам прыгать, сигналы смотреть и прочее. На хабре вон умельцы даже USB на нем симулируют.

В ПЦАДе есть симуляция работы схемы?
-----
Нет, разумеется - для того голова есть...

Ну если есть голова, то к чему топик создавать? Или просто всем показать, что круче вареных яиц?

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

Вот для этого и и использую симулятор - получаю приемлемый код, тогда толъко железку делаю.

тогда толъко железку делаю.
-----
Железяку делаю не Я... Уже третья редакция и все еще с багами...

если голова не больная, то берётся RTOS, каждый автомат пускается в отдельном процессе и вуаля. это уже советовали выше. есть куча легковесомых RTOS, с сорцами на си, как раз для таких ситуаций
если же посылать всех других учить матчать, а самому в этой самой матчасти нихрена не шарить, то можно кривыми руками набыдлокодить некое подобие rtos (на самом деле непреемтивную варицию main-loop'а), а потом каждый автомат пустить в отдельном процессе
для первого варианта есть несколько тулзов, который из всяких там uml диаграмок автоматов генерят очень компактный си код. это ещё до кучи, чтобы код автоматов своими кривыми ручками не набивать. там же их можно и мержить.
благодарностей не надо

берётся РТОС
-----
В том <PIC> что у меня - 64 килобайта памяти.
Судя по карте загрузки - используется порядка 80%... а одна из частей еще не в основном проэкте...
Куда там еще что-то добавлять? Там резать надо... и много резать... уже пару раз чистил код - все мало...
буду делать еще если время дадут...
есть несколько тулзов
-----
Вот и покажи что есть из доступных - подойдет - буду юзать... Бо, те, что Я знаю, в этой ситуации бесполезны.

НП.
Связанный воросик - <microSD> 4<gb>, <FAT32>.
Чтение и запись идут довольно крупными кусками, но по фат-ной модели данные пишутся в первый свободный сектор.
Есть какая тулузка под Вынью, которая выровняет файлы на границу блока?

Я что, за тебя должен вашу работу делать? Кто у вас системный архитектор? Ему за такое по роже ссаной тряпкой. Если заранее видно, что там будет дохрена автоматов, то пихать туда RTOS изначально. Не влазит? Бери потолще контроллер, паяй оперативку или делай партиционирование алгоритмов и выполняй некритические напрямую из флешки. Есть несколько RTOS на 5-10k памяти, а жрут они лишь несколько процентов от общего количества мипсов.
Такой подход окупается в разы более быстрым завершением проекта с гораздо меньшим количеством народа. Это чтобы без геморроя дополнять функционал, а не бегать по форумам с идиотскими вопросами и затыкать всем рот якобы знанием матчасти.

Кто у вас системный архитектор?
-----
Архитектора Я увижу сегодня. Буду обяснять что <HEX> для 64 не будет работать на 256...
Блин, это же Ирландия - тут редко когда люди занимаются своим делом... ну поручили, ну делает...
Блин, Я на момент начала работ не имел понятия об <PIC>ах... да и сейчас - еле-еле... нормально...
Так что с тулузками?