Часы-термометр на Atmega16 и Nokia3310 lcd

[within]

Дело вот какое. Изготовление: 1.берём телефон, оставляем корпус, экран, кнопки. Остальное - долой. 2.Запихиваем туда мк, датчик температуры. Результат: показывает время, дату, температуру. Это для начала. Потом можно будет и ещё что-нибудь добавить.

Проблема. Если главный бесконечный цикл оставить пустым - всё ок. Но не соответствует замыслу использования меню с настройками. Если вписать в него обращение к функциям или просто вкл./выкл. подсветки, то часы начинают сильно отставать. Часы на асинхронном таймере с часовым кварцем. Работа с экраном отсюда: http://radiokot.ru/articles/29/

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

Вложения

1.c

Исходник

(63.58 KiB) Скачиваний: 456

[mas123]

Проблема. Если главный бесконечный цикл оставить пустым - всё ок. Но не соответствует замыслу использования меню с настройками. Если вписать в него обращение к функциям или просто вкл./выкл. подсветки, то часы начинают сильно отставать. Часы на асинхронном таймере с часовым кварцем.

Раз часы отстают - кто-то где-то выключает прерывания надолго. Ищи где.
Проверь функцию delay_ms() - не запрещает ли она прерывания унутри.
Пробуй отключать по очереди все функции меню или подсветки - смотри где заработает.

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

Читать тяжело код
А, ну вот возможная причина.
У тебя ВСЁ зафигачено в прерывание. И подсчет времени (мдя, BCD подсчет времени порадовал )
И даже опрос температуры - он ДОЛГИЙ!!! а ты в прерывании его делаешь.

За вывод на LCD из секундного прерывания нужно выдать медаль
Мало тормозов от LcdClear(), так ты ещё добавил тормоза от кучи-кучи sprintf() и добил LcdUpdate().
ЖЖЖуть!

[within]

А, ну вот возможная причина.
У тебя ВСЁ зафигачено в прерывание. И подсчет времени (мдя, BCD подсчет времени порадовал )
И даже опрос температуры - он ДОЛГИЙ!!! а ты в прерывании его делаешь.

За вывод на LCD из секундного прерывания нужно выдать медаль
Мало тормозов от LcdClear(), так ты ещё добавил тормоза от кучи-кучи sprintf() и добил LcdUpdate().
ЖЖЖуть!

А теперь посмотри картинку и прикинь, что к чему. Сверху - время всего прерывания. Снизу - sprintf. От начала верхнего до начала нижнего - подсчёт времени/даты и чтение датчика(9 бит, если не заметил). От конца нижнего до конца верхнего - LcdUpdate. Много времени занимает?

Вложения

Proteus DSO Printing.rar

(5.3 KiB) Скачиваний: 268

[mas123]

А теперь посмотри картинку и прикинь, что к чему. Сверху - время всего прерывания. Снизу - sprintf. От начала верхнего до начала нижнего - подсчёт времени/даты и чтение датчика(9 бит, если не заметил). От конца нижнего до конца верхнего - LcdUpdate. Много времени занимает?

Поясни картинку ещё раз.
Я правильно понимаю, что нарастающий фронт - это вход в прерывание, а падающий фронт - выход из прерывания?

Снизу - sprintf

Т.е. высокий уровень на нижнем графике - это суммарное время кучки вызовов sprintf() + LcdStringBold()?

[within]

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

[mas123]

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

Давай посчитаем вместе. Я вот тупо замерил линейкой расстояние между фронтами и у меня получилось, что в прерывании ты сидишь ~273мс, т.е. 27% времени.
Считаешь это "ниачем"?

А теперь попробуй провести опыты на живом приборе. Точно так же перекидывай какую-нить ножку порта при входе-выходе из прерывания. К этой ноге подключи осцилл. Второй сигнал осцилла на вход импульсов 1 сек.
И понаблюдай что происходит при нажатии на кнопки или при мигании подсветки. Короче, сделай чтоб часы отставали.
Очень и очень вероятно, что ты увидишь "пропажу" импульсов прерывания. Либо, увидишь что отработка прерывания превышает 1 сек.

[within]

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

Давай посчитаем вместе. Я вот тупо замерил линейкой расстояние между фронтами и у меня получилось, что в прерывании ты сидишь ~273мс, т.е. 27% времени.
Считаешь это "ниачем"?

