Rf-module + Микроконтроллер. Spi-интерфейс.

[Cavalryman]

Здравствуйте.

Не могу осилить одно место в даташите. Прошу помощи. Даташит на ВЧ-модуль, а точнее на микросхему (CC2500 / Texas Instruments), которая лежит в основе модуля. Чип на 2.4 ГГц, связь с МК по SPI-интерфейсу.

All transactions on the SPI interface start with

a header byte containing a R/W bit, a burst

access bit ( B ), and a 6-bit address (A5 – A0).

________________________________________

10.1 Chip Status Byte

When the header byte, data byte or, command

strobe is sent on the SPI interface, the chip

status byte is sent by the CC2500 on the SO

pin. The status byte contains key status

signals, useful for the MCU.

А почему тут тогда показано, что можно долбить байтами почти без передышки, если надо еще статусный байт принять от ВЧ-чипа :

И пишут:

Note: The minimum tsp,pd figure in Table 16 can be used in cases where the user does not read the

CHIP_RDYn signal.

Как этот самый байт не считывать, если он все равно передается и заполняет собой (тратя время) единственный буферный байт в микроконтроллере ?

*****************************************

Может я сбивчиво и непонятно описал проблему ? Мне просто со стороны не видно. Могу побольше букавак написать...

Изменено 25 ноября, 2009 пользователем Cavalryman

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Migray]

А что у тебя за МК, если буфер передатчика и буфер приемника не разделены?

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Cavalryman]

Ну я буду делать на PIC16F877, но там в любом даташите один буферный регистр.

Вот это, например, от PIC18F4550, но такая же структура и у других, в том числе и у PIC16F877:

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Cavalryman]

А знаете, что может быть ?

Может, как только первый бит выстреливает из этого регистра, на освободившееся место (Менее значимый бит) записывается уже ответ от модуля ?

Потому что в презентации по интерфейсу SPI пишут (передается значение какого-то счетчика, ну это и не важно):

Тут не ждут и не контроллируют приём байта, тут он автоматически принят в регистр SSPBUF, из которого он стирается: типа не нужен. Если это то, конечно.

Изменено 25 ноября, 2009 пользователем Cavalryman

[Alexeyslav]

Ничего не понимаю, ведь все итак понятно ... передаем и одновременно с этим контроллер принимает биты регистра статуса. У контроллера есть отдельно регистр для передатчика и отдельно регистр для приемника, в чем проблемы?

Кстати, тоже купил эти чипы все думаю когда ими занятся...

[Cavalryman]

Ну, если одновременно, при наличии отдельных регистров для приема и передачи, то действительно всё понятно и проблем нету.

Просто на структурной схеме, да и вообще по даташиту регистр-то один (SSPSR). Это и смущало.

Получается(получалось), перед каждой "вставкой" байта в регистр SSPBUF на передачу, надо выполнить команду сброса/копирования этого самого регистра, как показано в презентации от микрочипа (предыдущий пост).

П.С. Спасибо, что ответили.

[Alexeyslav]

Хм, а может и так ... я точно не знаю, но вообще логичней было бы чтобы было два регистра ... получается, некий "регистр сдвига" который прокачивает данные через себя как колбасу. Ну раз надо, значит надо ...

[Cavalryman]

Я где-то что-то такое вычитал, уж не вспомню где: "Одни говорят, что одновременная работа аппаратных SPI и UART невозможна, а другие, что возможна"

А как на самом деле ? Если сначала "отработать" с SPI, а потом посылать что-нить по UART, то это ж не будет ничего плохого ? По даташиту пины, задействованные этими двумя модулями, висят на одном порте, но на друг друга не налагаются.

[Alexeyslav]

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

[Cavalryman]

Гарантию того, что во время работы SPI по UART ничего не поступит дает, так скажем, априори известная информация.

Конкретно мне хочеться сделать следующее:

По КОМ-порту, используя простенькую программулину, я посылаю фиксированное кл-во байт на МК (UART), после чего рассовываю эти байты по регистрам общего назначения МК. Далее, эти самые байты я посылаю по интерфейсу SPI на ВЧ-модуль (CC2500), который, по радиоканалу, передаёт эти байты на второй такой же ВЧ-модуль + МК, а они, например, отображают принятые байты с помощью восьми светодиодов (первый байт, задержка, второй...).

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

А почему будет выдавать ошибки приема ? Это просто так есть или из-за помех там каких-нибудь ?

