Hi, before buying the PCA10056 kit, I have some questions about the USB CDC ACM example.
At the Infocenter, it says that
This example shows how to use the CDC ACM USB class, commonly known as Virtual COM port.
The port can be opened and closed just like a traditional serial port.
Using a terminal emulator, for example putty,
send test data from the host computer to the development kit. LED 3 will blink.
Does this mean that the nRF52840 can transfer or receive UART data without adding extra UART-USB ICs like FT232R?
If I use the USB CDC ACM example, can I read or write after I open the port from PuTTY just like using the UART example?
In the case of nRF52832-QFAA, the NFC1 and 2 pins were fixed to pin 11 and 12.
What about the nRF52840 and what pins are used for this example?
Is it the UART0 module used for the example, since it is enabled in the header file, and use pin 13 and 14?
Also, can I use any pins, except the power pins, to configure it as an USB related pins using PPI?
However, when creating a custom PCB which is related to Li-PO USB charging such as the BQ25010, I won't populate the J-Link MCU.
In this case, how should I configure my schematic wirings to connect the nRF52840's pins directly to the USB connector (D+/D-) when supplying 3.3 volts to the nRF52840?
-Best Regards, MANGO
Yes. The USB interface in the nRF52840 allows it to implement FT232 like functionality without any additional hardware.
Since the USB interface is fully programmable it can also do a lot more, as you can see by all the different USB examples available in the SDK.
Just keep in mind that you need to connect to the second USB connector on the nRF52840 PDK to get access to the Nordic USB interface, otherwise you are just connecting to the Segger programming chip.
From your terminal program the comport should look like any other, yes, and both read and write is supported.
The USB interface has dedicated pins that are separate from the standard GPIO ports, and they can not be relocated to any other pins. The reason for this is that the USB interface pins require dedicated hardware that would be expensive and impractical to duplicate on multiple pins.
The physical UART is only used for logging in this example, and the default configuration of UART0 (which allows it to connect to the UART interface in the Segger chip) is printed on the back of the nRF52840 PDK. This is the same configuration that we have always used, even before we got USB support in the chip, and it uses the CDC ACM functionality of the Segger chip to make the UART available on the PC.
If you want to connect the Nordic CDC interface to a physical UART you could potentially use UART1 for this, allowing you to keep using UART0 for logging and debugging purposes.
Regarding the layout you should refer to the reference schematic.
As you can see the VBUS, D+ and D- lines should just be connected directly to the connector.
Edit: I have attached the CDC MSC hands on examples here:
Wow. Thanks for the detailed answer, Torbjørn!
If you want to transfer files you should probably consider the MSC examples instead
I want to both send UART data (or ASCII data packets, maybe?) to the connected PC
and receive files from the PC with the single nRF52840 chip by merging both examples.
Is this possible?
showcasing the new QSPI interface in the chip
You mean there was a video demo that used QSPI?
The infocenter tells that The nRF52840 Preview DK board has a 64-Mb external flash memory. The memory is a multi-I/O memory supporting both regular SPI and Quad SPI. and this feature might be the thing I was looking for.
The nRF52840 Preview DK board has a 64-Mb external flash memory. The memory is a multi-I/O memory supporting both regular SPI and Quad SPI.
I made a hands on example showing you how to combine MSC and CDC a while back, and put it on github: CDC MSC hands on
I never got past the first task, but this is what you need (combining two USB classes into one example).
No, my point was that the MSC example essentially shows of two things:
Hello, Torbjørn. Wow, a hands on example, I'm deeply touched!
Although that GitHub link shows a 404 error, I will check the code soon.
Thanks for your time.
My bad, I forgot the repo was private.
I have attached the files in my original reply.