Эммм... Да! В данном случае это ничто. Пусть хоть 900мс там сидит, это не космическая станция. Ничего не пропустит. А 73% запаса это совсем не мало. Или лучше, чтоб он за 10мс всё сделал и остальные 990 читал клаву? Лучше не смайлики шоковые вставляй, а обьясни, чем тебя число 273 так пугает?

А теперь попробуй провести опыты на живом приборе. Точно так же перекидывай какую-нить ножку порта при входе-выходе из прерывания. К этой ноге подключи осцилл. Второй сигнал осцилла на вход импульсов 1 сек.
И понаблюдай что происходит при нажатии на кнопки или при мигании подсветки. Короче, сделай чтоб часы отставали.
Очень и очень вероятно, что ты увидишь "пропажу" импульсов прерывания. Либо, увидишь что отработка прерывания превышает 1 сек.

Что-то тебя заклинило на прерывании. В вопросе ясно написано: бесконечный цикл пустой - всё ок, заполненный - проблема. Как наличие чего-либо в главном цикле, даже запрета прерываний, может повлиять на продолжительность обработчика? Прерывание может приходить с опозданием, но не из-за обработчика(соотношение 27%обработчика/73%главного цикла), а, скорее, из-за чего-то в этом цикле. Моё мнение, считаю его вполне логичным.

[mas123]

Эммм... Да! В данном случае это ничто. Пусть хоть 900мс там сидит, это не космическая станция. Ничего не пропустит. А 73% запаса это совсем не мало. Или лучше, чтоб он за 10мс всё сделал и остальные 990 читал клаву?

Да, лучше именно так.

Лучше не смайлики шоковые вставляй, а обьясни, чем тебя число 273 так пугает?

Нахождение в прерывании 27% времени - это ОЧЕНЬ много.

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

Ты издеваешься или прикидываешься?
- ты запретил прерывание, надолго. А оно произошло.
- разрешил прерывание... ну пусть через 800 мс от прихода прерывания.
- прерывание начали выполнять, в это время таймер снова дотикал до 255.
И что в итоге? теряем 1 сек в подсчете.

Прерывание может приходить с опозданием, но не из-за обработчика(соотношение 27%обработчика/73%главного цикла), а, скорее, из-за чего-то в этом цикле. Моё мнение, считаю его вполне логичным.

Ну, в таком случае копай свой цикл. Я тогда не понимаю смысле твоего вопроса. Зачем спрашивать, ежели ты УЖЕ ЗНАЕШЬ где проблема - так ищи её, разбирай каждую строчку основной функции, коли в ней проблема.

Я же не зря просил промерять время нахождения в прерывании на живой железке.
Ну-ка, мистер точно знающий, расскажи мне:

* что будут делать функции LcdClear(), sprintf (), LcdStringBold(), LcdString() и LcdUpdate() будучи одновременно вызванными из основного цикла и из прерывания?
Как у тебя в этих функциях организована потокобезопасность?

* а нет ли у тебя хорошей такой наводки на PD5? Схемы-то нет... Надеюсь, резюк на VCC там нормальный?

[within]

Нахождение в прерывании 27% времени - это ОЧЕНЬ много.

Смотря для чего устройство делалось.

Ты издеваешься или прикидываешься?
- ты запретил прерывание, надолго. А оно произошло.
- разрешил прерывание... ну пусть через 800 мс от прихода прерывания.
- прерывание начали выполнять, в это время таймер снова дотикал до 255.
И что в итоге? теряем 1 сек в подсчете.

А каким образом тут увеличился обработчик? Прерывания сдвинулись во времени. Но продолжительность каждого не изменилась.

Ну, в таком случае копай свой цикл. Я тогда не понимаю смысле твоего вопроса. Зачем спрашивать, ежели ты УЖЕ ЗНАЕШЬ где проблема - так ищи её, разбирай каждую строчку основной функции, коли в ней проблема.

Я же не зря просил промерять время нахождения в прерывании на живой железке.
Ну-ка, мистер точно знающий, расскажи мне:

* что будут делать функции LcdClear(), sprintf (), LcdStringBold(), LcdString() и LcdUpdate() будучи одновременно вызванными из основного цикла и из прерывания?
Как у тебя в этих функциях организована потокобезопасность?

* а нет ли у тебя хорошей такой наводки на PD5? Схемы-то нет... Надеюсь, резюк на VCC там нормальный?

