-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
applications: connectivity_bridge: thingy91 debug #18146
Conversation
CONFIG_CMSIS_DAP_DEVICE_VENDOR="Nordic Semiconductor ASA" | ||
CONFIG_CMSIS_DAP_DEVICE_NAME="nrf91" | ||
|
||
CONFIG_HEAP_MEM_POOL_SIZE=6000 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RAM is tight - had to decrease usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: A lot of RAM is used for the USB CDC FIFOs. In prj.conf, CONFIG_USB_CDC_ACM_RINGBUF_SIZE=16384
. As there are 2 x CDC instances, there are 4 of these buffers in total (=64 KiB RAM). So only a slight reduction of this parameter could give you the RAM you need,
Sadly the "old" USB CDC class doesn't let you set the buffer size on a per instance basis. The USB-next version will. I suspect only the CDC instance used for trace would need this kind of buffering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, I slightly reduced the cdc buffer instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope the missing 1K isn't going to cause any trouble with certificate provisioning. There still is a lot of buffer.
0f84499
to
fbb1bc1
Compare
CI InformationTo view the history of this post, clich the 'edited' button above Inputs:Sources:sdk-nrf: PR head: 0e377ad3822eed59b332429b40dcb47d4ec7636f more detailssdk-nrf:
Github labels
List of changed files detected by CI (6)
Outputs:ToolchainVersion: f51bdba1d9 Test Spec & Results: ✅ Success; ❌ Failure; 🟠 Queued; 🟡 Progress; ◻️ Skipped;
|
You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds. Note: This comment is automatically posted by the Documentation Publishing GitHub Action. |
e321ef2
to
8a60a3e
Compare
This depends on zephyrproject-rtos/zephyr#80920. Gotta fix an error that I introduced myself. 🙈 |
8a60a3e
to
920283a
Compare
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
920283a
to
e14a2b2
Compare
#if defined(CONFIG_BOARD_THINGY91X) | ||
len = dap_execute_vendor_cmd(buf->data, tx_buf); | ||
#else | ||
len = dap_execute_cmd(buf->data, tx_buf); | ||
#endif /* defined(CONFIG_BOARD_THINGY91X) */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in general, adding board dependencies in code is a bad practice. The clean way to to this is to revert the dependency, ie
- An app level Kconfig (or none)
- Boards that want DAP simply enable DAP, or select app level option
- Application enables DAP based on DAP Kconfigs or the custom one if required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand the notion. In this case, the application is tailored to only two specific boards and we needed some place for this code to go. These features are very specific to these boards, but also don't really have a place in board files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gmarull is the above response OK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if this application is used by a customer with its own custom board? Board specific code in applications is never a good idea. Never.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't add board specific code. It reuses code specific to the Thingy:91 X.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a sample. If customers want to use it with other boards, they have to port it. Other applications work just the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again: board switches at application level are not acceptable. This makes application non-easily portable and makes life unnecessary difficult for end users. The right thing to do this is:
- Add an application level setting, like CONFIG_APP_ENABLE_THIS
- Make sure board overlay enables it if needed
This way, app stays board agnostic, and if any customer porting this app needs the option, they can just touch a conf overlay and not C code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, consider the case where a user creates a board with the same features as Thingy:91 because they want to run this application (so HW requirements are covered), but maybe they just change e.g. the PMIC or adjust its form factor. Then, instead of being able to use the sample as is with some overlays, they'll be forced to essentially create a copy and patch the sample code.
e14a2b2
to
f7fd87d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awaiting confirmation from @gmarull
app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/usb_bulk_interface.c) | ||
|
||
target_sources_ifdef(CONFIG_BOARD_THINGY91X_NRF5340_CPUAPP | ||
app PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/usb_bulk_commands.c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
align properly as with above lines
#if defined(CONFIG_BOARD_THINGY91X) | ||
len = dap_execute_vendor_cmd(buf->data, tx_buf); | ||
#else | ||
len = dap_execute_cmd(buf->data, tx_buf); | ||
#endif /* defined(CONFIG_BOARD_THINGY91X) */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gmarull is the above response OK?
f7fd87d
to
3c183e6
Compare
3c183e6
to
5a0b3a9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Add the CMSIS-DAP feature of the thingy91x to the thingy91. Signed-off-by: Maximilian Deubel <[email protected]>
5a0b3a9
to
0e377ad
Compare
Add the CMSIS-DAP feature of the thingy91x to the thingy91.