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

What is an Application Event?

I am searching for a straight answer to this question. 'Application event' is used frequently in the documentation but never defined. I write the application but I clearly do not define these events. Initially I assumed they were events I defined and I could use them with sd_app_evt_wait(). Alas that is not the case.

So what is an application event?

All events received by my application?

If I know what an application event actually is, then I might be able to use sd_app_evt_wait(). If SoftDevice events (such as all the Bluetooth GAP and GATT events) are 'application events', I might be able to use sd_app_evt_wait() to support semaphore-like behavior that I really need.

Someone please tell me what 'application events' are and give some examples! It would also be helpful to tell me what events received by my application from SoftDevice are NOT 'application events'.

I guess while your at it, can you tell me what application interrupts are? These sound more like interrupts I define unlike application events.

  • The example I am referring to it the demo 'write to flash' example. By dynamic I mean the size of the application I write will be dynamic, As I add/change code the size of its footprint will change. What would be nice in the example is if they would illustrate how to find the first free area of flash so you would have the maximum amount of storage available. I do not store measurement data in my example but I want to. In order to do that I will need more than the last page.

  • brianreinhold said:
    The example I am referring to it the demo 'write to flash' example.

    Thank you for clarifying.

    brianreinhold said:
    By dynamic I mean the size of the application I write will be dynamic, As I add/change code the size of its footprint will change.

    That is true - the memory requirement of the application will certainly change during development.
    If you do not want to update your memory map for each time this happens, you could make due with a smaller partition during development, and then resize it once the development of the application is done.

    brianreinhold said:
    I do not store measurement data in my example but I want to. In order to do that I will need more than the last page.

    Have you taken a look at the Flash Storage and Flash Data Storage examples? They demonstrate the usage of both the fstorage and fds library.
    It sounds like either of them could be a good fit for the use-case you describe.

    Best regards,
    Karl

  • I have looked at them a little bit but I am not using the SDK but SoftDevice. That is because I am also using pc-ble-driver with similar code. There is no SDK for that.

    I did search through the code to see if I could find some indication has how the end of used flash could be obtained programmatically. I already write to flash using the last page, so writing to flash is not the problem. Its programmatically finding where to start.

    However, it sounds like you are saying that it is an impossible task. I have to manually hard code the start location based upon reading a map file every compile - then recompile.

  • brianreinhold said:
    I have looked at them a little bit but I am not using the SDK but SoftDevice. That is because I am also using pc-ble-driver with similar code. There is no SDK for that.

    Yes, I have understood this - but I have not quite understood your aversion to using the SDK for your firmware developing. Could you elaborate on why this is so?
    As mentioned the pc-ble-driver is just a serialized SoftDevice API, so there really is not a lot to go on in terms of creating an SDK for the pc-ble-driver, unless you by this mean that there should be an array of examples using the pc-ble-driver akin to the SDK's examples?

    brianreinhold said:
    However, it sounds like you are saying that it is an impossible task. I have to manually hard code the start location based upon reading a map file every compile - then recompile.

    Well, both yes and no. If you insist on not using any parts of the SDK other than the SoftDevice API, then yes, you will have to keep track of the size of your application yourself. However, if you open for using the SDK then you will have multiple options.
    For example, with you current setup you may use the CODE_START, CODE_END, and CODE_SIZE define's from the app_util.h file.
    Or, you may use the fds or fstorage libraries, as they both start at the top of the Flash(also checking if there is a bootloader present and proceeding accordingly), and writes downwards.

    Again, I would recommend that you do make use of the SDK components instead of implementing these things yourself - it will save you a lot of time and work.

    Best regards,
    Karl

  • Karl,

    There are a couple of reasons I am not using the SDK. I am covering a range of platforms from s110 to s140 and these SoftDevice API do change, but not by much. The associated SDKs, on the other hand, change dramatically; the storage routines perhaps changed the most. Once I changed the original SDK-based s110 code to use just SoftDevice, moving to s130 was trivial. I also do most of my design work using the pc-ble-driver as it is obviously easier to create new designs on a PC than any embedded platform. That makes portability of that test code to any on-device implementation quite easy.

    Lastly, we are working on a new health device standard that is generic. Clearly there is no support for such a standard on any platform. One of the guiding principles here is that it be a simple as possible with minimum Bluetooth knowledge needed. I want to make it as easy as possible to develop using the fewest and most basic GATT GAP operations possible.

    Except for finding the first free start address, I found using SoftDevice to write to flash to be very straight forward and simple. Yes, it was a bit of a pain to assure 4-byte boundaries and write in 4-byte chunks. But this is flash on an embedded system! When is that ever completely simple?

    Also, I could only figure out how to emulate semaphores using the sd_ calls. I needed to indicate and notify characteristics that were multiple MTUs in length. In the driver, I use semaphores. On the platform, I cannot. I could only figure out how to do that using softdevice. Basically two calls to handle the wait for event and get events/dispatch events in the main loop. I could not figure out how to do the same using the SDK.

    Okay, I have grown fond of SoftDevice. I can understand what it does because I have a good understanding of BTLE at the GATT/GAP level. When I need something, I have a good idea what to look for.

Related