1. Вот я для этого и создал эту тему, чтоб покопать его с кем-то ещё.
2.Они не будут вызываться одновременно, как ты это себе представляешь? Посмотри внимательней код.
3. А причём тут PD5? Он в меню сам не заходит. А просто часы отстают.

[mas123]

Нахождение в прерывании 27% времени - это ОЧЕНЬ много.

Смотря для чего устройство делалось.

Эээ, делалось для того, чтоб часы отставали?

Ты издеваешься или прикидываешься?
- ты запретил прерывание, надолго. А оно произошло.
- разрешил прерывание... ну пусть через 800 мс от прихода прерывания.
- прерывание начали выполнять, в это время таймер снова дотикал до 255.
И что в итоге? теряем 1 сек в подсчете.

А каким образом тут увеличился обработчик? Прерывания сдвинулись во времени. Но продолжительность каждого не изменилась.

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

2.Они не будут вызываться одновременно, как ты это себе представляешь? Посмотри внимательней код.

А. точно, не должны вызываться. При условии что "bit a" компилятор обработает как volatile.

3. А причём тут PD5? Он в меню сам не заходит. А просто часы отстают.

Т.е. за качество входных сигналов с кнопок ты ручаешься. Хорошо.
Повторюсь ещё раз - подключи в живую осцилл, один вход на реальные секундные импульсы (сконфигурируй Timer2, чтоб он на выходе OC выдавал импульс при переполнении), а второй вход осцилла на твой сигнал входа и выхода из прерывания. И наблюдай ГДЕ по времени находится твой обработчик.
Ну и проверь функцию delay_ms() - не запрещает ли она прерывания при работе.

[within]

Эээ, делалось для того, чтоб часы отставали?

Смешно то как) Для особо одарённого тебя объясняю. Прерывание, как следствие переполнения таймера/счётчика, происходит раз в сек. Исходя из этого, имеем 1000мс от начала одного до начала другого на всё, что душа пожелает при условии, что: 1. это время внутри обработчика; 2. помимо обработчика ничего более не надо. В этом устройстве, помимо обработчика, нужно три кнопки читать. На это нужно время. Но речь идёт не о том, что кнопки не работают корректно в связи с тем, что прерывания идут одно за другим. Следовательно, прерывание менее 1000мс, так как я, даже учитывая скорость своей реакции и задержки при нажатии, могу нажать их все последовательно между концом одного прерывания и началом следующего и получить действие - реакцию на нажатие.

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

Это не я издеваюсь, это ты...) Я это прекрасно понимаю и без твоих смешков) Но я не сдвигаю время входа! Я пытаюсь узнать, что в цикле while может это сделать? Почему именно в нём? Во-первых. Результат наблюдения показал, что именно при наличии в нём того, что там есть, фигня и творится. Во-вторых. Ты думаешь, что даже при самом плохом раскладе вычислений и чтения температуры(9 бит), этот расклад может сожрать 73% времени сверх?

Ну и проверь функцию delay_ms() - не запрещает ли она прерывания при работе.

А ты разве не знаешь? Если бы знал, то не писал бы такое. Как вариант, ты никогда не использовал одновременно прерывания и задержки времени. Хотя странно это... Давно ты с контроллерами знаком? Как изучал? Что делал? На каком языке писал?

[mas123]

Прерывание, как следствие переполнения таймера/счётчика, происходит раз в сек. Исходя из этого, имеем 1000мс от начала одного до начала другого на всё, что душа пожелает при условии, что: 1. это время внутри обработчика; 2. помимо обработчика ничего более не надо.

Хм, исходя из (2) - убери всё из цикла в main() и будет тебе "щастье".

В этом устройстве, помимо обработчика, нужно три кнопки читать. На это нужно время.

Тебе требуется ТАК много времени на опрос кнопок?

Код:

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

Это не я издеваюсь, это ты...) Я это прекрасно понимаю и без твоих смешков) Но я не сдвигаю время входа! Я пытаюсь узнать, что в цикле while может это сделать? Почему именно в нём?

Именно в нём потому, что ничего другого нет. А причина элементарная - потеря прерывания. Думаешь иначе? Давай, выдвини свою теорию.

Ты думаешь, что даже при самом плохом раскладе вычислений и чтения температуры(9 бит), этот расклад может сожрать 73% времени сверх?

Ага. Давай посмотрим на гениальный код:

