This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Need help regarding implementation of a library exactly like softdevice

Hello, I am working on Bluetooth mesh application and i am using nRF52832/40 for the development purpose.

I wants to create one independent library with its own data section in RAM, where main application will interact with this library and may use its data variables.

As Nordics soft-device already working like an independent library, Can you please help us with the implementation of soft-device?
How to initialize the ram section independently before execution of main application?
How to access the data variables from RAM section allocated for library?

Is there any documentation regarding soft-device implementation??

Parents
  • Hi,

    I am afraid we cannot recommend to try to implement what you describe, or anything like it.

    While it may be possible to write the equivalent of a dynamically linked library, you cannot do that the same way as we have written the SoftDevice. The reason is the SoftDevice acts in some respect as a light-weight operating system on the device, and you cannot have two such systems on the device at the same time. Note also that all interrupts go through the SoftDevice interrupt handlers and get redirected to the interrupt handlers of the application. (Hence slightly higher interrupt delays when using SoftDevice.) You would not want a shared library to also act as an interrupt vector table switchboard.

    If you make a shared library, as a standalone build and separate from Bootloader, SoftDevice and Application, you no longer fit within the DFU Bootloader paradigm of having one SoftDevice, one Bootloader, and one Application. You introduce an extra unit, let's call it "Library", and you introduce dependencies from Bootloader to Library and from Application to Library. With that, you must rework the DFU Bootloader to handle those dependencies, to handle the additional type of DFU unit (the Library), and you must handle all possible edge cases that may arise.

    If you want to call into an external application, you can use the Supervisor call interface. Before designing anything using supervisor calls you should have a thorough understanding of the SoC and understand what is meant in all the "Warning" sections in the Supervisor call interface documentation (see the above link).

    If all you want is to use the same UART functions in application and bootloader, then a statically linked library (that gets linked into both application and bootloader) is extremely likely to be the best solution. I.e. you get slightly higher code flash usage (because it gets built into both bootloader and application), but you get much much much less complexity and it will be way way way easier to implement.

    Regards,
    Terje

Reply
  • Hi,

    I am afraid we cannot recommend to try to implement what you describe, or anything like it.

    While it may be possible to write the equivalent of a dynamically linked library, you cannot do that the same way as we have written the SoftDevice. The reason is the SoftDevice acts in some respect as a light-weight operating system on the device, and you cannot have two such systems on the device at the same time. Note also that all interrupts go through the SoftDevice interrupt handlers and get redirected to the interrupt handlers of the application. (Hence slightly higher interrupt delays when using SoftDevice.) You would not want a shared library to also act as an interrupt vector table switchboard.

    If you make a shared library, as a standalone build and separate from Bootloader, SoftDevice and Application, you no longer fit within the DFU Bootloader paradigm of having one SoftDevice, one Bootloader, and one Application. You introduce an extra unit, let's call it "Library", and you introduce dependencies from Bootloader to Library and from Application to Library. With that, you must rework the DFU Bootloader to handle those dependencies, to handle the additional type of DFU unit (the Library), and you must handle all possible edge cases that may arise.

    If you want to call into an external application, you can use the Supervisor call interface. Before designing anything using supervisor calls you should have a thorough understanding of the SoC and understand what is meant in all the "Warning" sections in the Supervisor call interface documentation (see the above link).

    If all you want is to use the same UART functions in application and bootloader, then a statically linked library (that gets linked into both application and bootloader) is extremely likely to be the best solution. I.e. you get slightly higher code flash usage (because it gets built into both bootloader and application), but you get much much much less complexity and it will be way way way easier to implement.

    Regards,
    Terje

Children
No Data
Related