Does hspi work on the 28X1 A.0?

Tom2000

Senior Member
I'm designing a system to control an Analog Devices AD9851 DDS chip from a 28X1 A.0.

The 9851 requires 5 bytes transmitted serially and sequentially, clocked by the rising edge of the clock pulse. It doesn't require a chip select, and it sends no data to the 28X1. (I need two other leads for the 9851: an update line that will send a high pulse when all 40 bits have been transmitted, and one line to control power to the 9851 board, for a total of four lines.)

I'd like to drive the 9851 using the 28X1's SPI facility, with the sdo and sck lines only.

In addition to the 9851, I want the 28X1 to handle a 2-wire optical encoder, 7-wire keypad, 6-wire LCD, and a single pushbutton. With the four leads required to drive the 9851, I have no pins available to dummy in the 28X1's SPI module's chip select and sdi lines.

I found this ominous note in the Picaxe Manual 2 documentation of the hspiout command:

Due to the internal operation of the microcontrollers SPI port, a hspiout command will only function when the hspiin ‘input pin’ is in the expected default state. If this pin is incorrect (e.g. high when it should be low), the hspiout byte cannot be sent (as the microcontroller automtically detects an SPI error condition). After 2.3 seconds of fault condition the PICAXE microcontroller will automatically reset.
I've spent a good deal of time digging throught the Picaxe documentation and the 16F886 data sheet, trying to find the meaning of this warning message. For the life of me, though, I haven't been able to find any limitations on SPI received data. "What's it all mean?"

I've also searched the forum for information on hspi on the 28X1. Although I found nothing specifically on the A.0 firmware, BCJKiwi has done some extensive testing with an A.1 28X1 driving a VMusic2 via SPI. He learned that a CS toggle is necessary between each SPI byte (I think) and that hspi doesn't work in fast speed.

So, I guess my questions are these:

1. Is hspi operation even feasible with an A.0 chip?

2. Must the CS lead be toggled between each transmitted byte?

3. What does that odd warning message, quoted above, really mean?

If hspi doesn't work as I need it to, I could fall back on the bit-banged spiout routine, but BCJKiwi mentioned that spiout shares the same problems he found with hspi. As a final fallback position, I could write my own bit-banged SPI output routine, but I'd rather not. I need all the speed I can get in this app.

Many thanks,

Tom
 

Technical

Technical Support
Staff member
1) hspi does work in all modes on all firmware versions.
2) The work done by bcjkiwi was for a particular device with a strange bit-busted spi mode. We have no experience of any issues with any other device. Toggling CS is not required unless the slave device expects it.
3) It means that if the spi bus locks, ie the slave device does not give a correct answer, after 2.3 seconds of no activity within the PICs internal spi buffer, the PICAXE chip will reset (technically the PICAXE firmware loads the spi transmit buffer with a byte. However the PIC internal module will simply not transmit that byte from the buffer if the SPI bus is held in the incorrect state. The chip then locks up until a watchdog timeout. This information is not found in the Microchip datasheets...!) However this should never happen on a PCB with slave devices that work correctly over the SPI bus.


Here is some code that works perfectly with an spi eeprom
Code:
; Hardware SPI with a 26LC160 EEPROM
; Faster and more efficient than non-hardware version.
; This test program demonstrates SPI interfacing to the EEPROM
; Two bytes are written and then read back to verify.
#picaxe 28x1
'#com 4
' Input / Output pin setup
'24LC160 pins
'1 = CS  = PICAXE output7
'2 = SO  = PICAXE input4 (SPI DI)
'3 = WP  = +5V
'4 = Vss = 0V
'5 = SI = PICAXE input5 (SPI DO)
'6 = SCK = PICAXE input3 (SPI CLK)
'7 = HOLD  = +5V
'8 = Vdd   = +5V
'remember PICAXE input connects to EEPROM output and vice versa!
symbol cs = 7 ' chip select is connected to PICAXE output 7
' 25LC160 Commands
symbol WRSR = 1 ' write status register
symbol WR   = 2 ' write
symbol RD   = 3 ' read
symbol WRDI = 4 ' write disable
symbol RDSR = 5 ' read status register
symbol WREN = 6 ' write enable
'Variables
symbol add_low   = b0 ' address low byte
symbol add_high  = b1 ' address high byte
symbol test_data1 = b2 ' dummy test data 1
symbol test_data2 = b3 ' dummy test data 2
symbol SR_Value1  = b4 ' read status regsietr 1
symbol SR_Value2  = b5 ' read status register again
Symbol RD_Value1  = b6 ' read data byte 1
Symbol RD_Value2  = b7 ' read data byte 2
 
 'set cs high and wait a while
init:
 high cs 'chip select high
 ' setup spi mode - mode 1,1 with sample at end, medium speed
 hspisetup spimode11e,spimedium
 pause 50 ' wait a while
 'load some test values
 add_high = 0
 add_low = 25
 test_data1 = 55
 test_data2 = 99
 
