Связь двух процессоров по SPI. Посоветуйте, покритикуйте, выскажитесь(+) («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

[an error occurred while processing this directive] [an error occurred while processing this directive] Связь двух процессоров по SPI. Посоветуйте, покритикуйте, выскажитесь(+)

(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Отправлено abivan 20 ноября 2001 г. 12:06

Почитал я архивы нашей конфы, но ответов на свой вопрос я не нашел.
Необходимо связать два процессора по SPI. Одно устройство Slave ( аппаратный, буфер на 2 байта). Выделяется дополнительная линия SlaveReady это линия готовности Slave к приему данных.
Дело в том, что после отправки мастером байта, слэйв должен убрать готовность и установить готовность вновь когда байт будет считан. Это правильно, или есть другие варианты?

Теперь проблема как убрать готовность. Готовность должна быть убрана сразу после прихода 8-го бита по SPI. После приема 8-го бита выставляется флаг прерывания, но мне от этого не легче, так как обработать этот флаг я сразу не могу.(одноуровневое прерывание)
Поэтому решил поставить лишний корпус с триггером. Сигнал CS сбрасывает READY, а SLAVE после чтения байта устанавливает триггер.
Если у кого есть другие варианты прошу высказываться.
Можно конечно применить процессор с двухуровневым прерыванием, но это более дорогой например PIC18C242-5.5$
Состав модуля, если кому необходимо. PIC16C63(SPI+USART-3.5$ )+триггер+FM25160(EEPROM+ОЗУ в одном флаконе – 1.16$)

С уважением, Иван

Составить ответ ||| Конференция ||| Архив

Ответы

Ответ: можно попробовать привязать CCP... — Михаил Евстафьев (20.11.2001 21:39, 446 байт)
- Ответ: да, и точно так же можно регистрировать фронты на CS... — Михаил Евстафьев (20.11.2001 22:24, 424 байт)
Ответ: Ecли мастер может читать состояние линии MISO, то пусть считывает. — XZ (20.11.2001 20:24, 546 байт)
Было дело. — Yuriy (20.11.2001 20:10, 239 байт)
- Я вот тоже к этой мысли склоняюсь(+) — abivan (20.11.2001 20:32, 215 байт)
  - Лучше триггер. — Yuriy (20.11.2001 22:50, 287 байт, ссылка)
Без дополнительной линии не обойтись, — Александр Гайворонский (20.11.2001 18:16, 238 байт)
- Тоже вариант. Добавляю к списку возможных вариантов, но(+) — abivan (20.11.2001 18:39, 177 байт)
  - Кстати, самое системное решение — Александр Гайворонский (21.11.2001 09:38, 357 байт)
    - У SPI PIC один сдвиговый, второй данных. Вот в USART у PIC 2FIFO + сдвиговый. Время съема для SPI больше получается.(-) — abivan (21.11.2001 10:00, пустое)
Может кто другой процессор предложит?(+) — abivan (20.11.2001 17:24, 173 байт)
- AT90S8515-8AI @$3.3 — Димыч (20.11.2001 17:33, пустое)
Объясните наивному — Mihasic (20.11.2001 15:19, 272 байт)
- Делал я на i2c. Отказался я от этого(+) — abivan (20.11.2001 15:41, 473 байт)
  - Ответ: beg your pardon — Mihasic (20.11.2001 20:46, 301 байт)
    - Ответ: (+) — abivan (21.11.2001 09:35, 634 байт)
    - На самом деле принципиальной разницы нет, I2C или SPI использоать :) — Щ.С. (20.11.2001 22:37, пустое)
  - о помехоустойчивости SPI. — Yuriy (20.11.2001 19:53, 554 байт)
    - Ответ: Не так страшен черт (насчет приема лишних бит) — Linuxoid (20.11.2001 20:43, 302 байт)
    - Я в помехозащищенности конечно не силен, но(+) — abivan (20.11.2001 20:22, 210 байт)
      - Ну, в и2с я вообще не разбираюсь. :)) — Yuriy (20.11.2001 23:07, 445 байт)
        
        Спасибо за предупреждение. Буду знать как лечить, если что.(-) — abivan (21.11.2001 09:43, пустое)
наверное не стоит коверкать сущность SPI(+) — Димыч (20.11.2001 13:54, 284 байт)
- Я вот тоже хотел возразить abivan, НО (+) — Щ.С. (20.11.2001 15:49, 719 байт)
  - Ответ: Позвольте небольшое замечание.... — Hog (20.11.2001 17:29, 727 байт)
    - Постановщик задачи не я, но, насколько понял, именно о разрешении обслужиания потоков речь идет (+) — Щ.С. (20.11.2001 18:06, 530 байт)
      - Небольшое пояснение, SPI-rate, ессно, мастером задается... — Щ.С. (20.11.2001 22:23, пустое)
      - Вот по этому процессору я и хочу задать вопрос.(+) — abivan   (20.11.2001 18:31, 376 байт)
        
        Ответ: — Щ.С.   (20.11.2001 19:20, 397 байт)
        
        Спасибо, доку скачал. Почитаю. Если, что не пойму, спрошу(-) — abivan   (20.11.2001 19:51, пустое)
    - Ну вот, у Вас был буфер на 64 байта в EEPROM, а у меня в SLAVE нет его(2 байта не считаются).(-) — abivan (20.11.2001 17:40, пустое)
  - Хочу добавить, что разрабатывается универсальный протокол обмена...(+) — abivan (20.11.2001 16:40, 1121 байт)
