0 - 63: Core event types (TIMER, MQUEUE_DATA, etc.)
64+: Per-task event types.
So, the options for the host package are:
1. Reserve new core event IDs. This avoids conflicts, but permanently
uses up a limited resource.
2. Use arbitrary per-task event IDs. This has the potential for
Yeah, I can see why you chose OS_EVENT_TIMER. It is almost like we should
rename that event type :-) But I agree with everything you say below; creating
a new event type for this seems wasteful. I am not quite sure what you mean by
"My concern there is that applications may want to add special
On Mon, Apr 18, 2016 at 09:18:16AM -0700, will sanfilippo wrote:
> For #2, my only “concerns” (if you could call them such) are:
> * Using OS_EVENT_TIMER as opposed to some other event. Should all
> OS_EVENT_TIMER events be caused by a timer? Probably no big deal… What
> events are going to be
All sounds excellent!
+1 for #1. That only seems like a good thing.
For #2, my only “concerns” (if you could call them such) are:
* Using OS_EVENT_TIMER as opposed to some other event. Should all
OS_EVENT_TIMER events be caused by a timer? Probably no big deal… What events
are going to be
Hello all,
The Mynewt BLE stack is called Nimble. Nimble consists of two packages:
* Controller (link-layer) [net/nimble/controller]
* Host (upper layers) [net/nimble/host]
This email concerns the Nimble host.
As I indicated in an email a few weeks ago, the code size of the
