vladimir_orl

Обвязка вся отключена.

Я думал, что он всегда включен. Спасибо, попробую. Там ещё входы MISO MOSI и DI DO, там они совпадают. Вообще tiny2313 шьётся через USI или SPI? Или это только меги шьются через уси?

STK500. Программирую с разъёма ISP6PIN. Для tiny2313 больше никакая обвязка не нужна? SS на землю посадить не надо? Т. е. шьём tiny2313 через STK500, разъём ISP6PIN. Все 6 проводов - с разъёма. Вот MISO не отвечает. МК вроде как живые. Или кварц нужен? Для SPI вроде без кварца... Мы без кварца. Там в плате свой источник питания для МК на 3.3 вольта. Поначалу думали, что из-за того что не совпадают уровни напряжений (у ISP 5 вольт). Потом ИП отсоединили, подали питание с STK500. Тот же результат.

Всем здравствуйте. Если можно, киньте ссылку, как происходит процесс ISP для микроконтроллеров AVR (с картинками, т.е. осциллограммами). Жёлтый - MOSI Фиолетовый - MISO Зелёный - RESET Синий - MOSI Вот что-то MISO не отвечает. Думаем, либо мк не рабочий, либо ещё что. Есть документ AVR910, но что-то там немного не то.

Здравствуйте. Столкнулись тоже с проблемкой. Не шьётся Tiny2313 в ISP режиме. Шью с STK500 с разъёма ISP6PIN (AStudio 4.19). Смотрю осциллографом. Первоначально все сигналы в "1". Затем падают в 0, через некоторое время клоки и MOSI приходят, MISO не отсылается. Так и продолжает в "1" оставаться. Соответственно студия отвечает - нет коннекта. Что это может быть? Дохлые микросхемы? Но вроде в кз не уходят. Там MISO и MOSI надо правильно подключать? Жёлтый - MOSI Фиолетовый - MISO Зелёный - RESET Синий - MOSI Насколько я понял, в STK500-м линия MISO подтянута к VCC (VTG). А мк её придавливает? Или киньте ссылку как происходит процесс программирования. А то в инете на нашёл, если можно с диаграммами напряжений.

Включил максимальную оптимизацию - всё заработало. Да, похоже на будущее придётся ассемблер вспоминать. Всем спасибо за помощь.

Спасибо. Там код-то всего - 100 строчек. Программная реализация модифицированного SPI интерфейса. Попробую. И опять-таки остаётся проблемка. При включенной оптимизации в дебагере сдвигаются строки.

Нет, оптимизацию не включал. Когда включаю, быстрее работает. Но в дебагере при этом строки сдвигаются, нет возможности пошаговой отладки. Или это надо настройки какие-то ставить. Если знаете, подскажите. Как я понимаю, в AVR студии по умолчанию переменные в ОЗУ хранятся. И такты тратятся на их извлечение из ОЗУ, обработку, и запихивание обратно. Помню, переменные как-то можно register объявить. Чтобы всегда в регистрах были. Тем более что их не очень много (около 20).

А подскажите, какие типы по скорости бывают. К примеру, код: m_camera_byte <<= 1; m_lens_byte <<= 1; требует в AVR Studio5 на выполнение 40 тактов. Типы объявлял и как volatile unsigned char и как просто unsigned char. Почему-то компилятор упорно хранит из в ОЗУ. Пытался объявить их как register, компилятор ругается, что не знает такого типа.

