+1 for efficiency. All the best Wayne
On 23 June 2016 at 23:42, Vipul Rahane <[email protected]> wrote: > +1 for efficiency. > > Regards, > Vipul Rahane > > > On Jun 23, 2016, at 2:35 PM, chris collins <[email protected]> wrote: > > > > I would also favor efficiency over genericness in this case since > > cputime is fundamental to time-critical tasks. It will mean more > > configuration for the application developer, but I don't see a way > > around that. > > > > On Thu, Jun 23, 2016 at 1:33 PM, will sanfilippo <[email protected]> > wrote: > >> Hello: > >> > >> I wanted to post a question to the dev list to see if folks had > opinions regarding the following topic. As others have stated “this will be > a long and dry email” so be forewarned… > >> > >> HAL cputime was developed to provide application developers access to a > generic, high resolution timer. The API provided by the hal allows > developers to create “timers” that can be added to a timer queue. The API > also provides a set of routines to convert “normal” time units to hw timer > “ticks”. The timer queue is used to provide applications with a callback > that will occur at a given ‘cputime’. The term ‘cputime’ refers to the > underlying timebase that is kept by the hal. Cputime always counts in tick > increments, with the time per tick dependent on the underlying HW timer > resolution/configuration. > >> > >> The main impetus behind creating this HAL was for use in networking > stacks. BLE (bluetooth low energy) is a good example of such a stack. The > specification requires actions to occur at particular times and many of > these actions are relatlive to the transmission or reception time of a > packet. The cputime HAL provides a consistent timebase for the BLE > controller stack to interface to the underlying HW and should provide a > handy abstraction when porting to various BLE transceivers/socs. > >> > >> Using the current nimBLE stack (mynewt’s BLE stack) as example, the > stack instantiates cputime using a 1 MHz clock. This means that each > cputime tick is 1 usec. This timebase was chosen as it provides enough > (more than enough!) resolution for the BLE stack and is in a time unit that > is a common factor of any time interval used in the specification. For > example, advertising events are in units of 625 usecs and connection > intervals are in units of 1250 usecs. > >> > >> While using a 1 usec timebase has its advantages, there are > disadvantages as well. The main drawback is that on some HW this timebase > would require use of a higher power timer. For example, the nrf52 has a low > power timer (they call it the RTC) but this timer has a minimum resolution > of 30.517 usecs as it is based on a 32.768kHz crystal. In its current > incarnation, hal cputime cannot support this timer as the minimum clock > frequency accepted by this hal is 1 MHz. > >> > >> So, this (finally!) leads to the question I want to ask the community: > how does the community feel about sacrificing “genericness” for > “efficiency”? If it were up to me, I would sacrifice genericness for > efficiency in a microsecond (forgive the bad pun!) in this case. Let me go > into a bit more detail here. It should be obvious to the reader that there > are neat tricks you can play when dividing by a power of 2 (it is a simple > shift right). In the case of a 32.768 kHz crystal, each tick is 1/32768 > seconds in length (this is where we get the ~30.517 usec tick interval). > What I would like to do is have a compile time definition specifying use of > a 32.768 kHz crystal for cputime. How this gets defined is outside the > scope of this email. It may be a target variable, something in a pkg.yml > file or a newt feature. With this definition the API that converts ticks to > usecs (and vice versa) does a shift instead of a divide or multiply. On the > nrf51 this can lead to quite a large savings in time. Using the C library > 64-bit divide routine that mynewt uses, it takes about 60 usecs to perform > this divide. When we shift a 64-bit number to perform the divide this time > gets down to 4 or 5 usecs (slightly more than an order of magnitude > savings!). Of course, on faster processors or processors that support > faster divides this might be a moot point, but for those using the nrf51 it > is not. > >> > >> Now you may say “you could have done the same thing in your current HAL > cputime with a 1 MHz clock”. In this case, the routine to “convert” ticks > to usecs (and vice versa) would simply return the number passed in. I would > like to make this change as well personally. Seems quite a big win (and > would also save some code space too!). > >> > >> Comments? > >> > >> Will > >> > >> > >
