+1 for new BSP as opposed to #ifdef.
Regards,
Vipul Rahane
> On Apr 18, 2016, at 2:04 PM, p...@wrada.com wrote:
>
> I concur with what Chris is saying. This is how we do it for arduino, but
> its not ideal in my opinion.
>
> It worked OK for arduino zero versus Zero Pro, but for your case we
I concur with what Chris is saying. This is how we do it for arduino, but
its not ideal in my opinion.
It worked OK for arduino zero versus Zero Pro, but for your case we are
talking about two very different products (arduino and NRF eval board).
I wish I had a good answer. One possibility is
Hi Andre,
On Mon, Apr 18, 2016 at 10:55:49AM +0300, Andrei Emeltchenko wrote:
> Hi,
>
> I am working on arduino_101 development board.
> https://www.arduino.cc/en/Main/ArduinoBoard101
>
> It has nrf51 BLE chip, Basically the configuration is the same as for
> the nrf51dk-16kbram with the only
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
