This commit tries to also fix the documentations of sicslowpan and
uip6 to reflect the current code state. I’m not sure if everything
makes sense.
sicslowpan: There are still some references to HC01, can this be
replaced by HC06?
uip6: Section about timers has changed, is this correct?
Doxyfile: The documentations reference static functions, to link to
them correctly EXTRACT_STATIC = YES is needed.
Congratulations you fixed 134 of doxygen's warnings (old: 134 new: 0).
This commit fixes nearly all of the reported doxygen warnings.
I tried to not clutter the log with removed trailing spaces.
Removed whitespace and converted tab/spaces for all files affected by this commit
are in a separate branch.
This commit simplifies the regression test for the doxygen build to
allow only 0 warnings.
Clean doxygen.runlog and doxygen.runerr for clean target
and ignore them in .gitignore.
This commit applies a number of improvements to the logic used when trying to drop to a CC13xx/CC26xx low-power mode:
* We identify whether there are any pending etimers by using `etimer_pending()` instead of `etimer_next_expiration_time()`. This subsequently allows us to also identify whether an etimer is set to fire at time 0.
* We run a larger portion of the code with the global interrupt disabled. This prevents a number of messy conditions that can occur if an interrupt fires after we have started the low-power sequence.
* We check whether there are pending events earlier in the sequence.
* We make sure to schedule a next wakeup event even when an LPM module prohibits deep sleep and forces sleep instead.
This fixes some of the issues discussed in #1236
The AON RTC CH1 event handler aims to schedule the next compare event on the next 512 RTC counter boundary. However, the current calculation of "now" takes place too early within the interrupt handler. In some cases, this results in the next event getting scheduled too soon in the future or on some extreme cases even in the past.
AON RTC compare events cannot happen within 2 SCLK_LF cycles after a clearance (4 RTC ticks in the 16.16 format). Thus, if the next 512 boundary is too soon (5 ticks for margin), we skip it altogether. When this happens, etimers that would have expired on the skipped tick will expire 1 tick later instead. Skipping a tick has no negative impact on our s/w clock counter, since this is always derived directly from the hardware counter.
The sent ICMP6 packets (for example from RPL) are currently
not counted towards the sum of sent ip and icmp packets.
Is there any reason behind this or is it just a bug?
Looking at the code I found no side effects of adding these two lines.
Debug output:
```
uip_stat.ip .recv 10 .sent 23 .forwared 0 .drop 0
uip_stat.icmp .recv 10 .sent 11 .drop 0
uip_stat.udp .recv 0 .sent 12 .drop 0
```
(Sum of ip.sent matches icmp.sent and udp.sent)
The current logic attempts to send `CMD_SET_TX_POWER` before saving the new power setting. If `CMD_SET_TX_POWER` fails the power setting will not get saved. As a result, when the RFC is powered off, all attempts to change TX power will fail.
This commit changes this logic to always save the new TX setting as requested by the user. If the RFC is powered up, we apply it immediately. If it is powered down, the new setting will automatically be applied next time we send `CMD_RADIO_SETUP`.
Fixes#1340
After page loading has finished the number of free bytes left for page attributes is logged. It turns out that "usual" pages tend to get along with ~800 bytes while i.e. the Google search pages use all of the 2000 bytes of page attribute memory allocated by default (because of the long URLs with many parameters). So it seems that reducing this default isn't exactly the best way to reduce memory consumption...
CC_FASTCALL was introduced many years ago for the cc65 tool chain. It was never used for another tool chain. With a798b1d648 the cc65 tool chain doesn't need CC_FASTCALL anymore.
