A Better Way to Implement Bit Fields

Re:A Better Way to Implement Bit Fields by nneonneo on Wednesday November 14, 2018 @05:15PM (#18454636)

IMHO it would be better to capitalize the OTG structure field names according to the standard. This would turn "avalidoven" into "AvalidOvEn", which makes much more sense: it's the "A-side session valid override enable bit", which allows the software to override the "Avalid" signal with the value from AvalidOvVal.

Also, this needs a (2017) tag.

[ Parent | on HN ]

Re:A Better Way to Implement Bit Fields by coldtea on Thursday November 15, 2018 @03:29AM (#18457734)

>which allows the software to override the "Avalid" signal with the value from AvalidOvVal.

How is "Avalid" any more meaningful though?

"The AValid signal is used to indicate if the session for an A-peripheral is valid. This signal is 1b when Vbus is above 2V"

They could use some better naming.

[ Parent | on HN ]

Re:A Better Way to Implement Bit Fields by eps on Wednesday November 14, 2018 @06:00PM (#18455037)

How is your comment even remotely relevant to the post topic?

[ Parent | on HN ]

Re:A Better Way to Implement Bit Fields by henry_bone on Wednesday November 14, 2018 @06:08PM (#18455084)

Read the article. At the end the author says

> By the way it's nice to know that the USB protocol has a bit to indicate "a valid oven". I wonder when that is used.

The bit fields he uses as an example related to USB protocol implementation.

[ Parent | on HN ]

Re:A Better Way to Implement Bit Fields by nneonneo on Wednesday November 14, 2018 @06:05PM (#18455070)

The post discusses bit-fields in the context of implementing some part of the USB OTG specification. Author makes a joke about USB having bits for “a valid oven”.

[ Parent | on HN ]