Код:

     devices=w1_init();  //ищем датчик
     ds18b20_init(0,-50,50,1); //ставим границы "аварии", и разрешение 9бит
      if(devices>0)
        {     
         Tnew=ds18b20_temperature(0);  //читаем температуру 
        }     


Сколько времени занимает поиск датчика? И зачем его искать каждую секунду? Сколько времени выполняется инициализация?
Кстати, а писать "0" вместо NULL это специально? Да, компилятору это одинаково, но не так читабельно.
Ну а писать вместо константы число... А ты УВЕРЕН что настроил термометр на 9 бит, а?

Ну и проверь функцию delay_ms() - не запрещает ли она прерывания при работе.

А ты разве не знаешь? Если бы знал, то не писал бы такое.

Я не знаю что CVAVR творит в данной функции, но я бы уже давно посмотрел на asm исходник.

Как вариант, ты никогда не использовал одновременно прерывания и задержки времени. Хотя странно это... Давно ты с контроллерами знаком? Как изучал? Что делал? На каком языке писал?

Ваууу, ну ты попа-а-а-ал... Щазз разогну пальцы веером
Записывай.
<тут пальцы разгибаются>
* с 1990 ZX-Spectrum. бейсик и ассемблер. (MMD, ZX-News, ... Надеюсь тебе это ничего не говорит )
* с 1996 PC. asm x86, С, С++. Основное направление - связь.
* с 2000 AVR. ассемблер, С.
* с 2005 Z380. С
* c 2008 Blackfin. С, С++
* с 2011 чуть-чуть MSP430. С.

Тебя интересуют мои более-менее крупные поделки на контроллерах?
(Кстати, а Z80, Z380 и BF-537 будем считать контроллерами?)

* простенький реобас для ПЦ (3 датчика, 2 кулера)

* часы. 2 будильника, 4 больших 7-ми сегментника, 4 кнопки. Резервная батарейка, контроль батарейки, вывод напряжения и мигание индикатора "меняй батарейки"
Тикают уже лет 10.

* часы-метео. 6 индикаторов о 17 сегментах (мечта децццтва), RGB-светодироды.
5 кнопок, 4 будильника, резервная батарейка с контролем. DS18B20 внутри часов (этот датчик лишний на самом деле).
Два отдельных модуля на tiny: каждый меряет температуру, давление, влажность. Один в комнате, второй на балконе.
Связь по RS-485, контроль подключения и отключения модулей "на лету".
В часах организовано 16 "каналов данных", каждый модуль пишет в свои каналы. А при "нахождении" модуля часами, модуль сообщает в какие каналы он будет писать, как именно часам выводить данные из канала (число цифр, наличие запятой, положение на индикаторах, название измерения).

* Бортовой комп для машинки, он же музыка.
Модуль подключается к штатной магнитоле WV, выступая в роли CD-ченджера. (ага, разбираемся с протоколом между магнитолой и ченджером).
С другой стороны модуль подключается к плееру iRiver, управляя им. В итоге кнопки на "голове" управляют всей системой, а плеер через "голову" играет.
Прошивку для плеера тоже правил, в итоге управляю как хочу, а из плеера выходит название трека, время и ты-пы.
Помимо отображения на "голове" отдельный модуль с LCD (самый простой WH1602C).
Помимо музЫки БК читает данные с датчиков машины: уровень топлива, импульсы с форсунки, с датчика скорости. И на этих данных в реальном времени вычисляется мгновенный расход, средний расход, максимальная и минимальные скорости, сколько бензина потратили, на сколько км ещё осталось.

* бортовой комплекс для более новой машинки.
1. модуль стеклоподъемника. Доводчик и вверх и вниз, закрытие окон по сигналке. Кнопки же будут и управлять всем комплексом.
2. Радио-метео модуль. AVR + CC1101 + BMP085 + SHT10. Опрашивает датчики, читает команды от сигналки (ага, опять разборки с протоколом).
Всё это "щастье" передается в эфир. На руке eZ430-Chronos с переделанной прошивкой, которые принимают данные и выводят их. Ну и писчат, когда сигналка срабатывает.
3. Модуль индикации. AVR + LCD Nokia 6100 + DS18B20. Игрался и с LCD 3310 - не понравилось.
Всё это хозяйство связано по своей сеточке, плюс простенький протокол. В процессе сейчас (3), поэтому для отладки (2) лежит рядышком с ним на столе.

