Harvester

Хочу использовать Tiny13, задействовав все его ноги под I/O. После прочтения документации сложилось впечатление, что низковольтное ISP при выключенном RESET-е невозможно. Это действительно так?

Аналогично буквы L, разница только в техпроцессе, который позволяет такие чипы тактировать до 20Mhz. Чипы без "V" способны работать в диапазоне 2.7-5.5V на граничных частотах 18-20Mhz, а если их тактировать частотой меньше 10Mhz тогда можно смело пользоваться диапазоном серии V (1.8-5.5). На практике, чипы без V (тактируемые 9.6Mhz) устойчиво работают при питании 1.4-1.55V. Вообще-то из графиков следует, что "V"-чипы при 5 В работают также, как и обычные, без "V"

Есть контроллер, скажем, ATmega64L. На первой странице datasheet написано, что ATmega64L-8 - Vcc = 2.7...5.5 V, 0...8 MHz. А в электрических параметрах (частота внешнего clock)указано, что при Vcc = 2.7...5.5 V, f = 0...8 MHz, а при Vcc = 4.5...5.5 V, f = 0...16 MHz безотносительно к исполнению МК. Вопрос - можно ли серийно использовать 64L 16 MHz при 5 V или нет? В новых моделях макс. частота указана явно для каждого интервала Vcc, почему и возник вопрос.

А не проще в самом издательстве (Додэка XXI) купить? Если заказать доставку по почте, то и родственников напрягать не надо.

Вообще-то с IAR-ом библиотеки для работы с разной периферией не поставляются. Могу посоветовать библиотеку AVRlib (). Потребуется только немного доработать исходник под иаровский компилятор.

Начинаю осваивать ARM LPC2000 Скомпилировал в uVision пустую функцию main() (с одним while(1)), используя разные компиляторы. Результат: Keil CARM около 400 байт, RealView - более 1 К. Как я понимаю это размер голого стартового кода. Почему такая разница, можно ли уменьшить (для RealView) и есть ли вообще у RealView какие-либо преимущества по сравнению с CARM?

Выбираю микроконтроллер для нового проекта. Нужен высокоскоростной UART (не менее 0.5 Мбит/с) + высокая производительность + минимально возможная цена. Пока остановился на LPC2101. В доках на LPC2000 пишут, что при Pclk=20 МГц можно получить ~0.5 Мбит/с. А будет ли блок UART работать на 60 МГц, что теоретически даст 1.5 Мбит/с? Кто-нибудь гонял его при такой частоте?

Спасибо! В общем-то я так и предполагал, но мне казалось, что 23 бит мантиссы достаточно для 4-х знаков после запятой.

Впервые использовал float и возник следующий вопрос. Берем число (от фонаря): -362.0927, в HEX - C3B50BDE пересылаем эти байты по UART в PC, получаем -362.0927124 (программа на Visual C++). Это нормально? Вроде бы формат хранения float в обеих компиляторах один и тот же (IEEE), тогда почему отличаются числа?

Dars Так и надо писать, правда вместо чисел лучше использовать константы.

Возможные причины: 1. в терминалке на ПК установлены другие параметры 2. Неправильно прошиты FUSES, из-за чего AVR работает не на 4 МГц => скорость не 9600

Спасибо всем :cheers: Проблему решил, уменьшив длину кабеля между платами АЦП и контроллера.

При чтении проверяется сигнал /DRDY, так что это маловероятно. К тому же описанный эфект проявляется случайным образом. Иногда не проявляется вообще (тестировал весь рабочий день). А исходники - пожалуйста, во вложении (IAR C для AVR). Функция ReadADCdata вызывается раз в секунду в фоновом цикле программы. read_ad7714.txt

Микроконтроллер последовательно считывает данные со всех трех каналов АЦП. Все работает замечательно, но иногда АЦП начинает по какому-либо каналу (а то и не по одному) выдавать одни 0xFF независимо от входного сигнала. Момент совершенно непредсказуемый, пеерзапуском питания лечится не всегда. Кто-нибудь встречался с такой проблемой? PS При работе только с одним каналом как в datasheet - никаких проблем.

Микроконтроллер последовательно считывает данные со всех трех каналов АЦП. Все работает замечательно, но иногда АЦП начинает по какому-либо каналу (а то и не по одному) выдавать одни 0xFF независимо от входного сигнала. Момент совершенно непредсказуемый, пеерзапуском питания лечится не всегда. Кто-нибудь встречался с такой проблемой? PS При работе только с одним каналом как в datasheet - никаких проблем.