[
https://issues.apache.org/jira/browse/MYNEWT-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261383#comment-15261383
]
William San Filippo commented on MYNEWT-85:
-------------------------------------------
The changes for this commit were fairly extensive and a bit more broad reaching
than intended. For now, I had to remove the 64-bit API for hal cputime from the
nrf51 and nrf52. This is temporary as we plan to change timers being used by
the chip in future implementations of the controller. Unfortunately, if you use
any timer other than the RTC on the chip there is no way to read the counter
nor generate an overflow without burning two output compares. Timer 0 is also
tied into the RF so that automatic PPI channels can be used to automatically
capture packet start/end times. Timer 0 is also used to start
transmission/reception at a given time by using a compare register on the
timer. Timer 0 has only 4 compare/captures; other timers have 6.
Since I am not sure if we will end up using the RTC or a different timer I did
not move hal cputime from timer 0; I decided to remove the 64-bit API in order
to free up the CC register that I needed.
Note that the timing issues occurred at the start of the connection event. The
first transmission/reception of the connection event was not always at the
proper time (it would vary based on interrupt latency). With the use of an
output compare, the timing is to the resolution of timer (1MHz or 1 usec).
If the device is late when trying to transmit it will abort the transmission.
If the device is late when going to receive we still attempt to receive as
window widening may give us enough time to receive the packet. Statistics are
counted if we are late (tx late and rx late).
> Transmit timing for certain BLE transmissions may not meet the specification.
> -----------------------------------------------------------------------------
>
> Key: MYNEWT-85
> URL: https://issues.apache.org/jira/browse/MYNEWT-85
> Project: Mynewt
> Issue Type: Improvement
> Components: Nimble
> Affects Versions: v0_8_0_beta1
> Reporter: William San Filippo
> Assignee: William San Filippo
> Priority: Critical
> Fix For: v0_9_0_rel
>
>
> Although the unplugfest went well in this regard, it could have been because
> we "exaggerated" the amount of clock drift. The current BLE controller code
> does not use an output compare to transmit a BLE frame at a specific time.
> This could cause the transmission to occur outside the BLE specification. The
> code should be modified to use the BLE transceiver HW to enforce more exact
> transmission timing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
