The naming of the 'help wanted' section is unclear, and unhelpful.
Additionally, most of the items listed in it are not actually part of
the contribution process:
- While *Documentation* is welcome, it is not helpful to document the
kinds in the contributing document. The contributing document should
document *how*, not *what*.
- The *Issues* section is out of place: I doubt anyone will look at the
*contributing guidelines* to find out how to open an issue.
The content is also pretty self-explanatory.
- What's left is only 'Contributing Code', so promote it!
The previous favicon was a 35x40 png file. Some (if not all) browsers
stretch the icon to a square. This stretched the original favicon
without keeping the aspect ratio. This commit replaces the favicon with
a square 128x128 png image.
It turns out hooking up an unused peripheral to a disabled GCLK
leads to surprising power savings.
Name the GCLK to be more explicit (and since not all members of
the extended samd2x family have a GCLK7).
Turns out we can just use a non-existing GCLK ID for this, this
even saves us a real GCLK that we can use for something else.
Also make sure to disable *all* peripherals by using
`GCLK_CLKCTRL_ID_Msk` instead of relying on a magic value.
Looks like we previously missed some, since this leads to some
additional power savings:
master: 4.22 mA
this patch: 4.09 mA
This simplifies (written and compiled) code by doing a head rather than
a tail insertion of the new listener into gcoap's list.
As handling of listeners without a link_encoder is now fixed,
gcoap_get_resource_list can handles this now without having to manually
skip over the .well-known/core handler (which is not the first entry any
more now).
Incidentally, this allows the user to install a custom handler for
.well-known/core, as the default handler is now evaluated last.
The NULL case can not regularly be reached (because regularly
gcoap_register_listener sets thel link_encoder to a default one), but if
it is (eg. because an application unsets its link_encoder to hide a
resource set at runtime), the existing `continue` is a good idea (skip
over this entry) but erroneously created an endless loop by skipping the
advancement step.