main:
 
 ; write enable
 low cs
 hspiout (WREN)
 high cs
 
 ; write status register to 0 to remove block protect
 low cs
 hspiout (WRSR,0)
 high cs
 pause 5 ; wait write time
 
 ; write enable
 low cs
 hspiout (WREN)
 high cs
 
 ; read status register to see if it has worked
 ; we expect this value to now be 2
 low cs
 hspiout (RDSR)
 hspiin (SR_Value1)
 high cs
 
 ; write
 low cs
 hspiout (WR,add_high,add_low,test_data1,test_data2)
 high cs
 pause 5 ; wait write time 5ms
 
 ;read
 low cs
 hspiout (RD,add_high,add_low)
 hspiin (RD_Value1,RD_Value2)
 high cs
 
 ; write enable
 low cs
 hspiout (WREN)
 high cs
 
 ; read status register to see if it has worked
 ; we expect this value to now be 2
 low cs
 hspiout (RDSR)
 hspiin (SR_Value2)
 high cs
 
 ; write disable the chip
 low cs
 hspiout (WRDI)
 high cs
 'display values on screen and then loop
 debug
 pause 1000
 
 
 'increment test data
 inc test_data1
 inc test_data2
 
 goto main
 
Last edited:

Tom2000

Senior Member
3) It means that if the spi bus locks, ie the slave device does not give a correct answer, after 2.3 seconds of no activity within the PICs internal spi buffer, the PICAXE chip will reset (technically the PICAXE firmware loads the spi transmit buffer with a byte. However the PIC internal module will simply not transmit that byte from the buffer if the SPI bus is held in the incorrect state. The chip then locks up until a watchdog timeout. This information is not found in the Microchip datasheets...!) However this should never happen on a PCB with slave devices that work correctly over the SPI bus.
Technical,

Thanks very much for your assurance and for the sample code.

However, I'm as confused by your response as I was by the hspiout warning message. If the receive condition of an SPI interface that isn't receiving anything isn't defined, how can the SPI bus be "held in the incorrect state" if it's not expecting to receive anything?

Do I need to do anything in particular with the sdi pin, or may I use it for another purpose?

What provisions must I make to keep the SPI bus "in the correct state?"

Help!

Tom
 

Technical

Technical Support
Staff member
You do not need to worry about it if using a 'proper' third party SPI device. We have never seen the issue on any branded IC.

Hardware SPI use three pins - SDO, SDI and SCLK. You cannot use just two of them.

Data is sent out of the PICAXE chip via the SDO pin. However the PICs internal module refuses to do this if the SDI input pin is held in the wrong state, even though the SDI pin is not actually used during the hspiout command. But if you are connected to a third party chip this isn't going to happen anyway - its only if you try to use SDO without connecting up SDI that the issue could arise.

This is not a silicon error, if the SDI pin is in the incorrect state the PIC's internal module, quite correctly, assumes there is a bus error and hence refuses to use the bus any more.
 
Last edited:

hippy

Technical Support
Staff member
@ Technical : The real question is, what if one just wants to use SDO and SCLK; what does one do with SDI which isn't used - what is "incorrect state" and what is "correct state" ?

I think everyone will appreciate such a configuration may not be to a 'traditional, fully implemented SPI device", but it's a very likely scenario for driving shift registers and counters using just SCLK, SDO or both but not utilising SDI at all.

The $64K question is, what needs to be done with SDI to make such a scenario work ?

I was under the impression that SPI simply clocked whatever was on SDI in as SCLK rose/fell as configured, and it wouldn't care how SDI was set prior to initiating SPI nor how or when SDI changed ( if it did ) during such a transfer. I'm not aware of any higher-level SPI protocol such as there is with I2C.

Added : It's this which really confuses me ...

3) It means that if the spi bus locks, ie the slave device does not give a correct answer
I don't see what "correct answer" there is from an SPI device to give, would be given, or how the SPI bus can actuall "lock".
 
Last edited:

Technical

Technical Support
Staff member
We do not disagree with the theory of what you are saying. We are just reporting what happens in real life - as proven by extensive testing! We think the issue is because the same internal PIC buffer is used for transmit and receive.

When using hardware hspi mode the SDI pin cannot be used for anything else anyway (as it is controlled by the internal PIC SPI module and cannot be used for any other i/o work atthe same time) so it might as well be held in the correct state if not connected to the third party chip (the correct state is the clock mode default state, ie high if the clock defaults high, low if the clock defaults low). This depends on the SPI mode used.

If you really only want two use two pins - SDO and SCLK, use the non hardware spiout command on two output pins.
 

BCJKiwi

Senior Member
I note with interest that Technical did not advise that the "particular device with a strange bit-busted spi mode" was in fact the VDrive2!
 
Top