Birden

Тогда все-таки придется применить 4-битное подключение индикатора.

Насчет тегов: если пассивные теги обеспечать устойчивое их считывание на заданном расстоянии (1 - 1.5м), то ради бога. С этим все более-менее понятно. Тогда все сводится к проектированию считывателя. Например, как указали выше, на базе EM4298. Но что-то поиск по ней мало что дает. Где ее вообще можно купить, хотя бы для пробы. По поводу бюджета еще раз: как только я увижу предложение, которое меня устроит (без раздувания объемов, как это было сделано выше), так сразу же разговор пойдет и о бюджете.

И тем не менее. Сначала хотелось бы услышать предложение, а потом это предложение можно и оценить.

Зависит от предложения :rolleyes:

Не самое главное на данный момент. Главное - принципиальное решение.

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

Требуется разработка (либо посильная помощь советом) системы бесконтактной идентификации. Система должна состоять из двух частей: 1. Пассивная метка. Либо активная (с элементом питания), но с достаточным сроком службы, не менее 1 года. К ней требования простые - минимальные габариты. 2. Считыватель. Идеальным вариантом будет что-то типа готовой платы с приемником для "встраивания" в другую систему посредством какого-либо интерфейсе (UART, SPI, I2C...). Дальность считывания метки - 1-1.5м. Больше - не нужно, даже навредит. При считывании метки он должен передать код метки по внешнему интерфейсу. Периодичность опроса меток - до 10 раз в секунду. Тут тоже требования по габаритам - конечный прибор с этой платой предполагается сделать не обременительным для постоянного ношения его человеком. За доп.вопросами прошу в ЛС.

Кстати, не подскажет ли кто-нибудь, как прикрутить какой-нить arm-gcc тулчейн к codeblocks? Желательно подробнее. Сколько раз пытался это сделать - не выходит никак, вылазят ошибки при компиляции.

По какой причине не получилось? Что было написано в "ответе"?

Если Вы про командную строку, то какие проблемы? Я пользуюсь bat-файлом, который запускаю из-под CodeBlocks. Что-то типа такого: "C:\Program Files\Atmel\AVR Tools\AvrDragon\avrdragon -cUSB -datmega64 -e -i%1.hex -pf -vf%1"

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

Могу посоветовать "средство" - Winavr, или его нынешнее развитие - AVR Toolchain. Это компилятор, IDE к нему каждый выбирает по себе. Я, например, использую CodeBlocks. Еще одно необходимое "средство" - документация (datasheet) на используемый МК. Если Вы планируете и дальше заниматьсся решением подобных задач, то это должно стать вашей "настольной книгой" первое время. По поводу примера программы: любую задачу можно попробовать начать решать с составления алгоритма. В данном случае, это можно представить так: 1. Настройка захвата - выбор типа фронта, вкл. или выкл. шумоподавителя, прерываний (если нужно) 2. Настройка соответствующего таймера (выбор режима и т.д.) 3. Сброс флага захвата 4. Включение захвата 5. Ожидание флага захвата, старт таймера. 6. Сброс флага захвата 7. Ожидание флага захвата, чтение результата. Это примерный алгоритм, для начала. В качестве оптимизации можно добавить некоторые моменты: старт таймера перед включением захвата, чтобы по приходу первого фронта знать содержимое таймера; организация что-то вроде конечного автомата для измерения некоторого числа периодов (для усреднения) и т.д.

Да, полностью согласен с Вами, Палыч. Почему-то думал, что этот программатор только для AVR. Хотя вполне логично было бы предположить, что могут поддерживаться все атмеловские чипы с ISP. По теме: мне тоже не нравится использование в схеме катушки индуктивности. Может стоит посмотреть, что происходит на входе генератора?

Reset у AT89S52 активный высоким уровнем, а у AVR - низким. Может быть в этом дело?

Вариантов реализации 1-Wire довольно много - выбирай любой. И ждать там совсем незачем, принцип простой: раз в секунду (например) прочитали температуру, потом сразу же отправили команду на преобразование. К следующей секунде преобразование как раз будет готово. А вообще, прерывания там желательно запрещать только на время приема/отправки одного бита.