As said in #6971, it would be nice if there's written somewhere that USEMODULE += xbee would suffice to use an XBee shield.

Also, that the UART can be specified through:

XBEE_UART ?= "1"		
CFLAGS += -DXBEE_PARAM_UART=$(XBEE_UART)

@kYc0o see my comment above: I don't think this belongs here. But feel free to create a wiki page about the xbee that explains how to use it.

But feel free to create a wiki page about the xbee that explains how to use it.

I disagree with the wiki page. Why not adding this documentation in the xbee.h driver file as doxygen documentation ?

Because this kind of documentation is not specific to the xbee. I mean, we also don't put information on how to use a device in the default example to every single sensor driver that supports SAUL...

Thinking from a newcomer with a Xbee module point of view, his first question will be how can I use it with gnrc_networking or any other networking example. So this should be somewhere in the documentation:

To use the networking application with XBee, add USEMODULE+=xbee in the Makefile of the application.

or something similar. Putting it in the doxygen is imho better regarding code and documentation maintenance.

we also don't put information on how to use a device in the default example to every single sensor driver that supports SAUL...

Sure, but I don't see this as a good reason for not doing it here. We always have to start somewhere.

Thinking from a newcomer with a Xbee module point of view, his first question will be...

Yes, very true. But the same is true for many other boards/network devices/misc modules. So I think we should find a way to gracefully 'educate' the newcomers to understand our basic concepts, instead of giving them copy-paste instructions for every single peace of code we include. Don't get me wrong, I am not whatsoever going against elaborate documentation here, I am just thinking that we should focus on more generic parts (where applicable) instead of doing things that are not going to scale...

I am not whatsoever going against elaborate documentation here, I am just thinking that we should focus on more generic parts (where applicable) instead of doing things that are not going to scale

Fine with me. Regarding documentation, I would definitely prefer to find all documentation in a single place. Doxygen is made for that and today RIOT has very nice api doc style (thanks @miri64). For example, we could even imagine to move all boards description from the wiki to Doxygen.

But for now, we can just keep the comment (with USEMODULE+=xbee) in the application Makefile ? At least the information is somewhere.

But for now, we can just keep the comment (with USEMODULE+=xbee) in the application Makefile ? At least the information is somewhere.

no :-) Thats exactly what I don't want. Then the next person puts an out-commented USEMODULE += mrf24xx in there, and the next an out-commented USEMODULE += ble_whatsoever, all with a comment that if you want to use this or that, just comment in this line... And before we notice, half of our example makefiles are clocked up with these kind of comments... So I say let's not even start this!

So I think we should find a way to gracefully 'educate' the newcomers to understand our basic concepts, instead of giving them copy-paste instructions for every single peace [sic] of code we include.

Well, there is this invention from the 60s we could use: Hypertext ;-P

What I mean: we could write a doc page for our doxygen documentation (e.g. "How to enable pluggable devices"), list all devices we support that fall into that category there and link to there any time this is applicable (or at least in the examples most beginners go into first, like e.g. gnrc_networking)

What I mean: we could write a doc page for our doxygen documentation...

Makes a lot of sense +1, let's do this documentation job in follow-up PRs

opened #7001 to keep track of the auto_init documentation topic