| Author |
Message |
Roman Mashak
Guest
|
 Posted:
Fri Dec 10, 2004 5:56 am Post subject:
Re: SPI slave on ATmega162: transferring data |
|
|
Hello, Mark!
You wrote on Thu, 09 Dec 2004 15:35:51 GMT:
MB> And if the LED0_blink() takes longer than 8 SCK cycles to execute,
MB> you're going to have problems with continuous data. If LED0_Blink()
MB> simply sets a flag so that the main routine can blink the LED,
MB> you may be OK.
Yeah,, may be that's the main issue. My LED0_blink() function is pretty
dumb and I'm not sure it's fast enought to jump out of ISR:
void LED0_blink(void)
{
uint8_t i=0;
DDRC = 0x01;
// flash LED (LED is inverse)
PORTC &= ~(1 << PC0);
for (i = 0; i < 50; i++) {
_delay_loop_2(100);
}
// down LED
PORTC |= (1 << PC0);
for (i = 0; i < 50; i++) {
_delay_loop_2(100);
}
}
MB> You haven't said what SCK rate is being used by the master. If
MB> the slave is being implemented on an 8MHz machine, I suspect it
MB> may not like SCK signals in excess of 2MHz. If the SCK is
MB> 2Mhz, You don't have a lot of machine cycles to respond
MB> to the interrupts.
SCK rate of master is 500KHz
MB> I would suggest starting with a clock rate in the 100KHz region,
MB> with perhaps a millisecond between transfers at the host end.
MB> When that works, you can start increasing the SCK rate.
MB> One of the nice things about being an SPI slave is that you
MB> don't really have to worry about slow clock rates.
With best regards, Roman Mashak. E-mail: mrv@tusur.ru |
|
| Back to top |
|
 |
Gary Kato
Guest
|
| Posted:
Fri Dec 10, 2004 8:02 am Post subject:
Re: SPI slave on ATmega162: transferring data |
|
|
| Quote: | My LED0_blink() function is pretty
dumb and I'm not sure it's fast enought to jump out of ISR:
|
Always do as little as possible in your interrupt service routines. |
|
| Back to top |
|
|
Meindert Sprang
Guest
|
| Posted:
Fri Dec 10, 2004 11:02 am Post subject:
Re: SPI slave on ATmega162: transferring data |
|
|
"Roman Mashak" <mrv@tusur.ru> wrote in message
news:cpas34$1u4i$1@mpeks.tomsk.su...
| Quote: | Hello, Meindert!
You wrote on Thu, 9 Dec 2004 15:27:20 +0100:
??
MS> Almost. You do not detect whether you are at the end of the array or
MS> ready sending data.
I don't have any array, I'm sending just 1 byte.
|
Yes, but you're sending it over and over again until you hit the reset
button.
Meindert |
|
| Back to top |
|
|
Roman Mashak
Guest
|
| Posted:
Fri Dec 10, 2004 11:15 am Post subject:
Re: SPI slave on ATmega162: transferring data |
|
|
Hello, Meindert!
You wrote on Fri, 10 Dec 2004 07:02:42 +0100:
MS>>> Almost. You do not detect whether you are at the end of the array or
MS>>> ready sending data.
??>> I don't have any array, I'm sending just 1 byte.
MS> Yes, but you're sending it over and over again until you hit the reset
MS> button.
Do you mean, some flag indicating the status of process should be included
in code?
With best regards, Roman Mashak. E-mail: mrv@tusur.ru |
|
| Back to top |
|
|
Meindert Sprang
Guest
|
| Posted:
Fri Dec 10, 2004 12:09 pm Post subject:
Re: SPI slave on ATmega162: transferring data |
|
|
"Roman Mashak" <mrv@tusur.ru> wrote in message
news:cpbeu5$2mtm$1@mpeks.tomsk.su...
| Quote: | Hello, Meindert!
You wrote on Fri, 10 Dec 2004 07:02:42 +0100:
MS>>> Almost. You do not detect whether you are at the end of the array
or
MS>>> ready sending data.
??>> I don't have any array, I'm sending just 1 byte.
MS> Yes, but you're sending it over and over again until you hit the
reset
MS> button.
Do you mean, some flag indicating the status of process should be included
in code?
|
Well, it depends on what you want to achieve. Your original code sent out a
string, there you have to test for the end of the string. Later, you changed
your code to send only one byte, to see what went wrong. But that code keeps
sending indefinately because of the interrupt routine that gets called after
you send the first and only byte 'manually'. Oh, and as other already
pointed out: in an interrupt routine that runs very frequently (do you
actually know how often it is executed? You should!), you cannot blink a LED
and then wait in a nested loop. During that loop, the interrupt routine
might get called another few 10-100 thousand times but not executed because
the processor inhibits interrupts unless you enable them explicitly within
the interrupt handler. If all this sounds like chinese to you, with all
respect try something more easy to achive until you thoroughly understand
what the processor is doing during interrupts.
Meindert |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in