Т.е. как у вас было, через деление. Но в этом случае она длится около 135мкс, против 80мкс в моем варианте...
Обработчик прерывания у меня длится около 8.25мкс, против вашего с 14.1мкс, и вызывается примерно в 4-е раза реже...
Любой, заслуживающий внимания, опыт приобретается себе в убыток...
Вот вы, уважаемый mr_smith, прежде чем обижаться, лучше бы внимательно посты почитали, а еще лучше - заново всю тему! Вам же явно указали ссылку на статью ( там и исходник): http://radiokot.ru/forum/viewtopic.php?p=231499#231499.
Просто внимательнее читайте и будет вам счастье!
Мужики, я конечно понимаю что вы все хотите показать какие вы умные, но я тоже не дурак. Тут дело не в принципах реализации. Goodefine, зашил в свою мегу твою прошивку. Смотри сам.
На 16 секунде в первом ролике. На 17 и на 36 секунде во втором.
Последний раз редактировалось mr_smit Пн июн 15, 2009 21:34:13, всего редактировалось 1 раз.
mr_smit писал(а):
Тут дело не в принципах реализации. Goodefine, зашил в свою мегу твою прошивку. Смотри сам.
Ясен пень, в чем тут дело - в неправильном значении температуры, возвращаемой с датчика. Тут либо датчик виноват, либо встроенная библиотека CAVR. Лечится элементарно. Главный цикл:
for (;;)//---------------------MAIN_LOOP----------------------------------
{
#asm("wdr") //для Протеуса
//получаем температуру
temp=ds18b20_temperature(&ds18b20_rom_codes[0][0]);
//преобразуем значение температуры в строку и ложим в буфер buffer
if((temp>=0)&&(temp<100))decbin_ds(&temp, buffer);
//пауза
delay_ms(100);
} //end MAIN_LOOP----------------------------------------------------
Немного костыли, но должно помочь...
Любой, заслуживающий внимания, опыт приобретается себе в убыток...
Вот и я подумал, что мало - сделал вообще без нее, засинхронизировав заодно чтение датчика и прерывание. Но опрос датчика длится около 144мс, потому при динамической индикации, прерывание будет по любому влазить в опрос примерно 10 раз...
Любой, заслуживающий внимания, опыт приобретается себе в убыток...