STM32 direct register write to DAC1,2,3.

[MT]

I have gone totally blind!

Does anyone know how to do a direct register write to DAC1,2,3 on a F303, F334, F358 to output a simple dc voltage?
I got floating PA4,5,6 despite dac enabled, clock enabled and also no data is seen in the DOR register.

In stm32f30x.h  only a offset is defined:
#define  DAC_DHR8R1_DACC1DHR                 ((uint8_t)0xFF)

The compiler is not complaining over:
DAC->DHR8R1= 127;

Despite it's totally wrong.

How are DAC1,2,3 actually defined because there is only:
#define  DAC_DHR8R1_DACC1DHR                 ((uint8_t)0xFF)
#define  DAC_DHR8R2_DACC2DHR                 ((uint8_t)0xFF)

Thanks for your effort and time!

[newbrain]

Which specific stm32f30x.h are you looking at?
In CMSIS all the DAC registers are defined in the specific processor include, e.g., in stm32f303x8.h:

Code: [Select]

typedef struct
{
  __IO uint32_t CR;       /*!< DAC control register,                                    Address offset: 0x00 */
  __IO uint32_t SWTRIGR;  /*!< DAC software trigger register,                           Address offset: 0x04 */
  __IO uint32_t DHR12R1;  /*!< DAC channel1 12-bit right-aligned data holding register, Address offset: 0x08 */
  __IO uint32_t DHR12L1;  /*!< DAC channel1 12-bit left aligned data holding register,  Address offset: 0x0C */
  __IO uint32_t DHR8R1;   /*!< DAC channel1 8-bit right aligned data holding register,  Address offset: 0x10 */
  __IO uint32_t DHR12R2;  /*!< DAC channel2 12-bit right aligned data holding register, Address offset: 0x14 */
  __IO uint32_t DHR12L2;  /*!< DAC channel2 12-bit left aligned data holding register,  Address offset: 0x18 */
  __IO uint32_t DHR8R2;   /*!< DAC channel2 8-bit right-aligned data holding register,  Address offset: 0x1C */
  __IO uint32_t DHR12RD;  /*!< Dual DAC 12-bit right-aligned data holding register,     Address offset: 0x20 */
  __IO uint32_t DHR12LD;  /*!< DUAL DAC 12-bit left aligned data holding register,      Address offset: 0x24 */
  __IO uint32_t DHR8RD;   /*!< DUAL DAC 8-bit right aligned data holding register,      Address offset: 0x28 */
  __IO uint32_t DOR1;     /*!< DAC channel1 data output register,                       Address offset: 0x2C */
  __IO uint32_t DOR2;     /*!< DAC channel2 data output register,                       Address offset: 0x30 */
  __IO uint32_t SR;       /*!< DAC status register,                                     Address offset: 0x34 */
} DAC_TypeDef;

Remember that writing to the data register is not enough, the DAC needs a trigger.
If you enabled the SW trigger by setting the TSELx [x=1,2] bits in the CR to 111, to have the data transferred to DORx [x=1,2] you must set the SWTRIGx [x=1,2] bit in the SWTRIGR register.
The bit will be cleared by the HW, signalling that the DAC is ready to accept another value.

See pages 429 onwards of the reference manual for all the registers, and page 420 for the SW trigger description.
Remember to define the pins as analog "In order to avoid parasitic consumption".

But you might instead want to use the HAL... (I know your stance on the topic).

Edit: later on in the .h, all needed bitmasks and base pointers are also defined.

[MT]

Which specific stm32f30x.h are you looking at?

Specifically the latest stm32f30x.h  dated 2015who covers 303, 334, 358, 328.

In CMSIS all the DAC registers are defined in the specific processor include, e.g., in stm32f303x8.h:

I'm not using CMSIS!   I hate CMSIS!   But i do glare into 303SPL! But im not using it!

Remember that writing to the data register is not enough, the DAC needs a trigger.