Наверное, для моей "мега-задачи" лучше УАРТ отключать на время работы СПИ.

А еще, хотелось бы сделать так: комп посылает на МК байты. МК посылает эти байты на ВЧ-модуль, тот передает по радиоканалу. Вторая сторона принимает байти и эти же байты отправляет обратно. Первые МК + модуль принимает, посылает на комп... Вобщем так можно будет и проверить всю систему на предмет ошибочности. Но это сложнее конечно...

[Alexeyslav]

у вас МК является ведомым по UART. Где гарантия что когда данные начнут поступать с компа, контроллер будет гарантировано находится в режиме приема? Только на авосе будет все работать.

А почему будет выдавать ошибки приема ? Это просто так есть или из-за помех там каких-нибудь ?

Потому что у SPI свое условие стартовое, у UART - свое, и при различных комбинациях сигналов будут неожиданно возникать стартовые условия для неиспользуемого в конкретный момент модуля - если он будет включен. Впрочем, реализовать обмен в таком случае возможно, но прийдется тогда обрабатывать и другие сигналы RS232 интерфейса... Например, выдавать сигнал "приемник не готов" на то время пока будет идти обмен по SPI - только это гарантирует что компьютер не начнет передачу раньше времени(кстати, если при открытии порта были указаны функции аппаратного контроля потока данных).

А проверять прием данных нужно будет конечно, только в комп его отправлять вовсе не нужно, достаточно чтобы этим занимался сам контроллер(скажем 10 раз пытается передать данные и получить определенный ответ по радиомодулю, при неудаче - устанавливает бит "неудача" и сбрасывает бит "в процессе") а по запросу с компьютера сообщал результат последней отправки, успешно или нет. Потом, добавить надо будет байт адреса чтобы адресовать как-то радиомодули и пару байт для контроля четности и восстановления данных при незначительных повреждениях.

[Cavalryman]

"А проверять прием данных нужно будет конечно, только в комп его отправлять вовсе не нужно, достаточно чтобы этим занимался сам контроллер. (скажем 10 раз пытается передать данные и получить определенный ответ по радиомодулю, при неудаче - устанавливает бит "неудача" и сбрасывает бит "в процессе") "

А ведь действительно, так и проще будет. Спасибо.

Тогда, все ж таки, придется отключать УАРТ. МК ведь и не "дернется", если при отключенном УАРТе поступят какие-то данные от компьютера ?

Хоть бы увидеть радиомодули в действии.

Впрочем, реализовать обмен в таком случае возможно, но прийдется тогда обрабатывать и другие сигналы RS232 интерфейса...Например, выдавать сигнал "приемник не готов" на то время пока будет идти обмен по SPI

Кстати, если по СПИ использовать тактирование Т/16 , то МК точно может успеть по-быстрому ответить компу, как вы говорите, "приемник не готов".

Изменено 29 ноября, 2009 пользователем Cavalryman

[Alexeyslav]

пока модуль SPI будет передавать или принимать переключать функции выводов нельзя - испортите текущий обмен по SPI.

Отключать можно, если управлять сигналом готовности и убрать его когда UART отключен, комп будет ждать сигнала готовности от контроллера для приема данных(со строны компьютера без вмешательства программы может таким образом ожидать до 15 байт, при записи 16-го программа получит ошибку что буффер переполнен).

[Cavalryman]

пока модуль SPI будет передавать или принимать переключать функции выводов нельзя - испортите текущий обмен по SPI.

Ок. Так делать не буду. Только СПИ, потом только УАРТ... и наоборот. С задержками на всякий случай.

А вот программу для задействования КОМ-порта я еще не нащел. Там, где-то читал, можно и самому легко сделать, но это попозже.

Спасибо еще раз, всё более менее ясно.

Изменено 29 ноября, 2009 пользователем Cavalryman

[Alexeyslav]

Что-то ты вводишь тут в заблуждение, посмотрел даташит - эти модули USART и SPI полностью раздельны как аппаратно на уровне регистров так и выводы у них разные... их можно использовать одновременно на ЭТОМ контроллере. это у SPI и I2C выводы и функции совмещены. Пользуйся без проблем.

[Cavalryman]

Хы, тогда вообще супер. Вот, собственно и иллюстрация:

****************************************************

Эх, рассеянная я башка, контроллер-то у меня оказывается PIC16F887.

Я вначале название указал неправильно... Но выкладки все с правильного даташита, просто опечатка.

Изменено 30 ноября, 2009 пользователем Cavalryman