Диагностика через светодиод, 1 диод, много состояний Опции

[singlskv]

Вопрос в следующем:
- есть один 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. как это сделать в принципе, я знаю, интересны просто варианты сделать это оптимально.

[yod]

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

[AHTOXA]

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

Код

typedef struct
{
    unsigned int OnTime;
    unsigned int OffTime;
}LedStateTimes;

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

Код

typedef enum
{
    lsState1 = 0,
    lsState2,
    lsState3,
    lsState4
}LedStates;

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

Код

const LedStateTimes LedTimes[] =
{
    {20, 50},
    {20, 500},
    {200, 50},
    {2000, 50},
};

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

Код

LedStates led_state = lsState1;

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

Код

{
    static unsigned int ticks = 10;
    static int led_is_on;

    if (!--ticks)
    {
        if (led_is_on)
        {
            led_is_on = 0;
            off(LED_PIN);
            ticks = LedTimes[led_state].OffTime;
        }
        else
        {
            led_is_on = 1;
            on(LED_PIN);
            ticks = LedTimes[led_state].OnTime;
        }
    }
}

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

[war4one]

Вопрос в следующем:...

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

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

Код

#define TmQuartSeconds 7    // 1/4 секунды при частоте переполнения таймера 30 Гц
#define TmFullSSPeriod 160    // Один раз в столько тиков обновляется информация о уровне сигнала

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

Код

++Ticks;
    if (Ticks % TmFullSSPeriod == 0)    // Загрузка значения уровня сигнала
    {
        TmSS = 2*GSMSigStrength;
        clrbit(PORTC, GSMLED);
    }
    if    (Ticks % TmQuartSeconds == 0)    // Проверяем состояние GSM-модуля раз в четверть секунды
    {
        if (GSMStatus == 2)            // Если GSM-модуль зарегистрирован в сети - показываем уровень сигнала
        {
            if (TmSS > 0)        // Индикатор мигает
            {
                invbit(PORTC, GSMLED);
                TmSS--;
            }
            else clrbit(PORTC, GSMLED);    // Индикатор потушен
        }
    }

Сообщение отредактировал war4one - Feb 27 2008, 05:26

[Сергей Борщ]

Ну например так. Заводим структуру:
Перечисляем возможные состояния светодиода:

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

Код

enum tLEDState { LED_IDLE, LED_GPS_OFF, LED_GPS_NOT_VALID, LED_GPS_VALID };
typedef struct
{
    tFastTime OnTime;
    tFastTime Period;
} tLEDBlink;
#define    sec    *(OSC/65536)
__flash tLEDBlink const LEDBlink[] =
{
    {0,0},
    {0.15 sec, 10 sec},
    {1.35 sec, 1.5 sec},
    {0.15 sec, 1.5 sec},
};

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

[Dog Pawlowa]

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

Код

void Blinks(char pulses)
{        char i;
        if (!pulses) return;
        for (i=0; i<pulses; i++)
        {    ON_LED;
            __delay_cycles(500000);
            OFF_LED;
            __delay_cycles(1600000);
        }
         __delay_cycles(10000000);
}

[Kirill Frolov]

Вопрос в следующем:
- есть один LED загорающийся подачей 0 в порт

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

- нужно выводить много различных состояний(диагностика) на этот LED
- примеры:
0,5c горим; 0,5 не горим
0,25c горим; 1c не горим; 0,25 горим, .....
0,25c горим; 0,25c не горим, 0,25 горим, 1c не горим,....
ну и т.д.
- количество состояний ограниченно чем-нить разумным, типа 4-6 вариантов последовательностей.

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

[AHTOXA]

Код практически один-в-один как у меня, только непонятно, зачем led_is_on, ведь можно считывать if(signal(LED_PIN)).

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

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

[war4one]

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

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

А декодировать всякие там двоично-десятичные коды закодированные манчестером никакой дурак в трезвом уме не будет.

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

[bodja74]

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

[muravei]

Лучше две ножки использовать. Тогда можно ставить двухцветыные светодиоды

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

[singlskv]

....................

...................

Ну у меня примерно тоже самое.., только вопрос вот в чем,
У вас все задействованно только под длит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 // все время включено

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

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

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

[zhevak]

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

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

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

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

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

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

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


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

[singlskv]

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

...а потом выдаем собственно серию этих самых всышек. Любая толстаяжо тетка сообразит посчитать вспышки и сообщить по телефону (или как там) специалисту о неисправности системы. Тупо, просто и предельно понятно.

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

[bodja74]

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

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

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

[Сергей Борщ]

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

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

Код

.h:

typedef struct
{
    unsigned char Freq;
    unsigned Time;
} NoteType;
extern void beep(NoteType *);

extern    NoteType PowerOnBeep[];
extern    NoteType PowerOffBeep[];
extern    NoteType LegalKeyBeep[];
extern    NoteType IllegalKeyBeep[];

.c:

NoteType const PowerOnBeep[]=
{
    {Hz(2000),100 ms},
    {Hz(1000),100 ms},
    {Hz(500),100 ms},
    {Hz(200),200 ms},
    {0,0}
};
NoteType const PowerOffBeep[]=
{
    {Hz(100),200 ms},
    {Hz(500),100 ms},
    {0,0}
};
NoteType const LegalKeyBeep[]={{Hz(1000),100 ms},{0,0}};
NoteType const IllegalKeyBeep[]={{Hz(200),100 ms},{0,0}};

[AHTOXA]

нужно разные(в том числе по количеству состояний) последовательности,
как в моем первом примере, 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 - вернуться к началу...

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

[Nanobyte]

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

[Wildcat]

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

Святые слова

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

[singlskv]

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

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

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

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

[rezident]

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

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

[zltigo]

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

Код

//---------------------------------------------------------------------------
#define MAX_LED_MODES    10
static const ulong led_const[MAX_LED_MODES] =
                    { 0x00000000,            // 0 Off
                      0x11111111,            // 1 On
                      0x11110000,            // 2 Slow Blink
                      0x11001100,            // 3 Normal Blink
                      0x10101010,            // 4 Fast Blink
                      0x10000000,            // 5 Single Flash
                      0x10100000,            // 6 Two    Flash
                      0x10101000,            // 7 Tree   Flash
                      0x01111111,            // 8 Single Blackout
                      0x01011111            // 9 Two    Blackout
                    };
ulong ledstat =    0;
//  4 LEDS processor
//---------------------------------------------------------------------------
void led_prosess( int counter )
{
ulong curstat;
    curstat = ((ledstat >> ((counter & 0x07 )<<2)) & 0x0F)<<BIT_LED0;
    if( curstat )
        IO1CLR = curstat;
    curstat = (~curstat)&(0x0F<<BIT_LED0);
    if( curstat )
        IO1SET = curstat;
}

[singlskv]

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

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

[ReAl]

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

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

[zltigo]

...на различии Т и 2Т, а 1,5Т всё равно будет мало отличимо от обеих.

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

[singlskv]

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

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

[Angelo]

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