I tested today with Curiosity Nano two DACs, but with MPLAB and generating code with MCC .
DACs works good with redirect DAC3 to OPA1OUT (to portA.1)
but I have one problem,in every two seconds both DACs drops to 0V for 10ms.
I use only below code:
void main()
{
OPA1_Initialize(); //DAC to port A1
OPA1_Initialize();
DAC2_Initialize();
DAC3_Initialize();
DAC2DATL = 50;
DAC3DATL = 127;
while (1)
{
}
}
It doesn't matter for now because it's just a test, but he's acting strange.
Last edit: Boguslaw 2023-12-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will check WDT.
U have as below (copied from MPLAB:
RA1PPS=0x1B;C1OUTOP1>RA1'--------------OPA-------------------------------OPA1CON1=0x0;OPA1CON2=0x6;NCHNoConnection;PCHDAC3_OUT;//FMS No Connection; INTOE Disabled; PSS OPA1IN0+;OPA1CON3=0x0;//PTRES No reset; OFCST Calibration complete; OFCSEL Factory calibrated value in OPAxOFFSET;OPA1CON4=0x0;//OREN Disabled; HWCH Basic OPA configuration with user defined feedback; ORPOL Non Inverted; HWCL Basic OPA configuration with user defined feedback;OPA1HWC=0x0;//ORS OPAxORPPS;OPA1ORS=0x0;kontrolujeopórwyjściowydlawzmacniacza0=wyłczonaregulacja//EN Enabled; CPON Disabled; UG OPA Output;OPA1CON0=0x88;0b10001000OPA1CON0.5=0;disablechargepumpbitCPON'------------------------------------------------DAC2CON=144;'DACPSSVDD;DACNSSVSS;DACOEDACOUT2EnabledandDACOUT1Disabled;DACENenabled;DAC3CON=160doforeverDAC2DATL=127'RA2DAC3DATL=10'RA1fromOP1loop
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now works in GCbasic, but is little different on the oscilloscope.
In GCbasic sine is faster, but probably I have different configuration for system clock in MPLAB, and the sine is slightly truncated at the top
#chipPIC18F56Q71,64#optionexplicit'--------------OPA-------------------------------OPA1CON1=0x0;OPA1CON2=0x6;NCHNoConnection;PCHDAC3_OUT;//FMS No Connection; INTOE Disabled; PSS OPA1IN0+;OPA1CON3=0x0;//PTRES No reset; OFCST Calibration complete; OFCSEL Factory calibrated value in OPAxOFFSET;OPA1CON4=0x0;//OREN Disabled; HWCH Basic OPA configuration with user defined feedback; ORPOL Non Inverted; HWCL Basic OPA configuration with user defined feedback;OPA1HWC=0x0;wzmocnieniewyłczone,czyli=1//ORS OPAxORPPS;OPA1ORS=0x0;kontrolujeopórwyjściowydlawzmacniacza0=wyłczonaregulacja//EN Enabled; CPON Disabled; UG OPA Output;OPA1CON0=0x88;0b10001000OPA1CON0.5=0;disablechargepumpbitCPON'------------------------------------------------DAC2CON=144'DACPSSVDD;DACNSSVSS;DACOEDACOUT2EnabledandDACOUT1Disabled;DACENenabled;DAC3CON=160DimDACCounterasBytedimtmpasbyteDIMsinus_reg(32)ASbyteDIMsinus_wzorzec(32)ASbytesinus_reg=127,121,114,108,103,99,95,93,93,94,95,99,103,108,114,121,128,134,141,147,152,156,160,162,162,162,160,156,152,147,141,134,128sinus_wzorzec=127,102,78,56,37,21,9,2,0,2,9,21,37,56,78,102,127,152,176,198,217,233,245,252,255,252,245,233,217,198,176,152doforDACcounter=1to32DAC2DATL=sinus_reg(DACcounter)DAC3DATL=sinus_wzorzec(DACcounter)nextloop
So, after playing around with a standalone 18F26Q71 I think I finally made some sense out of how the DACs work. It certainly didn't match the way I originally read the datasheet, but here goes:
Even though there are 3 DACs with 2 selectable output pins, once you enable any DAC output on RA2/RB7 then the DAC with the highest priority will appear on one or both of the enabled output pins, with DAC1>DAC2>DAC3.
In effect there's only a single DACOUT, and if you want to use the others externally then you have to route them through OPA1 or OPA2.
If you enable more than one DAC output keep in mind the output priority since the DAC with the highest priority will appear on the enabled output pin(s). It doesn't necessarily follow how you assign the outputs in the DACxCON0 registers... priority wins.
To use all three DACs you could use something like this (regs shown in binary)-
DAC1CON0 = 10010000 // DAC1 output RA2
DAC2CON0 = 10000000 // DAC2 no assigned output (use OPA1)
DAC3CON0 = 10000000 // DAC3 no assigned output (use OPA2)
OPA1CON0 = 00001000 // EN=0, CPON=0, UG=1
OPA1CON1 = 00000111 // GSEL=000, RESON=0, NSS=111(Vss)
OPA1CON2 = 00000101 // NCH=000(NC), PCH=DAC2_OUT (OPA1 output is on RA1)
OPA1CON3 = 00000000 // FMS=000(NC), INTOE=0, PSS=00(ext in not used)
OPA2CON0 = 00001000 // EN=0, CPON=0, UG=1
OPA2CON1 = 00000111 // GSEL=000, RESON=0, NSS=111(Vss)
OPA2CON2 = 00000110 // NCH=000(NC), PCH=DAC3_OUT (OPA2 output is on RB1)
OPA2CON3 = 00000000 // FMS=000(NC), INTOE=0, PSS=00(ext in not used)
With this, since DAC1 is the highest priority if you enable any of the DACxCON0 OE0 bits for RB7, you'll get DAC1 on that pin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DAC1CON0 is actually DAC1CON ?
Read binaries with leading 0B/
With this, since DAC1 is the highest priority if you enable any of the DACxCON0 OE0 bits for RB7, you'll get DAC1 on that pin.
With this configuration, since DAC1 is the highest priority, if you were to enable any of the DACxCON0 OE0 bits for RB7, you'll still only get DAC1 on that pin.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tested today with Curiosity Nano two DACs, but with MPLAB and generating code with MCC .
DACs works good with redirect DAC3 to OPA1OUT (to portA.1)
but I have one problem,in every two seconds both DACs drops to 0V for 10ms.
I use only below code:
It doesn't matter for now because it's just a test, but he's acting strange.
Last edit: Boguslaw 2023-12-21
Do you have the WDT disabled?
In your setup above, what pins are DACs 2 and 3 being routed to?
Could you show the OPA1 register settings? I'd like to try the same thing...
Last edit: Jerry Messina 2023-12-22
I will check WDT.
U have as below (copied from MPLAB:
Yes Wadtchog was enabled, thanks.
Here is working two DACs in MPLAB, in GCbasic not work yet
Now works in GCbasic, but is little different on the oscilloscope.
In GCbasic sine is faster, but probably I have different configuration for system clock in MPLAB, and the sine is slightly truncated at the top
Last edit: Boguslaw 2023-12-22
.
Last edit: Boguslaw 2023-12-22
So, after playing around with a standalone 18F26Q71 I think I finally made some sense out of how the DACs work. It certainly didn't match the way I originally read the datasheet, but here goes:
Even though there are 3 DACs with 2 selectable output pins, once you enable any DAC output on RA2/RB7 then the DAC with the highest priority will appear on one or both of the enabled output pins, with DAC1>DAC2>DAC3.
In effect there's only a single DACOUT, and if you want to use the others externally then you have to route them through OPA1 or OPA2.
If you enable more than one DAC output keep in mind the output priority since the DAC with the highest priority will appear on the enabled output pin(s). It doesn't necessarily follow how you assign the outputs in the DACxCON0 registers... priority wins.
To use all three DACs you could use something like this (regs shown in binary)-
DAC1CON0 = 10010000 // DAC1 output RA2
DAC2CON0 = 10000000 // DAC2 no assigned output (use OPA1)
DAC3CON0 = 10000000 // DAC3 no assigned output (use OPA2)
OPA1CON0 = 00001000 // EN=0, CPON=0, UG=1
OPA1CON1 = 00000111 // GSEL=000, RESON=0, NSS=111(Vss)
OPA1CON2 = 00000101 // NCH=000(NC), PCH=DAC2_OUT (OPA1 output is on RA1)
OPA1CON3 = 00000000 // FMS=000(NC), INTOE=0, PSS=00(ext in not used)
OPA2CON0 = 00001000 // EN=0, CPON=0, UG=1
OPA2CON1 = 00000111 // GSEL=000, RESON=0, NSS=111(Vss)
OPA2CON2 = 00000110 // NCH=000(NC), PCH=DAC3_OUT (OPA2 output is on RB1)
OPA2CON3 = 00000000 // FMS=000(NC), INTOE=0, PSS=00(ext in not used)
With this, since DAC1 is the highest priority if you enable any of the DACxCON0 OE0 bits for RB7, you'll get DAC1 on that pin.
I thank you!
Trying to understand/clarify
DAC1CON0 is actually DAC1CON ?
Read binaries with leading 0B/
With this
configuration
, since DAC1 is the highest priority, if youwere to
enable any of the DACxCON0 OE0 bits for RB7, you'llstill only
get DAC1 on that pin.oops, yes. DACxCON0 should actually be DACxCON