Что-то, как говорится, либо лыжи не едут, либо...
В общем, не удаётся настроить PB3 в ATtiny45 на вход.
На выход работает нормально, как переключаю на вход, сразу откуда-то берётся 1.75V, соответственно, при опросе, воспринимается, как постоянный "0".
Вроде уж все альтернативные модули принудительно отключил. Ничего не меняется.
При этом, на симуляторе - всё в порядке.
Клок - PLL, но пробовал и внутренний RC.

Наверняка фузы настроены неправильно и PB3 используется как XTAL.

И какими фьюзами, кроме CKSEL, это можно сделать?

Нажмите для просмотра прикрепленного файла

Зачем RESET убил?
Именно ими и преключает альтернативу.
Подтяжку на порт повесить и всего делов

Нужен дополнительный порт (а могут быть другие причины?).

Так и что, при настройке на внутренний генератор, задействуется внешний XTAL?

Что даст подтяжка, если нога на "0" (есть там подтяжка)?

Первые два вопроса было не Вам.

Что на пин подключено?

А кому?


Кнопка, пока разбираюсь.
А вообще - выход с другого МК.
А какая разница?

Артёму


Тогда нормально.

Чего нормального-то, когда "ноль" прёт?

Нога судя по всему в воздухе

Выход другого мк обеспечит на входной ноге Вашего мк единицу а вот кнопка нет.
Если кроме кнопки ко входу ничего не подключено то всё правильно работает.


Похоже нету подтяжки


1.75V это не совсем ноль.

Ребяты! Вы чего?
Как отсутствие подтяжки даст ноль?


Хватает, что б подключаемая линия второго МК всё время определялась, как "0".

Я думаю что : если один из подключенных друг к другу мк выдаёт единицу а другой получает на входе ноль то один из них просто дохлый
попробуйте заменить мк.
отсоедините мк друг от друга и проверьте каждый в отдельности.
Формирует ли первый на выходе 1/0?
Переходит ли линия второго в состояние входа (подключите к ней щуп осциллографа и одновременно прикоснитесь пальцем, должны увидеть некую рваную синусоиду частотой герц эдак 50).

Вы схемку подключения кнопочки не ленитесь показать. И заодно почитайте о не подключенных входах цифровой логики.
Обычно на таких входах наблюдается половина напряжения питания. Но и зависит от типа используемой технологии. Так вот ваше 1.75 прекрасно вписывается в этот постулат.
Кнопка к Вашему сведению имеет 2 устойчивых состояния - ноль и бесконечность. , Сама по себе она питание не вырабатывает.
Два выхода включённых параллельно , являются друг для друга такими же кнопками.
Какой нибудь из этих двух выходов должен сгореть в итоге- деваться то ему некуда и не сбежишь.

Друзья!
Вы прочтите с самого начала.
Как можно спалить порт, что б он на выход нормально работал, а на вход коротил?
И не на одном чипе?

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.: А данный код как-раз и выполняется в прерывании.

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

У 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 портами не являются.

Абсолютную.

В каком смысле "какой"? Они что, разные бывают?

Вы вообще о чём? При чём тут какой-то UART, который где-то работает?

А прочесть пару первых постов?

А и надо, что б он не переключался, а он как-раз переключается.
Впрочем влияние альтернативных функций - одна из версий (о чём писАл не далее, как в предыдущем посте). Если знаете какие-то тонкости настройки, вэлком!

А смысл в этой точности?


Я к тому что UART не требует абсолютной точности, тем более при работе от RC-генератора.
Но к вашей проблеме это мало относится...


Как вы это определяете? Осциллографом? Отладчиком?


Имхо, маловероятно - я не нашёл альтернативных функций которые могут установить DDB3. Есть функции, которые требуют установки DDB3, но тех что сами ставят нет. Фузы могут отключать этот пин, но на вход.

