- Fri Sep 07, 2007 7:53 am
#34792
I'm using the USI on an ATtiny2313 to pass some data between an SPI master (a Z80 based master) and the ATtiny.
One thing I note is the ATtiny doesn't respond to SPI input after power up until you've tried sending it several commands: with the Z80 master being run at 6MHz, usually about four or five commands will make the ATtiny spring to life, and bizarrely, if I put a 4MHz crystal onto the master, it takes about 30 retries to get the ATtiny's USI to start receiving the proper data.
Since the ATtiny2313 doesn't have a hardware CS line for the USI, this is implemented by a 74HCT125, the /EN pins of each buffer gating the inputs and outputs of the USI interface. It's possible a bit is being shifted into the USI's shift register when the whole mess is powered up - however, after running a self-test routine (taking about 5 seconds), I have this code, which I *thought* would ensure that the USI was reset and in a sane state: Since USI set-up happens 5 seconds after power up, any power-on glitches will be ancient history. The initialization code:
What I did was implement a SYNC command, which does nothing but reply with 0xAA, whose sole purpose is to allow the Z80 master to try sending the SYNC command in a loop until it gets 0xAA in response. Once this has happened, the USI works absolutely perfectly; it's not a case of bytes getting lost because the ISR isn't fast enough.
Other SPI devices (such as the SCP1000) connected to the same system don't have this problem, so there's nothing wrong with the SPI interface on the Z80 master, as far as I can tell.
While the SYNC command approach works, it would be on the whole much better if the USI interface worked right from power-up. Am I missing something in my setup routine to make this happen?
One thing I note is the ATtiny doesn't respond to SPI input after power up until you've tried sending it several commands: with the Z80 master being run at 6MHz, usually about four or five commands will make the ATtiny spring to life, and bizarrely, if I put a 4MHz crystal onto the master, it takes about 30 retries to get the ATtiny's USI to start receiving the proper data.
Since the ATtiny2313 doesn't have a hardware CS line for the USI, this is implemented by a 74HCT125, the /EN pins of each buffer gating the inputs and outputs of the USI interface. It's possible a bit is being shifted into the USI's shift register when the whole mess is powered up - however, after running a self-test routine (taking about 5 seconds), I have this code, which I *thought* would ensure that the USI was reset and in a sane state: Since USI set-up happens 5 seconds after power up, any power-on glitches will be ancient history. The initialization code:
Code: Select all
The code that deals with the incoming data is in a very short ISR (the USI overflow interrupt) which stuffs each incoming byte into a circular buffer so that the main loop can deal with what's been sent at its leisure.void usiinit(void)
{
USICR = (1 << USIWM0) | (1 << USICS1) | (1 << USIOIE);
USISR = 0;
USIDR = 0;
}
What I did was implement a SYNC command, which does nothing but reply with 0xAA, whose sole purpose is to allow the Z80 master to try sending the SYNC command in a loop until it gets 0xAA in response. Once this has happened, the USI works absolutely perfectly; it's not a case of bytes getting lost because the ISR isn't fast enough.
Other SPI devices (such as the SCP1000) connected to the same system don't have this problem, so there's nothing wrong with the SPI interface on the Z80 master, as far as I can tell.
While the SYNC command approach works, it would be on the whole much better if the USI interface worked right from power-up. Am I missing something in my setup routine to make this happen?