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:
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
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:
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?"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 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