Остаётся ошибка в программе: одновременная запись в разных местах программы или запись в DDRB по неправильному указателю или может ещё что...
Думать что

установит DDB3 в "1" как-то бессмысленно.

Даташит на вашу ATtiny45, стр. 55:
Тут же, кстати, фигурирует и расшифровка аббревиатуры DDR (выделил специально для вас).

Даташит ревизии N от 04.11, стр 205-206:
Ни слова про порт. А вот слово Register вынесено в заголовок раздела.

Во- первых в эррате нет ни слова про то, что "регистр DDR может иногда читаться неправильно" или "команда EOR иногда может работать неправильно".
Во-вторых, "миллионы леммингов не могут ошибаться" и если бы описанные вами ошибки в кристалле имели место - они бы уже были много раз найдены, описаны в эррате, а кристаллы пошли бы в мусорку, ибо с такими дефектами ни одна программа сложнее "мигания одним светодиодом" не могла бы работать.
Вы можете посмотреть хоть Гуглю хоть этот форум на предмет "ошибка компилятора". В 99.9% случаев оказывается, что виноват горе-программист.
Начинающему может быть и понятно, а специалисту хотя бы с небольшим опытом очевидно, что ошибка где-то в вашей программе. Вот уже и конфигурация всплыла... О конфигурации чего вы теперь ведете речь?
Откуда вы такое взяли? Я утверждаю, что если порт переключился на выход, значит кто-то где-то записал единицу в соответствующий разряд DDR. И надо искать кто и где это делает, а не валить все на некорректную работу элементарных команд или узлов кристалла.
При чем здесь вывод RESET? Он у вашей тиньки совмещен с пятым, а не третьим битом порта C. Или вам не нужно найти причину неправильного поведения вашей программы, а важно лишь поспорить, причем совершенно все равно - о чем?
Некоторые могут и не понимать. Хотели открыть нам Истину - не вышло. Для организации выхода типа "открытый коллектор". Весь грамотно написанный программный I2C строится именно так. Неграмотных реализаций полно и в интернете и на этом форуме они всплывали тоже.
Нет, не необходимо. Если это софтовый UART. Достаточно, чтобы длительность каждого битового интервала укладывалась в допуски, т.е. чтобы в конце десятого бита "разбег" между приемником и передатчиком был не более половины бита. Это дает +-2.5% на длительность каждого бита для каждой стороны (+-2.5% для приемника и +-2.5% для передатчика).

Неужели надо объяснять, что погрешности перемножаются?
Зачем, имея погрешность генераторов и линий, накладывать ещё погрешность программы?
Я поставил задачу её исключить.
Разумеется, если кто-то считает, что это - лишнее, может этого не делать.
Но, это - действительно оффтоп.

Давайте рассуждать.
Установлено, что ошибка происходит при считывании данных из регистра DDRB (вместо "0" считывается "1")
Как Вы (и многие другие) утверждаете, где-то в другом месте программы, происходит запись в этот регистр "1".
При этом порт продолжает работать на вход.
Такое может быть?
Впрочем, стопроцентную гарантию обеспечивает только страховой полис, и раз уж Вы (и остальные) так на этом настаиваете, давайте возмём под сомнение в/у утверждение, и подумаем, каким образом данные могут записаться не в тот регистр, в который предназначались?




Это переводится, как: "Портом называется совокупность ног ввода-вывода и связанных с ними регистров PORTx, PINx, DDRx"?

Невнимательно смотрите.
Стр.206: "In Port", "Out Port".
Но, если Вам так принципиально, будем считать, что Вы - правы, и давайте больше к этому вопросу не возвращаться (и так половина оффтопа в теме).

Это Вы к чему?
Если б они там были, этой бы темы и не существовало.

Ну, покажите, где в еррате написанно, что вместе с ресетом надо отключать SPI?
Или где написанно, что для некоторых кристаллов STK-500 меняет функционал выводов?

