 |
 |
| View previous topic :: View next topic |
| Author |
Message |
norm
Joined: 19 Aug 2010
Posts: 4
|
| No DAC output on RA2. PIC18F45K22 |
 Posted: Tue Sep 07, 2010 1:06 pm |
 |
|
I'm single stepping through the dac_out lines of code in the MPLAB v 8.53
Using CCS PCH 4.110
I've tried using the setup_dac and dac_write functions, they don't effect the correct registers locations. So I'm manipulating those directly.
Registers are changing the way I would expect, but no output.
What am I missing?
Norm
| Code: |
/* PIC 18F45K22 - E-tools CAC Drawer Control Program */
/* Part# 209-0046-C00-00 0 */
/* E-tools CAC Interface 201-0073-C00-00 */
/* */
/* */
#include <18F45K22.H>
#include <stdio.h>
#include <pic18math.c>
//#fuses RC, NOLVP, NOPROTECT, WDT, NOPUT, BROWNOUT
#fuses INTRC_IO, NOLVP, NOPROTECT, NOWDT, NOPUT, BROWNOUT // Used during debug
#use delay(clock=4000000)
// PIC 18F45k22 Register/Bit definitions
#byte SSP1ADD = 0xFC8 // i2c address location in slave mode
#byte SSP1CON1 = 0xFC6 // i2c
#bit SSP1EN = SSP1CON1.5
#byte SSP1CON2 = 0xFC5 // i2c
#byte SSP1CON3 = 0xFCB // i2c
#byte SSP1STAT = 0xFC7 // i2c
#byte PIR1 = 0XF9E
#byte PIR2 = 0XFA1
#byte CCP1CON = 0XFBD
#byte RCSTA1 = 0XFAB
#bit CREN = RCSTA1.4
#bit OERR = RCSTA1.1
#bit FERR = RCSTA1.2
#byte RCREG1 = 0XFAE
#bit TMR1IF = PIR1.0
#bit TMR2IF = PIR1.1
#bit CCP1IF = PIR1.2
#bit RCIF = PIR1.5
#bit CCP2IF = PIR2.0
#byte TIMER_1_LOW = 0xFCE
#byte TIMER_1_HIGH = 0xFCF
#byte ADCON1 = 0xFC1
#bit NVCFG_0 = ADCON1.0
#bit NVCFG_1 = ADCON1.1
#bit PVCFG_0 = ADCON1.2
#bit PVCFG_1 = ADCON1.3
#byte ADCON2 = 0xFC0
#bit ACQT_0 = ADCON2.3
#bit ACQT_1 = ADCON2.4
#bit ACQT_2 = ADCON2.5
#byte CCPTMRS1 = 0xF48
#bit C4TSEL_0 = CCPTMRS1.0
#bit C4TSEL_1 = CCPTMRS1.1
#byte VREFCON0 = 0xF42
#bit FVRS_0 = VREFCON0.4
#bit FVRS_1 = VREFCON0.5
#bit FVREN = VREFCON0.7
#byte WPUB = 0xF61
#byte INTCON2 = 0xFF1
#bit RBPU = INTCON2.7
#byte TRISC = 0xF94
#bit DSDA = TRISC.4
#bit DSCL = TRISC.3
#byte LATC = 0xF8B
#bit SDA = LATC.4
#bit SCL = LATC.3
#byte ANSELA = 0xF38
#byte ANSELB = 0xF39
#byte ANSELC = 0xF3A
#byte ANSELD = 0xF3B
#byte ANSELE = 0xF3C
#byte VREFCON1 = 0xF41
#byte VREFCON0 = 0xF42
#byte VREFCON2 = 0xF40
#byte dac_out = 0xF40
void initialize_controller()
{ /* set peripherals up */
disable_interrupts(GLOBAL);
setup_oscillator(OSC_4MHZ,0);
// Disable Analog channels that are not going to be used.
ANSELA = 0;
ANSELB = 0;
ANSELC = 0;
ANSELD = 0;
ANSELE = 0;
// Setup DAC for internal 2.048V refence
VREFCON1 = 0xC8;
VREFCON0 = 0xA0;
/* Set port pins to inputs or outputs 1 - inputs, 0 - output */
set_tris_a( 0XEC );
enable_interrupts(INT_TIMER1);
enable_interrupts(GLOBAL);
} /****************** END OF initialize_controller() ********************/
void main()
{
unsigned char half_sec_counter, dummy;
// Single pass after reset.
initialize_controller();
dac_out = 31; // Full scale
dac_out = 15;
dac_out = 23;
dac_out = 7;
dac_out = 0;
// Infinte Loop
while (TRUE)
{
} /*************** End of Infinite Loop ***************/
} /*********************** end of main ***************************/ |
|
|
 |
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Tue Sep 07, 2010 1:42 pm |
|
|
You're setting up interrupts for timer1 with no ISR defined.
This is very bad. Until you have an ISR defined (even if it does nothing), you should removed/comment out the enabled_interrupts() -- Both of them.
Why are you enabling timer1 anyway?
lastly,
You're stepping through the outputs without a delay. What are you looking at the output with? A DMM? The code steps through the output at the rate of the instructions with NO DELAY.
your DMM might not show it.
Now if you're using a scope, that's different.
Try writing a test example for us using the right CCS functions so we can look at the .LST file too. If it turns out the wrong locations are in the output, we (you) need to report it to CCS right away so they can fix it.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
MikeP
Joined: 07 Sep 2003
Posts: 49
|
|
| Posted: Tue Sep 07, 2010 2:13 pm |
|
|
| Did you read the part in the data sheet about DACOUT needing a output buffer. see 22.6 and figure 22-2 |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Tue Sep 07, 2010 2:26 pm |
|
|
| MikeP wrote: | | Did you read the part in the data sheet about DACOUT needing a output buffer. see 22.6 and figure 22-2 |
If he's using a DMM, just as a test, he shouldn't need one yet..
but yes... You will need an output buffer if you want a load unaffected by the DAC source impedance.
Anyway:
I just tried this code and then updated to compiler 4.112 (from 4.111) and found that 4.111 does have address issues where 4.112 does not.
If you can upgrade, try this code and see if it works. I don't have a 45K22 target to test against.
-Ben
| Code: |
//////// Program memory: 16384x16 Data RAM: 512 Stack: 31
//////// I/O: 36 Analog Pins: 28
//////// Data EEPROM: 256
//////// C Scratch area: 00 ID Location: 200000
//////// Fuses: LP,PROTECT,NOPROTECT,BROWNOUT_NOSL,NOBROWNOUT,WDT1,NOWDT
//////// Fuses: BORV45,PUT,NOPUT,CPD,NOSTVREN,STVREN,NODEBUG,DEBUG,NOLVP,WRT
//////// Fuses: NOWRT,WRTD,NOIESO,NOFCMEN,NOPBADEN,CCP2B3,WRTC,WRTB,EBTR
//////// Fuses: NOEBTR,EBTRB,CPB,NOLPT1OSC,NOMCLR,NOXINST,NOHFOFST,NOPLLEN
//////// Fuses: PRIMARY_SW,TIMER3B5,CCP2C0,BROWNOUT,WDT8,NOEBTRB,ECL,EC_IO
//////// Fuses: EC,INTRC_IO,H4,HS,PLLEN,FCMEN,BROWNOUT_SW,BORV27,WDT
//////// Fuses: WDT_NOSLEEP,WDT16384,WDT4096,WDT1024,WDT256,WDT64,WDT16,WDT2
//////// Fuses: PBADEN,NODELAYINTOSC,CCP2D2,LVP,NOCPB,NOWRTC,NOWRTD,INTRC,RC
//////// Fuses: PRIMARY_ON,BORV20,WDT_SW,WDT8192,WDT512,WDT32,CCP2C1
//////// Fuses: TIMER3C0,XINST,NOWRTB,RC_IO,IESO,WDT32768,WDT128,LPT1OSC
//////// Fuses: NOCPD,XT,WDT2048,MCLR,BORV42,WDT4,ECL_IO
#include <18F45k22.h>
#device *=16
#fuses INTRC_IO, NOLVP, NOPROTECT, NOWDT, NOPUT, BROWNOUT // Used during debug
#use delay(clock=4M, int=4M)
void main () {
unsigned int x;
#if getenv("VERSION") == 4.111
setup_dac(DAC_VDD | DAC_OUTPUT);
#elif getenv("VERSION") >= 4.112
setup_dac(DAC_VSS_VDD | DAC_OUTPUT);
#endif
while(1) {
for (x=0; x < 31; x +=2) {
dac_write(x);
delay_ms(125);
}
}
}
|
EDIT: I asked CCS (just now) about the DAC section of the help file that mentions the #USE DELAY it mentions MUST be added.
It's an "option" for PIC's that can use a separate clock for the DAC. I don't quickly (but verify my eyeballs and quick scan) that the 18F45k22 has this feature, so "MUST* is a mis-use of the word and the AUX options do not need to be added to #USE DELAY with this PIC.
Remember, READ THE DATASHEET for the PIC. (you're doing that, I can tell, but not completely) and also remember to report bugs like bad register addresses so you get your free upgrade to something that fixes those bugs!
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
Last edited by bkamen on Tue Sep 07, 2010 2:35 pm; edited 2 times in total |
|
|
norm
Joined: 19 Aug 2010
Posts: 4
|
|
| Posted: Tue Sep 07, 2010 2:29 pm |
|
|
The ISR is an artifact from the larger chunk of code. Code behaves the same in the larger chunk of code.
I'm executing the code one line at time using the MPLAB and ICD3.
So there is plenty of time for the output to stablize between lines of code.
I'm using a DMM to measure the output.
The DACOUT pin is driving the input of a non-inverting buffer in my circuit.
In the CCS manual, it talks about needed the Aux added to the #USE DELAY. Any idea what that is supposed to be doing? |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Tue Sep 07, 2010 2:36 pm |
|
|
| norm wrote: |
In the CCS manual, it talks about needed the Aux added to the #USE DELAY. Any idea what that is supposed to be doing? |
See my previous message. I just edited that to answer this exact question.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
norm
Joined: 19 Aug 2010
Posts: 4
|
|
| Posted: Wed Sep 08, 2010 6:54 am |
|
|
The 4.112 compiler helps the situation.
It's clearer using the functions.
I was writing a 0xC8 instead of a 0xA8 to VREFCON1 register.
Thanks for the help.
Norm |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Wed Sep 08, 2010 9:57 am |
|
|
| norm wrote: | The 4.112 compiler helps the situation.
It's clearer using the functions.
|
Well, the functions look nice -- but if you broke them down, they'd look a lot like what we'd all have to write anyway. :D
Look at official microchip Cxx code sometime (Microchip libraries are free downloads written for C18, C30, C32).
It's.... interesting..
| Quote: |
I was writing a 0xC8 instead of a 0xA8 to VREFCON1 register.
|
oops. We *never* make mistakes like that. 
Glad it's working now for you.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
