nrf52840_bitfields.h library has strange macros

[Hannibal]

Hello, here is the question about nrf52840_bitfields.h. Is there any problem with macros definition? For example we have such definition:

/* Bit 20 : Enable differential mode */
#define SAADC_CH_CONFIG_MODE_Pos (20UL) /*!< Position of MODE field. */
#define SAADC_CH_CONFIG_MODE_Msk (0x1UL << SAADC_CH_CONFIG_MODE_Pos) /*!< Bit mask of MODE field. */
#define SAADC_CH_CONFIG_MODE_SE (0UL) /*!< Single-ended, PSELN will be ignored, negative input to SAADC shorted to GND */
#define SAADC_CH_CONFIG_MODE_Diff (1UL) /*!< Differential */

I expected to see definition of SAADC_CH_CONFIG_MODE_Diff, as 0x1UL << SAADC_CH_CONFIG_MODE_Pos, but this if definition of SAADC_CH_CONFIG_MODE_Msk.

So I can't just write NRF_SAADC->CH[n]. CONFIG |= SAADC_CH_CONFIG_MODE_Diff.

And I have to write  NRF_SAADC->CH[n]. CONFIG |= SAADC_CH_CONFIG_MODE_Diff << SAADC_CH_CONFIG_MODE_Pos instead.

So here is the question: does it really comfortable to work with such macros? For me it creates some difficulties with code reading and writing, maybe it is possible to fix this in the next generation libraries?

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

[ovrebekk]

Hi 

The idea is to keep the value of a field and it's position in the register separated, just as it is in the register description in the product specification. 

There shouldn't really be a need for the application to access these bitfields directly. Instead we provide a series of low level drivers in the nrfx module to abstract away these macros, and all direct register access. 

Is there any reason you can't just use the nrfx_saadc driver instead?

Best regards
Torbjørn

[Hannibal]

Hi,

thank you for the answer. Yes, I wanted to use bitfields directly because for me it is much simpler and allows you to program device more flexible. I have found a lot of code in nrfx libraries that I don't need. Some extra checks and so on, that I don't really need in my program. And in some cases it is easier to simply check datasheet and write good code instead of trying to find some additional info in internet about the library because some part of it doesn't work as expected and no description about it in documentation.  So in some cases it is very convenient to use nrfx libraries, but in some cases it is easier and faster to write directly with bitfields, for example GPIOTE + PPI. I need to write only 5 lines of code instead of a lot of code from ppi example, and it was much easier to understand what do I need to do with bitfields comparing to nrfx library.

TRANSLATE with x

English

Arabic	Hebrew	Polish
Bulgarian	Hindi	Portuguese
Catalan	Hmong Daw	Romanian
Chinese Simplified	Hungarian	Russian
Chinese Traditional	Indonesian	Slovak
Czech	Italian	Slovenian
Danish	Japanese	Spanish
Dutch	Klingon	Swedish
English	Korean	Thai
Estonian	Latvian	Turkish
Finnish	Lithuanian	Ukrainian
French	Malay	Urdu
German	Maltese	Vietnamese
Greek	Norwegian	Welsh
Haitian Creole	Persian

TRANSLATE with

COPY THE URL BELOW

Back

EMBED THE SNIPPET BELOW IN YOUR SITE

Enable collaborative features and customize widget: Bing Webmaster Portal

Back

[ovrebekk]

Hi

To be honest I agree that some of the simpler peripherals are just as easy to use directly, compared to going through nrfx, such as the TIMER, GPIOTE and PPI peripherals. 

But for peripherals that are more complicated to use, such as the SAADC peripheral and all the serial interfaces (UART, SPI, TWI etc) I would strongly recommend using the nrfx drivers instead. These drivers have been tested and developed over a long period of time to make sure that they are reliable and bug free, and incorporate the required workarounds for errata issues relevant to that peripheral. 

It is also limited how much support we can provide for debugging custom driver implementations if you have any issues, so again I would only do this for peripherals that are quick and easy to configure and use. 

Back to the question of using the bitfields, the normal way to handle it for multi field registers is like this, separating each field on its own line for clarity. 

For 1 bit fields there is also a small cheat you can use, and just use the _Msk define directly, rather than using the value and the pos defines. Some examples of this:

// Enable channel 2
NRF_PPI->CHENSET = PPI_CHENSET_CH2_Msk;

// Set the COMPARE0 to CLEAR and COMPARE0 to STOP shortcuts
NRF_TIMER0->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Msk | TIMER_SHORTS_COMPARE0_STOP_Msk;

Best regards
Torbjørn

[Hannibal]

I see, I didn't want to write such a massive code, so that was my point when I have created this issue. Thank you for the answers.

[ovrebekk]

Hi 

Any code that will interface hardware registers directly should be put in a driver source file of some kind (similar to the nrfx drivers).  

Then you can present a more streamlined and efficient API to the application, and you only need to work with the bitfields when you are working on the driver itself. 

Best regards
Torbjørn