[RadiatoR 2]

Всем доброго дня.

Завожу MRF24J40. SPI.

Аппаратного CS нету, вылезаем софтверно.

 

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

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

 

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

 

Спасибо.

 

PS

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

 

[ViKo 1]

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

[AlanDrakes 1]

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

    GPIOA->BSRR = (GPIO_BSRR_BR_2 | GPIO_BSRR_BR_6);    // nCS DN, D/C# DN
    SPI1->DR = command;
    while (!(SPI1->SR & SPI_SR_TXE));
    while (SPI1->SR & SPI_SR_BSY);
    GPIOA->BSRR = GPIO_BSRR_BS_2;        // nCS UP

 

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

Изменено 17 сентября, 2016 пользователем AlanDrakes

[scifi 1]

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

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

[RadiatoR 2]

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

 

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

 

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

[jcxz 213]

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

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

[ViKo 1]

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

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

[RadiatoR 2]

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

 

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

 

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

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

А по поводу mrf - походу антенна не заходит в кабель. Кабель и антенну купил в разных местах и промазал походу.

вот такой набор:

 

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

[scifi 1]

Ждать тоже не хочется - все таки это не хороший тон ждать в прерывании.

Глупости.

Нехороший тон - это делать то, чего не понимаешь.

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

[ViKo 1]

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

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

[RadiatoR 2]

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

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

[scifi 1]

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

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

[RadiatoR 2]

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

 

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

[jcxz 213]

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

Что именно "не то"?

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

как оказалось запись в чип происходит по спаду клока,

Так всё-таки: чип MRF24J40 защёлкивает данные по фронту или по спаду??? Неужели на этот чип нет доки? Или читать не умеете?

Если всё-таки по спаду, то CPOL=1, CPHA=0 - должно решить проблему.

[RadiatoR 2]

Или читать не умеете?

 

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

 

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

CPOL и CPHA созданы для другого.