Но, это всё домашние игрушки. Тебе хочется серьёзных вещей? Их есть у меня.
* промышленная система: энергоучет, телеметрия, телеуправление
Как просто доработки существующей, так и разработка новой с нуля. (не я один, это понятно уж).
Моё: ядро (система реального времени), SD-карта, многоканальное АЦП, TCP/IP стек,
HTTP-сервер, журналирование, контроль работоспособности процессов, ...
<тут пальцы cгибаются обратно>
Теперь скажи въюноша бледный, со взором горящим - достаточно ли я опытен, чтобы давать тебе советы?
И можно теперь поинтересоваться твоими опытом и наработками?

[within]

Я перед недалёким человеком не буду хвалиться) Что ни напишу, всё насмешки. Так что моё останется за кадром. Скажу лишь то, область моих изделий куда шире, чем твоя.

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

Менее 27% времени. В пределах допустимого и с ОООООЧЕНЬ приличным запасом.

Кстати, а писать "0" вместо NULL это специально? Да, компилятору это одинаково, но не так читабельно.

Вопрос этой тему не стоит в просьбе помощи улучшения читаемости кода. Не придирайся. Это к делу не относится.

А ты УВЕРЕН что настроил термометр на 9 бит, а?

А ты уверен, что нет, а? Косвенное доказательство: время опроса. Если тебе не верится,
почитай:

Код:

#define DS18B20_9BIT_RES 0  // 9 bit thermometer resolution
unsigned char ds18b20_init(unsigned char *addr,signed char temp_low,signed char temp_high,
unsigned char resolution);

Вещь простая, а ты спрашиваешь, уверен ли я?
Спроси себя лучше, уверен ли ты?

Я не знаю что CVAVR творит в данной функции, но я бы уже давно посмотрел на asm исходник.

Так какого лезешь с советами? Или возможность прерывания временной задержки зависит от компилятора? Хм... Ты странный.

Короче, если есть, что сказать, помимо ужасающих 27% времени на обработчик, и ты разбираешь в основных принципах работы авр'ок, то говори по сути, а не разводи болтовню. Прерывание в пределах нормы. Если есть что-то ещё - пиши. Нет - выпендривайся в других темах.

[within]

Ты преподом не работаешь?

[mas123]

Я перед недалёким человеком не буду хвалиться) Что ни напишу, всё насмешки. Так что моё останется за кадром. Скажу лишь то, область моих изделий куда шире, чем твоя.

Не-а, не верю. Ты не писал ничего "в команде" - по коду видно. Ты не писал ничего серьезного - один только подсчет двухзначного числа в двух переменных чего стоит.
Моё предположение - лет 15-17. И похвастаться нечем.
Была бы область "шире" так бы не наглючил с такими простыми часами. Да и с клавой тоже.

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

Менее 27% времени. В пределах допустимого и с ОООООЧЕНЬ приличным запасом.

Т.е. точных цифр ты назвать не можешь. Вот ещё один признак.

А ты УВЕРЕН что настроил термометр на 9 бит, а?

А ты уверен, что нет, а? Косвенное доказательство: время опроса. Если тебе не верится,
почитай:

Код:

#define DS18B20_9BIT_RES 0  // 9 bit thermometer resolution
unsigned char ds18b20_init(unsigned char *addr,signed char temp_low,signed char temp_high,
unsigned char resolution);

Вещь простая, а ты спрашиваешь, уверен ли я?
Спроси себя лучше, уверен ли ты?

Мдя.... ну что-же, давай посмотрим в гениальный код:

Код:

     devices=w1_init();  //ищем датчик
     ds18b20_init(0,-50,50,1); //ставим границы "аварии", и разрешение 9бит

Ну что, так кто из нас уверен, а? 10-ти битный режим у тебя. А ещё с таким норовом "да я, да вещь простая, да сам-то уверен".

Я не знаю что CVAVR творит в данной функции, но я бы уже давно посмотрел на asm исходник.

Так какого лезешь с советами?

Советов просил ты. Тебя тыкнули носом в "бяко"-код и в дикое прерывание. Да ткнули носом у всех на виду, да обидно и неприятно - чё уж тут говорить. Знакомо. Меня самого тыкали также ещё в Фидо.

Или возможность прерывания временной задержки зависит от компилятора? Хм... Ты странный.

