Revision fb28b4cb7ccc9b157bedf9a506fc893f14a40969 authored by Karl Palsson on 08 March 2018, 10:57:50 UTC, committed by Karl Palsson on 08 March 2018, 10:57:50 UTC
The original author had included nice descriptions, so only a tiny bit of massaging to get it all in doxygen nicely too.
1 parent 6b40e97
HACKING
------------------------------------------------------------------------------
HACKING
------------------------------------------------------------------------------
Coding style
------------
The whole library is programmed using the Linux kernel coding style, see
http://lxr.linux.no/linux/Documentation/CodingStyle for details.
Please use the same style for any code contributions, thanks!
Amendments to the Linux kernel coding style
-------------------------------------------
1) We use the stdint types. The linux kernel accepts the abbreviated types (u8,
s8, u16 and so on) for legacy reasons. We should in general not introduce
things like types ourselves as long as they are not necessary to make our
job possible of refining the hardware and make it easier to be used. stdint
is a standard and it is not in the scope of our project to introduce a new
type standard.
2) Based on the same logic as in (1) we do not use __packed and __aligned
definitions, it is not our job to add compiler extensions. If we need to
deal with compiler incompatibility we will do that the same way we are
dealing with the deprecated attribute by introducing a normal macro that is
not in the compiler reserved keyword space.
3) We accept to write an empty body busy waiting while loop like this:
while (1);
there is no need to put the colon on the next line as per linux kernel
style.
4) We always add brackets around bodies of if, while and for statements, even
if the body contains only one expression. It is dangerous to not have them
as it easily happens that one adds a second expression and is hunting for
hours why the code is not working just because of a missing bracket pair.
Development guidelines
----------------------
- Every new file added must have the usual license header, see the
existing files for examples.
- In general, please try to keep the register and bit naming as close
as possible to the official vendor datasheets. Among other reasons, this
makes it easier for users to find what they're looking for in the
datasheets, programming manuals, and application notes.
- All register definitions should follow the following naming conventions:
- The #define names should be all-caps, parts are separated by
an underscore.
- The name should be of the form SUBSYSTEM_REGISTER_BIT, e.g.
ADC_CR2_DMA, where ADC is the subsystem name, CR2 is the register NAME,
and DMA is the name of the bit in the register that is defined.
- All subsystem-specific function names should be prefixed with the
subsystem name. For example, gpio_set_mode() or rcc_osc_on().
- Please consistently use the stdint types.
- Variables that are used to store register values read from registers or
to be stored in a register should be named reg8, reg16, reg32 etc.
- For examples on using libopencm3 see the libopencm3-examples repository.
- Doxygen is used to generate API docs, please follow that style for function
and definition commentary where possible.
Tips and tricks
---------------
SublimeText users:
- The project contains a sublime project description file with some basic
settings provided to make hacking on libopencm3 easier.
- Recommended SublimeText plugins when hacking on libopencm3:
- TrailingSpaces: Show and trim trailing line spaces.
- SublimeLinter: Run checkpatch.pl in the background while you write your
code and indicate possible coding style issues on the fly.
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...