Поиск сообщества
Показаны результаты для тегов 'dashkova'.
Найдено: 7 результатов
-
Давайте начнем
parovoZZ опубликовал запись в блоге в Изучаем USI на основе сверхэкономичного прототипа
Цель - разработка экономичного беспроводного монитора температуры и относительной влажности. Что мы имеем: МК Attiny24A, датчик SHT10 от SENSIRION, популярный трансивер nRF24l01+ и источник питания в виде пары батареек LR41. Работа будет весьма насыщенной и объемной, т.к. мы будем использовать модуль USI сразу в двух режимах, жонглировать регистрами (с) и заниматься прочими непристойными вещами. Но давайте сначала разберем и проанализируем ошибки первого моего прототипа такого устройства, но на датчике DS18B20. Первая детская неожиданность Первый прототип состоял из озвученного DS18B20 в металлическом корпусе и МК atmega 328p на плате ProMini с кварцем на 8 МГц. Т.е. это была версия, адаптированная под питание 3.3в. Сперва разберем Схемотехнические ошибки Разумеется, что на плате была проведена операция стабилизатороэктомия, а также светодиодоэктомия. Но для контроля работы интерфейса SPI был оставлен ещё один светодиод - на линии данных. Какой бы небольшой ток он не потреблял, но первый путь утечки тока присутствовал. Как известно, для работы датчика DS18B20 необходим подтягивающий резистор. Был поставлен первый попавшийся под руку и он же рекомендуемый - сопротивлением 4700 Ом (у монтажников-слаботочников отобрал =) ). Это был второй путь утечки тока абсолютно на ровном месте. Как не сложно догадаться, величина этого тока составляла до 0,64 мА при питании напряжением три вольта. Третье. Я никак не выключал свои периферийные устройства. Трансивер nRF24L01+ в режиме PowerDown потребляет до 0.9 мкА, а датчик DS18B20 до 1 мкА, что в сумме дает 2 мкА. Четвертое. Для такого класса устройств DS18B20 вообще не подходит. Абсолютно не интересный диапазон питающих напряжений (хоть у меня он и работал при 2.7в, но это не показатель. Ведь напряжение у литиевой батарейки может проседать до 2 вольт без снижения отдаваемого тока), очень длительный период измерения - до 750 мс, потребляемый ток при этом доходит до 1.5 мА. Программные ошибки Я работал на внешнем кварце 8 МГц при этом никак не снижая частоту. У меня был включен BOD, который останавливал работу МК при напряжении на батарее 2.7в. И вроде как я его программно выключал, но в устройствах подобного класса он не нужен вообще. Тем более, что он и кушает также прилично. Я работал с датчиком DS18B20 в абсолютно дичайшем режиме - все необходимые паузы были организованы с помощью delay_us(), Один только сброс в 480 мкс поднимал с пола озвученные выше 0.6 мА и заставлял МК нопить. Ну и реализация всего протокола общения с этим датчиком реализована в таком же ключе. Это сегодня я бы попробовал реализовать этот протокол через USI или более экономичным способом. А тогда мне было важно всё это дело запустить, ну а оптимизация потом... Работа с трансивером nRF24L01+ была организована по образцу из какого-то проекта. А так как я тогда ещё не умел жонглировать регистрами (с), то кусок кода был выдран из проекта полностью. А трансивер там работал с подтверждением приема, ну и в нагрузку ещё проверялся буфер приемника, хотя никаких данных с пакетом подтверждения я не отправлял (прим. ну разумеется - я ж не умел ещё тогда жонглировать регистрами (с)). Пакеты с данными слались раз в 8-9 секунд (максимальный период вачдога у МК atmega). Для монитора окружающей температуры так часто не нужно. Сам код был написан самым не оптимальным образом несмотря на глубокий сон везде, где только можно. Результат ошибок Всё это вкупе приводило к тому, что литиевая батарейка 123A за почти полтора года проседала с 3.0 до 2.7 вольт. Ну а дальше привет BOD и сушим весла. Такой разряд батареи - это не то, чтобы немного - это даже слишком. -
AREF - внутренний ИОН 1.1в Вот такой код снятия результатов: temp = ADC; if (ADCH & (1<<ADCH1)) // Если значение отрицательное { temp |= 0xFC00; temp = (~temp) + 1; } Value_current_lsb = (uint8_t)(temp >> 2); Никак не пойму - на выбранные дифф. входы надо подать 85 мВ, чтобы АЦП выдал 0. Но это могу списать на внутренний ОУ в виде УГ. Если подаю -1,1 в - то получаю 127. Здесь все верно. Но при подаче положительного смещения те же 127 получаю уже при 0,72в. Что за ерунда? Неужели ОУ на столько УГ? Либо же где-то теряется разряд?
-
Микрофон с Vcc/2 на выходе - есть ли в природе?
parovoZZ опубликовал тема в Справочная радиоэлементов
Ну, собственно, сабж. Питание - от 2.4 и до 3.6. На сигнальном выводе необходима половина напряжения питания (по постоянке, разумеется). -
Не секрет, что адресация глобальных переменных прямая, а переменных в стеке - косвенная. Стек в AVR программный, то бишь откусывается от ОЗУ. Так вот вопрос - при передаче в функцию (и обратно) больших объемов данных (которые невозможно передать через РОН) все же что будет производительнее - через глобальные переменные или через параметры? Понятно, что в функцию вида uint8_t My_super_function (uint8_t data); переменные уйдут через РОН, а вот в такую void My_super_function (uint8_t *data, uint8_t *ret); через стек? Так может ну его нафик, стек этот?
-
Я сейчас про случай, когда тактовая частота SPI равна половине или даже равна тактовой процессора. Соответственно, чем занять МК, пока идет отправка данных? У нас есть всего 16 тактов (или меньше). Обычно идет проверка флага опустошения буфера. Но тогда в чем профит аппаратного SPI, если на том же USI данные отправляются за те же 16 тактов, но МК занят тактированием(!)?. Вот чем занять МК? Отправить в остановку? Так дольше будем подготавливаться к остановке, потом уход на вектор прерывания (4 такта как минимум) и возврат из него. Ежели заниматься чем-то параллельно, то так же теряем время на обработку прерывания. Получается - только тупить в троттлинге?
-
Поставил LUFA, следом абсолютно не нужный мне ASF. Но в упор не понимаю - как создать проект на базе этой библиотеки из студии? Приходится вручную копировать папку с заголовочниками LUFA, прописывать пути в makefile, лишние телодвижения по добавлению папки в свойства проекта. Если я это делаю всё вручную, то тогда для чего это расширение? Примеры я могу и так покрутить. ЗЫ - не слишком высокий скилл в юзании Atmel Studio/
-
Есть у нас функция инициализации какого-то модуля или устройства, либо функция, которая просто возвращает значение регистра. Логичнее эти функции писать в файлах "драйверах", а не в main. Ну хотя бы с точки зрения переносимости кода между проектами. Но сразу появляется вопрос - что удобно программисту, то неудобно компилятору. Смысла в вызове однократно используемой функции или функции с одной командой нет - такие функции разумнее встроить в код. Но вот как быть - inline из другого *.c файла не вызывается, то бишь такую функцию надо писать в заголовке. Но такую функцию можно написать и как макрос (в том же заголовке - макрос в *.c файле тоже не виден али нет?). Так вот меня разрывает внутренняя устойчивая связь - как же поступить?