If you enabled the SW trigger by setting the TSELx [x=1,2] bits in the CR to 111, to have the data transferred to DORx [x=1,2] you must set the SWTRIGx [x=1,2] bit in the SWTRIGR register. The bit will be cleared by the HW, signalling that the DAC is ready to accept another value. See pages 429 onwards of the reference manual for all the registers, and page 420 for the SW trigger description.
Remember to define the pins as analog "In order to avoid parasitic consumption".

I'm aware of  TSEL ,etc, etc, im reading as my eyes bleed! Thats why i cant see the glory "obviousness" of ST!
But i got the impression you can write directly without using any triggers. RM0316 quote:

Depending on the loaded DAC_DHRyyyx register, the data written by the user is shifted
and stored into the corresponding DHRx (data holding registerx, which are internal
non-memorymapped registers). The DHRx register is then loaded into the DORx register
either automatically, by software trigger or by an external event trigger.

So this sign as i interpret that ""automatically" is the PCLK1 clk that shifts DHR8R1 data
into DHR1 , RM0316 also mentions one PCLK1 cycle to shift for anything that is not using trigger.

Why would you have a trigger enable register if trigger was always the default way to get data out of dac?
It makes no sense RM0316 qoute!
Bit 1 SWTRIG2: DAC channel2 software trigger
This bit is set and cleared by software to enable/disable the software trigger.
0: Software trigger disabled
1: Software trigger enabled
Note: This bit is cleared by hardware

Pins should also not float, RM0316 quote:

Once the DACx channel y is enabled, the corresponding GPIO pin (PA4, PA5 or PA6) is
automatically connected to the analog converter output (DACx_OUTy). In order to avoid
parasitic consumption, the PA4, PA5 or PA6 pin should first be configured to analog (AIN).

And the do stop float when MODER is set from Analog to GEN. Also there is OUTEN1, 2 register
bits with no explanation in the ref manual only mentioned in the register map sharing position
with BOFF, and where is DAC3 mentioned in your struct?? except for ST 303 eval main.c which
is pure bizzarness! How do you make a distinction between DAC1,2 and DAC 3 who is
actually described in RM0316 as DAC channel 2, i assumed DAC1 channel2!?!

But you might instead want to use the HAL... (I know your stance on the topic).

My stance on HAL is known!

[newbrain]

Specifically the latest stm32f30x.h  dated 2015who covers 303, 334, 358, 328.

I see, oh, actually I don't. Where can I find that file? To answer your question I went to ST.com and dowloaded the F3 cube (I know, I know...) and the ref manual.
That include file is not (AFAIK) in the cube, it seems...

I'm not using CMSIS!   I hate CMSIS!   But i do glare into 303SPL! But im not using it!

