Я, бывало, к одному процессору подключал две ЕЕПРОМ по разным интерфейсам, чтобы избежать ненужных коллизий между разным.... («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

Я, бывало, к одному процессору подключал две ЕЕПРОМ по разным интерфейсам, чтобы избежать ненужных коллизий между разными "приложениями". Оно то можно, но риск сложных ситуаций возрастает, нужен надежный протокол взаимодействия.

Отправлено Vladimir Ljaschko 06 ноября 2007 г. 10:14
В ответ на: Кто-нибудь делал попеременное обращение к одной I2C EEPROM двумя независимыми процессорами? Какие грабли могут ожидать акромя очевидных, т.е. исключения попытки одновременного доступа? отправлено -=Shura=- 06 ноября 2007 г. 10:00

Составить ответ | Вернуться на конференцию

Ответы

Протокол простой, как грабли :-) Один проц (мастер) подаёт питание на слейв, тот отрабатывает свою задачу и пишет данные в EEPROM. Через определённое время мастер вычитывает чаво он там понаписал — -=Shura=- (06.11.2007 10:20:3 217.21.50.43, пустое)
- нормально всё будет - одновренного доступа ведь нет. Не забыть при считывании учитывать время записи в ЕЕ — argus98 (06.11.2007 10:44:2 81.22.205.230, пустое)
- Для полного совершенства добавь, чтобы мастер еще и сброс слэйва удерживал. Заодно на одном WDT сэкономишь :) — Vladimir Ljaschko (06.11.2007 10:31:22 194.158.204.49, пустое)
  - Было б мне ЧЕМ удерживать я бы этой хернёй не занимался :-)) Нет ни одной свободной ноги у проца, а к нему надо "плату расширения" привесить. Т.к. EEPROM на проце висит, то пришла мысля повесить на ту же шину второй с другим адресом и организовать Дубровскому дупло :-) — -=Shura=- (06.11.2007 10:33:47 217.21.50.43, пустое)
    - А второй проц может работать в режиме I2C slave? — vmp (06.11.2007 11:01:28 87.245.155.195, пустое)
      - Аппаратно - нет, а программно ваять I2C слейв ломает. Тем более, только ради того, чтобы передать содержимое еепромки — -=Shura=-   (06.11.2007 11:04:26 217.21.50.43, пустое)
        
        Взять проц который "умеет". — PlainUser   (06.11.2007 11:42:57 62.148.242.234, пустое)
        
        Можно, но есть ли смысл? — -=Shura=-   (06.11.2007 11:44:34 217.21.50.43, пустое)
        
        Зависит в основном от субъективных причин. — PlainUser   (06.11.2007 12:07:34 62.148.242.234, пустое)
        
        Субъективных нет, есть только объективная - времени мало, надо сделать самым простым способом — -=Shura=-   (06.11.2007 12:11:20 217.21.50.43, пустое)
        
        Быстро значит на знакомой элементной базе.А по сути ... — PlainUser   (06.11.2007 12:22:22 62.148.242.234, 258 байт)
        
        А мастер не пишет ничего, только читает. И выдернуть низзя, припаяно — -=Shura=-   (06.11.2007 12:23:34 217.21.50.43, пустое)
        
        Да наверно имеется в виду, что слейв-МК(+) — Quasy   (06.11.2007 14:14:30 80.243.9.34, 250 байт)
        
        Не понял идеи "ограждения"... Можно попроще объяснить? :-) — -=Shura=-   (06.11.2007 14:20:7 217.21.50.43, пустое)
        
        Да бред в-общем-то... Если позволяет(+) — Quasy   (06.11.2007 14:34:45 80.243.9.34, 638 байт)
        
        Спасибо, идею понял. — -=Shura=-   (06.11.2007 14:38:7 217.21.50.43, пустое)
        
        Если припаяно то отпадает , но для себя я бы взял Atmega8... и AVR311 — PlainUser   (06.11.2007 12:40:51 62.148.242.234, пустое)
- дык логично чтоб мастер снял питание со слейва - тот и не сможет конфликтовать) шучу... но истина рядом... когда есть командир - конфликтов нет) — basilmak (06.11.2007 10:28:39 82.142.173.231, пустое)
  - Ага, а диоды? Питание слэйва должно быть, пока мастер читает — Vladimir Ljaschko (06.11.2007 10:33:16 194.158.204.49, пустое)
    - ага, просто ресет ему держать - шоб не лазял...) — basilmak (06.11.2007 14:27:49 82.142.173.231, пустое)