Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

drivers/can: fix doxygen documentation + typo #7289

Merged
merged 1 commit into from
Jul 3, 2017

Conversation

aabadie
Copy link
Contributor

@aabadie aabadie commented Jul 2, 2017

I found some problems in the CAN doxygen documentation:

  • some typos
  • grouping problems

This PR solves the 2.

@aabadie aabadie added Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation Area: doc Area: Documentation labels Jul 2, 2017
@aabadie aabadie added this to the Release 2017.07 milestone Jul 2, 2017
@aabadie aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jul 2, 2017
@@ -7,7 +7,7 @@
*/

/**
* @ingroup native_cpu
* @ingroup candev_linux
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this name... And technically it is in both, so I would keep the removed line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If one keeps the two, it results in a very weird rendering of the parent groups breadcrumbs. I think removing is one of the best solution.
Maybe I can add a ref to native_cpu: @see native_cpu ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

C-files aren't rendered by our doxygen-config anyways (so there are no breadcrumbs), and @smlng made a move to do that grouping for C-files.

@@ -7,9 +7,9 @@
*/

/**
* @ingroup native_cpu
* @ingroup drivers_can
* @defgroup candev_linux SocketCAN driver
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about drivers_candev_linux instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense

drivers/doc.txt Outdated
/**
* @defgroup drivers_can CAN Drivers
* @ingroup drivers
* @ingroup can
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(don't know where this is defined, but) we don't have a directory can in RIOTBASE, so NACK for the name alone. Second, why do we need it? Third, why ist there a whole subgroup under drivers, just for CAN alone?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because CAN is also a separate stack. This group is defined in sys/include/can/doc.txt. There other opened PR (I 3 or 4) that will provide CAN hardware driver. I was unsure if it should go in the netdev_drivers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LoRa is a seperate stack, too. This doesn't imply that it needs a whole new group. If can devices don't fit into drivers_netdev for some reason (because CAN isn't networking (?)) how about renaming it to something like "communication devices"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renaming it to something like "communication devices"

Do you mean renaming "Network Device Drivers" (drivers_netdev) to "Communication Device Drivers" (drivers_communication) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but I don't get, why we can't keep the name, just because CAN doesn't use the netdev API... After all, CAN stands for Controller Area Network ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For simplicity, we can keep drivers_netdev, but the displayed name can become "Communication Device Drivers".

After all, CAN stands for Controller Area Network ;)

Sure!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I even would keep the displayed name...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I don't even know, why it has its own API... Looking at the API, all of that could have been done with netdev...

@@ -7,16 +7,14 @@
*/

/**
* @ingroup can
* @defgroup can_dll Data Link Layer
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sys_can

* @defgroup can_dll Data Link Layer
* @ingroup can
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sys

* @defgroup can_common Common
* @ingroup can
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sys_can

@@ -7,8 +7,8 @@
*/

/**
* @ingroup can
* @defgroup can_common Common
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sys_can_common

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Names should adhere to the doc group naming scheme and this PR doesn't fix the grouping IMHO.

@@ -7,12 +7,11 @@
*/

/**
* @defgroup can_isotp ISOTP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sys_can_isotp

@aabadie
Copy link
Contributor Author

aabadie commented Jul 2, 2017

Names should adhere to the doc group naming scheme and this PR doesn't fix the grouping IMHO.

For the moment, I'll update it so that it does

@aabadie
Copy link
Contributor Author

aabadie commented Jul 2, 2017

@miri64, comments addressed:

  • drivers_can is now a subgroup of drivers_netdev
  • sys_can is now a subgroup of net

I removed the multi-parent grouping because of the bad breadcumbs rendering and put @see instead for cross referencing sys_can and drivers_can from each other.

* @defgroup drivers_can CAN Drivers
* @ingroup drivers_netdev
* @brief Drivers for CAN devices
* @see sys_can
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add a @note These devices are not covered by the @ref drivers_netdev_api?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and add but by the @ref drivers_candev "candev API"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miri64, comments addressed.

@@ -7,12 +7,11 @@
*/

/**
* @ingroup can
* @defgroup isotp ISOTP
* @defgroup sys_can_isotp ISOTP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please pull up the wording from the brief up here (without the ISO number), but leave the @brief as is? ISOTP isn't really saying anything to me ;-).

@aabadie
Copy link
Contributor Author

aabadie commented Jul 3, 2017

@miri64, are you ok with this one ?

Copy link
Member

@miri64 miri64 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from some nitpicks: ACK. Please squash

@@ -7,15 +7,14 @@
*/

/**
* @ingroup can
* @defgroup conn_can Connection
* @defgroup sys_conn_can Connection
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpicky: sys_can_conn

@@ -7,16 +7,15 @@
*/

/**
* @defgroup drivers_can transceiver
* @ingroup drivers
* @ingroup drivers_trx_can
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpicky: sys_can_trx

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you mean drivers_can_trx

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes :-)

@@ -7,12 +7,11 @@
*/

/**
* @ingroup can
* @defgroup isotp ISOTP
* @defgroup sys_can_isotp ISO transport protocol over CAN (ISO15765)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the ISO number can be removed here.

@aabadie
Copy link
Contributor Author

aabadie commented Jul 3, 2017

@miri64, remaining nits addressed, directly squashed.

@miri64 miri64 merged commit 7ea64e3 into RIOT-OS:master Jul 3, 2017
@aabadie aabadie deleted the can_fix_doc branch February 26, 2018 11:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: doc Area: Documentation CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants