Using the nRF52840 Dongle (PCA10059) as a USB serial-to-BLE port

I have already read thru past inquiries along this line, and I see that many others are trying to do the same thing, but Nordic is still not providing appropriate example code. My product (actual several products for several clients) needs to use the BLE UART capability to get data into a PC. The most obvious application of the Dongle is for just this purpose. I also see that others have thought of trying to merge the USB-serial example with the UART-central example, none successfully that I found. Will Nordic provide such an example?

Parents
  • Sorry that I seem to be tangling things up with my multiple attempts to get this to work. I'm trying to understand how to do the job, and trying not to become a tech support nightmare expecting you to do everything for me. I have tried for different combinations:

    A) Choice of build environment: Either nRF5 SDK or nRF Connect. I am very familiar with the former, just getting my feet wet with the latter.

    B) Choice of hardware platform: I need to run the Multi-NUS example code on both the nRF52840 devkit (which uses a real UART to talk thru the programmer chip as a USB serial port), and the nRF52840 Dongle (which has to have a USB serial port emulation running in the nRF52840 code).

    I have been trying all four possible combinations of the two choices above. I would be more than happy to have either toolset work for either final target, even if they must differ. One place where I'm quite sure I'm just missing something simple, is how to load the multi-NUS code into nRF Connect - there doesn't seem to be any sort of project or configuration file. I would bet that a 15 minute zoom call where you could watch over my shoulder, would allow you to say "well, of course that doesn't work - you're supposed to do it THIS way". It might also generate suggestions you could make to the back-room boys to cut down on future tech support needs. I've been in this business for over 4 decades, and can usually figure it out on my own. Not so, this time.

  • Hi Steve,

    SteveHx said:
    A) Choice of build environment: Either nRF5 SDK or nRF Connect. I am very familiar with the former, just getting my feet wet with the latter.

    There are good reasons for using either SDK. However, if you are starting with a new project now it might make sense to go for the nRF Connect SDK for the reasons laid out in the nRF Connect SDK and nRF5 SDK statement. However, the SDKs are completely different and there is no way to use an example from one SDK on the other (the APIs are vastly different). So if you have an example you want to use, you need to use it with the SDK it was written for.

    SteveHx said:
    B) Choice of hardware platform: I need to run the Multi-NUS example code on both the nRF52840 devkit (which uses a real UART to talk thru the programmer chip as a USB serial port), and the nRF52840 Dongle (which has to have a USB serial port emulation running in the nRF52840 code).

    By "Multi-NUS example", are you referring to this unofficial example? This for the nRF Connect SDK (you can for instance see this because it has CMakeLists.txt and prj.conf). Also, it is for a rather old version so I assume you will need to make some adjustments to use it with the latest nRF Connect SDK release. I have not seen this example before to be honest, but from what I see in the code this use "normal" UART and not use USB-CDC, so if that is what you want to use then that must be added. Other than that, most samples work on any Nordic board as long as they depend on some HW resources that are not present on the specific board.

    SteveHx said:
    I have been trying all four possible combinations of the two choices above. I would be more than happy to have either toolset work for either final target, even if they must differ. One place where I'm quite sure I'm just missing something simple, is how to load the multi-NUS code into nRF Connect - there doesn't seem to be any sort of project or configuration file.

    The project files here are the CMakeLists.txt and prj.conf and prj.overlay. This sample is built like any other nRF Connect SDK sample (but again, the problem is that it is a bit old). I suggest you start experimenting a bit with the nRF Connect SDK before you dive straight into this (or other unofficial and/or outdated samples).  As always, it makes sense to start with something like Blinky, and then move on. If you have not done so, you should start by installing the toolchain with the help of the toolchain manager. Then look at how to build and flash examples on the DK using VS code. Note that I do not recommend using Segger Embedded Studio with the nRF Connect SDK - you should use VS Code with the nRF Connect plugin. This is more user friendly, integrates better with the SDK and is what will be supported going forward.

    SteveHx said:
    I would bet that a 15 minute zoom call where you could watch over my shoulder, would allow you to say "well, of course that doesn't work - you're supposed to do it THIS way".

    I suggest you contact your local FAE contact about that (send me a PM if you need their contact information).

    SteveHx said:
    It might also generate suggestions you could make to the back-room boys to cut down on future tech support needs. I've been in this business for over 4 decades, and can usually figure it out on my own. Not so, this time.

    That is true. The nRF Connect SDK is still evolving and we are working hard to make it more user friendly, and any feedback that can help with that is welcome.

Reply
  • Hi Steve,

    SteveHx said:
    A) Choice of build environment: Either nRF5 SDK or nRF Connect. I am very familiar with the former, just getting my feet wet with the latter.

    There are good reasons for using either SDK. However, if you are starting with a new project now it might make sense to go for the nRF Connect SDK for the reasons laid out in the nRF Connect SDK and nRF5 SDK statement. However, the SDKs are completely different and there is no way to use an example from one SDK on the other (the APIs are vastly different). So if you have an example you want to use, you need to use it with the SDK it was written for.

    SteveHx said:
    B) Choice of hardware platform: I need to run the Multi-NUS example code on both the nRF52840 devkit (which uses a real UART to talk thru the programmer chip as a USB serial port), and the nRF52840 Dongle (which has to have a USB serial port emulation running in the nRF52840 code).

    By "Multi-NUS example", are you referring to this unofficial example? This for the nRF Connect SDK (you can for instance see this because it has CMakeLists.txt and prj.conf). Also, it is for a rather old version so I assume you will need to make some adjustments to use it with the latest nRF Connect SDK release. I have not seen this example before to be honest, but from what I see in the code this use "normal" UART and not use USB-CDC, so if that is what you want to use then that must be added. Other than that, most samples work on any Nordic board as long as they depend on some HW resources that are not present on the specific board.

    SteveHx said:
    I have been trying all four possible combinations of the two choices above. I would be more than happy to have either toolset work for either final target, even if they must differ. One place where I'm quite sure I'm just missing something simple, is how to load the multi-NUS code into nRF Connect - there doesn't seem to be any sort of project or configuration file.

    The project files here are the CMakeLists.txt and prj.conf and prj.overlay. This sample is built like any other nRF Connect SDK sample (but again, the problem is that it is a bit old). I suggest you start experimenting a bit with the nRF Connect SDK before you dive straight into this (or other unofficial and/or outdated samples).  As always, it makes sense to start with something like Blinky, and then move on. If you have not done so, you should start by installing the toolchain with the help of the toolchain manager. Then look at how to build and flash examples on the DK using VS code. Note that I do not recommend using Segger Embedded Studio with the nRF Connect SDK - you should use VS Code with the nRF Connect plugin. This is more user friendly, integrates better with the SDK and is what will be supported going forward.

    SteveHx said:
    I would bet that a 15 minute zoom call where you could watch over my shoulder, would allow you to say "well, of course that doesn't work - you're supposed to do it THIS way".

    I suggest you contact your local FAE contact about that (send me a PM if you need their contact information).

    SteveHx said:
    It might also generate suggestions you could make to the back-room boys to cut down on future tech support needs. I've been in this business for over 4 decades, and can usually figure it out on my own. Not so, this time.

    That is true. The nRF Connect SDK is still evolving and we are working hard to make it more user friendly, and any feedback that can help with that is welcome.

Children
No Data
Related