-
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
ESL PR separate into subsys and sample #12012
Conversation
Test specificationCI/Jenkins/NRF
CI/Jenkins/integration
Detailed information of selected test modules Note: This message is automatically posted and updated by the CI |
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. |
There is a compliance failure. It's rejecting the images as binary files. Do you have a solution for this? |
Does this PR replace the old PR? If so can you close the old one? |
Re-open for tech writer document review. |
46a6c88
to
85538a3
Compare
Adding @annakielar and @peknis to take care of the docs, as per mail thread. |
85538a3
to
0bcfdb0
Compare
Add electronic shelf label service (ESLS). Add electronic shelf label service (ESLS) client. It implemented all mandatory features. Leave all hardware-related control to callback functions. Signed-off-by: Pirun Lee <pirun.lee@nordicsemi.no>
Add a sample running electronic shelf label service as tag role. The sample use LED on DKs to simulate EPD display. This sample provides real EPD reference code as well. Add a sample running esl client as AP role. Signed-off-by: Pirun Lee <pirun.lee@nordicsemi.no>
Change PR status to trigger doc build. |
da36dc0
to
1844c74
Compare
Add esl service and profile library document. Signed-off-by: Pirun Lee <pirun.lee@nordicsemi.no>
1844c74
to
2d630c1
Compare
Tuning the library docs to match them to the template, at least to some extent. Signed-off-by: Pekka Niskanen <pekka.niskanen@nordicsemi.no>
A few more minor fixes to the docs, based on answers from the SME. Signed-off-by: Pekka Niskanen <pekka.niskanen@nordicsemi.no>
Using a link to the sample doc. Signed-off-by: Pekka Niskanen <pekka.niskanen@nordicsemi.no>
You need to implement the following callbacks to if display device exists on ESL Tag. | ||
The :c:func:`display_init` callback is used to initialize the display device if additional work is not done by display driver. e.g.: Initialize memory region for framebuffer, set font type. To implement this callback, you need to write a function that initializes the display device. | ||
This function is called when the tag device is booting up and unassociated. | ||
To implement this callback, you need to write a function that takes the index of the display device and displays the necessary information on the device. |
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.
Do we need to describe what parameters the function takes?
This is described in the API documentation section.
Similarly in other places.
If the sensor reading is successful, value ``0`` is returned. | ||
If the sensor reading is not fast enough or fails, value `-EBUSY` is returned. |
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.
A detailde description of the returned values by the funkction shoud be in the API dokumentation.
There is a sentence there: "If the operation was successful. Otherwise, a (negative) error code is returned", this can be extended.
Power Consumption Measurement | ||
============================= | ||
|
||
Prerequisite: Read :ref:`app_power_opt_general` and get `Power Profiler Kit II (PPK2)`_ | ||
|
||
1. Build and program the Tag (:ref:`nrf52833dk_nrf52833`) Power Profiling configuration by following :ref:`peripheral_esl_build_and_program` and :ref:`peripheral_esl_power_profiling_variant` | ||
|
||
#. Follow `Preparing a DK for current measurement`_ to prepare 52833DK for Power Consumption measurements | ||
|
||
a. Cut SB40. | ||
b. Connect VOUT of PPK2 to nRF current Measurement on DK, connect GND of PPK2 to External supply negative polarity pin (`-`). By doing so, PPK2 will provide power to only the nRF52 SoC. | ||
c. Connect the PPK2 (powered ON) in “Source Meter” mode to the :ref:`nrf52833dk_nrf52833` (turned ON) and enable power output 3000mV on the Power Profiler GUI and start measurement. Power the rest of the ESL Tag DevKit via USB (same as programming USB port), and keep the DevKit turned ON. |
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.
It seems to me that in the sample dokumentation we don't need a dedscription of how to use the Power Profiler Kit. This is included in the PPK documentation.
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.
Some general suggestion from me.
ESL Service:
- UUID definitions for this service should be in the
zephyr/include/zephyr/bluetooth/uuuid.h
file. - It seems that the service can be registered statically. We don't need to use "Bluetooth GATT attribute pools"
- Initialization of the display, LEDs, sensors should be outside the service.
- The setup of advertising, PAwR should be outside the service.
- The OTS should run alongside the ESL service; it is not a part of it.
- There are a lot of work_q and work Items used. Are all of them necessary? I'm worried that it could lead to a race condition. Please optimize it.
- Connection and bond management should be outside the service.
ESL Client:
- Scanning and advertising should be outside.
- The discovery process should be outside.
- Client should be able to read or write all the service characteristics.
Other:
- Are the
Kconfig.esl_client.defaults
andKconfig.esl.defaults
files necessary? - In file names, functions, etc., consider using the acronym "ESLS" (Electronic Shelf Labels Service).
- In the
/nrf/include/bluetooth/services/
directory, I suggest that there should be only esl.h and esl_client.h files.
The proposal for changes to the Service and Client APIs will be discussed offline.
I might've been wrong in my assessment and the ESL might fall into the category of demos according to https://nordicsemi.atlassian.net/wiki/spaces/NC/pages/56004256/Product+requirements . @peknis , @annakielar , @pirun , could you discuss this with Lorenzo and Eirik? |
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
Separate ESL application into two parts.
BLE ESL service and profile in subsys/bluetooth/service.
ESL AP and Tag sample in samples/bluetooth.