This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is nrf at all production friendly?

Hi

I am using the nrfjprog.dll to program my UUT (nrf51822) during our production PCBA test. Apparently this is a bad idea to use this dll since you sometimes change the definitions and then production stops if we update nrf tools. The reason that I have to update is that we start to use the nrf51802 instead of nrf51822 and then I had to update nrfjprog.dll. And then everything stops working because you Guys have added the text "NRFJPROG" in all function names. Should I use the command line Tool (nrfjprog.exe) instead or do you also change in that every now and then without making it backwards compatible? image description

Parents
  • Sorry for the inconvenience, but the name change was needed. When we compiled for OSX there was a conflict in several function names (read and write for example). There were in some very common library functions in OSX that were called the same and had the same number and type of parameters in the same order.

    We try not to break the compatibility of our tools, because we understand that every change is an inconvenience. If the API is changed, we update the major revision number. If you look at the changelog in nrfjprog_release_notes.txt you can see that it was changed to 5.x.x to 7.x.x due to the addition of the nRF52 that required some changes, and from 7.x.x to 8.x.x due to the change you mentioned.

    Regarding nrfjprog.exe, we also change when needed, but we try to avoid it as much as possible. You can still use the dll, and there are no plans to modify the API in the future.

Reply
  • Sorry for the inconvenience, but the name change was needed. When we compiled for OSX there was a conflict in several function names (read and write for example). There were in some very common library functions in OSX that were called the same and had the same number and type of parameters in the same order.

    We try not to break the compatibility of our tools, because we understand that every change is an inconvenience. If the API is changed, we update the major revision number. If you look at the changelog in nrfjprog_release_notes.txt you can see that it was changed to 5.x.x to 7.x.x due to the addition of the nRF52 that required some changes, and from 7.x.x to 8.x.x due to the change you mentioned.

    Regarding nrfjprog.exe, we also change when needed, but we try to avoid it as much as possible. You can still use the dll, and there are no plans to modify the API in the future.

Children
No Data
Related