SX/B Shiftin/Shiftout SPI

Rsadeika

I have seen, in other discussions,·where the shiftin/shiftout (shift*) command·can be used to·simulate(?) an SPI protocol. Now, I am wondering if something like that can be done in SX/B. It would be nice if it could be a master/slave multiples. Meaning, master with many slaves or multiple masters and slaves ...

After looking at the asm code for SPI, I noticed that it uses four pins to accomplish the SPI protocol, the shift* commands can only address two pins, one of which is set up as a clk.·Also, what would it take to get the transfer rates up to the one meg level. So, is the answer no, it cannot be done with shift* commands, or will it do it, in a very limited usefullness situation.

If it is possible, then could it be done within an interrupt, or does this mess things up for other commands or the program itself. This seems like it could be a nice solution, no messing around with resistors, just plug wires into the selected pins, and off you go.

Has anybody done something like this, and is willing to share some example code. Or, will the next release of SX/B have the SPI thing covered, and I just sit on my hands till then LOL. Any ideas or input would be appreciated.

Thanks

Ray

Jon Williams

Ray,

As you know, SHIFTIN and SHIFTOUT will cover most applications; if you're after more it's a pretty simple matter to craft it in code. There won't be any changes to SX/B that affect SHIFTIN and SHIFOUT, so you may want to develop something specific for your application. I did this for a Sony PlayStation controller project -- it uses and SPI type protocol where bits are shifted in and out at the same time. There code was very simple to implement (I had even done it on a BASIC Stamp) and the project works well.

Here's how I did it for the PSX:

' Use: {inByte} = PSX_SHIFTIO {outByte}
' -- sends [noparse][[/noparse]optional] "outByte" to PSX
' -- receives [noparse][[/noparse]optional] "inByte" from PSX
PSX_SHIFTIO:
· IF __PARAMCNT = 1 THEN
··· temp3 = __PARAM1······· ' copy output byte
· ELSE
··· temp3 = 0
· ENDIF
· temp4 = 0·················' clear input byte
· FOR temp5 = 1 TO 8····· ··' shift eight bits
··· PsxCmd = temp3.0······ ·' move lsb to Cmd pin
··· temp3 = temp3 >> 1··· ··' shift for next bit
··· PsxClock = 0········· ··' clock the bit
··· WAIT_US 5
··· temp4 = temp4 >> 1···· ·' prep for next bit
··· temp4.7 = PsxData····· ·' get lsb from Data pin
··· PsxClock = 1·········· ·' release clock
··· WAIT_US 5
· NEXT
· RETURN temp4

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Post Edited (Jon Williams (Parallax)) : 2/3/2006 7:23:50 PM GMT

Paul Baker

SPI can be done through SHIFOUT/SHIFTIN in SX/B, SPI was designed as a single master, multi-slave system, Ill explain why SPI is not suited for multi-master in a bit. The fourth signal line you speak of is for Slave Select, which is handled much in the way a /CS signal is used on a system bus. This is normally transitioned before and after the serial communication so is handled externally to the SHFTOUT/SHIFTIN routine. Each slave requires its own slave select signal, so without doing address encoding/decoding requires one additional pin for each slave on the SPI bus. This is in contrast to I2C which performs slave select within the serial data stream.

SPI is not well suited for multi-mastering, for one there is more than one data-line Master->Slave and Slave->Master and collision of the Serial Clock is not provided for. Because of this a master would have to be able to access all slave select data pins in order to be absolutely sure the bus was free, the possibility of data and clock collision resulting in garbled transmissions and possible deadlocking of the SPI bus are very high and can arise from many different scenarios.

The SHIFTIN/SHIFTOUT commands are designed for low bandwidth synchronous communications, to achieve 1Mbps throughput, you'd have to write your own assembly routine, speeds approaching OSC/2 are possible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Rsadeika

Thanks Jon and Paul, good example, and good insight on the multiple master thing. It seems that I can not come up with the right combination for an easy to use inter uC solution. I guess I just have to keep hacking away at this, I hope I don't end up·developing my own protocol. It seems like the easiest, serial, messes with the use of interrupts, and all the others have to be done in asm. So, where do I start with my own protocol ...

Thanks

Ray

Paul Baker

I2C does support multimaster and has well defined collision avoidance scheme in the multi-master scenario. It is easier to implement a well thought out system then trying to tackle the entire thing yourself (in multi-master systems, there are several ways of entering a collision situation, its easy to miss one or two when you are coding your own). SX/B I2C commands are not multi-master, but the docs page for SX has MM versions, but I think we've already discussed that right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Rsadeika

Yes we have, I am still trying to stick with SX/B on this. Half my body is already in the asm bit pit, if I get completely sucked in I may never come out, and then I will start acting strange and ...

Thanks

Ray

Jon Williams

There is no reason why the you can't mix assembly into SX/B -- use ASM where timing is critical (e.g., ISR), and do the "big stuff" with SX/B.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Rsadeika

I have looked at all of the asm examples for I2C,SPI, and UART, I personally think, that it would be pretty big challenge for me to try to fit·any of those·into an SX/B ISR, and have it work correctly. Still pondering the ...
·

Jon Williams

You might want to get a copy of Guenther's book -- if memory serves me (I'm still in the middle of a move so copy is in storage) he has interrupt-driven I2C routines in the book. Even if he doesn't, it's a great resource.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Rsadeika

Yes I have looked at his book and the code, it is almost as daunting as the Scenix stuff. If I am not mistaken the owner of Parallax, Chip, was coauthor on the code (WOW the guy is a bit banger, no wonder he stays in hiding). I have been looking at this stuff, and thinking about how to accomplish this, but when you try to go in reverse, put major asm code into SX/B, it is not that easy. You may·claim "inline assembly" for SX/B, but that applies for some very small pieces of code, in my opinion.

Still searching ...

Jon Williams

This one may turn out harder than you want it to be, Ray. But as a friend of my often says, if it doesn't kill you it will make you stronger!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Guenther Daubach

Rsadeika,

I must admit that the I²C examples in my book are not the easiest to be followed by a reader who is new to this topic, especially when it comes to multi-master systems, bus arbitration, and all these "nice" events that might happen. But I swear that Chip did not act as a co-author here. If he would, you can be sure that the code would be a lot more efficient, shorter, "more tricky", and almost un-readable.

Just have a look at the UART code most commonly used in SX ISRs. This was originally written by Chip, and I have adapted his version in my book. It is amazing how much can be done with a minimum of SX instructions if you "personally know" each and every bit inside the SX .

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

Günther

Rsadeika

Sorry Guenther, it was the UART code, I got it all mixed up. I still·think that SX/B can be a very good prototype tool, if everything was easy to use,·and that asm should be used to optimize, but that is my opinion. And, when I say optimize, that may mean a rewrite in asm.

Now back to the problem at hand.

Paul Baker

You can block delininate assembly in SX/B, switching completely to assembler mode for the duration of the assembly instructions.

Look at the ASM...ENDASM command, you could write entire ISRs in assembly (or the entire program for that matter) with little effort.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Post Edited (Paul Baker) : 2/4/2006 3:22:23 PM GMT

Rsadeika

I am familiar with the usage of asm ... endasm. What I will probably have to do is experiment. What I am thinking is, put in the device and freq info that SX/B needs, then right under that, asm, paste in all the asm code, end it with endasm. Then put in the SX/B code that I will need. The asm code should take care of things like reset, banking, and the requirements for the ISR. After it compiles correctly, then I will have to see what has to be adapted to make the SPI actually work. Boy, doesn't this sound simple.

Thanks

Ray