совместная работа i2c и spi для pic18 Опции

[dac]

могут быть какие-нибудь грабли для i2c ? PIC - мастер, остальные ведомые.
Выводы совмещенные, на SPI висит MMC карточка, на i2c часы и индикатор.
то что spi мешать не будут понятно, у него есть вывод выбора, а вот при интенсивном обмене по spi, I2C ведомые не будут глючить (для них нет вывода разрешения)?
Или стоит поставить ключи и на время обмена по spi, отключать ведомые устройства? Кто-нибудь делал такое?

[MaxPIC]

Ну тогда брать PIC с двумя модулями MSSP.

Кстати, чуть не забыл. В SPI режиме не требуется подтягивающих резисторов, например, на DOUT и SCLK. Пик аппаратно переключает их между +5 и GND. А вот в режиме I2C подключение к шине выполняется по схеме монтажное И, и чтобы реализовать её требуются подтягивающие резисторы на питание, и ножка, во избежание электрических конфликтов, переключается между высокоимпедансым состоянием (+5 через резистор) и GND. Поэтому городить огород на схеме электрической принципиальной я бы не стал.

[dac]

Ну тогда брать PIC с двумя модулями MSSP.

Это решение я и сам знаю, не подходит

Кстати, чуть не забыл. В SPI режиме не требуется подтягивающих резисторов, например, на DOUT и SCLK. Пик аппаратно переключает их между +5 и GND. А вот в режиме I2C подключение к шине выполняется по схеме монтажное И, и чтобы реализовать её требуются подтягивающие резисторы на питание, и ножка, во избежание электрических конфликтов, переключается между высокоимпедансым состоянием (+5 через резистор) и GND. Поэтому городить огород на схеме электрической принципиальной я бы не стал.

Спасибо, это я знаю, и именно с аппаратной частью (если слейв без спроса не дернет шину) проблем нет.
Если отделить i2c слейвы от ПИКа двунаправленным ключем, с pull-up по обе стороны ключей, то это решит проблему несанкционированных действий со стороны слейва, которые в принципе возможны только при случайном появлении в потоке данных SPi адреса устройства I2C. С учетом гораздо большей скорости обмена по SPI это маловероятно, но возможно. В общем получается аналог вывода ChipSelect для SPI устройств.

Поэтому и спрашивалю, может кто реально делал и решил эту проблему проще.

[DL36]

Это решение я и сам знаю, не подходит
Спасибо, это я знаю, и именно с аппаратной частью (если слейв без спроса не дернет шину) проблем нет.
Если отделить i2c слейвы от ПИКа двунаправленным ключем, с pull-up по обе стороны ключей, то это решит проблему несанкционированных действий со стороны слейва, которые в принципе возможны только при случайном появлении в потоке данных SPi адреса устройства I2C. С учетом гораздо большей скорости обмена по SPI это маловероятно, но возможно. В общем получается аналог вывода ChipSelect для SPI устройств.

Поэтому и спрашиваю, может кто реально делал и решил эту проблему проще.

Так идея возникла, для обсуждения:

Поставить два мосфета встречно с p каналом, на шине, и I2C отключать таким образом. В первом приближении должно быть работоспособно.

[George!]

Я думаю вы зря все так усложняете. У нас схемы где SPI и I2C на одном MSSP сидят уже несколько лет используются. Никаких проблем не возникает.
Вот здесь подобное обсуждалось microchip.ru, правда тоже к результату не пришли.

[dac]

У нас схемы где SPI и I2C на одном MSSP сидят уже несколько лет используются. Никаких проблем не возникает.

Спасибо большое, именно это (практический опыт) я и хотел услышать

Если не секрет, что именно висит одновременно?

[George!]

Спасибо большое, именно это (практический опыт) я и хотел услышать

Если не секрет, что именно висит одновременно?

На вскидку.
SPI: память.
I2C: память, RTC и расширитель интерфейса (порты в/в)