PIC16 SSP

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Hi All, hope you are having a nice day!


Вот сейчас бьюсь с одной проблемкой:

Имеется PIC16F819 (@8MHz INTRC) который по I2C-slave принимает данные от
мастера (PIC18F452). Мастер шлет данные со
скоростью 72 кбита, меньше уже сделать не получается (высокая тактовая). Кто с
пиками работал, то знает, что конечный
автомат SSP иммеет 5 состояний: WR_ADDR, WR_DATA, RD_ADDR, RD_DATA, RD_NACK (ну
я думаю смысл ясен из обозначений).

Проблема в том, что при приеме данных от мастера слейв не умеет притормаживать
мастер удерживая клок в нуле, поэтому
требуется успеть обработать прерывание до прихода следующего байта. Собственно
между двумя байтами интервал 125 мкс,
поэтому проблем нет. Проблема появляется после посылки последнего байта
мастером и далнейшей выдачей STOP на шину.
Между прырыванием от последнего байта и обнаружением стопа проходит чуть больше
14 мкс. За это время слейв не всегда
успевает откликнуться на прерывание (есть критические секции в коде) и войдя в
обработчик видит уже измененное
состояние конечного автомата, которое вобщем-то нужно считать ошибочным и
ресетить интерфейс. Естесственно последний
принятый байт теряется и мастер об это не знает, т.к. честно получил ACK от
SSP.

После всех оптимизаций сделать критическую секцию короче 16 мкс не получилось,
т.е. проблема все таки иногда может
проявиться (и проявляется). Я вижу два пути решения проблемы:

1. Перед выдачей STOP мастером делать паузу, чтобы слейв успел обработать
прерывание.
2. Ввести еще одно (недокументированое) состояние конечного автомата SSP,
которое соответствет WR_DATA+STOP и
обрабатывать его также, как и WR_DATA.

Пока я остановился на втором варианте и он даже вроде бы нормально работает.
Смущает то, что в общем-то такой расклад в
документации не прописан.

Вобщем интересует мнение работавших с аппаратным SSP пиков о допустимости
такого решения.

WBR,
    AVB

ICQ# 43835774
mailto: avb<at>dialup.etr.ru

Site Timeline