Всем доброго дня.
Завожу MRF24J40. SPI.
Аппаратного CS нету, вылезаем софтверно.

Ногу CS опускаю в начале записи, поднимаю по прерыванию RXNEIE. Все вроде бы нормально (процесс записи в регистр 0x18 значения 0x98):

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

Собственно вопрос - как оптимально сдвинуть CS на половину периода клока? То есть после того, как он опустится.

Спасибо.

PS
Очень интересно - проблема решилась сама собой с увеличением частоты. На скриншоте частота = 24МГц/256. поставил делитель 64 и CS сдвинулся более чем на пол периода

Поднимайте ногу CS по SPI_SR_BSY.

Лично у меня - вот такая конструкция:


Магия? Возможно. Но без первой инструкции ожидания порой пролетал мимо передачи и пин /CS дёргался вниз-вверх за 2 такта, а уже после этого начиналась передача. Третью строку можно убрать, но на свой страх и риск.

Сообщение отредактировал AlanDrakes - Sep 17 2016, 13:59

Ничего интересного. Просто обработчик прерывания не успел дёрнуть CS раньше. Сегодня не успел, а завтра успеет. Следовательно, не вариант.

2ViKo не вариант - не использую вайлы

2scifi при частоте 375к у ядра на периода клока 128 тактов. Вполне возможно, что задержался. Но это был его самый "быстрый путь" по коду. так что врядли будет быстрее.

А вот mrf так и не завелась толком... Отправляет вроде, прерывание на отправку генерит, в статусе все ок. А вот приемник пару раз с антенной на прерывание входил и все. Никак не заработает. И мощности добавил и антенну поменял.. Не понятно что не так

Использовать другой режим SPI (биты CPOL, CPHA).

В прерывании от TXE (или от RXNE, если очень хочется) дождитесь BSY, не много потеряете. Если внимательно рассмотрите RM, увидите на картинках, что да как.

Это не то. Они не дали того эффекта


Ждать тоже не хочется - все таки это не хороший тон ждать в прерывании. В любом случае я добился своего.
А по поводу mrf - походу антенна не заходит в кабель. Кабель и антенну купил в разных местах и промазал походу.
вот такой набор:


Ее подергаешь бац - несколько пакетов подряд примет, потом о5 пропадает. Короче антенну заменю.

Глупости.
Нехороший тон - это делать то, чего не понимаешь.
Если же понимание присутствует, то можно и ждать в прерывании, и рвать шаблоны слабонервным ещё тысячью способов, одновременно указывая любителям хорошего тона, куда им можно пойти.

Да, увеличив скорость, добились. А когда уменьшите, косяк вылезет назад. Если будете проверять BSY, то вам и ждать не придется на высокой скорости, он уже выключится. А на низкой спасет.

Уменьшать и не планирую - низкую ставил пока отлаживал. Вообще попробую с BSY. Если на осцилле будет такая же картина может и оставлю.

Вообще, конечно, плохо, что нет у STM32 нужного прерывания. Похожая история с I2C: непрерывный обмен только на прерываниях без ожидания флагов часто сделать невозможно.
Если хочется совсем по феншую, можно привлечь таймер для доп. задержки. Но, боюсь, в данном случае это не даст никакого выигрыша по сравнению с простым и недолгим ожиданием флага BUSY.

В общем я гляну как будет себя вести ожидание BSY и сколько тактов оно на себя сожрет и посмотрю

Вообще у стм порой странности бывают. Например с той же ножкой NSS. Она, конечно, нужна не для Chip select, но могли же добавить в нее такую возможность... В конце концов очень часто бывает, что на 1 SPI вешают только 1 девайс, а тут такая засада...

Что именно "не то"?
Судя по картинке у Вас CPOL=0, CPHA=0. Т.е. - Вы настроили защёлкивание данных по фронту SCLK. И в то же время пишете:

Так всё-таки: чип MRF24J40 защёлкивает данные по фронту или по спаду??? Неужели на этот чип нет доки? Или читать не умеете?
Если всё-таки по спаду, то CPOL=1, CPHA=0 - должно решить проблему.

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

А по сабжу - как происходит запись/захват я описал еще в первом посте. Захват происходит по фронту. Все как полагается. Но, видимо, захват значения (при записи в регистры mrf) происходит по фронту, а запись этого значения по спаду, при включенном CS. Опыты показали именно такое поведение.
CPOL и CPHA созданы для другого.