Thanks, Will, It seems I can not get the things work by the simple way. I just want to find out a free time slot at high level to access PHY resource such as CPU and radio RF exclusively. With your explain, I should interleave my events into BLE events at low level in the same schedule queue.
Best Regards, Jiacheng > 在 2017年1月24日，13:48，will sanfilippo <[email protected]> 写道： > > Jiacheng: > > First thing with the code excerpt below: TAILQ_FIRST always gives you the > head of the queue. To iterate through all the queue elements you would use > TAILQ_FOREACH() or you would modify the code to get the next element using > TAILQ_NEXT. I would just use TAILQ_FOREACH. There is an example of this in > ble_ll_sched.c. > > Some other things to note about scheduler queue: > 1) It is possible for items to be on the queue that have already expired. > That means that the current cputime might have passed sch->start_time. > Depending on how you want to deal with things, you are might be better off > doing a signed 32-bit subtract when calculating time_tmp. > 2) You are not taking into account the end time of the scheduled event. The > event starts at sch->start_time and ends at sch->end_time. Well, if all you > care about is the time till the next event you wont have to worry about the > end time of the event, but if you want to iterate through the schedule, the > time between events is the start time of event N minus the end time of event > N - 1. > 3) When an event is executed it is removed from the scheduler queue. Thus, if > you asynchronously look at the first item in the scheduler queue and compare > it to the time now you have to be aware that an event might be running and > that the nimble stack is using the PHY. This could also cause you to think > that nothing is going to be done in the future, but when the scheduled event > is over that item gets rescheduled and might get put back in the scheduler > queue (see #4, below). > 4) Events in the scheduler queue appear only once. This is not an issue if > you are only looking at the first item on the queue, but if you iterate > through the queue this could affect you. For example, say there are two items > on the queue (item 1 is at head, item 2 is next and is last). You see that > the gap between the two events is 400 milliseconds (I just made that number > up). When item 1 is executed and done, that event will get rescheduled. So > lets say item 1 is a periodic event that occurs every 100 msecs. Item 1 will > get rescheduled causing you to really only have 100 msecs between events. > 5) The “end_time” of the scheduled item may not be the true end time of the > underlying event. When scheduling connections we schedule them for some fixed > amount of time. This is done to guarantee that all connections get a place in > the scheduler queue. When the schedule item executes at “start_time” and the > item is a connection event, the connection code will keep the current > connection going past the “end_time” of the scheduled event if there is more > data to be sent and the next scheduled item wont be missed. So you may think > you have a gap between scheduled events when in reality the underlying code > is still running. > 6) For better or worse, scanning events are not on the scheduler queue; they > are dealt with in an entirely different manner. This means that the > underlying PHY could be used when there is nothing on the schedule queue. > > I have an idea of what you are trying to do and it might end up being a bit > tricky given the current code implementation. You may be better served adding > an item to the schedule queue but it all depends on how you want to > prioritize BLE activity with what you want to do. > > Will > >> On Jan 23, 2017, at 8:56 PM, WangJiacheng <[email protected]> wrote: >> >> Hi, >> >> I’m trying to find out a free time slot between Nimble scheduled events. >> >> I try to go through all items on the schedule queue global variable >> “g_ble_ll_sched_q” to find out all the scheduled LL events near future, >> function as >> /********************************************************************************/ >> uint32_t ll_eventq_free_time_from_now(void) >> { >> struct ble_ll_sched_item *sch; >> uint32_t cpu_time_now; >> uint32_t time_free; >> uint32_t time_tmp; >> >> time_free = 1000000000; >> cpu_time_now = os_cputime_get32(); >> >> /* Look through schedule queue */ >> while ((sch = TAILQ_FIRST(&g_ble_ll_sched_q)) != NULL) >> { >> time_tmp = sch->start_time - cpu_time_now; >> if (time_tmp < time_free) >> { >> time_free = time_tmp; >> } >> } >> >> return (time_free); >> } >> /********************************************************************************/ >> >> Does above function make sense to find out the free time at any given time >> point? or any suggestion to find out the free time slot between LL events? >> >> >> Thanks, >> >> Jiacheng >> >
