MCP 4921 DAC CODE not updating. - Page 1
Forum section: electronics / general

author: diyaudio
author_rank: Frequent Contributor
timestamp: April 16, 2014, 11:52:47 am
content: Hi all.I have a strange issue and unable to come to a logical reason why my code is behaving strangely.The code below updates the MCP 4921 DAC with the dac code incremented/decremented from a rotary encoder CCW or CW, when I turn clockwise the code increases, if I decrement the code decreases, so everything is fine here.The problemwhen I use the tracking variable dac_code_adj" it doesn't seem to "update" the DAC output, I have a LCD and the code is clearly displaying increase/decrease values as I turn the rotary encoder, Here is the strange part, if I use the same number as a hard-code the value, I can see the DAC output the voltage. I have no idea why its behaving this way.Code:volatile const int dac_fine_code_inc = 1;volatile const int dac_course_code_inc = 50;volatile const int dac_max = 2515;volatile const int dac_min = 0;volatile int dac_code_adj;// Rotraty encoder will trigger CN for CCW OR CWvoid __attribute__((__interrupt__,__auto_psv__)) _CNInterrupt(void){/*When a CN interrupt occurs, the user should read the PORT register associated with the CNpin(s). This will clear the mismatch condition and set up the CN logic to detect the next pinchange. The current PORT value can be compared to the PORT read value obtained at the lastCN interrupt to determine the pin that changed.The CN pins have a minimum input pulse-width specification. Refer to the ?ElectricalCharacteristics? section of the specific device data sheet for further details.*/process_rotray_encoder();rotray_ready = 1;IFS1bits.CNIF = 0; // Clear flag for on change interrupt}int main(void){init_system_setup();while(1){system_process();}return (EXIT_SUCCESS);}void system_process(void){__delay_us(10);// DAC SPI config + DAC code.dac_write( 0x5, dac_code_adj );// Display code.unsigned char* buf;itoa( buf, dac_code_adj, 10 );}void dac_write(unsigned short config, int data){int result = (data | (config << 12));CS_DAC = 0;SPI1BUF = result;while(!SPI1STATbits.SPIRBF);CS_DAC = 1;}void process_rotray_encoder(void){if( read_encoder() == DIR_CW){dac_code_adj += dac_course_code_inc;}else if( read_encoder() == DIR_CCW ){dac_code_adj -= dac_course_code_inc;}if( dac_code_adj < dac_min ){dac_code_adj = dac_min;}else if ( dac_code_adj > dac_max){dac_code_adj = dac_max;}}

author: dannyf
author_rank: Super Contributor
timestamp: April 16, 2014, 12:15:51 pm
content: No one knows how read encoder works.in cases like this, try to break the code and debug individual pieces. For exaple, in the main manually increment or decrement dac code adj and see if the dac output follows, and go from there.

author: diyaudio
author_rank: Frequent Contributor
timestamp: April 16, 2014, 12:23:56 pm
content: Quote from: dannyf on April 16, 2014, 12:15:51 pmIts funny you mention that I actually have this, it sits on the timer and is called every 1 second. only when the #define TEST_DAC_STEP is defined. Let me try that,Code:void dac_step_test(void){if( m_mode == 1){dac_code_adj += 100;}else{dac_code_adj -= 100;}if( dac_code_adj < dac_min ){m_mode = 1;dac_code_adj = dac_min;}else if ( dac_code_adj > 2515){m_mode = 0;dac_code_adj = 2515;}}

author: dannyf
author_rank: Super Contributor
timestamp: April 17, 2014, 11:29:36 am
content: It shouldn't be this difficult. Try this and see what yo observe on the dac outputCode:void system_process(void){static unsigned char sdac_code_adj=0; //led it round out at 0xff__delay_us(10);// DAC SPI config + DAC code.dac_write( 0x5, sdac_code_adj );// Display code.unsigned char* buf;itoa( buf, sdac_code_adj++, 10 );}

author: diyaudio
author_rank: Frequent Contributor
timestamp: April 17, 2014, 02:00:36 pm
content: Quote from: dannyf on April 17, 2014, 11:29:36 amGot busy with real work, im back now.Yes, I tried direct variable assignment, and it works as expected (also as you presented here). I think its a variable scope issue, i haven't used static in the inside function block though.im not sure, its probably something very simple that im overlooking.. ?? bah!