Вопрос в следующем:
- есть один LED загорающийся подачей 0 в порт
- пусть имя порта определено типа #define LED_PORT PORTx
- и маска пина диода типа #define LED_MASK (1<<Pxx)
- есть прерывание(функция) вызывающаяся допустим раз в миллисекунду
- нужно выводить много различных состояний(диагностика) на этот LED
- примеры:
0,5c горим; 0,5 не горим
0,25c горим; 1c не горим; 0,25 горим, .....
0,25c горим; 0,25c не горим, 0,25 горим, 1c не горим,....
ну и т.д.
- количество состояний ограниченно чем-нить разумным, типа 4-6 вариантов последовательностей.

вопрос в том как эфективнее(и по коду и по скорости) это организовать...

P.S. крайние варианты типа горим полгода а потом не горим 1мс не рассматриваем
P.P.S должен присутствовать и вариант просто горим непрерывно
P.P.P.S. как это сделать в принципе, я знаю, интересны просто варианты сделать это оптимально.

Ну как в PC сделано - при загрузке динамик орет если какая ошибка в процесе POST возникла - вот аналогично и надо делать (у нас в конторе так делается).
Основное время ГОРИМ. в случае ошибки - генерируется код ошибки (1,2,3 и т.д.) периодично (ограждая последовательность вспышек интервалами по 2-3 секунде ) зажигаем лед с периодом 1 сек и меандром 0.5 столько раз чтоб соотвествовать коду ошибки. Тогда дяде Васе легко даже с бодуна посчитать скильки раз всыхнула лампочка на контроллере
Ну и модификация метода - в нормальном режиме не просто горим а а плавно моргаем - помогает иногда отследить зависания, ну и можно иногда на глаз "перегрузку" процессора отследить (рывки в моргании).

Ну например так. Заводим структуру:

Перечисляем возможные состояния светодиода:


И соответствующие им длительности горения/негорения (в тиках таймера):


объявляем переменную состояния диода:



И в таймерном прерывании:


Вот, как-то так:-)

Имхо, проще сделать дифференциацию по количеству подмаргиваний, а не по времени. Делал так для индикации светодиодом уровня сигнала GSM-модуля.

Было что-то вроде:


Потом, в таймерном прерывании:

Код практически один-в-один как у меня, только непонятно, зачем led_is_on, ведь можно считывать if(signal(LED_PIN)). Еще у меня состояния перечислены в порядке их приоритетов, первое состояние IDLE (не горим):
После откончания цикла состояние возвращается в IDLE и функция blink(), через которую прописывается новое состояние, проверяет - если новое состояние более приоритетно, чем текущее - оно принимается и процесс перезапускается. Если менее - игнорируется. В программе blink() вызывается на каждом проходе основного цикла (можно в нескольких разных местах).

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

Лучше две ножки использовать. Тогда можно ставить двухцветыные светодиоды и отображать разом 4 цвета: чёрный, красный, зелёный и жёлтый.
лисекунду



Всё это муторно сильно для пользователя. Единственный разумный вариант: тишина (или свербыстрое перемигивание) и потом 1..10 чётко различимых вспышек разумной (0.5с горит, 0.5с пауза) длительности, чтоб их можно было сосчитать вручную (плюс дублирование звуковым сигналом, если возможно). А декодировать всякие там двоично-десятичные коды закодированные манчестером никакой дурак в трезвом уме не будет.

Тогда уж не signal(), а latch() :-)

А переменная у меня для совместимости с MCS51, там бывали проблемы, когда диод подсаживал ногу.

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



Почему же, видел и такое. У светодиода была три состояния: просто горит - все путем, "спокойно" мигает - неизвестная ошибка, хаотично мигает - значит, проц определил неисправность и передает ее в последовательном коде. Далее извлекался цифровой осциллограф и начинался процесс камлания

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

Я тоже так делал : на четыре ноги - 4 двухцв. св. диода (дин. инд.) и еще можно помигать разными цветами и попеременно. А одноцвеным мигать лучше азбукой Морзе.

