CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Fastest way to set pin output
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

Fastest way to set pin output
PostPosted: Thu Jul 06, 2017 3:07 pm     Reply with quote

Ok. I know I always have weird questions but I am still playing around with outputting data to a CODEC chip.

I am running a 24EP512GP810 at 140MHz

I am outputting a 705kHz PWM out to the CODEC chip to synchronise as well looking at the OC1 interrupt. I was sending it to an external interrupt but was since playing with the OC1 interrupt.

If I am ready to send out bits to the CODEC I want them to clock out with the PWM. But I need to send the output to the pin as fast as possible to stay in sync with the PWM to clock the bit out.

I am also taking a 16bit variable and shifting left so I have the MSB to send out the PIN.

I may be doing this completely backwards but let me know if you have any thoughts.

Below is taking 4 instructions to output to the pin in the interrupt. It takes the same to set the PORTA.0 Latch as well.

Is there a way to set the pin high or low in the main and then in the interrupt just set the pin to the latch?


Code:
unsigned int pp = 0xAAAA;
#bit bit0 = pp.15
#byte PORTA = 0x0E22
#bit bitOut = PORTA.0
#bit LATA0 = 0x0E04.0
int1 ppBits = 0;


#INT_OC1
void rrr(){

bitOut = bit0;
}

/// this is in MAIN
//ppBits = bit_test(pp,15);
pp = pp<<1;
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Jul 06, 2017 9:18 pm     Reply with quote

Post the manufacturer and part number of the codec, so we can consider
the whole problem. A lot of times, if we take the poster's method and
try to optimize it, it may be a mistake. There may be a lot simpler way
to do it if we are given full information.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Thu Jul 06, 2017 9:27 pm     Reply with quote

Thanks PCM its AK4637.
I can either that the BICK and FCK from it or generate them myself.Either way I am also having an issue with the interrupt taking too long to even fire. The BICK will be at 32x22.05KHz. So by the time the interrupt fires I will be out of sync by about 1/2 bit.

I have been just playing with different configurations to see what is possible.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Jul 06, 2017 10:03 pm     Reply with quote

Quote:
I am running a 24EP512GP810 at 140MHz

I can't find this PIC, so I assume you must mean "GU" instead of GP.

This PIC has a DCI interface, which is designed to work with an audio codec. See this section of the 24EP512GU810 data sheet:
Quote:
24.0 DATA CONVERTER INTERFACE (DCI) MODULE
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Thu Jul 06, 2017 10:07 pm     Reply with quote

Yes. Sorry. I always get them mixed. But my production units will be using the 24EP256GP206. Its does not have the DCI module. I have the big Mikroe test board EasyPic Fusion 7 that I proto stuff on for new ideas. That is why I am using the bigger part. I am running the production part at the same speed though. Hope that's not too confusing.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Thu Jul 06, 2017 10:42 pm     Reply with quote

Just some more info. I am doing nothing in the main except for a output_toggle(PIN_G0); The frequency of this is only 4.39MHz. This does seem low?

Here is my fuses.
Code:

#fuses NOJTAG, IESO, PROTECT, NOWDT, DEBUG,OSCIO
#fuses NOWINDIS, NOIOL1WAY, IESO//,FRC_PS,FRC_PLL
#use delay(clock=140000000,internal=140000000)
temtronic



Joined: 01 Jul 2010
Posts: 9162
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Jul 07, 2017 5:31 am     Reply with quote

Perhaps a silly question and I don't use the 24 series but... are you using fast_io() or standard_IO() ?

Where speed is required fast_io is, well, faster.....
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Fri Jul 07, 2017 7:28 am     Reply with quote

Well. There is no such thing as a silly question.

The silly answer though is NO. I am not. Don't know how i forgot that.

I will put that in, like it should be and give it a shot. I will let you know.

