28X1 as an SPI slave

[commanda]

Hi,
I've been searching, and can't find the answer to this one.
I want to use a 28X1 as an SPI slave. Picaxe drives a parallel input LCD. Another processor sends screen data (ascii) to Picaxe via SPI.
Plenty of examples using the Picaxe as a master, but not as a slave. Is it even possible? Pointers to something I couldn't find welcome.

Amanda

 

[westaust55]

From what I can see in the PIC datasheet, SPI is only supported in Master mode. i2c supports master and slave modes.

• Master Synchronous Serial Port (MSSP) Module supporting 3-wire SPI (all 4 modes) and I2C™ Master and Slave Modes . . . .

 

[tiscando]

I think "keyin" and "kbin" are like a spi slave input, but only holds the last byte of a stream of data.

Maybe there could be a special memory IC with 2 spi buses, or an IC with 2 large shift registers with one's parallel inputs connected to the other's parallel outputs, and the other way round (as in the picture), which enables 2 picaxes to communicate to each other using SPI master buses.

 

[MPep]

To use a 28X1 as a slave in any system, use I2C.

@WA: you forgot the closing ].

 

[westaust55]

To use a 28X1 as a slave in any system, use I2C.

@WA: you forgot the closing ].

Thanks MPep - fixed for completeness

 

[tiscando]

I'm going to look at the SFRs to see if I can get SPI slave which holds more than 1 byte so I can use the keyboard on the picaxe just how a computer reads it.

 

[tiscando]

I've discovered that the Hser- and the kbin/kbled use the EUSART (enhanced universal synchronous asynchronous receiver transmitter). I've been poking registers that are associated with the EUSART.
However, how would it cope with the start and stop signals from the keyboard when the pic16f886 datasheet said in one paragraph "Start and Stop bits are not used in synchronous transmissions." in the blurb in secion 12.4?

The keyboard does use start, parity, and stop bits in its ps/2 proocol, and I checked this fact on my new 'scope.

 

[Technical]

I've discovered that the Hser- and the kbin/kbled use the EUSART (enhanced universal synchronous asynchronous receiver transmitter).

No they don't! keyin etc. is bit busted special code to match the PS2 format.

To use a 28X1 as a slave we would also recommend i2c rather than spi.

 

[tiscando]

Oh really?!
so why can't the kbin command load more than one of the received bytes into variables?

 

[hippy]

Oh really?!
so why can't the kbin command load more than one of the received bytes into variables?

I'm not entirely sure of the semantics of the question, but the answer would seem to be "by design".

Keyboard input by its nature is infrequent with long ( as far as a PICAXE is concerned ) periods of inactivity between keys pressed so it makes sense to read a keyboard character, process it in the user's program, wait for the next.

While it would be possible to read multiple key presses into multiple bytes, that's really no different to a sequence of KEYIN or KBIN commands to do the same.

 

[tiscando]

I meant that:
1. the special keys e.g. 'prt scrn' and 'pause' have a special multi-digit code.
2. the numeric keypad keys which have the same last digit as the keys beween the qwerty part and the numeric part, but there is a $E0 before the last digit.
3. when a pressed key is released, the keyboard sends a special byte meaning 'released' before the key# bytes are sent again. Found that on my 'scope.

So I basically meant that on a kbin2 command, it records all the sent bytes from the keyboard like this: After a byte has been received, it waits for 20ms for another byte before leaving the command. So this is rather than discarding the bytes before the last byte which is what happens with the current keyin and kbin commands.

Syntax example: KBIN2 var1, var2, var3{, var4}