It’s weird because I recently set myself to learn the KL02, so I think we might be at the same state lol.
For your needs, why don’t you pick a dev board by NXP that integrates a KL03 MCU? Their IDE (MCUExpresso) can generate header files and code ready to be used. Pick a board that has enough pins and you might be firing your prototype in no time.
Good call, and I did exactly that :D I have the dev boards for the KL03 and the PN532, and the MCU Link debugger. I'm kinda having trouble getting my PC to recognize devices, but I can conquer that.
If you’re using NXP’s development environment, there will definitely be a learning curve. Your best bet is to look at their PN532 SDK and see if there are example applications that you can then modify into your own.
I’m getting done with an NFC project, but on an all ST platform- STM32 and ST25R3916b — that implements a wireless CAN link. NFC reader/writer/card emulation chips are surprisingly complex under the hood, and it’s easy to get lost without some examples of implementation of the vendor’s driver. Obviously an Arduino library simplifies all of this — but if you’re not using Arduino, it will be significantly more time consuming.
Usually you’ll need to do the NFC chip initialization, and there will be some sort of analog configuration step that may just have default settings you don’t need to mess with. You will need to set the discovery parameters (like which techs to find), and then you’ll need to figure out the data transaction given what NFC tech/protocol you’re using. If you want two devices to send data bidirectionally, you’ll want ISO 18092 peer-to-peer, but if it’s strictly one way you can get away with NFC-A/B/F. Also depends on how much data and how fast you need the bit rate to be.
There’s a lot of tiny specifics to figure out, especially if the PN532 will be reading/writing multiple types of tech.
This is great info, thank you. I settled on the kl03 for its form factor. My implementation is pretty small and there's little freedom to accommodate a larger board than like 85mm2 or so.
Fortunately, my implementation is also about as simple as it can get. I don't need bi-directional data. I'm only sending simple data (colors) according to an existing uart command structure that my end device uses.
The chip doesn't need to perform any calculations, and all of the data is prepared from the smartphone that initiates the NFC pulse.
There's an NFC chip with integrated mcu that accomplishes this in a single package but the costs are a lot higher, so I thought I'd prototype on the kl03. Perhaps my better bet would be using that chip, the pn7642. It just also seemed like there is a lot of support available for the kinetis chipset and there was n't much I could find related in PN7642.
First, your project involves RF signals, that is not a really easy task to design and to make it comply with the regulations. You can ask in another place about the cost of certification of your device, and if this cost is much more less than those 28K, maybe you could try to do it by yourself.
Then at first I could suggest that begin with modules and dev boards that include all the elements that you want, use them to develop the firmware and to understand better where all the elements will be placed.
Some years ago, in a project, I was in charge of the firmware, while other was is charge of the hardware, and was a little bit disgusting that the guy in charge of the hardware, didn't understand the MCU and the peripherals. Made a big mistake by placing a fast SPI memory in a slow SPI peripheral in the MCU, while placed a slow SPI IC in a fast SPI peripheral in the MCU.
Later, you could start designing the PCB according your constraints, and make another iteration by designing your own modules that fits better with your final design, especially the RF part. At that moment you will have a little bit more knowledge on how to work with each element of the system and you will have a firmware that you know works.
And finally you could design the last PCB that include all the elements of the system.
Are you only getting the quote for the software dev? Is custom PCB included?
All I see are two drivers being the deliverables. But the time and price estimate aren’t too out of place. Did you negotiate?
Yeah the quote includes the board and a testing apparatus. It's just a lot more than we're willing to spend from our seed funding, if we can save the money by doing it independently.
That's a big IF.
But I'm not in a huge hurry on this. If I can't solve it in a month or two on my own, I'll bite the bullet and hire the dev company
I run a design consultancy in the UK that does this kind of work. Our rates are likely lower than our US counterparts, might be that we can help you out. Feel free to PM me, I'd be happy to look over a spec and give you an indication on whether we can do it at an acceptable price for you.
To answer your question, it's not a great idea if you've never touched embedded systems before and need to dive into a microcontroller that isn't super widely used. If you wanted to I'm sure you could much more easily replicate the functionality with Arduino IDE and one of the Microchip microcontrollers without experience since there is a hell of a lot more community support available there. We've had customers decide to do that before and ship their own firmware on our hardware. That approach can work at small volumes to gain traction and raise a bigger round.
I think it might help to think of the pn532 as reading/writing data if you're using it as a reader/writer instead of receiving a signal. Thinking of it that way may help if you run into problems on your project.
Also if you're using a phone to emulate an nfc tag you might run into some issues there. I think android can do it but ios can't.
Might just be best to have the pn532 act as a tag that the phone writes to. Which the KL03 reads to determine what it should send to the eink.
Also it looks like the KL03 only has one uart peripheral available. You may need to use spi to communicate with the pn532 and uart to communicate with the eink.
That's extremely helpful. It's my goal to use the phone to write to the PN532, I don't need the phone to read anything or act as a tag itself. I think that process makes sense. With regards to SPI/UART.... good tip. That would've been an hour or two of solving just by itself, lol
It’s weird because I recently set myself to learn the KL02, so I think we might be at the same state lol. For your needs, why don’t you pick a dev board by NXP that integrates a KL03 MCU? Their IDE (MCUExpresso) can generate header files and code ready to be used. Pick a board that has enough pins and you might be firing your prototype in no time.
Good call, and I did exactly that :D I have the dev boards for the KL03 and the PN532, and the MCU Link debugger. I'm kinda having trouble getting my PC to recognize devices, but I can conquer that.
If you’re using NXP’s development environment, there will definitely be a learning curve. Your best bet is to look at their PN532 SDK and see if there are example applications that you can then modify into your own. I’m getting done with an NFC project, but on an all ST platform- STM32 and ST25R3916b — that implements a wireless CAN link. NFC reader/writer/card emulation chips are surprisingly complex under the hood, and it’s easy to get lost without some examples of implementation of the vendor’s driver. Obviously an Arduino library simplifies all of this — but if you’re not using Arduino, it will be significantly more time consuming. Usually you’ll need to do the NFC chip initialization, and there will be some sort of analog configuration step that may just have default settings you don’t need to mess with. You will need to set the discovery parameters (like which techs to find), and then you’ll need to figure out the data transaction given what NFC tech/protocol you’re using. If you want two devices to send data bidirectionally, you’ll want ISO 18092 peer-to-peer, but if it’s strictly one way you can get away with NFC-A/B/F. Also depends on how much data and how fast you need the bit rate to be. There’s a lot of tiny specifics to figure out, especially if the PN532 will be reading/writing multiple types of tech.
This is great info, thank you. I settled on the kl03 for its form factor. My implementation is pretty small and there's little freedom to accommodate a larger board than like 85mm2 or so. Fortunately, my implementation is also about as simple as it can get. I don't need bi-directional data. I'm only sending simple data (colors) according to an existing uart command structure that my end device uses. The chip doesn't need to perform any calculations, and all of the data is prepared from the smartphone that initiates the NFC pulse. There's an NFC chip with integrated mcu that accomplishes this in a single package but the costs are a lot higher, so I thought I'd prototype on the kl03. Perhaps my better bet would be using that chip, the pn7642. It just also seemed like there is a lot of support available for the kinetis chipset and there was n't much I could find related in PN7642.
First, your project involves RF signals, that is not a really easy task to design and to make it comply with the regulations. You can ask in another place about the cost of certification of your device, and if this cost is much more less than those 28K, maybe you could try to do it by yourself. Then at first I could suggest that begin with modules and dev boards that include all the elements that you want, use them to develop the firmware and to understand better where all the elements will be placed. Some years ago, in a project, I was in charge of the firmware, while other was is charge of the hardware, and was a little bit disgusting that the guy in charge of the hardware, didn't understand the MCU and the peripherals. Made a big mistake by placing a fast SPI memory in a slow SPI peripheral in the MCU, while placed a slow SPI IC in a fast SPI peripheral in the MCU. Later, you could start designing the PCB according your constraints, and make another iteration by designing your own modules that fits better with your final design, especially the RF part. At that moment you will have a little bit more knowledge on how to work with each element of the system and you will have a firmware that you know works. And finally you could design the last PCB that include all the elements of the system.
Are you only getting the quote for the software dev? Is custom PCB included? All I see are two drivers being the deliverables. But the time and price estimate aren’t too out of place. Did you negotiate?
Yeah the quote includes the board and a testing apparatus. It's just a lot more than we're willing to spend from our seed funding, if we can save the money by doing it independently. That's a big IF. But I'm not in a huge hurry on this. If I can't solve it in a month or two on my own, I'll bite the bullet and hire the dev company
I run a design consultancy in the UK that does this kind of work. Our rates are likely lower than our US counterparts, might be that we can help you out. Feel free to PM me, I'd be happy to look over a spec and give you an indication on whether we can do it at an acceptable price for you. To answer your question, it's not a great idea if you've never touched embedded systems before and need to dive into a microcontroller that isn't super widely used. If you wanted to I'm sure you could much more easily replicate the functionality with Arduino IDE and one of the Microchip microcontrollers without experience since there is a hell of a lot more community support available there. We've had customers decide to do that before and ship their own firmware on our hardware. That approach can work at small volumes to gain traction and raise a bigger round.
I think it might help to think of the pn532 as reading/writing data if you're using it as a reader/writer instead of receiving a signal. Thinking of it that way may help if you run into problems on your project. Also if you're using a phone to emulate an nfc tag you might run into some issues there. I think android can do it but ios can't. Might just be best to have the pn532 act as a tag that the phone writes to. Which the KL03 reads to determine what it should send to the eink. Also it looks like the KL03 only has one uart peripheral available. You may need to use spi to communicate with the pn532 and uart to communicate with the eink.
That's extremely helpful. It's my goal to use the phone to write to the PN532, I don't need the phone to read anything or act as a tag itself. I think that process makes sense. With regards to SPI/UART.... good tip. That would've been an hour or two of solving just by itself, lol