spi ss line / pin issue

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I have an interface where it communicate in the same fashion as an SPI. Only issue is the normal SS lines is an ack.

Is blips just before data is transmitted to the master. I want to replicate that and I'm guessing I can to do that with the SS line.

 

I'm using the atmega32u4 and b0 is the SS line. When the SPI is enabled I can not drive that pin high or lo.

 

So what I'm wondering is.  Is there any way to make the SS pull low for 2.31us and then go high? - Of course I'm not sure if the master is influencing the line or just reading it. If not I guess it would be ok to turn off the API do the blip and exit or maybe just use another pin.

 

 

 

 

 

 

 

 

 

 

 

 

Last Edited: Tue. Jul 16, 2019 - 08:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Only issue is the normal SS lines is an ack.

I don't quite understand, is the (pb0) pin an output? It MUST be even if not used for a slave select in master mode or the SPI will shut down the instant it goes low as an input.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its is held High when connect to the master but as long as I do not enable the SPI on my device I can pull it low.  I can not pull it low if I enable the SPI. At the moment I'm not able to communicate with the master and I'm a bit unsure why I'm guessing I need some external hardware. All pins are not pulled up externally yet.

 

 

Doing this below does nothing, it never seems to read the SPI master and so the other code never runs. Tried with and without interrupts.
 


unsigned char Spi_read(void)
{
    volatile char temp=0;
    SPDR  = 0;    
    while((SPSR & (1<<SPIF)));
    temp = SPDR;
    return temp;
}
void spi_send(unsigned char byte)
{
    SPDR  = byte;    
    while(!(SPSR & (1<<SPIF)));
}


char Probe(void)
{
    SPCR = (1<<SPE)|(1<<SPIE)|(1<<SPR1)|(1<<SPR0)|(1<<DORD)|(1<<CPHA)|(1<<CPOL);//needed for psx, could try without (1<<SPR0)//enable the slave
    if ( Spi_read() == 0xff)//read a ff
    {

//kill the spi and blip the ack pin.
        SPCR &= ~(1<<SPE);
        ATT_ON();
        _delay_us(2.31);
        ATT_OFF();
        

//bring back up the spi and try to send
        SPCR = (1<<SPE)|(1<<SPIE)|(1<<SPR1)|(1<<SPR0)|(1<<DORD)|(1<<CPHA)|(1<<CPOL);//needed for psx, could try without (1<<SPR0)
        spi_send(0x33);
    }

}


 

Last Edited: Tue. Jul 16, 2019 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry the morning coffee is slowly making it's way to the brain here laugh so is the atmega32u4 the master or the slave? If slave then pb0 must be an input and you cannot control it, the master does.

 

If master then pb0 must be output.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah slave.

 

So maybe I'm wrong about how the SS line works (or in this case ack line) Remember this is not "really" and SPI. But yeah pretty much looks like one.

 

So the master (not the atmega device) is sending out FF ever 16 ms. With no slave I see a reply of 0x80. No idea why, my guess is the master is bring the first bit High for a reason (maybe to detect the slave?). When the "real" slave is attached this same thing occurs ff->80 but then I see the SS line dip for 2.31us and data begins.

 

normal talk is

ff->80

SS blip

cd->48

0a->e7

..

..

..

and more data.

 

 

 

 

Not I'm trying to act as the slave here.  but I'm not sure what the master is looking for to know when I'm connected. My guess was that blip but as you said that is reserved for the master that can not be it, or maybe in this case it is (hence the name Acknowledge?). After I see the FF->80 it never send the 0xcd, so I'm trying to figure out what I need to do to get this 0xcd. Of course this is guess work and not documented well.

 

Though, for a test I should be able to see and read the FF. This is my first step and its not working, My device is not reading that FF. This is were I'm appear to be stuck at the moment. I have never programed a slave device but is there any external hardware I need to be using for mosi/miso/ss ? Like a pull up?

 

 

 

 

 

 

 

 

 

Last Edited: Tue. Jul 16, 2019 - 10:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd use an extra pin if you have one available.

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Still, and based on what js said its not going to work like that? and He is right that SS line is on the master end I can not influence it.

 

Tell me, what is it on that image (and those are all the pins) that make the master know a slave is connect? Top part is a connected slave button is no slave. It must be using the SS line some how?

 

Last Edited: Tue. Jul 16, 2019 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Waht is the master? Does it have a data sheet that shows what it expects?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

its a PlayStation ps2 gaming console. It's proprietary. I found this write up to be quite good.

http://store.curiousinventor.com...

 

Last Edited: Tue. Jul 16, 2019 - 11:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess everything I need to know is in here

http://blog.nearfuturelaboratory...

author says " . So, off to the right of this image is lots of clock signals, and ACKS, but no meaningful data, until the SS pulls back high. Also notice the ACKS in the fifth channel (green) — these are acknowledge signals sent from the controller back to the console to verify that it’s alive and so forth. Evidently, these are necessary for the communication to work, but not strictly part of the SPI protocol. "

 

So my suspicions where right, now I just need to figure out how this works because that master is holding that line (ack line not ss). I can not see to pull on that wire. I thin kmy mistake was tying that line to SS where the "enable" lines should have gone to ss. Time to rewire.

 

Yup I can now create the ACK signal but still can not read the SPI. I know my settings are right but I'm not sure how why this code does not work.

unsigned char spi_tranceiver (unsigned char data)
{
    // Load data into the buffer
    SPDR = data;

    //Wait until transmission complete
    while(!(SPSR & (1<<SPIF)));   // Return received data

  return(SPDR);
}

    SPCR = (1<<SPE)|(1<<SPIE)|(1<<SPR1)|(1<<SPR0)|(1<<DORD)|(1<<CPHA)|(1<<CPOL);//needed for psx, could try without (1<<SPR0)//my set up.
 
    if ( Spi_read( 0x81) == 0xff) //my test, but I see the code is stuck in Spi_read.

 

Last Edited: Wed. Jul 17, 2019 - 03:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just realized the system I'm working with is 3v logic.