What is an Application Event?

[brianreinhold]

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.

[Karl Ylvisaker]

Hello,

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.

Please see the answer by my colleague Susheel in this ticket.

So what is an application event?

All events received by my application?

In essence, yes. Application events are the subset of all the possible events, that is passed to the application - for instance, many of the events are only used by the SoftDevice, and thus not forwarded to the Application layer.
You may use the NRF_SDH_BLE_OBSERVER macro to forward BLE events to handlers in your application.

I might be able to use sd_app_evt_wait() to support semaphore-like behavior that I really need.

Could you elaborate on exactly what this behavior you are looking for is?
Are you developing with the nRF5 SDK, or nRF Connect SDK? In the case of the latter you should know that Zephyr is an RTOS that already provide this for you.

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 explanation here is the same as for the application events - the application interrupts are the subset of interrupts which are passed to and handled by the application.
An example of this would be a TIMER instance that you setup to periodically trigger an interrupt in your application - this is an application interrupt.
An example of a 'non-application interrupt' would be the SoftDevice's own timers interrupt, which are never seen by the application.

Please let me know if anything should still be unclear, or if you encounter any other issues or questions.

Best regards,
Karl

[brianreinhold]

First I am not using the SDK for any Bluetooth, but only SoftDevice, I have several good reasons for that, but mainly that I am working with the BT SIG Med group to define a single generic health device standard that can be used for all devices. Also I am using the pc-ble-driver for the same purpose. (Here I am writing for the nRF51822 to use on a real device.) Nice to have the two as similar as possible.

The problem I am trying to solve is the simulation of a semaphore. I have a characteristic value that is several MTUs long, so I indicate, need to wait for the response event, and repeat. The start of the sequence is given when the peer writes a command to do so. I have another posted thread on this site about that. But in that thread and in the documentation there are endless references to 'application event' without ever defining what that was.

Thus this post to get a straight concrete answer so I can move forward and have a better understand of what my options are. Being able to 'indicate' long characteristic values is central to this standard. Right now when I do a while loop on the sd_ble_gatts_hvx() call and the NRF_ERROR_BUSY it hangs after about three indications. I am calling the method from a timer started in the ble event handler.

[Karl Ylvisaker]

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

[brianreinhold]

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.

[Karl Ylvisaker]

Hello Brian,

I have been out of office for some days, thank you for your patience.

brianreinhold said:

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.

brianreinhold said:

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.

Thank you for elaborating - I definitely understand what you mean about the SDK's changing more dramatically then the SoftDevice API's, and I suppose that if you aspire to always keep the SDK up to date with the latest version, this is a better way of doing it - especially since you are able to implement all the functionality you are after, using this way.

brianreinhold said:

this is flash on an embedded system! When is that ever completely simple?

I wholeheartedly concur! I am also glad to hear that you have found an approach that achieves your intended functionality, in an easy way. 

brianreinhold said:

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.

I am happy to hear that, brianreinhold! Then you have already gotten to 'the sweet spot' of BLE development, in my opinion! Good knowledge of the protocol - and SoftDevice implementation of it - significantly speeds up the development, and makes the whole process significantly easier.

Please do not hesitate to open a new ticket if you should encounter any issues or questions in the future.

Good luck with your development!

Best regards,
Karl

[brianreinhold]

Only thing missing is finding the start of free flash programmatically. I'll work on that issue later.

[Karl Ylvisaker]

To accomplish this without using the app_util.h file from the SKD, I suppose you could just take out the relevant parts of the file, to be used in your application.
For example, take a look at the following code from the app_util.h file.

#elif defined(__SES_ARM)
extern uint32_t * _vectors;
extern uint32_t __FLASH_segment_used_end__;
#define CODE_START ((uint32_t)&_vectors)
#define CODE_END   ((uint32_t)&__FLASH_segment_used_end__)
#define CODE_SIZE  (CODE_END - CODE_START)

You could then have your application calculate where the first free page is located by subtracting the application and SoftDevice size from the available flash.
Keep in mind that if you at any point add a DFU bootloader or similar at the top of the memory, you will need to account for this yourself, in your application logic.

Best regards,
Karl