2009-06-03 3 views
2

PIC16F88X에 대한 I2C 프로토콜을 조사 중입니다. I2C에서 수신 한 데이터에 따라 I2C 슬레이브에서 ACK 또는 NACK을 활성화하는 것이 좋습니다.데이터에 대한 PIC I2C 슬레이브 승인

PIC는 회선에서 보낸 I2C 주소에 대해 ACK 또는 NACK을 보낼 수 있지만 읽은 이후부터는 이후에 수신 한 바이트에 대해 항상 ACK가됩니다. 그 맞습니까? 다음 커뮤니케이션에서

: 내가 등록 _ 값의 값에 따라 ACK 수 또는 낵로 슬레이브 싶습니다

Start - I2c_Addr+write/ACK - Register_value/Nack 

. 슬레이브가 Register _ 값을 이해하지 못하면 Ack가되어서는 안됩니다.

누군가가 이것이 불가능하다는 것을 확인해 주거나 그것을 수행하는 방법을 말해 줄 수 있습니까?

+0

빠른 설명 : 귀하의 PIC가이 I2C 트랜잭션에서 마스터 또는 슬레이브 (또는 둘 다)가됩니까? – Nate

+0

2 개의 PIC, 1 개의 슬레이브 및 1 개의 마스터. 문제는 슬레이브에있는 것 같습니다 (관련없는 레지스터를 NAck로 결정). 여러 마스터에 대해 생각해보십시오. 만약 당신이 있고 당신이 줄 정보가 있다면, 주저하지 말고 대답 해주십시오 ... – Gauthier

답변

7

가정하여 MSSP 주변

짧은 대답을 사용하여 : 무엇 당신이 요구하는 최소 비트 두드리는 I/O 라인없이 PIC와 아마 수 없습니다. 그 이유는 ack/nack은 9 번째 클럭 에지에서 검사되고 SSPIF 인터럽트는 9 번째 클럭이 끝날 때까지 발생하지 않기 때문입니다. 데이터 바이트가 I/O 레지스터 (8 번째 클럭)로 이동하자마자 BF 비트가 반복적으로 체크되도록 설정할 수 있습니다. 비교를하고 SSPOV 비트를 9 번째 클록 사이클 전에 설정하면 NACK가 생성되어야합니다. 인터럽트가 실행 중이면 매우 간단합니다.

답변 : 슬레이브가받는 데이터 바이트가 유효한지 확인하는 것과 같은 소리가납니다. 개인적으로 나는 이것을하지 않을 것이며, ack는 데이터 무결성을 검증하지 않고 라인의 무결성을 신호로 보내는 것입니다. 장치가 슬레이브 인 경우 마스터는 정의에 따라 정확하게 작동하는 방법을 알고 있어야하며 I2C 회선에서 푸시하기 전에 바이트의 유효성을 검사 할 수 있어야합니다. 이 경우에는 I2C 마스터의 코드를 제어 할 수 있다고 가정하고 코드의 불일치를 피하기 위해 보낼 수있는 모든 명령 또는 유효한 데이터 바이트를 정의하는 하나의 공통 헤더 파일을 사용하십시오.

어떤 이유로 든 올바른 바이트가 전송되었다고 보장해야하는 경우 마스터가 응답 바이트를 슬레이브에 요청하고 이전 슬레이브의 결과를 나타내는 코드를 슬레이브에게 반환하게합니다.

I2C 라인의 무결성을 보장하려는 의도라면 이러한 접근법 중 어느 것도 실제로 작동하지 않습니다. 유일한 옵션은 부트시 대량의 바이트를 보내거나 주기적으로 CRC를 사용하여 슬레이브에서 일치하는지 확인하는 것입니다. 일반적으로 I2C 라인은 작동하지 않거나, 저속이며 일반적으로 짧은 트레이스를 가지며 허용 가능한 버스 커패시턴스가 높습니다. 작동하지 않으면 전혀 문제가 없습니다.

+0

좋은 답변 주셔서 감사합니다. 이것은 (불행히도) 내가 기대했던 것입니다. BF 비트에 대해서도 생각했습니다. BF에서 인터럽트를 사용하는 것이 좋았을 것입니다. – Gauthier

1

I2C 하드웨어가 PIC에 내장되어있는 경우 내 추측은 없습니다. 내가 작업 해 온 하드웨어 솔루션에는 전송에 문제가없는 한 두 번째 바이트를 ACK 할 수없는 상태 머신이 있습니다 (예를 들어 비트가 누락되었습니다). 당신은 비트 뱅킹 (bit-banging)과 ACK를위한 오픈 콜렉터 버퍼를 사용하여 소프트웨어로 자신 만의 I2C 구현을 만드는 것이 낫습니다. 그렇다면 원하는 모든 것을 할 수 있습니다. I2C 표준이 아니므로 버스에 사양에 맞지 않는 장치를 설치하면주의하십시오. 나는 분명히 확신하지는 않지만 모든 표준 I2C 디바이스가 ACK를받지 못하면 데이터 또는 단지 오류를 재전송 할 수 있다고 생각한다. 실패 후 버스 제어권을 누가 가지고 있는지 확실하지 않기 때문에 (NAK).