Hi FC,
Microwire (TM National Semiconductor) depending on the flavour is either one of two of the four modes available to SPI (TM Motorola Semiconductor).
So a Microwire peripheral will always work on an SPI port but a SPI peripheral may not work on a Microwire port.
Most parts these days (especially from Maxim) claim to be compatible with both.
Regards David
For example,
Trying to setup an interface to the Maxim DS1302 RTC. How would the bidirectional data be handled using the 9S08QG8 SPI?
Hi FC,
I think you might be able to use mode 0,0.
The main problem is that you need to flip direction exactly at the last SCK edge, because this same edge would start the reply from the 1302. Maybe you could time the direction from the start of the transfer and flip it slightly early.
You might be able to use the SPI after some experimentation or like rocco said just bit bang it.
Regards David
Hello,
It would seem possible to use the SPI facility for the DS1302, provided CPHA = 0 (and CPOL = 0). In the Dallas data sheet, it would appear that fig 3 for the single byte read may have an error with only 15 clock pulse shown - there would need to be a sixteenth clock for the MCU master to read the LS bit of the returned byte on its positive edge, and this would be compatible with SPI.
For the CPHA = 0 operation, the MS bit of the returned data needs to be valid on the positive edge of the ninth clock pulse, so the data becoming output on the negative edge of the eighth clock pulse is correct. To avoid the timing issues during the input-to-output transition of the data line at the DS1302 (a conflict might be present for a very short interval) I would suggest to include a series resistor in the line, say 4k7, to provide current limiting.
For MCU operation with a single data line (MOSI becomes MOMI),
SPIC2_SPCO = 1;
Prior to the command byte being sent,
SPIC2_BIDIROE = 1; // For data output from MCU
Prior to receiving the return data byte (by sending a dummy byte),
SPIC2_BIDIROE = 0; // For data input to MCU
Regards,
Mac
Hi, Mac:
bigmac wrote:
In the Dallas data sheet, it would appear that fig 3 for the single byte read may have an error with only 15 clock pulse shown . . .
Hi,
Of course unless the OP has a big box of 1302's gathering dust this is all academic.
You could use open-collector buffers as well!
I think you loose burst mode too with this 15 clocks business (or too messy if you can)
Another idea:
The OP is using QG8, it has I2C, so the DS1307 is possibly a better choice as you don't need the extra pin as with the SPI 1306.
Regards David