nrf/nfc: Add basic support for NFC tag 2. #5104
Conversation
This patch adds a new submodule nrfxlib which contains a static library for NFC on nRF52 devices. Currently, only Tag2 library has been targeted. The patch also introduce a basic NFC machine module which expose API for starting and stopping the NFC library/peripheral and an API to to set raw payload. Example: from machine import NFC n = NFC() payload = bytearray([0x03, 0x0F, 0xD1, 0x01, 0x0B, 0x55, 0x02] payload += [ord(i) for i in "google.com"]) n.payload_raw_set(payload) n.start() ... n.stop()
|
Great I will give it a try :-) |
|
@glennrub Thanks a lot for this! I wonder.. do you think it would be feasable to leave out the binary blobs ("libnfct2t_nrf52.a" etc) and go for a open source, nrfx based solution - based on nrfx's NFCT driver? I'm unsure about the licencse requirements of this lib and honestly don't like closed source binaries. I'm also not sure if that is going to be accepted by the maintainers. Would you mind to share some thoughts about it? As for use cases... our application mainly wanted to have the "tap to pair" functionality.. means OOB bluetooth pairing initated via NFC. But that's an advanced use case and certainly not the first thing to do. I guess a simple NDEF messages with a weblink would be something that a lot of people are waiting for. And your approach is already doing this I suppose (I haven't checked, but the payload given in your example is the header/type of a weblink NDEF message?). So don't get me wrong, it's great we have something to play with! I'll give it a try perhaps next week. Thanks. |
|
hi @hoihu , Thanks for the feedback. Let me start with the easy one, the sample i provided in the commit message is an NDEF URL to https://google.com. =) When it comes to the closed source library ("libnfct2t_nrf52.a" etc) i do not find this problematic when targeting nrf-chipset. For more details i'll provide a link to the Nordic 5-clause license summary: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/introducing-nordics-new-software-licensing-schemes. One important aspect of this license is that there is no need to include the license with binaries. You triggered me a bit on your question, whether it is feasible to write an open source variant of the library. I'm not an NFC expert, but from what i see in documents online is that it does not look too complex to implement. I'm not sure anymore if the full stack should be the interface for the machine.NFC API (like proposed in this PR), as all other machine APIs are quite low level. And including a full stack is a bit more than that. I have started to think that the machine.NFC should be a pure nrfx NFCT driver wrapper. This should enable the possibility to write a pure micropython .py NFC/NDEF driver or an USER_C_MODULE/separate inbuilt module. Do you know if there are any requirement of membership in order to provide an implementation? |
|
Just tested the NFC on the EVK_NINA_B1 and works great! For testing I use the NXP |
yes I'm thinking along the same lines.. Perhaps the NDEF TLV memory structure/logic can be separated so that interfacing external NFC chips (e.g. NXP's NTAG chips) can be supported too. I've played with the NTAG chips a couple of years ago and got it working with uPy (it's basically an I2C memory slave and you write the NDEF data to memory segments). Also I asked again on the nordic repo about the open source driver and got this answer. So at least, the NFCT driver will stay compatible with the binary blob. On a related note, another user asked for a similar thing and got a bit further.
I'm sorry but I didn't get this. What kind of membership? For the NFC forum tag specifications? I got my information so far from this site |
|
Hi @hoihu, I think we both share the same view on what might be more optimal solution here. However, I want to also play the devil's advocate for a minute: We have both seen the Tag specifications online. However, that might not grant us license to use what we see there. Looking at the website of NFC Forum on "How to get specification" it states: Even if someone of us signs the agreement and someone pays the bill for the specifications, i'm not sure if micropython as a project benefit of having to maintain a NFC stack of its own, when the chip providers already provide solutions for this (I2C, lib.a) and take care of conformance. (Maybe @dpgeorge can fill in here if he has a long term wish for a NFC stack inside microypthon). Redistribution might also be a concern. Can the NFC stack be MIT licensed, or is it bound to the "company"/person signing the license and pay's the bill? Back as a developer: I'll do a bit more searching online to see if i can find any open source alternatives. Maybe, by luck there is a tinyNFC somewhere there, like what tinyUSB does for USB. On the other hand, if we were to implement a hierarchy like "NDEF -> open source driver -> NFCT HAL" for nRF, i would guess that we would end up in higher abstraction level API not to far from NXP I2C or nrf-library as both wants to read and write payloads. This leave us with a common NDEF implementation that can run over multiple ports. Maybe for time being we provide a solution for this? Accepting that NFC on nRF is as closed as NXP I2C? =) Also to be a bit clear, even if earlier stated that NFC Tag2/4 does not seem to complex it does not mean i will pick the task myself to develop this stack even if purchase and license agreements are signed. I'm basically running a bit short on time these days. Unless someone else would volunteer to do this we will not see NFC support for nRF in a while, unless we use what is available right now. |
|
Just for the creation of NDEF records and reasonably small... |
|
@glennrub Thanks for your detailed answer.
yep - on the other hand - all the informations that's being around in the internet (e.g. @rolandvs link with the python ndef package). Where does the author of this package got his spec's from? I'm not sure if we are holier than the pope, as we say... ;)
ups - sad to see this!
This is likely not the intention of this repository, yes. Possibly, a C based low level implementation could be developed in a separate project (ideally just a thin wrapper around NFCT, as you suggested), with some higher level uPy support for NDEF messages? This may then be added to uPy via git submodule?
I guess the main difference is that we are directly linking in a binary blob with unknown content from an external company telit. What's worse, this binary blob may handle sensitive data (e.g. handover keys, links etc). I'm confused why nordic goes down that way but here we go. |
|
@glennrub : Interesting enough is the |
|
What's wrong with the code? I cloned the repository and build for BOARD=pca10040. Everythng fine. But if I add D:\msys64\tmp\cchwcWvg.ltrans3.ltrans.o: In function |
|
This is an automated heads-up that we've just merged a Pull Request See #13763 A search suggests this PR might apply the STATIC macro to some C code. If it Although this is an automated message, feel free to @-reply to me directly if |
This patch adds a new submodule nrfxlib which contains a static
library for NFC on nRF52 devices. Currently, only Tag2 library has
been targeted.
The patch also introduce a basic NFC machine module which expose API for
starting and stopping the NFC library/peripheral and an API to
to set raw payload.
Example:
from machine import NFC
n = NFC()
payload = bytearray([0x03, 0x0F, 0xD1, 0x01, 0x0B, 0x55, 0x02]
payload += [ord(i) for i in "google.com"])
n.payload_raw_set(payload)
n.start()
...
n.stop()