Improve performance and add ability to sleep

[dunkmann00]

After looking more into #40 it seemed that there was some potential to improve this library more substantially than by just removing some of the I2C delays.

This adds support to put the PN532 into a low power state (which reduces the current draw by up to ~60mA from my testing). It also better handles waking up the PN532 from this low power state, which resulted in not needing many of the delays that were present in all of the communication subclasses.

The responsiveness of the PN532 is much better with these changes. I tested this with both an itsybitsy m4 express and an itsybitsy m0 express for all 3 communication methods (I2C, SPI, & UART) on the Adafruit PN532 Shield but would welcome if someone else could also verify these changes!

[tannewt]

@nitz Do you have a PN532? I know you've been doing other NFC stuff.

[nitz]

Uh, you'll have to let me check when I get home. I definitely bought something for that side of the NFC equation, but it's in a box at the house and I don't remember if I've even taken it out 😂! Poke me if I don't update here in a few hours!

Edit: I do have one! Hurray for drunken amazon purchases.

I think my only boards with CP on them right now are the two @dunkmann00 has tried, but I've got something around here I can put CP back on other than those, just gotta... find it.

I've also got to put a header or some leads on this thing.

[nitz]

Okay, I'm back, with news!

Via i2c and spi, I was able to run pn532_simpletest.py and waved whatever cheapy RFID chips this PN532 came with in front of it, and it spit up their UIDs. I was also able to test with a handful of different NTAG215s I have, and that went peachy too.

However, switching to UART, the initialization went fine and it was able to read the FW Version from the PN532, but as soon as I'd wave any tag near it, it'd freeze. I'd like to have more info on where or why, but I don't have that yet (and I'm starving, so I gotta go eat dinner.)

My test board is this nRF52840 kit. I'm not using the TX/RX pins on the board there, as I'm pretty sure they're default bound to something else, and I didn't feel like shaving that particular yak.

I also ran into this very bizarre thing, where I had my FTDI TTL to USB 232 attached to those TX/RX pins, and while the board was completely unpowered, the LED on the PN532 board was lit, as long as I had TX connected. But only while the PN532 was in I2C mode. Yeah, I've got no idea for that, but seems to be a hardware thing, and not a code thing.

Anyways: after I get something to eat I'll see if I can figure out -- woah, okay. Literally as I'm typing this I'm staring at the frozen output and it spits out the UID of the card I waved in front of it at least a few minutes ago, and it's running again. Waving another in front freezes it, and after a minute or two it spits the UID and keeps going. So I guess it's not a hard lock.

Stay tuned!

[dunkmann00]

@nitz I might know why you saw that long delay.

What timeout value are you using when you initialize the uart object? For the old examples I think the values were never updated. So the example code sets the timeout=100, which for the newer CP that is 100 seconds, not milliseconds.

Try setting timeout=0.1 and see if that works better. I put this value in correctly for the new example I added, pn532_low_power.py, but I didn't change it in the old ones as I figured it wasn't really a part of this pull request.

Let me know how that goes!

[nitz]

Well that's a bingo! Yeah I just copied and pasted the old ones into my code.py, mega timeout and all!

Everything else seems solid to me, including all three methods in your pn532_low_power.py. I don't have a Pi set up with blinka, but I imagine the addition of a reset/req won't hurt 🙂