Комментарии 8
Мне кажется, или даташит врёт: на 2 ногу в микросхему TDA7563 приходит сигнал ST-BY/MUTE…
Выводим сигнал remote из автомагнитолы с управляемым по i2c усилителем
Зачем?
Нам всего лишь нужно реализовать i2c-slave с адресом как у TDA7563 (0x6C) и ждать обращений на запись
Зачем делать с таким же адресом? Можно просто шину слушать, не вмешиваясь в обмен магнитолы с усилителем.
Зачем?
Чтобы внешние усилители держать включенными только вместе с магнитолой. Для тех, кого не устраивает управление усилителями от ACC/зажигания.
Зачем делать с таким же адресом? Можно просто шину слушать, не вмешиваясь в обмен магнитолы с усилителем.
Чтобы просыпаться только тогда, когда идёт обращение к усилителю, а не на каждый чих на шине.
Хм, похоже, я поторопился с прослушкой шины
www.microchip.com/forums/m388315.aspx
Используя MSSP модуль в ПИКе (или похожий в другом МК) нельзя пассивно читать данные из шины. То есть надо либо софтовый сниффер делать, либо вот так как автор…
www.microchip.com/forums/m388315.aspx
Используя MSSP модуль в ПИКе (или похожий в другом МК) нельзя пассивно читать данные из шины. То есть надо либо софтовый сниффер делать, либо вот так как автор…
ну есть несколько нюансов в моей реализации, о которых мне известно:
— можно слушать только операции записи от мастера к слейву, операции чтения из слейва перехватить не получится (в моей задаче и не нужно)
— шпион выдаёт аппаратно ACK на каждый байт, который мастер пишет в слейв. Если TDA отвалится от шины (выйдет из строя) процессор магнитолы будет считать что TDA отвечает на шине, но шлёт 0xFF. Как на это среагирует мастер — знает только разработчик магнитолы))
— слейв (в данном случае TDA) имеет право задерживать выдачу ACK если сильно занят. В итоге возможна ситуация, когда мастер продолжит обмен по ACKу шпиона, хотя реальный слейв не готов принимать следующий байт. Уверен, что TDA не использует эту возможность.
Для моей задачи все эти пункты не критичны.
— можно слушать только операции записи от мастера к слейву, операции чтения из слейва перехватить не получится (в моей задаче и не нужно)
— шпион выдаёт аппаратно ACK на каждый байт, который мастер пишет в слейв. Если TDA отвалится от шины (выйдет из строя) процессор магнитолы будет считать что TDA отвечает на шине, но шлёт 0xFF. Как на это среагирует мастер — знает только разработчик магнитолы))
— слейв (в данном случае TDA) имеет право задерживать выдачу ACK если сильно занят. В итоге возможна ситуация, когда мастер продолжит обмен по ACKу шпиона, хотя реальный слейв не готов принимать следующий байт. Уверен, что TDA не использует эту возможность.
Для моей задачи все эти пункты не критичны.
Если усилок держит шину, аккнуть ее не получится. В этом-то смысле все ОК.
Акки/Накки-то ты сам в софте генеришь. В этом смысле проблемы нет, можно сидеть на шине с адресом усилка, но действий не производить никакиъ — меня в этом плане волнует больше, не отморозится ли модуль в МК, если не передернуть правильным образом нужные регистры.
Акки/Накки-то ты сам в софте генеришь. В этом смысле проблемы нет, можно сидеть на шине с адресом усилка, но действий не производить никакиъ — меня в этом плане волнует больше, не отморозится ли модуль в МК, если не передернуть правильным образом нужные регистры.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выводим сигнал remote из автомагнитолы с управляемым по i2c усилителем