Вот те раз!
Даже моя программа и то работает, не говоря уже о "миллионах" которые не лезут в такие "дебри".

См. выше.

И вот, что я Вам хочу сказать.
Если Вами движет желание действительно помочь, Вам действительно интересна данная тема, и Вы хотите, что б был диалог, то:
1. Прочтите тему с начала (что б не спрашивать то, о чём сказано в начале)
2. Говорите от себя, а не за "миллионы" (по-моему, так должен поступать любой хомо-сапиенс)
Ваша основная мысль - "ошибка в программе" вполне ясна. Безусловно, я её ещё раз тщательно проверю.
И, если у Вас не возникнет других мыслей, не надо устраивать оффтоп, который, уж извините, я буду просто игнорировать.

Нет. Это вам кажется, что вместо 0 считывается 1. Остальные участники дискусии пытаются вас убедить в том, что 1 считывается именно потому, что он был туда (случайно) записан вашей программой.
Ваше знание классиков делает вам честь. Причин же может быть великое множество. Некоторые из них, связанные с прерываниями, я пытался вам изложить. Не видя исходника гадать можно до потери сознания (однако, боюсь, найдется совсем немного желающих ковыряться в ассемблерном исходнике даже если вы его покажете).
Вы не поверите...

Я понял. Это рудимент с времен i8080, когда адресные пространства делились на "память" и "порты ввода-вывода". И тогда действительно периферийные устройства подключались к процессору как устройства ввода-вывода и адресовались только командами IN и OUT. Сейчас же "смешались в кучу кони, люди" и используется более общее название "регистры специального назначения". Портами же принято называть нечто, "торчащее ногами наружу". И именно в таком ключе написана вся остальная документация на контроллер.
Это я к тому, что если бы был повод, то они бы там были. Просто по теории вероятностей если бы такая ошибка существовала, ее уже давно нашли бы. Если бы вы работали с инженерными образцами кристаллов - такую возможность можно было бы допустить, но в этом случае вы бы писали не сюда, а непосредственно в Атмел по прямому каналу в отдел разработок или как он там называется (в свое время я писал подобные письма в Texas Instruments по поводу первых образцов флешовых MSP430).
Оппа... Давайте вы изложите проблему более подробно, я распаяю в макетку имеющийся у меня ATtiny85 и мы попробуем разобраться с этим вопросом отдельно. У меня есть некоторая уверенность, что все не так страшно, как вам кажется.
Простите, а что здесь дебри - команда "Исключающее ИЛИ" или чтение регистра DDRx?

Спорю на пиво. Перешлю вам 1.5л красного имбиного Ingver Alus, если виноватым окажется не ваша программа. Если же ошибка в программе - вы мне пересылаете 1.5л вашего хорошего нефильтрованного. Принимаете?

Почти Ваша правда. "1" не считывается, но дело действительно было в программе.

Не поверю.

Это "рудимент" терминалогии Атмела, которые выделили их в отдельную область и назвали "I/O Register"

Так может и нашли, но я не читал.

Проблема 1: При отключённом Ресете, но включённом последовательном программировании, на в/у PB3, если он настраивался на вход, висело 1,75V. Сегодня опять попробовал, но всё заработало нормально (экспериментировал со старой программой, ещё до того, как исправил). Поэтому остаётся записать в "загадки".
Проблема 2: STK-500 не хочет программировать ATtiny 2313a по HVPP
Проблема 3: Для некоторых кристаллов, в STK-500 меняется функционал выходных портов. Проблема решена переделкой адаптера.
Проблема 4: При использовании конвертера USB-COM, необходимо устанавливать Jungo, иначе Студия не видит STK-500 (как программатор), хотя может заливать прошивку в сам программатор.

Отключение Ресета, да и вообще высоковольтное программирование. Правда "дебри", наверное, не совсем правильное выражение.

Поздняк метаться.
P.S.: Кстати, пива не жалко и так, но вот с пересылкой, это - такой гемор.