Здравствуйте. Пишу программный эмулятор SPI (mega128) с использованием внешнего прерывания EINT2. Номер режима SPI - 3, прерывание настроено по фронту. Вначале включение-отключение программного блока происходило управлением переменной ISR (INT2_vect) { if (m_enable_collect == TRUE){ .... .... .... { } Всё работало. Но для ускорения и снижения накладных расходов на проверку переменной решил управлять с помощью выставления и снимания бита в EIMSK. if (m_SPI_start){ EIFR = 0; EIMSK = (1 << INT2); } else { EIFR = 0; EIMSK = 0; } Столкнулся с такой особенностью, что теперь при включении EINT генерится одно лишнее прерывание в самом начале. Возможно потому что линия уже в единице. Оно может и не лишнее, но нежелательное. Подскажите, можно ли обойти его хардварными способами. Программными можно, но тогда по быстродействию не пройдём. 1. До

Вот тоже по долгу службы занимаюсь этим вопросом. Вот что узнал. В конце посылки из 8 бит мастер переводит линию LCLK в 3 состояние для того чтобы слэйв со своей стороны сигнализировал об ошибках поднятием этой линии в 1. Так что переход в 1 после перерыва - это просто мастер снова выставил 1 на тактовой линии.

Да. Здесь я нашёл ветку. Там это тоже есть. В частности Но вот мне надо эмулятор объектива сделать. Пробовал пропускать 9-й такт и читать данные без него - всё равно белиберда. Наверное, это в схеме надо что-то подправить, т. к. в протеусе всё работает. И насчёт подтяжки тоже не совсем понял. Сигнал 1/0 формируется слэйвом или подтяжкой линии MISO к vdd? А слэйв только как открытый коллектор работает?

Вот у меня есть, если интересно: Список поддерживаемых команд (все команды в шестнадцатеричном виде) Название, описание. Длина Байты Нулевая команда. 1 00 Повтор изменения значения диафрагмы. 1 02 Повтор изменения значения диафрагмы. 1 03 Переход в положение "минимальный AF". 1 05 Переход в положение "максимальный AF". 1 06 Инициализация. 1 0A Закрыть/открыть диафрагму на XX шагов. 1 12 XX Переход в положение "максимальный AF". 1 16 Информация об объективе. 7 97 01 Получить мин/макс значение апертуры 4 B0 Текущее значение увеличения 2 A0 Закрыть/открыть диафрагму на XX шагов. 4 07 13 XX Открыть диафрагму (полностью). 2 13 80 Относительное значение положения двигателя автофокуса. 1 C0 Подвинуть объектив на ХХ шагов. 1 44 XX XX Включить ручное управление. 1 5E Информация о модели объектива. 1 80 Относительное значение двигателя автофокуса. 1 С2 Положение переключателя AF/MF. 1 90 Информация об объективе. 1 CA Переход в бесконечность. 1 25 Переход на отметку 2,5 м. 1 16 Получить значение апертуры 1 01 Вдвинуть объектив полностью 15, 25, 45, 55 Выдвинуть объектив полностью 16, 26, 46, 56 Да, хотел сказать клок. На днях как раз написал анализатор (монитор) протокола обмена. Железо - VS2010 + STK500 + mega128. Там игнорирую 9-й бит (у меня биты определяются по фронтам). Мне кажется, этот 9-й проверочный цикл всё же можно рассматривать как 9-й бит. Однако выдаётся белиберда. Однако, если просто управлять объективом CANON, то всё получается замечательно, даже без учёта этого проверочного бита. А объектив CANON знает когда ему можно подавать ответные сигналы? Просто по времени определяет? А клок притянут к земле? И, насколько я понял, в MISO тоже стоит подтяжка. Я поставил 4 кОм между MISO и питанием. Даже не знаю, правильно ли. Но работает. И скажите про логику ошибок. Они камерой рассматриваются как фатальные? То есть, если объектив выставил "1", то дальше работать нельзя, или посылаются другие команды?

То есть ему (объективу) даётся этот промежуток времени, чтобы он мог сигнализировать об ошибках? Так у объектива (слэйва) MOSI должен быть всегда настроен на вход. Или он на это время переключает его на выход?

Здравствуйте. Вот встретил в даташите на одно устройство упоминание, что оно использует SPI-протокол обмена "в третьем режиме с одним стоп-битом". Про третий режим всё понятно, а про стоп-биты в SPI слышу впервые. Может кто подскажет, что это такое и где почитать можно?

Вот нашёл в инете: (http://dangerousprototypes.com/forum/viewtopic.php?t=695) The pinout is known, we can connect to a camera and lens using a hacked mount adaptor, and we know the protocol uses "8-data-bit, 1-stop-bit SPI (mode 3)". I have a small amount of experience with AVR microcontrollers (some years ago) and have done a bit of amateur level software engineering. На объектив, действительно подаётся по 8 бит, как написано, и всё работает. Посылал данные согласно документам, описанным в "Автономное использование объективов Canon EOS". Но смотрел на осциллографе обмен тушки с объуктивом, там вот такая картинка: Зелёный – MOSI Розовый - MISO Жёлтый – CLK Размер по времени: 50 мкс в клетке. Т. е. присутствует 9-й такт. Я его пока просто игнорирую.

Да. Только как выяснилось, у кэнона протокол обмена по SPI включает ещё дополнительный, 9-й бит.

Да. Но тут вот такие девайсы. И надо программно монитор протокола написать. Буду все фронты, которые пришли после паузы больше чем 8 тактов, считать начальными. Тогда будет наложение данных от первого, настоящего фронта на последний, ненастоящий.

И ещё вопрос интересный. Если писать программный SPI для третьего режима. Там ведь захват данных по фронту клока. А когда мы включаем SPI, мы тоже выставляем на клоке единицу как начальное состояние. Если мы пишем монитор данных, как мы отличим фронт начального состояния от "рабочего" фронта? И ещё вопрос интересный. Если писать программный SPI для третьего режима. Там ведь захват данных по фронту клока. А когда мы включаем SPI, мы тоже выставляем на клоке единицу как начальное состояние. Если мы пишем монитор данных, как мы отличим фронт начального состояния от "рабочего" фронта?

Да, спасибо. Я и говорю, что это один из вариантов реализации SPI. Я вот просто думаю, зачем разработчики это всё сделали. Или это выдержка минимальной необходимой для слэйва паузы или так клоком какой-то управляющий сигнал для слэйва передаётся. Хотя может сам слэйв линию клока захватывает. Аналогично как в I2C.

В обрывках документации пишется про 8 битные данные. Насколько я знаю, в 3-м режиме данные читаются по фронту.

Жёлтый – CLK Розовый - MISO Зелёный – MOSI Показано начало обмена, пока ещё слэйв нули выдаёт. Линии "чипселект" там нет. Поскольку мастер и слэйв "заточены" друг под друга.

Жёлтый - это как раз сигнал клок. Видно, что после меандра идёт ещё спад длительностью равный примерно один байт.

Здравствуйте, уважаемые форумчане. Опять куча вопросов про SPI. Точнее про одну из реализаций. Сейчас разбираю, как общаются два устройства (собственно мастер и слэйв) по SPI в третьем режиме. Особенно заинтересовал сигнал Clock. Начало понятное - вначале 1, затем происходит спад с 1 на 0, затем восемь фронтов с 0 на 1. Так вот, там есть ещё один цикл, девятый, по длительности примерно равный всему байту. Фото осциллографа - в пристёжке. Это что - сигнал самосинхронизации? И как его учитывать, если я хочу написать программный слэйв? У меня сейчас сделано определение начала по длительности сигнала, когда 1.

Спасибо. Обрадую себя и вас. AVRStudio5 его тоже поддерживает. Tools->add STK500 (v 5.1.208).