Man I feel a little stupid right now. :(
jeremiah



Joined: 20 Jul 2010
Posts: 1322

View user's profile Send private message

PostPosted: Fri Jul 07, 2017 8:02 am     Reply with quote

curt2go wrote:
Just some more info. I am doing nothing in the main except for a output_toggle(PIN_G0); The frequency of this is only 4.39MHz. This does seem low?

Here is my fuses.
Code:

#fuses NOJTAG, IESO, PROTECT, NOWDT, DEBUG,OSCIO
#fuses NOWINDIS, NOIOL1WAY, IESO//,FRC_PS,FRC_PLL
#use delay(clock=140000000,internal=140000000)


Even without fast_io, that frequency is too slow. Can you post a small fully compilable example of your toggling (so others can take exactly what you are using and put into their own test beds)? That should only be <= 20 lines of code so it should be easy to generate.

I don't know that chip specifically, but some of them cannot start with the PLL running right off the bat. They will start up on the internal FRC (no PLL) instead and you have to put in the code to switch the clock source. What you are seeing sounds more like that.
curt2go



Joined: 21 Nov 2003
Posts: 200

View user's profile Send private message

PostPosted: Fri Jul 07, 2017 11:29 am     Reply with quote

I edited this. I was playing and forgot to comment out the FRC_DIV_BY_16


Code:
#include <24EP512GU810.h>

#DEVICE icd=1
#device PASS_STRINGS=IN_RAM
#device CONST=ROM
#device adc=10 *=16


// Setup configuration bits
#fuses NOJTAG, IESO, PROTECT, NOWDT, DEBUG,OSCIO
#fuses NOWINDIS, NOIOL1WAY, IESO//FRC_DIV_BY_16//,FRC_PS,FRC_PLL
#use delay(clock=140000000,internal=140000000)

void main(){

enable_interrupts(INTR_GLOBAL);

while(1){
output_toggle(PIN_G0);
}

}
temtronic



Joined: 01 Jul 2010
Posts: 9162
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jul 08, 2017 5:52 am     Reply with quote

hmm..
OK maybe another silly thing...

I see this" icd=1 ", does that mean the ICD IS enabled ? I do not use ICDs or debuggers so not sure what the syntax means.

IF so that may slow down things.

Also I assume program is compiled in 'release' mode not 'debug'...

There's only so many straws in a bale but eventually we'll pull the right one !

Jay
Alphada



Joined: 19 Jun 2017
Posts: 27

View user's profile Send private message

PostPosted: Sat Jul 08, 2017 3:44 pm     Reply with quote

Code:
#byte PORTA = 0x0E22



Is that the address of that register? am I correct?

Where do i find those addresses? on the chip datasheet or is found on the chip .h driver?

Excuse me I'm learning.
temtronic



Joined: 01 Jul 2010
Posts: 9162
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jul 08, 2017 6:18 pm     Reply with quote

In the datasheet; every PIC has 100s of pages of 'need to know' information located there.
While there is a 'core' of technology that is common to all, each series or family of PICs have specialty features....so reading is very,very important if you want to 'play with PICs'.
Alphada



Joined: 19 Jun 2017
Posts: 27

View user's profile Send private message

PostPosted: Sat Jul 08, 2017 6:49 pm     Reply with quote

temtronic wrote:
In the datasheet; every PIC has 100s of pages of 'need to know' information located there.
While there is a 'core' of technology that is common to all, each series or family of PICs have specialty features....so reading is very,very important if you want to 'play with PICs'.


Thx
newguy



Joined: 24 Jun 2004
Posts: 1903

View user's profile Send private message

PostPosted: Sat Jul 08, 2017 7:13 pm     Reply with quote

Alphada wrote:
Code:
#byte PORTA = 0x0E22


The compiler has a very nice feature, "getenv" that saves you from looking up the addresses of the special function registers (SFRs). Use it like this:

Code:
#byte PORTA=getenv("sfr:PORTA")
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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