Will the real SPI Object please stand up?
Ken Gracey
Posts: 7,401
Hey there,
Prop programming noob here, and not a very capable one either. It seems like most of the SPI objects I find are wrapped up into other sensors, A/Ds, or ICs·for which it was·customized to communicate.·This makes it more difficult for me to adapt existing code to an SPI device not currently in use by·another OBEX contributor. I'd really enjoy having a complete SPI object that I can use with any part I desire.
Is this a real need to the other Prop programmers, or are you getting by fine with out a stand-alone, fully-functional SPI object?
Thank you,
Ken Gracey
·
Prop programming noob here, and not a very capable one either. It seems like most of the SPI objects I find are wrapped up into other sensors, A/Ds, or ICs·for which it was·customized to communicate.·This makes it more difficult for me to adapt existing code to an SPI device not currently in use by·another OBEX contributor. I'd really enjoy having a complete SPI object that I can use with any part I desire.
Is this a real need to the other Prop programmers, or are you getting by fine with out a stand-alone, fully-functional SPI object?
Thank you,
Ken Gracey
·
Comments
It would be possible to make a configurable routine that works much like the SHIFTIN / SHIFTOUT statements of the Stamps, that would compile an assembly routine to do the actual transfers.· For a lot of SPI devices, the Spin routines in the BS2 Library are fast enough.
Post Edited (Mike Green) : 3/17/2009 12:55:30 AM GMT
Honestly, there is so much already present in the object exchange that after about 2 years, I am just now getting to the point of looking around to see what else is available but not yet in the OBEX. And I really want a couple of Phil's accelerometers...
so making his job easier sounds good to me.
Not only do I think a generic SPI object is needed, but it is such an important topic that it deserves it's own learning lab. I just re-read the wikipedia on the subject, there is nothing in the general description that suggests that a fully configurable SPI object is not possible... except that the nature of the exchange between the corresponding shift registers is completely undefined... so any length word can be returned by any length response and this can vary within the same device...
This suggests that a generic object would not necessarily be fully functional without adding the device specific dialog info, which might be beyond simple abstraction... in which case you simply leave the generic object as a non-functioning template and then give a couple of example applications showing how to modify the template and where the info comes from, which leads to the specific examples. This might also lead to more readable SPI objects in the exchange.
So, I agree with you. I really think some kind of boiler plate is required. And since Mike is never wrong, I agree with him too... it looks like the boiler plate is largely available in the BS2 library... it is simply a matter of dressing it up, pushing it out and then telling everyone how pretty it is[noparse]:)[/noparse]
Rich
On top of the variants Mike described above, you also have variants and combinations of enable/clock/latch lines of varying sequencing/timing and polarity.
The effort required in configuring some form of SPI object to work with a specific bit of hardware would very likely equal the effort required to write the 10 lines of code required to interface to it anyway. And using the latter method you would build a firm understanding of how it all works while ending up with smaller, tighter code.
I'd second Rich's suggestion of a lab. Grab 4 or 5 different cheap bits of SPI interfaced gear and put together a tutorial on how to talk to each bit. It would serve the learner much better than trying to write/configure some form of generic SPI object.
SPI is never complex, but it's often very different.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cardinal Fang! Fetch the comfy chair.
But the fact remains that I'm still not happy with what we have to offer. Talking to others I can see that I'm not alone. There's something simple about the BS2 (okay, and Martin's library, too) with SHIFTIN/SHIFTOUT and although the Prop is no BS2, Parallax could at least provide a stand-alone SPI object that could be modified.
Parallax would be pleased to sponsor an SPI-only object contest. Even if it involved extracting, documenting, writing a tutorial, and isolating the BS2 library functions in a stand-alone format it would be useful to Parallax and our customers. Do you think that if we put $350 in a contest pot we would get positive results?
Ken Gracey
EDIT: I now read that others posted the idea too - that is what I get for fast skimming. I second (or third or forth) the lab idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" LCD Composite video display, eProto for SunSPOT
www.tdswieter.com
The SPI engine that Harrison mentions was written as a stand-alone compatible version of SHIFTIN/SHIFTOUT with a familiar "feel" to the Basic Stamp with the speed of Propeller assembly. In some cases it's been reported that it's actually too fast. So really the only thing that this code needs is a "throttle" around the CLOCK pulse portion of the code. I can spend some time on that tomorrow (Tuesday) if you would like.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
It would be fantastic to have an official Parallax SPI engine as part of our Prop IDE distribution. Add throttle, any documentation and perhaps an example to put it to use (DS1620?).
This would be a great addition and I encourage you to finish it for the Prop people with an OBEX post.
Thanks,
Ken Gracey
I will be interfacing an SPI Flash shortly, so I will try this object out.
Ken: It's great to see Parallax making great offers of support in contests, etc, to boost certain aspects of Propeller development.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I used the BS2 object because it seemed the simplest to use and I had a little experience with using the stamp shiftin and out.
I would absolutely love it if there was a Parallax sponsored SPI object. I think a contest is a great idea. I would certainly enter if I knew how to do this. Anything that makes the end product/project easier or quicker is of value!
That was an easy $350
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
J
I think Beau is going to need a few new chips to test everything out...
And then he is going to need some quality time alone... so, a secretary to answer his phone would be good.
So the final result should be: $350 + parts + staff...
or... a cup of coffee and a smile, whichever comes first.
Rich
You guys are really going to bat for Beau right now. I've dispatched a secretary and SPI parts to his house; no comment on the award cash. Parallax employees are usually not eligible for participation in our external contests. But he can have a free day off if he finishes the project. For now he's still as quiet as a mouse - I'm still looking for him this morning. . Beau. . . Beau. . . where art thou?
Ken Gracey
Parallax, Inc.
Ok, As per an E-mail Ken sent me this morning, I will get an Assembly version out to the OBEX sometime today, and A Spin version out sometime later in the week.
The difference between the two (Assembly or Spin) aside from the speed, is that the Assembly version will require it's own cog, while the Spin version will be parasitic to an existing cog.
As far as SPI parts, I have plenty of "stuff" to complete this project, but always happy to receive more for future projects.
I wasn't expecting a cash reward. I'm pretty humbled just getting something out that other people can benefit from. That's my reward.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
··
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I had previously read through Beau's code, and several of the SPI objects posted to the obex, in addition to wikipedia and various other web resources - I'm now starting to understand what I am doing. Although I am very curious to see what Beau comes up with as an interface for SPI, from my limited understanding of the code I've seen and several corresponding datasheets, it is apparent that there is a great deal of variety in how an SPI interface is defined for various sensors. So, I think it would also be helpful if a lab was still developed around this new object to step user's through the mapping of a datasheet spec to Beau's interface. Even better, as a part of this lab, might be to map the inputs/outputs from the example SPI object into Hanno's tool for viewing the traces.
In my case, I have 10+ sensor readings being output from the SPI object, and 10+ offsets/calibration parameters that can be fed into the sensor system.
If the concept of a lab built around Beau's object is outside of the scope for his work, I'd be happy to help write/test for such an effort since I think it would be generally useful for others in the community confronted with developing an SPI interface for the first time, although I'll probably have a few questions along the way.
Sorry for the delay... I received a new "toy" from E-Bay and when I went to plug it in to try it out, I inadvertently unplugged a few other things. Needless to say, I didn't save, nor had the auto-save kicked in.
If you find any problems with the SPI object, please let me know... there are a few aspects with the SHIFTIN that I was unable to test, so if anyone finds a circumstance that fails, then please let me know ASAP.
ianw,
If you and others can provide more specific details, I can make necessary changes to the SPI object. An aspect of SPI that I have not covered makes use of multiple data lines that can be used in parallel. If there is a strong interest there, that might be a worthwhile addition to the SPI object. The High Speed 14.5 Meg Baud Prop to Prop serial communication touches on this concept using 4 I/O lines but uses Asynchronous communication. The SPI is different in that it would need to use Synchronous communication.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
In regards to your other question, the ADIS16204 accelerometer has two data lines.
Like Ianw, I need help in understanding how to interpret the datasheet. For example, to figure out whether the chip was MSBPOST or MSBPRE, I had to do trial and error. I'm pretty sure it is MSB first. Looking at the oscilloscope I counted bits and looked at the received bits using debug. When the two matched I assumed I got it right. Now, my problem is to figure out how to decode the bits into a usable G. For example, the data is 14 bits, two's complement. I am thinking all I have to do is subtract one then flip the bits. I hope that is right.
Thanks again Beau!
It's exactly what I'was looking for [noparse]:D[/noparse]
Through the SPI interface, the Clock starts out HIGH and data is valid upon the rising edge, so this would mean that it needs a POST clock. ... and yes it is MSB, so you would use MSBPOST for the SHIFTIN command, and MSBFIRST for the SHIFTOUT command.
As far as the two data lines, I assume you mean DIN and DOUT. Generally the DIN and be connected directly to the DOUT via a 1K to 330 Ohm resistor, and you connect the Propeller directly to the DIN.
R DOUT >----/\/\---o---< DIN | o-----------> DataAccording to the datasheet on page 5 of the referenced pdf, The SPI's ClockDelay could be set to a minimum of 1 resulting in a 300ns clock pulse width.
''SPI.start(ClockDelay, ClockState) SPI.start(1, 1) Delay := 15 ''Clock delay '' = 300ns + (N-1) * 50ns '' Example1: '' A Delay of 5 would be 500ns '' 300ns + 4 * 50ns = 500ns '' Example2: '' A Delay of 15 would be 1us '' 300ns + 14 * 50ns = 1000ns = 1usReference PDF:
http://www.analog.com/static/imported-files/Data_Sheets/ADIS16204.pdf
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 3/18/2009 3:40:05 PM GMT
Ken Gracey
Parallax, Inc.
Thank you, I will get the Spin version out later in the week/weekend. For the most part Spin would be plenty fast for SPI. In some cases however you might want to use the Assembly version which I have posted that really blazes. Even faster if you streamline it to eliminate some of the conditional requirements for a specific project. The benefit however to having an all Spin version is that you could parasitically use an existing cog. The Assembly version requires it’s own cog, but with the dispatching used within the assembly, you can add additional Assembly functions, but again this is something that could be modified to meet the needs of a specific project. Either way, the Spin version or the Assembly version will have it's place.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
About combining the DIN and DOUT... the data sheet says "...Because the SPI port operates in full duplex mode, it supports simultaneous, 16-bit receive (DIN) and transmit (DOUT) functions during the same data frame." ... so my recommendation of combining the DIn and DOUT will not work unless the ADIS16204 will also operate in a half duplex mode.
There seems to be a need for a third SPI function that will simultaneously READ/WRITE ... let me think about this and I will get back to you.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I'll check it out... what would interest me is a tech note on using the counters to provide a clock to SPI interfaces, specifically how to synchronize starting/stopping the clock with the byte/word/whatever boundaries. I've been working with one chip and can get up to almost 5mbps without problems, but I would love to get the 10mbps counters would easily allow, or even higher [noparse]:)[/noparse]
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
Thank you very much. You have actually cleared up a lot. First, I never thought of using one pin to read both DIN and DOUT. I am going to try that. Also, using MSBPOST for the shiftin statement. Your answer gave also provided the logic for determining the correct thing in the future as well.
One question on setting the delay. Do I use both statements like this to start it running.
SPI.Start(1,1)
Delay := 15
Or were you just telling me the 1,1 parameters set the delay at 15 or???
Thanks again.
PS
I was also having trouble figuring out how to decipher two's compliment. In your demo
you had the line:
Celsius := Celsius << 23 ~> 23 '' extend sign bit
I believe I can use the same logic for the accelerometer right?
so if I did this:
bs2.pulsout_uS(clk, 210)
results := spi.shiftin(Dout, clk, SPI#MSBPost,16) 'most significant bits first
results := results << 2 ~> 2 '' extend sign bit
I think I will get the correct acceleration.
Right?
Just the... SPI.Start(1,1) ...will create a clock pulse width of about 300ns
The formula is:
Delay = 300ns + (N -1) * 50ns
where:
N = the delay value you supply in the first argument of the ... SPI.Start(1,1) ... command.
BTW, the second argument is the initial or Idle clock state.
I think that the ... Celsius := Celsius << 23 ~> 23 '' extend sign bit ... will work for you, but make sure you are only looking at the data. From briefly looking at the data sheet on your Accelerometer, it looks like there may be other bits embedded in the data that could corrupt the results.
But again, saying all this, unless the ADIS16204 will also operate in a half duplex mode, my SPI will not work when combining the DIN and DOUT. That trick only works if the SPI communication is half-duplex. The ADIS16204 appears to operate in full-duplex mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
This kind of attitude from Parallax is one of the things that has me so excited to be working with the Propeller.
Really refreshing!
Was there ever a full duplex 4-pin version of this object created?
Are there still any plans to make a lab for mapping a new SPI device's datasheet to the generic SPI object? By reading the BasicStamp docs, I was able to learn about ShiftIn-ShiftOut as it's used with the DS1620, but it would be helpful to see docs specific to the propeller that also addressed decoding SPI parameters from datsheets to be used by the object.
Thanks,
Ian