NetBurner Community Forum

I am going crazy here. I got an external IC that give me a interrupt every 20ms.
this IRQ is active low, and that is how I have my IRQ setup.
what I don't understand is when I comment out "LINE A" I can see on the scope that I am issuing a read signal, though its taking 16ms after the IRQ fires to do that, but that is another issue I don't get too.
I figured I would speed things up by not having the function call to OKI_Read and just put that line of code directly in the IRQ itself, yet when I add in "LINE A" and comment out "LINE B" I dont get any read requests anymore on the bus.

Would someone please enlighten me as to why this is & if you also have an idea why its taking 16ms to start this read would be helpful as well.


FYI, this is on the MOD5234, when I ran this on the MOD5270 it was smoking fast the read was virtually instant. The ONLY difference between these 2 boards is that the MOD5270 is talking to the chip using GPIO and the MOD5234 is using the address and data bus. I figured the address and data but method would smoke the GPIO way, but this is not the case.









//*************************************************************
//********************** GET DATA FROM OKI ***********************
//*************************************************************
BYTE OKI_Read(BYTE address)
{
return *( (unsigned char *)(CS3_ADDRESS + address));
}
//***************************************************************
//**************** OKI IRQ THAT DATA IS READY TO READ ****************
//***************************************************************
INTERRUPT(irq3_isr, 0x2300) // request to Read encoded audio
{
sim.eport.epfr |=0x08; // Clear This IRQ
BYTE x,y;

for(x=0;x<160;x++)
{
LINE A: y = *( (unsigned char *)(0x80000080));
LINE B: y = OKI_Read(0x80);
encoded_data[0] = y;
}
}

I don't get why you are writing to encoded_data[0] instead of encoded_data[x].

Also, the compiler is probably hosing you in some manner.

Try "Volatile Byte" instead of "byte" when hardware is involved and lose your optomization, make it small or something -Os

Chris

understandable, this codec has 2 IRQ's, one for transmit data and one for receive data buffers. Once the codec is initialized both of these IRQ's start firing at a rate of 20 ms.
In real code in my IRQ I have 2 if statements, if I am idle I just read to encoded_data[0] as the data I am reading is bogus anyway from the codec. If I don't read 120 bytes every time the IRQ fires the codec will stop working. When I am not idle then it starts using the encoded_data[x].

I have this working in the MOD5270 perfically, but this switch to the MOD5234 is causing me some headaches.

possibly a cache or optimization problem. try making y volatile: volatile BYTE y;
Or, try a debug build, which turns optimization off, and see if there is a difference.

thanks, i tried the volatile for both y and
*( (volatile unsigned char *)(CS3_ADDRESS + address));
with the same results. i will try the debug and see if there is any difference there.

Well allow me to answer this posts question.
"I am Just stupid!"

As I mention before this OKI chip has 2 IRQ's IRQA and IRQB, which were wired to IRQ3 & IRQ5 accordingly in the original board. When I switched to the MOD5234 I had to swap these two to make the layout routing better. The only problem is that I forgot I did that. Now that I have made IRQ3 code to be IRQ5 and visa versa it works just perfect.

HOW RUDE OF ME TO THINK IT WAS A NB SITUATION, SHAME ON ME, and 5 lashes goes to me!!!

ONCE AGAIN NB has proven itself as a AWESOME PRODUCT. I suppose I am just so trained from all the other crap out there that when I have a problem it's always been wither the compiler or an errata situation.

Glad to hear you figured it out. I think it is still a very good practice to use volatile for any variables that access external h/w. That way the code is more readable, and you know optimization will not byte you.