Хм, CAVR твой первый и пока что единственный компилятор на данное время, походу. Ты ответь - смотрел ли в асмовской код, который компилятор нагородил, изучал его?

Короче, если есть, что сказать, помимо ужасающих 27% времени на обработчик,

Кстати, ежели тебя не пугает такое огромное время в обработчике прерываний - это признак отсутствия "широты устройств".

и ты разбираешь в основных принципах работы авр'ок, то говори по сути, а не разводи болтовню.

Хех. смотри внимательно. У тебя и у меня AVR + DS18B20 + LCD.
У меня часы тикают, опрашивают через UART другую AVR. И ещё часы тикают и ты-ды. (см. выще).

У тебя часы отстают и клава работает "не так как надо". И кто же мешает тебе взять из своей "широкой области" рабочий код часов, LCD и термометра?

А по сути - переписать надо всё с нуля не грузить несчастную зверюшку огромным прерыванием.

Прерывание в пределах нормы. Если есть что-то ещё - пиши. Нет - выпендривайся в других темах.

Не, ну это просто финиш... Если у тебя кроме прерывания нет ничего больше и часы отстают - ты будешь с упорством уверять что прерывания в норме...
...Мыши кололись, плакали, но продолжали жрать кактус...

[mas123]

Ты преподом не работаешь?

Был у меня опыт преподавания. Когда писал диплом в универе, пол года в своей родной школе вел информатику.
И на выпускном концерте 11-ти классники выбрали меня в категории "самый умный учитель". На что остальные учителя дико обиделись - "мы же сами учили этого шалопая, а теперь его самым умным назвали"

Но, если бы ты читал внимательнее выше, увидел бы область где я работаю.

[mas123]

Я перед недалёким человеком не буду хвалиться) Что ни напишу, всё насмешки. Так что моё останется за кадром. Скажу лишь то, область моих изделий куда шире, чем твоя.

Хм, вот про 15-17 лет я ошибся.
Но вот скажи мне - а зачем врать о своей опытности в AVR?
Профиль - Поиск сообщений пользователя и видим ну всю историю.
"Ребят, сорри, только начинаю....Первая попытка с МК и такой облом..." <=== Пн фев 13, 2012 10:39:18
"...как установить разрешение в 9 бит для DS18b20 в стандартной библиотеке?..." а ведь тебе и ответили ПРАВИЛЬНО, а не то что у тебя в коде!

Хех. ежели тебе на самом деле нужна хоть какая-то помощь....
Я человек не злой (по вторникам), так что можно начать с начала, обсуждать твой жуткий код и ловить прерывания

[metan]

Здравствуйте!
Я удивляюсь людям. Настоящие специалисты тратят своё время на помощь тем, кто сделав чудовищные вещи в простейшей программе, кричит что более опытен. Ужос нах.
По теме.
Не считаю себя шибко грамотным специалистом, но подпишусь под каждым словом mas123
Из своего небогатого опыта могу сказать, что функции работы 1wire весьма прожорливы по времени и достаточно вольно работают с прерываниями. У меня в одной из моих поделок, при инициализации, опросе числа датчиков, опросе температуры достаточно ощутимо мигали индикаторы. А индикация была сделана на прерывании по таймеру.
Поэтому послушайте дельного совета и оставьте в прерывании МИНИМАЛЬНО НЕОБХОДИМЫЙ там код. И все будет хорошо.

[within]

Но вот скажи мне - а зачем врать о своей опытности в AVR?

Я говорил, что область шире, а не опыта больше в авр.

Т.е. точных цифр ты назвать не можешь. Вот ещё один признак.

А зачем их называть, если речь не идёт о соотношении 99%/1%. Хочешь комбайну лазерный прицел скотчем примотать?

Ну что, так кто из нас уверен, а? 10-ти битный режим у тебя.

Согласен, протупил. Экспериментировал, а поменять забыл.

Советов просил ты. Тебя тыкнули носом в "бяко"-код и в дикое прерывание. Да ткнули носом у всех на виду, да обидно и неприятно - чё уж тут говорить. Знакомо.

Меня терзают смутные сомнения, что ты прав. Сегодня проконсультировался с преподом знакомым. Он не особо с тобой согласился.

Кстати, ежели тебя не пугает такое огромное время в обработчике прерываний - это признак отсутствия "широты устройств".