Frankly, I'm lost. You are, of course, free not to use anything else provided by CMSIS and dislike it, but the device specific include files are there, with only the register definitions, which I think is what you are somehow missing.
The stuff brought in by including "core_mx.h" is, I would say, benign enough: some more definitions and static inline functions (that will not be there in the code if you don't use them). Same for system_stm32fxxx.h.

I'm aware of  TSEL ,etc, etc, im reading as my eyes bleed! Thats why i cant see the glory "obviousness" of ST!
But i got the impression you can write directly without using any triggers. RM0316 quote:

Depending on the loaded DAC_DHRyyyx register, the data written by the user is shifted
and stored into the corresponding DHRx (data holding registerx, which are internal
non-memorymapped registers). The DHRx register is then loaded into the DORx register
either automatically, by software trigger or by an external event trigger.

So this sign as i interpret that ""automatically" is the PCLK1 clk that shifts DHR8R1 data
into DHR1 , RM0316 also mentions one PCLK1 cycle to shift for anything that is not using trigger.

You are of course right, making sure TENx bits are 0, I misinterpreted your needs.

About OUTENx/BOFFx, I have never used the F3 (only F0,4,7) but, for what I can understand, some models have got a dual DAC and a half.
DAC2 only output and DAC1 output2 are unbuffered. For those, you must set the OUTENx bit to 1 to connect the pin to the actual DAC output.
Those bits are referenced in the diagrams at the beginning of the chapter, and then explained in the register description.

My stance on HAL is known!

...but I definitely had missed your position on CMSIS!

[MT]

I see, oh, actually I don't. Where can I find that file? To answer your question I went to ST.com and dowloaded
the F3 cube (I know, I know...) and the ref manual. That include file is not (AFAIK) in the cube, it seems...

I refuse to wrestle with Cube any more particularly after their latest 200megton gorilla release!
The latest stm32f30x.h etc files is found in stm32f30x_dsp_stdperiph_lib.zip go to dedicated
STM32F303 page and look for the dsp/spl library package.Actually it contain even more devices.

Frankly, I'm lost. You are, of course, free not to use anything else provided by CMSIS and dislike it, but
the device specific include files are there, with only the register definitions, which I think is what you
are somehow missing.

Pardon?? Didn't you just say Cube didn't contain any register definitions? prior it was said it was
just the typical warpping and call back stuff! If so what is then the point of having stm32f30x.h?!
Would you mind post the section of that where DAC1,2,3 is clearly described?

The stuff brought in by including "core_mx.h" is, I would say, benign enough: some more definitions
and static inline functions (that will not be there in the code if you don't use them). Same for system_stm32fxxx.h.

Point is not having everything split up and fragmented.

The stm32fxxxxx.h files is not specifically located in CMSIS they are everywhere!Every time you download a lib or example
or template you will find all kind of files. Since im on the dark side and do only register definition coding i want a bare
minimum of files i dont want core or pheripherial (well i can accept that if it was clean) or any other abstraction garbage
i want only one file containing definitions which is stm32f30x.h file in 2007 we had all that than ST destroyed it with
SPL and HAL CMSIS.

You are of course right, making sure TENx bits are 0, I misinterpreted your needs.

If you look into stm32f3xxx_dac.h you will find the following text:

#define DAC_Trigger_None    ((uint32_t)0x00000000) /* !< Conversion is automatic once the DAC1_DHRxxxx register
                                                                                               has been loaded, and not by external trigger */

Compare that with reference manual and note the significant difference quote:
Depending on the loaded DAC_DHRyyyx register,  snip.....snip....

About OUTENx/BOFFx, I have never used the F3 (only F0,4,7) but, for what I can understand, some models have got a dual DAC and a half.

Hehe, no device have half dac!    There is 3 complete DAC's. ST just want to gorillafy the shit!
F4 has same core and most peripherals as F3, very similar device.

DAC2 only output and DAC1 output2 are unbuffered.

It do seams so!

For those, you must set the OUTENx bit to 1 to connect the pin to the actual DAC output.

What i suspected all along! vaguely describes the duality of the BOFF bit is from stm32f30x_dac.h file which
if ST had been sane would had been inside the reference manual. Still where is the definition and write
register for DAC3? How do you write to DAC1 and half?

For example writing to a PWM channel is simple....TIM2->CCR2=123;.... DAC should be equally simple.

uint32_t DAC_Buffer_Switch;      /*!< Specifies whether the DAC channel output buffer is enabled or disabled or
                                                            the DAC channel output switch is enabled or disabled.
                                                            This parameter can be a value of @ref DAC_buffer_switch */

So the conclusion we can draw from this is contrary to reference manual says it's not enough to enable DAC alone to get it going.

Those bits are referenced in the diagrams at the beginning of the chapter, and then explained in the register description.

Page please!

...but I definitely had missed your position on CMSIS!

What is the bonafide to get entangled into CMSIS if i only want to stick to one manufacturer?
thanks to ST even code on register level is not directly runnable if switching to another device in
same family, well almost but certainly not from 103, 102 to F2 or F3  etc, even code based on
old SPL and HAL has to me migrated (read: rewritten) to work!

What about spelling errors in stm32fxxxx.h files? Code that once worked with 2011
version is now defunct due to spelling errors from 2012 migrating into 2015 version!
(i just discovered that one thank you very much ST)

So what are you going to change? The register definition in the stm32f30x.h file,
or your code or the referencemanual text? Maybe we should ask ST?

[newbrain]

OK, I started late in this game, so I have no exposure to the SPL, my bad.

But you don't have any need to wrestle, if you don't want to. 200MB (about half a Giga expanded) are not that much for today's computer.

I don't see where I said that Cube does not include the reg definition, albeit I assuredly concede the eventuality that from my imperfect commandeering of the English language, not my mother tongue, ensues the failure to convey my inner elucubrations.

Cube contains a lot of stuff, HAL, BSPs, code examples, horrific documentation (doxygen...I prefer reading the code), and yes, the dreaded CMSIS.

Just for kicks, I downloaded also the SPL, and had a look at the file you mentioned. It's basically the same as the one in the Cube (did not do a diff, but they really look the same), and if you use it, you are also using CMSIS (it itself is inside the CMSIS dir tree):

Code: [Select]

#include "core_cm4.h"            /* Cortex-M4 processor and core peripherals */

DAC Register names: lines 648 onward
DAC base addresses: lines 1231-1234
DAC pointers:           lines 1344-1346
DAC bitmasks:          lines 5152 onward

You really really don't want to use CMSIS? Take this file, physically include the lines needed to define base ARM features (core_mx.h stuff) and live happy ever after.

As for DACs, it was half a dual DAC 1 Dual + 1/2 Dual = 3, that's ST math for you , F4 and F7 have only one dual DAC, both channels buffered (going from memory).
So, in the F3s with three channels, there is no DAC3, there's a DAC1 (aliased to DAC) with two channels (as in F4-7) and a DAC2 with only one unbuffered channel.
You don't write to DAC3, you write to the first channel of DAC2.

Look at the registers scheme: each configuration register has one channel in the higher and one in the lower half-word.
Data registers can be written independently or, in dual mode, both at the same time if desired.

Picture for the bits on pages 415 and 416 (see pics), description on page 417 paragraph 16.3.2 and again in the register description, pages 431 and 433.
So the ENx bits will enable the DAC, but the unbuffered channels will not be connected to the pin if you don't set OUTENx.

Have a good night,
newbrain


 

[MT]

Well its late, i just realized i been looking into V1 of RM0316, you are looking at V3 so my bad the graphics in V1 is quite different!
In the mean time ST have released V5 but labeled it as V6 on their site! prior to this i actually got hold of some dac addresses.

OK, I started late in this game, so I have no exposure to the SPL, my bad. But you don't have any need to wrestle, if you don't
want to. 200MB (about half a Giga expanded) are not that much for today's computer.

Well, host , snörvel som det heter på svenska! To download a 200megaton gorilla just to get the address of a DAC or 3 DACs in
this case each 2 bytes long and should have been inside the stm32f30x.h register definition file in the dac section from the
start is kind of insane. But if you enjoy insanity i respect that!

Cube contains a lot of stuff, HAL, BSPs, code examples, horrific documentation (doxygen...I prefer reading the code), and yes, the dreaded CMSIS.

See even you dont like CMSIS. Come, come, join the dark side!

Just for kicks, I downloaded also the SPL, and had a look at the file you mentioned. It's basically the same as the one in the Cube (did not do a diff, but they really look the same), and if you use it, you are also using CMSIS (it itself is inside the CMSIS dir tree):

No its just CIMSIfied, you can CIMSIfy anything and claim it's CMSIS.

#include "core_cm4.h"            /* Cortex-M4 processor and core peripherals */
DAC Register names: lines 648 onward
DAC base addresses: lines 1231-1234
DAC pointers:           lines 1344-1346
DAC bitmasks:          lines 5152 onward

But that we allreday know about, the register definition file, but why are you relabeling stm32f30x.h as a CMSIS file just because
ST have CMSIfied it  or whatever?? I'm confused, core_cm4.h dont contain what you counted up there,it contains only syscore stuff
like systick, nvic etc.

You really really don't want to use CMSIS?

Im completely lost, what do you mean by CMSIS? CIMSIS is just a convoluted  mess of interentangled layers and blocks of garbage
clogging up my brain which makes me constantly slide out of the flow and not a specific register definition file. CMSIS is just a name
for an atempt to standarize the way of developing code accross many manufacturers while making everyones MCU code bloated both
in speed and memory usage. That's why you should not use it. As the hocker said: the dick locks posh but it aint stiff!

Take this file, physically include the lines needed to define base ARM features (core_mx.h stuff) and live happy ever after.

What file? ST have to include whatever they should include and keep all the garbage out!
Have you ever come across lets say a MPS430 or AVR or dSPIC33, PIC32MX register definition files? There is no CIMSIS.

As for DACs, it was half a dual DAC 1 Dual + 1/2 Dual = 3, that's ST math for you , F4 and F7 have only one dual DAC, both channels buffered (going from memory). So, in the F3s with three channels, there is no DAC3, there's a DAC1 (aliased to DAC) with two
channels (as in F4-7) and a DAC2 with only one unbuffered channel. You don't write to DAC3, you write to the first channel of DAC2.
Look at the registers scheme: each configuration register has one channel in the higher and one in the lower half-word. Data
registers can be written independently or, in dual mode, both at the same time if desired. Picture for the bits on pages 415 and 416
(see pics), description on page 417 paragraph 16.3.2 and again in the register description, pages 431 and 433. So the ENx bits will
enable the DAC, but the unbuffered channels will not be connected to the pin if you don't set OUTENx.

Well, at first you didnt even know it was possible to do direct writes to DAC.So using CMSIS didnt help you at all.
Alsing DAC's etc ,yes we allredy sorted that out 2 posts ago im afraid. Yes there is a third dac. No there is no such thing as one dual
dac. Yes each dac is a block consisting of a "resistor string and a latch" the rest is just stupid ST convoluted naming. So yes there is
defenitively a physical third dac. A single dual dac or "half dac" or channell dac's as you stubbornly maintian is when exist is called a
"TDM, time divisioned multiplexed dac" who often uses a mux which no STM device have..

Btw, in v1 of RM0316 there is missing info, not my fault! Didnt you read what i initially wrote? It's quite known since long time ST refmanuals is rather poor and often in an unfinished state. Take F103 for instance ST have managed to do 15 revisions of the document! I wonder if there is any other MCU manufacturer with such a poor quality record!

But thanks anyway newbrain it was entertaining to wrestle arguments about the insanity around ST!
Btw,DAC3 is still dead!

[newbrain]

I'll just answer some point, but I won't put any more time in this.

Come, come, join the dark side!

I like to span from the dark to darkest through gray to the bright and brightest, I have no technical religion.
Linux, Win, PC, MAC, assembler, C++, direct register writes and HAL (there, I said it!) all have their place.

...just to get the address of a DAC or 3 DACs in
this case each 2 bytes long and should have been inside the stm32f30x.h register definition file....

This is the part I'm having problems with.
All the DAC reg defs you need are inside that file, and I showed you exactly where (admittedly, with a formatting slip):

Code: [Select]

DAC Register names: lines 648 onward
DAC base addresses: lines 1231-1234
DAC pointers:       lines 1344-1346
DAC bitmasks:       lines 5152 onward

That file includes also the lower level part of CMSIS (core_m3.h), that contains ARM vendor independent common registers and definition.
You don't need anything above that. If you're not comfortable with the bloat (which will just sit there, gathering bit dust), prepare your files based on this.

Should ST provide a CMSIS liberated version?
Yes, maybe. Another piece of code fro them to maintain and to keep in synch, for a very limited audience.
You are welcome to disagree.

Code: [Select]

Take F103 for instance ST have managed to do 15 revisions of the document!I don't know and do not make assumption about your experience, but rest assured that having revisions is a actually a good thing.
Humans are not perfect, and faults slip through even with finely tuned processes and reviews, especially with complex stuff.
If you have no revisions, it means the product is abandoned, obsolete or nobody is really using it.
Just from the first MCU datasheet I had on hand (ATmega 328):

Code: [Select]

41.  Datasheet Revision History
41.1    Rev. 8271I – 10/2014
41.2    Rev. 8271H – 08/2014
41.3    Rev. 8271G – 02/2013
41.4    Rev. 8271F – 08/2012
41.5    Rev. 8271E – 07/2012
41.6    Rev. 8271D – 05/11
41.7    Rev. 8271C – 08/10
41.8    Rev. 8271B – 04/10
41.9    Rev. 8271A – 12/09So, always check to have the latest docs, especially if something is not clear.

Code: [Select]

Well, at first you didnt even know it was possible to do direct writes to DAC.Do not assume what I know or don't know.

I understand perfectly how a DAC works, thanks.
My EE Master is still on the wall, last I checked (in a drawer, actually).

Whether it's good or bad that ST decided to make it easy to configure and access two DAC channels at the time, I leave to your judgement.
Dual means that, yes there are two physical DACs, but they are sharing registers and other stuff (e.g. Vref)
This not uncommon, even as nomenclature, e.g. from MCP4922 DS (emphasis mine):

Code: [Select]

The MCP4902/4912/4922 devices are _dual_ 8-bit,
10-bit, and 12-bit buffered voltage output
_Digital-to-Analog Converters_ (DACs)
It's a sunny Saturday, at least in the capital, take a break from this stuff and relax. My bike is waiting for me.

[MT]

I'll just answer some point, but I won't put any more time in this.

Your wellcome.

I like to span from the dark to darkest through gray to the bright and brightest, I have no technical religion.
Linux, Win, PC, MAC, assembler, C++, direct register writes and HAL (there, I said it!) all have their place.

Forgot to mention Commodore ,ATARI and Sinclair Spectrum.

...just to get the address of a DAC or 3 DACs in  this case each 2 bytes long and should have
been inside the stm32f30x.h register definition file....

This is the part I'm having problems with.

Problems with the stm32f30x file as file? Really? You rather download 500Mbytes just to get a single header file? Serious? For kicks?

All the DAC reg defs you need are inside that file, and I showed you exactly where (admittedly, with a formatting slip):
That file includes also the lower level part of CMSIS (core_m3.h), that contains ARM vendor independent common registers and definition. You don't need anything above that. If you're not comfortable with the bloat (which will just sit there, gathering bit dust), prepare your files based on this.

Trying to build a solid case just to write me my nose? It's more likely yourself dont know how to get DAC work, else you hadent ranted so much about the obviousness of stm32f30x.h, btw i didn't say anything more significant then stm32f30x.h....why else this thread.

Should ST provide a CMSIS liberated version? Yes, maybe. Another piece of code from
them to maintain and to keep in synch, for a very limited audience. You are welcome to disagree.

So guru Clive1 and Jan is a limited audience, well one more file would tip the ST abstraction mountain over?
Shurely mr Holmes you must be joking, as they say in the TV series.

ST issues have been brought up by ton's of people over the years, not going to do it again but just sayyou said it your self
in prior posts. ST will likely slowly drown in their own CMSIS/HAL sync "wathever" maintenance mountain. Add another CMSIS block, call it CMSIS DSP, call it CMSIS RTOS, well supprice they allready did and they will continue to CIMSIfy until you as a coder drown in convoluted abstracted gigabytes...

A software coder who cant write decent condenced clear code on bare metal using the path of least resistance is not a decent coder.
No merrits and prestige in keeping high tresholds, steep learning curves, bloated tools, complicated pheripherials etc...

Not an excuse to use xzcywhateverIOTOGGLE() just to toggle a pin and when pin dont toggle HAL/CMSIS coder turns to STM Forum
and ask Clive1 for help because ST dont give a crap! ST asked people to DISCO with them but when they enter the dance floor ST suddenly stands offside pointing fingers.

It's interesting to watch ST , CooCox etc forums 98,9 % of the questions is about why pheripherials dont work or how-do-i-get -this-pheripherial-to-work. Obvious reasons, perhaps complexity leads to CIMSIfycation backed by poor documentation.

Btw a old colleauge called the other day begging for help, he had been given by his boss a Frescale ARM device that had a timer pheripherial that had 144 registers! I told him i have 80 registers of my own to faff with, he almost cried yet the guy is a 30+years EE Master engineer, im not! Im not even a coder , im certified gardener! You are asking me to comprehend? Please newbrain step down from your high horses for a moment.

Take F103 for instance ST have managed to do 15 revisions of the document!

I don't know and do not make assumption about your experience,

Yes you do.

but rest assured that having revisions is a actually a good thing.
Humans are not perfect, and faults slip through even with finely tuned processes and reviews, especially with complex stuff.
If you have no revisions, it means the product is abandoned, obsolete or nobody is really using it.

I assume you troll, but will reply.
I have done H/W engineering for 30 years at various BIG corporations (slapping my big baugette on the desk with a splash) and gardening for 40 years  and piloting for 50 years and we have had ton's of 1.1 products with 1.1 documentation revisions rolling out of factory years upon end. Reason? Because we made sure we had professional engineering on all levels and well tought out and professionaly driven documentation processes. What you say is pure nonsense and a strawman argument! Perhaps you are one of their paid fanboys who under all circumstances want to defend ST's sloppy craftmanship, or even a ST employee?

Humans are not perfect you say while being completely "blind folded" from their spelling errors. Well do ST even use computer based
spell checkers? They do?! How come spelling errors for years is migrating into new revsions? Perhaps their spell program is based on CIMSIS and HAL? Who knows! All i know is that wen a spell error is loctaed inside a register definition file things either dont work or stop working.Its bad enough they are in reference manuals.

Just from the first MCU datasheet I had on hand (ATmega 328):

Code: [Select]

41.  Datasheet Revision History
41.1    Rev. 8271I – 10/2014 41.2    Rev. 8271H – 08/2014 41.3    Rev. 8271G – 02/2013 41.4    Rev. 8271F – 08/2012 41.5    Rev. 8271E – 07/2012 41.6    Rev. 8271D – 05/11 41.7    Rev. 8271C – 08/10 41.8    Rev. 8271B – 04/10
41.9    Rev. 8271A – 12/09So, always check to have the latest docs, especially if something is not clear.

Nice move there trying to write me on my nose, yet you used a old version 3 claming it was not possible to do direct DAC writes.
Do your homework before asking everybody else to do theirs.

Well, at first you didnt even know it was possible to do direct writes to DAC.

Do not assume what I know or don't know. I understand perfectly how a DAC works, thanks. My EE Master is still on the wall, last I checked (in a drawer, actually).

No you dont! read your own posts. No need to assume so stop writing me and others on our noses and drop the prestige stuff!

Whether it's good or bad that ST decided to make it easy to configure and access two DAC channels at the time,

Are you even aware "what" you are saying? We could possible cogitate, dwell on ,brood further on but no engineer with EE Master
i known for past 30 years have ever claimed half a DAC exist..... But you are wellcome to dissagree.

It's a sunny Saturday, at least in the capital, take a break from this stuff and relax. My bike is waiting for me.

Chill out on the bike!