Ну у меня примерно тоже самое.., только вопрос вот в чем,
У вас все задействованно только под длитON,длитOFF,
а нужно разные(в том числе по количеству состояний) последовательности,
как в моем первом примере, OK, пусть нужно очень конкретные:
250MS_ON, 250MS_OFF, 250MS_ON, 250MS_OFF, 250MS_ON, 1000MS_OFF // три вспышки, пауза
500MS_ON, 500MS_OFF // равномерное мигание
250MS_ON, 250MS_OFF, 250MS_ON, 1000MS_OFF // две вспышки, пауза
_ON // все время включено

вопрос в том как запоминать все состояния эфективно, они все разные по длительности и по
количеству состояний.



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

Господа, господа!

Давайте сначала определимся с целевой аудиторией -- для кого эти моргания предназначены -- для себя людимого (1), для специалиста, который умеет тыкать осциллографом (2), или для юзера, который умеет тыкать пальцем (3).

Начну с последего -- с юзера (3). Тут бесспорно лучше отдать предпочтение предложению от Kirill Frolov



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

Если речь идет о специалисте (2) с компом, то самое простое -- это зажигать лампочку, а по TXD вываливать инфу. Причем можно это все дело совместить на одной ноге, как предложил bodja74. Спец цепляет ногу к компу, запускает терминалку и читает на экране ASCII-сообщения.

Про "себя любимого" (1) скажу только одно -- "Месье знает толк в извращениях" (С).


Что характерно, тема полезная получилась

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

Смотрите тематику автодиагностики.

Во всех машинах ошибки прописываются в EEPROM и лампочка мыргает ,ну а дальше с денежками
в дяде Васе ,бывшему автослесарю ,который поднялся и купил себе комп со шнурком

Примерно так (нашел в очень старом исходнике):

Тогда наверное проще иметь массив длительностей, и чтобы некоторые значения (например отрицательные) имели специальный смысл.
Например, -1 - остановиться, -2 - вернуться к началу...

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

Если прибор не сильно многосерийный, а пользователи не специалисты, лучше поставить один дешёвый семисегментный индикатор и регистр сдвига. Число осмысленных знаков более двух десятков, а если использовать и мигание, тогда, ИМХО, хватит на всё. Расходуется всего два пина, можно обойтись и одним. В итоге, получится ещё и дешевле, ибо экономятся деньги на междугородних переговорах с заказчиком.
В своё время мне приходилось растолковывать заказчикам мигающие сигналы, и хотя в мануале всё было расписано, всегда находится особо неопытный пользователь. После установки индикатора проблемы закончились.

Святые слова

По поводу одного светодиода с различными комбинациями для женщины - знало бы о ваших идеях наше ОТК => ... Количество глюков невообразимо. Могут пропускать все - мигание, включение, выключение, считать вспышки - тем более. Это вы и специалист разберетесь и знаете, когда работает, а когда нет. Ставьте индикатор по совету Nanobyte и не сомневайтесь. Вам будет намного легче жить

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

Вопрос был именно в организации хранения информации о состоянии светодиода(количество режимов,
количество состояний в каждом режиме, длительности интервалов ON/OFF).

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

ИМХО уровень реализации должен соответствовать уровню абстракции. Иначе можно было бы давно уже перпетум мобиле изготовить.

Когда-то особо не заморачиваясь написал мигалку на 10 состояний для 4x светодиодов, ARM

Спасибо.
Нечто подобное я обдумывал, но у такого варианта есть один недостаток,
все циклы(время одного прохода) имеют одинаковую длительность, а это не всегда удобно,
правда зато по памяти не накладно.

Ну и что? Всё равно очень тонких различий в длительности на глаз нельзя заметить - выбираете подходящий квант времени и останавливаетесь на различии Т и 2Т, а 1,5Т всё равно будет мало отличимо от обеих. Зато очень просто реализуется, "хочется вааще цветомузыку устроить" - дайте 16 бит маску на светодиод.
У меня с не помню каких времён так и светодиоды сделаны (загружается маска, в прерывании по старшему биту светим/не светим и циклический сдвиг маски влево) и пискунчики (только там маска в прерывании сдвигается логическим сдвигом, а не циклическим - отпищали и затихли).

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

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

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