- Да я хоть сейчас отрекусь. Если лучше получиться(+) — abivan (20.11.2001 15:47, пустое)
  - Добавка...(+) — abivan (20.11.2001 15:55, 426 байт)
    - дело вот в чем(+) — Димыч (20.11.2001 16:30, 513 байт)
      - Вы предлагаете ASCII протокол обмена?(+) — abivan   (20.11.2001 17:03, 380 байт)
        
        ну почему же ascii(+) — Димыч   (20.11.2001 17:25, 623 байт)
        
        Ответ: Мне тоже кажется, уважаемый abivan, что это не совсем удачно ставить ещё один корпус обычной логики ...Надо искать решение в программно-аппаратной части лишь ресурсами uC — Hog   (20.11.2001 17:41, пустое)
        
        Согласен. Не современно это. Наметились варианты.(+) — abivan   (20.11.2001 18:06, 488 байт)
        
        Есть логика в SOT-23(-) — Анатоль   (20.11.2001 19:22, пустое)
        
        Я в схемотехнике не силен. Где можно эту логику посмотреть(типы, производители, цены)? — abivan   (20.11.2001 19:49, пустое)
        
        См. на новой странице (-) — Анатоль   (21.11.2001 11:33, пустое)
        
        А что такое SLIP и где посмотреть? А по поводу другого процессора я вверху написал. Подскажите(-) — abivan   (20.11.2001 17:31, пустое)
        
        SLIP — Димыч   (20.11.2001 17:35, 205 байт)
        
        еще поправка — nvn   (21.11.2001 18:03, 248 байт)
        
        Спасибо(-) — abivan   (21.11.2001 18:29, пустое)
        
        еще поправка — nvn   (21.11.2001 18:01, 248 байт)
        
        еще поправка — nvn   (21.11.2001 18:01, 249 байт)
        
        Спасибо, буду теперь знать, что такое SLIP. А по поводу решения моей задачи, скорости он мне поубавит.(-) — abivan   (20.11.2001 18:21, пустое)
        
        поправка(+) — Димыч   (20.11.2001 17:59, 35 байт)
Вариант — Smav (20.11.2001 12:30, 443 байт)
- Скорость хотелось бы максимальную. А вот по первому предложению вопрос(+) — abivan (20.11.2001 13:16, 453 байт)
  - Ответ: — Smav (20.11.2001 17:50, 374 байт)
    - Наверное и первый вариант нормально будет работать.(+) — abivan (20.11.2001 18:48, 308 байт)
  - а две линии - запрос/подтверждение? — yes (20.11.2001 13:24, пустое)
    - Хороший вариант. Но конкретно для меня все же, жирно будет. Лучше тригер.(-). — abivan (20.11.2001 15:45, пустое)
а двойной буффер не поможет (в 16 пиках вроде так)? и почему мастер FM25160? — yes (20.11.2001 12:22, пустое)
- При таких скоростях по SPI и тройной буфер не поможет(+) — abivan (20.11.2001 13:01, 402 байт)
  - если задержки хуже в ПИКе - почему ему не быть мастером? — yes (20.11.2001 13:20, пустое)
    - Несколько непонятно. Я делаю модуль-Slave на PIC. Мастерами будут другие разработчики в нашем отделе(PIC, MSP430,Atmega и т.д.). (-) — abivan (20.11.2001 15:58, пустое)
      - Я когда то программировал бортовую машину с одноуровневой системой прерываний — Elektronik   (20.11.2001 17:08, 442 байт)
        
        Русский, как русский. Спасибо(+). — abivan   (20.11.2001 18:13, 125 байт, ссылка)
        
        простите за плохой русский язык ;) — Elektronik   (20.11.2001 17:09, пустое)
  - Есть идея (+) — Анатоль (20.11.2001 13:19, 484 байт)
    - Время потеряем. (+) — abivan (20.11.2001 16:19, 198 байт)
      - Можно не так (+) — Анатоль   (20.11.2001 19:13, 245 байт)
        
        А когда мастеру начинать следующий байт слать? И вопрос по логике.(+) — abivan   (20.11.2001 19:46, 518 байт)
        
        См. на новой странице (-) — Анатоль   (21.11.2001 11:34, пустое)

Перейти к списку ответов ||| Конференция ||| Архив ||| Главная страница ||| Содержание ||| Без кадра

E-mail: info@telesys.ru