За индикацию по прерыванию нас в институте цитирую:Сообщение от jamper
"Увижу - буду бить. Сильно, но аккуратно" (с) один хороший майор.
Пользователь с временем реакции 0.2 секунды не помрет, если получит индикацию на 10-50 миллисекунд позже. А чтобы символ не потерялся - нужно программировать так, чтобы после возврата из прерывания все сохранилось. Например хранить индекс сканируемого символа и выводимое значение индикатора целиком в памяти.
Прерывание, в отличие от основной программы, строится в расчете на непрерываемость - потому что памяти у нас мало, процессор слабенький - не до жиру.
Задержка без использования стека (тоже, кстати, надо по-минимуму в прерывании применять, как и любое другое обращение в ОЗУ - считал данные в начале работы, записал данные по окончании и хватит) и дополнительных извращений - это 255 тактов максимум. От нее сильно никому не поплохеет. Обычно, я задержки вставляю в прерываниях, чтобы внешний регистр успел перещелкнуться, или чтобы выдать синхронизацию строго после того, как данные на шине устаканились.
Конечно, если "по фен-шую", то в прерываниях должны только флаги выставляться, а по этим флагам основной цикл подпрограммы вызвать, разбираясь - кому времени побольше дать, а кому не очень. С флагами "меня после входа дольше чем на столько-то не прерывать" (чтобы протокол соблюсти например). Отправлять контроллер "спать", если ничего не делается. Чтобы истинная многозадачность была.
"Когда надо дать всем поровну, часто и помногу" (с) тот же самый майор.
Но это в больших проектах и/или на ЯВУ с поддержкой этой самой многозадачности компилятором.
А когда контроллер занимается неторопливым измерением одного параметра и не менее неторопливой выдачей его в интерфейсную шину или на индикацию - задержки - это самое простое, что можно использовать, чтобы не плодить сущности.
У меня совершенно противоположный подход. Все самое важное и требующее непрерывности, непременно полной обработки - по прерываниям, callback ам от прерываний, дополнительным процессам (когда надо - и с повышенным приоритетом).
А основной процесс занимается обработкой ввода пользователя, индикацией. Поэтому, если получит управление чуть попозже - ничего страшного не случится.
Да и сделать только основной процесс безопасно прерываемым гораздо проще, чем городить эту самую "реентрабельность" везде и всюду. Экономит и время написания и отладки, и код и оперативную память.
Перегружен - это P-CAD PC logs 1988-го года выпуска и Multisim начала 2000-х.
А Протеус прост как тапок. Главное накидать цифровых элементов, а не аналоговых - и вперед.
VMLab, при всей его навороченности и сложности всего-лишь отладчик.
Proteus отличается от Microcap или там EWB только тем, что контроллеры моделировать умеет. Поэтому после его освоения получится не потеряться и в них и хотя бы понимать "куда копать" в других программах подобного класса.
Хотя, может у меня такое мнение, потому что мой любимый AvrCo сам себе VMLab - есть в нем и индикатор ЖК, и семисегментные индикаторы, и эмулятор терминала для UART, и на АЦП можно подавать всякие загогулины, да много чего еще.
Согласен. Однако просто так самому дисциплинировать себя сложно.
Лучше написать что-нибудь зубодробительное без комментариев.
А потом при попытке разобраться в написанном в целях дополнения или модификации - плюнуть и переписать "как надо" уже заново, с правильными именами и структурой данных.
Когда наступишь на грабли сам, да еще несколько раз - набитая шишка не даст лениться.
Пожелаю удачи. Наверное так и надо.
А я так и не добил свой крупный проект на астме.
Может я и ленивый. Но когда написал его же за полторы недели на Паскале, и еще за месяц отладил до состояния "комар носа не подточит", после того как полгода мурыжил его на ассемблере - был счастлив.
Я наверное нестандартные велосипеды изобретаю.
Нормальные люди "ресетят" контроллер переходом по нулевому адресу. А я, если есть watchdog - вешаю контроллер, точно зная, что watchdog все сделает сам.
Ответить с цитированием