Читаю неделю на английском ничего не могу понять. Т.е. читаю назначение битов USICR - почти понятно но не работает. Перебрал комбинации - сим авр студии не показывает сдвижки данных в регистре USIDR.
Собственно нужно организовать обмен с ат45дб011.

USICR=0x13;

unsigned char spi(unsigned char data)
{
USIDR=data;
while ((USISR.USIOIF)==0)
{
PORTA^= (1<<SCL);
}
return USIDR;
}
Пробовал колбасить биты USICLK или USITC, сим показывает перепады на порту А, но сдвижки в усидр нет, флаг - молчит.
Помогите кто может... Вообще объясните, это просто "набор железа" для программной реализации или как? На аппаратную реализацию спи в мегах ну никак не похоже...

В даташите же есть пример. Зачем самодеятельность с PORTA^= (1<<SCL)?




Типа да.

Кстати. Совсем не факт, что студия симулирует USI правильно.

Дело в том, что пробовал и такой вариант, но в симе и, если Вы правы, сим действительно не симулирует уси... Завтра попробую в "железе".
Т.е. получается что скорость обмена - скорость с которой я могу крутить цикл? Тогда смысл прерывания по окончании передачи? Если я не могу аппаратно задать скорость, а обязан каждый обмен программно обслужить... Непонятно. зачем такие порты? Это вопрос не к вам, а так, вопрос, риторический , разработчику... Странно это как-то...

посмотри AVR319 - Using the USI module for SPI communication
Там для реализации SPI используют прерывание по таймеру. То есть в прерывании тупо генерируют фронт методом записи USICLK в USICR. А смысл прерывания по окончании передачи в том, чтобы не заводить отдельную переменную на подсчет фронтов.
Максимальной скорости обмена с такой реализацией не добиться.

P.S. Посмотрел описание Tiny24 - там и прерывание можно не использовать. Просто в качестве Clock Source выбрать Timer/Counter0 Compare Match. Но большИх скоростей при этом не добиться

#include <tiny24.h>

#define USIOIF 6
#define USITC 0
#define USICLK 1
#define USICS0 2
#define USICS1 3
#define USIWM0 4
#define USIWM1 5

#define SCL 4

unsigned char spi(unsigned char data)
{
USIDR=data;
USICR = (1<<USIWM0) | (1<<USICS1) | (1<<USICLK);
while ((USISR.USIOIF)==0)
{
USICR| = 1<<USITC;
}
return USIDR;
}
void main(void)
{

PORTA=0x00;
DDRA=0x50;

USICR=0x13;

while (1)
{
spi(0x55);
};
}


прочитав авр319, написал вот так, результат - 0... Висят "1" на моси и сцл и всё.

Атмеловцы ввели всех в заблуждение, оставив обозначения на ногах MOSI и MISO. На самом деле в 3-проводном режиме пин DO(MISO) всегда работает как выход (несмотря на то, что "master in"), а DI(MOSI) - на вход. Видимо, этими обозначеними (miso,mosi,sck) следует пользоваться только для подключения программатора.
Поэтому DDRA=0x30,
РА5/DO/MISO - выход
РА6/DI/MOSI - вход (не забудьте перепаять провода )

А "1" висит на сцл потому, что перед началом обмена нужно очистить флаг USIOIF. В вашем случае начиная со второго вызова spi() цикл внутри while ((USISR.USIOIF)==0) выполнятся не будет, соответственно, и на сцл Вы ничего не увидите.

Раньше такая очистка у меня работала, сейчас в симе аврстудии флаг устанавливается в "1" и цикл обходится...

USICR = (1<<USIWM0) | (1<<USICS1) | (1<<USICLK);

USISR|= 1<<USIOIF;//очистка флага

while ((USISR.USIOIF)==0)

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

Не, ну я расстроен, наглухо. ат45дб отлично стыковалась по ногам и для работы и для программирования, а теперь? программить микруху, а потом перебрасывать перемычками ноги? Ёлки-палки, их же 60 штук, плат... Неаккуратненько... придется вернуться на мегу48 или всё-таки программно слепить spi.

симулятору я обычно не доверяю. Да и в хелпе по симулятору написано, что "Simulation of TWI, USI and analog peripheral is not yet implemented."

"The clock is generated by the Master device software by toggling the USCK pin via the PORTA register or by writing a one to bit USITC bit in USICR."
То есть при записи "1" в USICR.USITC физически изменяется значение в регистре PORTA.PA5 на противоположное. Такого же эффекта можно было бы добиться, записав "1" в PINA.PA5. Но в первом случае программа не будет привязана к контроллеру (в меге169, например, USCK на пине E6)