Эммм... Это признак того, что в этом устройстве такое время обработчика не страшно. Было бы другое устройство, где несколько обрабатываемых событий, происходящих произвольно, я бы последовал совету. Но, увы, не в этот раз. Вывел на экран в конце прерывания текущее значение таймера/счётчика. Пока за 70 не переваливало. Поставлю включение подсветки при превышении значения 72, к примеру. Погоняю сутки. Если часы будут отставать, но подсветка не включится...

У тебя часы отстают и клава работает "не так как надо".

Клава работает как надо.

Не, ну это просто финиш... Если у тебя кроме прерывания нет ничего больше и часы отстают - ты будешь с упорством уверять что прерывания в норме...

Проверим)

Был у меня опыт преподавания. Когда писал диплом в универе, пол года в своей родной школе вел информатику.
И на выпускном концерте 11-ти классники выбрали меня в категории "самый умный учитель". На что остальные учителя дико обиделись - "мы же сами учили этого шалопая, а теперь его самым умным назвали"

Но, если бы ты читал внимательнее выше, увидел бы область где я работаю.

Видать, давно это было. Испортился ты( Не увидел бы, а смог бы определить. Я понял, что ты сейчас не преподаешь. Хотя в Могилянке преподы тоже серьёзными проэктами занимаются. А ты мог не всю жизнь на одном месте работать.

Я человек не злой (по вторникам), так что можно начать с начала, обсуждать твой жуткий код и ловить прерывания

Не злой, а вот насмехаться любишь.

Здравствуйте!
Я удивляюсь людям. Настоящие специалисты тратят своё время на помощь тем, кто сделав чудовищные вещи в простейшей программе, кричит что более опытен. Ужос нах.
По теме.
Не считаю себя шибко грамотным специалистом, но подпишусь под каждым словом mas123
Из своего небогатого опыта могу сказать, что функции работы 1wire весьма прожорливы по времени и достаточно вольно работают с прерываниями. У меня в одной из моих поделок, при инициализации, опросе числа датчиков, опросе температуры достаточно ощутимо мигали индикаторы. А индикация была сделана на прерывании по таймеру.
Поэтому послушайте дельного совета и оставьте в прерывании МИНИМАЛЬНО НЕОБХОДИМЫЙ там код. И все будет хорошо.

Процитируй, где моя "большая опытность". И где же те чудовищные ошибки?
Мигали? А ты какое разрешение датчика ставил? При 12 битах макс. время , к примеру, конвертации 750мс. При 9-ти - 93.75мс. Так что мигать может по разному. А прерывания на индикацию не мешали работе с датчиком?
Так покажи мне там минимально необходимый код обработчика.

[mas123]

Я говорил, что область шире, а не опыта больше в авр.

Так удиви, расскажи что за области

Ну что, так кто из нас уверен, а? 10-ти битный режим у тебя.

Согласен, протупил. Экспериментировал, а поменять забыл.

Это к вопросу об оформлении кода. Константы-то не зря придумали.

Меня терзают смутные сомнения, что ты прав. Сегодня проконсультировался с преподом знакомым. Он не особо с тобой согласился.

Хм, и с чем же твой препод не согласился?

Кстати, ежели тебя не пугает такое огромное время в обработчике прерываний - это признак отсутствия "широты устройств".

Эммм... Это признак того, что в этом устройстве такое время обработчика не страшно.

Ок, раз такое время обработки прерываний не страшно, то и отставание часов тоже не страшно. Значит, проблема решена

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

Ты сейчас напоминаешь героя анекдота, который ищет не там где потерял, а под фонарем. Ибо там светлее.

У тебя часы отстают и клава работает "не так как надо".

Клава работает как надо.

Тогда поясни эту фразу:
"...В этом устройстве, помимо обработчика, нужно три кнопки читать. На это нужно время. Но речь идёт не о том, что кнопки не работают корректно в связи с тем, что прерывания идут одно за другим...."

Видать, давно это было. Испортился ты( Не увидел бы, а смог бы определить.
Я понял, что ты сейчас не преподаешь.

Я человек не злой (по вторникам), так что можно начать с начала, обсуждать твой жуткий код и ловить прерывания

Не злой, а вот насмехаться любишь.

Я могу объяснить раз, ну два... ну, три. А когда на всё объяснения следует ответ "нет, прерывания нормальны, глючит что-то другое, хотя там больше ничего нет"...

Процитируй, где моя "большая опытность".

Придется цитирвоать все твои ответы этой темы
Вот это феерическое:

Если бы знал, то не писал бы такое. Как вариант, ты никогда не использовал одновременно прерывания и задержки времени. Хотя странно это... Давно ты с контроллерами знаком? Как изучал? Что делал? На каком языке писал?

Ну какая тебе разница сколько лет я держу в руках паяльник и клаву?

И вот этот "слив" в результате:

Я перед недалёким человеком не буду хвалиться) Что ни напишу, всё насмешки. Так что моё останется за кадром. Скажу лишь то, область моих изделий куда шире, чем твоя.

Уверенность в непогрешимости своего кода, даже не посмотрев в него вначале:

Вещь простая, а ты спрашиваешь, уверен ли я? Спроси себя лучше, уверен ли ты?

Я бы на твоем месте, вначале посмотрел бы код. Даже при полной уверенности в своей правоте. Глаз-то замыливается на своем коде.

И где же те чудовищные ошибки?

1) подсчет времени "в две переменные".

