• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 1866 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 116323
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 app scheduler and board support package

Tosa

I am using the nRF52 (SDK12.0.0) to create a very simple BLE application (maybe based on the BLE_APP_HRS example). The system will have a button, LED and interrupt pin from a sensor tied to three GPIO pins. I will use SPI to read the data from the sensor upon interrupt. This data will be sent to the the central (Android) via a notification. The central will use a separate read/write characteristic to configure the system/sensor/LED/etc.

I noticed that none of the examples use the scheduler library, but I did notice it is used in an example on Github referred to by nAN-36. The Nordic infocenter for SDK12.0.0's BLE examples describes that the scheduler can be used or not, but does not say why I would need to use it. My system seems simple enough that I wouldn't need it (I can simply set flags in the IRQ handlers that are processed in main's superloop). So what is the advantage of the scheduler, and why don't examples use it?

Also, the board support package (bsp.c) seems awfully complicated for toggling LEDs and detecting button presses. Was is made so that different duration of button presses can be detected and their functionality can be easily changed based on advertising/connected modes? I think the methods used in nAN-36 should work fine for simply detecting button a button press and toggling LEDs correct?

Parents
  • 0

    I think you have mostly answered your own questions, but I will attempt to elaborate a bit.

    The scheduler is used for transferring execution from the interrupt context to the main context. This ensures that all interrupt handlers are short, and that all interrupts are processed as quickly as possible. This can be very beneficial for some applications, but for many applications the same thing can easily be achieved using flags as you write. However, just naively using a flag may cause you to lose some events, if for example a second interrupt occurs before the first has been served. The scheduler is intended to be used as a simple library that will handle these complexities for you, and with integration with other SDK modules such as the application timer out of the box. If you want an introduction to the scheduler, you should check out the Scheduler Tutorial.

    I agree that the BSP seems very complicated. It is useful in the SDK as it allows us to support many different boards without any special handling in each example. For a "real" project that targets a single specific hardware, it mostly just adds to the complexity. For handling GPIO's it is generally easier to just use the GPIOTE driver, and possible some helper libraries, such as for example the Button Handler if you want debouncing done for you.

Reply
  • 0

    I think you have mostly answered your own questions, but I will attempt to elaborate a bit.

    The scheduler is used for transferring execution from the interrupt context to the main context. This ensures that all interrupt handlers are short, and that all interrupts are processed as quickly as possible. This can be very beneficial for some applications, but for many applications the same thing can easily be achieved using flags as you write. However, just naively using a flag may cause you to lose some events, if for example a second interrupt occurs before the first has been served. The scheduler is intended to be used as a simple library that will handle these complexities for you, and with integration with other SDK modules such as the application timer out of the box. If you want an introduction to the scheduler, you should check out the Scheduler Tutorial.

    I agree that the BSP seems very complicated. It is useful in the SDK as it allows us to support many different boards without any special handling in each example. For a "real" project that targets a single specific hardware, it mostly just adds to the complexity. For handling GPIO's it is generally easier to just use the GPIOTE driver, and possible some helper libraries, such as for example the Button Handler if you want debouncing done for you.

Children
No Data
Related
Terms of service