PS Атмеловцы рекомендуют вместо
USISR|= 1<<USIOIF;//очистка флага
писать
USISR = 1<<USIOIF.
Отличается от предыдущей очисткой счетчика фронтов.


А почему сразу их не перебросить, до программирования?

Если перебросить ноги "до", тогда нужно будет перебрасывать првода от программатора, в одном положении программить тиньку, перебросив провода - ат45. В любом случае надо делать телодвижения. с мегой48 всё было как по нотам, написано "моси", так оно моси и для программирования и для работы... Ну уже почти готов софтовый вариант спи...
Спасибо за разъяснения по тактированию.

Если писать SPI только под АТ45, то дело значительно упрощается. Для нее полного варианта SPI не нужно. Там нет операции записи в AT45 c одновременным чтением данных из нее. Т.е. запись - отдельно, чтение - отдельно.

При передаче с контроллера одного бита, один бит приходит от ат45 или любого другого устройства, т.е. прием-передача как раз одновременно. Это моё мнение, регистры данных двух устройств закольцованы... Или нет?

Да, но при передаче в AT45 байтов команды, адреса и записываемых данных можно игнорировать передаваемые из неё байты, а при чтении из неё данных (уже после передачи последнего байта адреса) - можно в неё писать что угодно, в том числе все нули или все единички.
Я бы не сказал, что это "упрощает" написание программного SPI, вместо одной простенькой функции
надо писать две столь же простеньких
однако обмен по второму варианту будет быстрее.

Читаю эту тему. И возникает вопрос.
Вот для режимов когда вначале читаем, затем сдвигаем всё просто.
А для режима когда вначале сдвигаем, затем выставляем - ка-то всё запутанно получается.
А всё потому, что в настоящем SPI есть дополнительная защёлка, а в USI её нет.
И самый старший бит уже "виден" наружу. И когда мы пытаемся сдвинуть байт, этот бит уходит.
Думал-думал. И реализовал просто программный SPI.
Кстати, в протеусе USI нормально эмулируется.

Вот, может быть, здесь чё-то полезное почерпнёте. Только там пример для 2313.

И все-таки (уж извините за тупость) как в реале обстоят дела?
PA6(вход) предполагается входом данных
PA7(вход) используется как приемник ~SS, при появлении 0 по прерыванию проводит инициализацию по даташиту:
ldi TM,(1<<USIWM0)|(1<<USICS1)
out USICR,TM
Остальные биты порта А = выходы.
Далее написанная херня исполняется прилежно:
ldi TM,(1<<USIOIF)
out USISR,TM Установили флаг
SlaveSPITransfer_loop:
in TM,USISR Его же тут же считали
sbrs TM,USIOIF Сравнили с самим собой
rjmp SlaveSPITransfer_loop
И вышли из цикла
В симуляторе никаких флагов не появляется, чтоб его обнулять,
тыканье в PinA,4 (сформирован на выход, используется как slave-CLK ) изменений 4х разрядного счетчика (USICNT) не вызывает,
ручная установка-обнуление счетчика флагов не вызывает ...
И где тут сАбака зарылась?!
Симулятор вообще симулирует в этом случае что-то?

Заглядываем в нелп студии ищем свой проц и смотрим симулирует или не симулирует сей проц симулятор ( если я отгадал , что он работает в студии и у него тинька - записывайте меня в телепаты)))

С одной стороны ты больше чем телеПат, ты телеМат - таки Студия.
А с другой стороны - в заголовке Atiny24 - угадать не трудно.
В любом случае - спасибо за внимание.
В Хелпе про SPI только то, что двойная скорость не поддерживается.
У меня не может быть мудреной заморочки.
Я, как всегда, где-то недочитал всем-гуру-известную хрень, про которую и спрашиваю.
В USIDR значение записывается, но на симуляцию внешнего USCK/SCL тыканьем мышкой в РinА,4 биты не сдвигаются , USICNT не реагирует, при его установке и обнулении флаг переполнения не выставляется ...
Явно что-то где-то не включил....

Добавлено : Все-таки ты помог!
Я обратил внимание, что Хелп все больше про Симулятор2, а у меня в Студии просто Симулятор, а он сцука SPI не симулирует.
Симулятор2 сработал нормально!
Не попадайтесь!

Честно говоря , это настолько избитая тема связанная с симулятором , что и отгадывать было нечего.