Код:

 sek++;                        //
 if(sek>9)                     //
  {                            //
   sek=0;                      //
   d_sek++;                    //
  }                            //
 if(d_sek>5)                   //
  {                            //
   sek=0;                      //
   d_sek=0;                    //
   min++;                      //
  }                            //


2) постоянный поиск термометра и его настройка и опрос в прерывании.
3) зачем постоянно чистить экран перед каждым выводом? ты же выводишь всё время в одни и те же координаты!
4) применение суровой функции sprintf, да ещё там где этого не нужно. Напоминаю, что во всех переменных хранится число в диапазоне [0...9]

Код:

   
   sprintf (lcd_buf, "%u", d_hour);  //заносим в буфер время
   LcdStringBold(2,2);               //
   sprintf (lcd_buf, "%u", hour);    //
   LcdStringBold(4,2);               //
   sprintf (lcd_buf, ":");           //
   LcdStringBold(6,2);               //
   sprintf (lcd_buf, "%u", d_min);   //
   LcdStringBold(8,2);               //
   sprintf (lcd_buf, "%u", min);     //
   LcdStringBold(10,2);              //
   sprintf (lcd_buf, ":");           //
   LcdString(12,2);                  //
   sprintf (lcd_buf, "%u", d_sek);   //
   LcdString(13,2);                  //
   sprintf (lcd_buf, "%u", sek);     //
   LcdString(14,2);                  //


5) демонстративное игнорирование каких либо констант и т.п.. Вот скажи, не глядя в схему/код - что такое if(PIND.4==0). И вспомнишь ли ты об этом через полгода?
Ну и тот самый момент с настройкой разрешения термометра.
6) в чем смысл все переменные делать глобальными? Например "char max_den; //максимальное количество дней в текущем месяце".
Используется в одном месте, между использованием не требует хранения результата.
7) Выбор имен для переменных. Глобальная переменная "a", "i" и т.п. - это сильно! Сразу выдает опытнейшего программиста с "широкой областью"
8 ) игнорирование возможностей языка. Зато смотрится красиво:

Код:

if(c==0)
{
.....
}
if(c==1)
{
.....
}
if(c==2)
{
.....
}
if(c==3)
{
.....
}


Так покажи мне там минимально необходимый код обработчика.

- в прерывании только подсчет времени. Причем, секунды считать в одной переменной (всё остальное тоже).
- убрать вывод на экран из прерывания. или сделать его БЫСТРЫМ! Сырсов твоей lcd-либы не видел, поэтому думай сам реально ли это.
- Поиск термометра перенести в main(), настройку датчика туда же. Делается это один раз при старте и больше не нужно.
- опрос термометра вынести в main(), либо сделать нормальным - без непосредственного ожидания выполнения.
Выдал команду "начинай замер температуры" и пошел себе дальше. На следующем прерывании смотришь - если замер температуры окончен, читаешь значение.
- Прерывание же опрашивает клавиатуру. Плюс антидребезг, плюс контроль много-нажатия клавиш и прочие плюшки.

В итоге прерывание будет выставлять флажки для главной программы, например:
- нажата клавиша, код клавиши в переменной. Читаем код, сбрасываем флаг и выполняем.
- пора мерить температуру. тут-то main() и замеряет. (если выносим замер)
- пора обновить экран. тут main() и перерисовывает всё (если вынесли отображение)

Да, кстати. А разве клавиатура от телефона была сделана не по матричной схеме, типа 3х4?