1. Чем меряете 1.75V ?
2. Есть ли кроме PB3 еще входные пины? они работают?
3. Что Вы хотите что бы на этом пине было? (1.75V, как я понимаю, Вас не устраивает). а чего нужно то?
4. Может схемку приведёте для более конкретного разговора?

1. Тестером/осциллографом
2. Есть. Работают.
3. Нужно, что б он работал входным портом, и принимал сигнал с другого МК, а не коротил его выход.
4. Кроме чипа ещё последовательный резистор на выходном порту. Рисовать?

Как хотите. А резистор зачем? и какой его номинал ?

Если после выполнения всех необходимых манипуляций (описанных в DS) с регистрами связанными с пином для перевода его в состояние входа этого не происходит.
Значит надо спрашивать у производителя.
Эх, был бы у меня такой мк я обязательно проверил бы.

В двух словах: так надо.
Потому что данный каскад управляет токовой петлёй. Номинал его 220Ом.
Только какое отношение это имеет к входному пину?

Так в этом, собственно, и главный вопрос.

Дальнейшие эксперименты показали, что, помимо RESET'а надо ещё отключить и последовательное программирование.
Но это ещё не всё.
После выполнения следующей последовательности:
1. Корректируем бит 3 (и другие, разумеется) в регистре R16 в "0"
2. Копируем порт DDRB в регистр R18. Бит 3 был настроен в "0"
3. Производим побитное XOR регистров R18 и R16 (с сохранением в R16). "0"+"0"="0"
4. Копируем регистр R16 в порт DDRB.

"0" почему-то становится "1", и порт, соответственно, переключается на выход.
Команда

после п.2 решает проблему, но хотелось бы понять, почему, в в/у пункте, вместо "0" считывается "1"?

Всегда? Подозреваю, что иногда. И что в программе используются прерывания. И что не все регистры корректно сохраняются/восстанавливаются в прерываниях.

Напрасно подозреваете.
После включения - вход. Первая же посылка - сразу "сваливается" на вывод.

Это вопрос или утверждение?
В любом случае: Прерывания используются. Всё сохраняется корректно (как бы, в противном случае, программа работала).

То есть вы утверждаете, что в вашем конкретном кристалле неправильно работает команда EOR? Как говорил в таких случаях великий Станиславский: "Не верю!". Приведенный вами в сообщении №20 код не может изменить состояние третьего бита DDRB. Значит каким-то образом портится либо содержимое DDRB до выполнения этого кода, либо содержимое R16 или R18 во время выполнения этого участка. Испортить регистры могут только прерывания. Как работает при этом остальная программа - загадка, но такое случается

Вы хотели версий - я дал одну.

Конкретных двух кристаллах из разных партий, и разных корпусах (см. предыдущие посты).

Поскольку неправильное выполнение команды EOR, как и порча содержимого регистров, маловероятно, напрашивается вывод, что неправильно считывается содержимое порта DDRB (это, кстати, вовсе не означает, что его содержимое испорчено).
Так вот, и хотелось бы услышать гуру, почему такое происходит?

P.S.: А данный код как-раз и выполняется в прерывании.

Сообщение отредактировал Dmitry Dubrovenko - Jun 12 2013, 13:24

Тем более.
Это не порт. Это регистр направления. Внутренний регистр. Вероятность его порчи по аппаратным причинам ничтожно мала.
Вот может это прерывание происходит во время доступа к этому же регистру из основного цикла? В этом случае надо в основном цикле обращения к этому регистру (как и к любой другой разделяемой переменной) выполнять при запрещенном прерывании.

У AVR это называется именно "порт", с использованием соответствующих инструкций.

Повторяю ещё раз: Неправильное считывание вовсе не означает повреждения регистра.

Не происходит.

Как-то сложно всё у ваc в 20м сообщении.
Нельзя просто записать константу в DDR? По приведённому куску кода я вижу инверсию ЧЕТВЁРТОГО бита DDRB, если он был "1" в r16 до "andi r16". А третий (и все, кроме четвёртого) бит в DDRB не изменился.

Портом называется совокупность ног ввода-вывода и связанных с ними регистров PORTx, PINx, DDRx. А отдельно взятый DDRx - регистр специального назначения (Special Function Register, SFR).
Ну продолжайте бороться с ветряными мельницами. Заметьте - вы первый за почти 20 лет существования AVR нашли в них такую особенность. Или смотрите питание - какой там должен быть ужас, чтобы сигнал добегал с искажениями из одной части кристалла до другой? Опять же, питание маловероятно ибо стабильно только один сигнал и на нескольких разных кристаллах. Ищите в консерватории своей программе.

P.S. да, когда найдете причину - не забудьте сообщить ее здесь.

Ссылочку на источник, плиз.
А по-моему, логичнее называть "портом" то, для чего используются команды работы с портом (см., например, даташит на ATtiny 25/45/85, стр.206).

Я Вас умоляю!
Если Вы не сталкивались, не надо за всех говорить.
Одних ерратов сколько вышло.
Посмотрите Гугль по теме, типа: "не программируется 2313a по HVPP", или ещё чего-нибудь, узнаете много интересного.

Чё ж у Вас за решения каие-то всё "координальные". По-моему, уже самому начинающему должно уже быть понятно, что, если это не глюк/особенность чипа, то - ошибка конфигурации. Или Вы хотите сказать, что одной строчкой в программе можно убрать помехи по питанию?

Вы хотите сказать, что в порт регистр DDRx можно записать "1" и он не переключится на выход?

А это надо? У всех же всё и так работает.
И вообще, найдите хотя бы пяток человек, которые Ресет отключают. А некоторые об этом и не знают.
Некоторые также не понимают, зачем выводить информацию в DDRx, а не в PORTx.


Не совсем так. Там возможны четыре варианта:
1. Бит в DDRB был "1", в r16 - "1" --> бит в DDRB инветртирутся.
2. Бит в DDRB был "1", в r16 - "0" --> бит в DDRB не инветртирутся.
3. Бит в DDRB был "0", в r16 - "1" --> бит в DDRB инветртирутся.
4. Бит в DDRB был "0", в r16 - "0" --> бит в DDRB не инветртирутся.
Это сделано, что бы исключить джиттер.
Поскольку это - софтовый UART, необходимо, что б все смены уровней происходили через одинаковые интервалы, поэтому все ветки программы (включая вход в обработчик прерывания) выровнены и оптимизированы по времени.

ДОЛЖЕН не изменяться, но почему-то (без принудительного сброса) меняется.
В этом собственно и суть вопроса.

И какую точность удалось получить с помощью "выравнивания" программы?


Какой джиттер? UART от 1-2% RC-генератора работает без проблем.
От чего у вас кстати МК тактируется?


Если альтернативная функция порта задействована, то может и не переключится.


По такой логике, к примеру, PORTG и PORTF mega128 портами не являются.