Deutsch   English   Français   Italiano  
<646387b7$0$31536$426a74cc@news.free.fr>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.nobody.at!weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!feed.abavia.com!abe006.abavia.com!abe003.abavia.com!proxad.net!feeder1-1.proxad.net!cleanfeed3-b.proxad.net!nnrp1-1.free.fr!not-for-mail
Newsgroups: fr.sci.electronique
From: JKB <JKB@hilbert.invalid>
Subject: PN532 en i2c
Reply-To: <jkb@invalid>
User-Agent: slrn/1.0.3 (Linux)
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Date: 16 May 2023 13:40:07 GMT
Lines: 76
Message-ID: <646387b7$0$31536$426a74cc@news.free.fr>
Organization: Guest of ProXad - France
NNTP-Posting-Date: 16 May 2023 15:40:07 CEST
NNTP-Posting-Host: 62.212.98.88
X-Trace: 1684244407 news-2.free.fr 31536 62.212.98.88:36743
X-Complaints-To: abuse@proxad.net
X-Received-Bytes: 3262
Bytes: 3490

	Bonjour à tous,

	J'essaie d'interfacer un PN532 avec un ATmega1284 en i2c et j'avoue
	ne pas arriver à dialoguer correctement.

	Sur le circuit, il y a déjà d'autres composants i2c qui fonctionnent
	parfaitement. Je pense que ce qui me pose problème est dans le
	dialogue à plus haut niveau (le datasheet, l'application design et
	le user manual de NXP sont subtilement différents).

	Je considère que l'adresse du composant i2c est 0x24 (dans l'une des
	docs, il faut l'initialiser, sa valeur par défaut étant... 0x00 !).

	Le composant semble répondre puisque je reçois une trame ACK valide.
	Mais à la suite de cette trame, il laisse le bus dans un état
	bizarre. La machine à états du processeur est en vrac et il faut le
	réinitialiser (électriquement) pour reprendre la main sur le bus.
	Un reset logique ne suffit pas.

	Voici ce que je fais :

	i2c_start()
	envoi de (0x24 << 1) | write
		réception de i2c_SLAW_ACK
	envoi de PN532_PREAMBLE
		réception de i2c_WDATA_ACK
	envoi de PN532_STARTCODE1
		réception de i2c_WDATA_ACK
	envoi de PN532_STARTCODE2
		réception de i2c_WDATA_ACK
	... envoi de la suite de la trame contenant l'instruction
	GetFirmwareVersion ...
	i2c_stop()

	Tout se passe bien, je reçois bien les signaux attendus. À partir de
	là, si j'ai bien compris la doc, je dois attendre une trame ACK de
	la part du PN532. Il faut tout d'abord initialiser une
	communication, en attendant que le bit READY soit positionné à 1.

	boucle infinie
		i2c_start()
		envoi de (0x24 << 1) | read
			réception de i2c_SLAR_ACK
		réception d'un octet
			positionnement de i2c_RDATA_ACK

		si READY == 1 sortie de la boucle

		i2c_stop()
	fin boucle
			
	Lecture des six octets suivants (réception de i2c_RDATA_ACK après
	chaque octet)
	i2c_stop().

	Cela se passe encore bien puisque je récupère :
	00 00 FF 00 FF 00
	qui correspond à une trame ACK.

	Sauf qu'après cela, si je peux bien reprendre la main sur le bus
	avec un i2c_start(), toute tentative d'écriture de l'OPcode (adresse
	du composant + bit lecture/écriture) échoue. Typiquement, le bit
	TWINT reste toujours à 0 lorsque je tente une écriture sur le bus.

	Et là, je sèche lamentablement.

	Je suppose que le PN532 attend un dialogue différent de celui que je
	lui impose, mais j'ai beau relire la doc, je ne vois pas mon erreur.

	Toute indication sera la bienvenue,

	JKB

-- 
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.