SMS

Reply to
Alexander Derazhne
Loading thread data ...
Reply to
George Shepelev
Reply to
George Shepelev
Reply to
George Shepelev
Reply to
Dimmy Timchenko
Reply to
Vladimir Vassilevsky
Reply to
Maxim Polyanskiy

Dear Igor,

17 Jan 04 11:05, Igor Ulanov wrote to Maxim Polyanskiy:

IU> Лyчше бы поговоpили об алгоpитмах:)

Hе говори...

IU> У меня напpимеp катастpофически огpомный код полyчается пpи IU> пpогpаммиpовании менюшек. Как сделать его меньше я не пpедставляю. IU> Кто-то готов подсказать?

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

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

51-м не помню сколько было за давностию лет, но того же порядка. После этого небольшой оверхед на неиспользуемые указатели в описаниях состояний кажутся полной ерундой. Собственно функционал (вход, выход, отрисовка) при реализации меню для большинства пунктов получается единым. Т.е. на входе пара строк на инициализацию переменных, а дальше все одинаково. Hа реализацию достаточно сложного меню с "формочками" задания значений (штук 7) и простых переключателей Yes/No или On/Off (еще штук 10), плюс собственно вывод основной программы в разных представлениях (а в данном подходе что меню, что форма, что программа - опять же все едино) уходит около 900-1100 байт. Да, понятно, что обработчик клавиатуры "незримо" присутствует в том же коде.

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

Sincerely yours, Old Greaser.

Reply to
Serge Bryxin
Reply to
Alexander Torres

Sun Jan 18 2004 22:27, Serge Bryxin wrote to Igor Ulanov:

SB> Я пару месяцев назад тут описывал один из очень красивых вариантов. Во SB> всяком случае - для небольшого количества кнопок.

SB> Программа представляет из себя автомат, ходящий по графу состояний. SB> Переходы инициируются нажатием одной из кнопок. Каждое состояние в общем SB> случае описывается указателями на другие состояния (по числу кнопок), SB> указателями на функцию входа в состояние, на функцию выхода из него и на SB> функцию отрисовки.

Красиво! И главное, корректность хорошо проверять. Достаточно нарисовать граф и окинуть его взглядом на предмет недостижимых состояний или состояний, не имеющих выхода. Спасибо за идею, побольше бы таких мессаг. А то все ругань не по делу...

Reply to
Ilia Tarasov
Reply to
Maxim Polyanskiy
Reply to
Vladimir Vassilevsky
Reply to
Alexander Torres
Reply to
Sergey Pinigin

DT>> то, что на 51-м делается одной командой, на AVR тpебует 2-3. HZ> Hа 51-м это делается за офигенную тучу тактов, т.ч. на АВР 2-3 HZ> команды обычно быстрее.

GS> Сегодня можно найти 51-совместимые контроллеры, которые требуют GS> гораздо меньше тактов на команду.

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

Reply to
Andy Mozzhevilov

IU> Лyчше бы поговоpили об алгоpитмах:) IU> У меня напpимеp катастpофически огpомный код полyчается пpи пpогpаммиpовании IU> менюшек. Как сделать его меньше я не пpедставляю. Кто-то готов подсказать?

Связанные списки. Что тут еще подсказывать. Например

/* Структура одного пункта меню */ typedef struct SS_MENU_ITEM_S { char * str; /* Указатель на строку, содержашую название пункта меню */ struct SS_MENU_ITEM_S const *submenu; /* Указатель на подменю */ void (* cmd)(void * data); /* Указатель на задачу, исполняющую этот пункт */ void * data; /* Указатель на данные, передаваемый задаче команды */ } SS_MENU_ITEM_T;

Далее объявление

SS_MENU_ITEM_T const Menu_ViewSubmenuTbl[] = { { "Буфер" , &Menu_SelectBufSubmenuTbl[0], 0, 0 }, { "Настройки" , 0, &CmdViewAdjust, 0 }, { "Неисправности" , 0, &CmdViewErrors, 0 }, { "Время и версии", 0, &CmdViewVer , 0 }, { 0 , 0, 0, 0 } };

Reply to
Andy Mozzhevilov

MP>> тут все думают, как-бы си за уши притянуть к процессорам mcs51 и MP>> PIC для которых какие-то умники накатали компилятор. AT> И не один. Кстати лет 13-14 назад, когда толком Си для 51- небыло,

MP> AT> многие писали на PL/M, и были в большом восторге. MP> 10 лет назад когда в совке внешняя память еще стоила какие-то деньги, а MP> достовабельные mcs51 с нутренней памятью ограничиваись 8751H я не видел ни MP> одного коммерческого проэкта, написанного на чем либо, отличным от АСМА!

Разве была какая-то обязательная регистрация всех коммерческих проектов, и этим непостредственно занимался ты?

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

Вот если бы их не было, тогда было бы очевидно, что на них никто не пишет. Я же в течение нескольких лет довольно неплохо писал на PL/M-51

Reply to
Andy Mozzhevilov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.