Shop OBEX P1 Docs P2 Docs Learn Events
I see safe_spi, is there a dangerous_spi? — Parallax Forums

I see safe_spi, is there a dangerous_spi?

jstjohnzjstjohnz Posts: 91
edited 2012-08-17 22:53 in Propeller 1
The safe_spi object that is a part of FSRW, uses 2 instructions per bit to read (10mhz) and one instruction per bit to write (20mhz). There is some commented out code in there that looks like it was intended to do 1-instruction per bit SPI reads. Is that doable? Is it not reliable and that's the reason why safe_spi is used?

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2012-08-15 23:39
    jstjohnz wrote: »
    Is that doable? Is it not reliable and that's the reason why safe_spi is used?
    Yes to both questions. See [thread=127653]waitpxx cog synchronisation[/thread] specifically [post=976476]post #7[/post].
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2012-08-16 08:01
    Maybe its kind of like managed spi vs unmanaged ;-)
  • RaymanRayman Posts: 14,671
    edited 2012-08-16 09:34
    The safe one works on 100% of Prop chips. But, for some reason, the other one only works on ~19 out of 20 Prop chips...
  • wjsteelewjsteele Posts: 697
    edited 2012-08-16 13:05
    Cool... we have a "SPI vs SPI" story in the making here!!! I always loved watching those two guys go at it!

    Bill
  • jstjohnzjstjohnz Posts: 91
    edited 2012-08-17 00:09
    kuroneko wrote: »
    Yes to both questions. See [thread=127653]waitpxx cog synchronisation[/thread] specifically [post=976476]post #7[/post].

    Well, that hurt me head. One more SPI question. In the fast SPI write routine, the initial value that's loaded into the phase register is defined as setting the phase between the clock pin and the data pin, and that makes sense. But in my testing, every value I used for the initial setting of phase worked, which just seems wrong. I would think that some values would work and other shouldn't work because this should be controlling when the data line changes in relation to the clock line.
  • jstjohnzjstjohnz Posts: 91
    edited 2012-08-17 00:13
    Rayman wrote: »
    The safe one works on 100% of Prop chips. But, for some reason, the other one only works on ~19 out of 20 Prop chips...

    Does it means it's on the ragged edge on all of them, and it just depends on which side of the ragged edge it falls? I guess what I'm asking is on the 95% of the chips where it works, can it be expected to work consistently, and on the other 5% can it expected to fail consistently? Probably not worth taking a chance.
  • RaymanRayman Posts: 14,671
    edited 2012-08-17 03:37
    That's what I remember anyway... The fast one worked great until I came across a Prop chip that it refused to work on...
    So, I think you can still use it reliably as long as you make sure it works with your particular Prop chip...
    On the other hand, better safe than sorry, right?
  • lonesocklonesock Posts: 917
    edited 2012-08-17 10:54
    Some quick notes from memory:
    • Glitches only happened when using PLL16X
    • It didn't seem to be layout-dependent...using a long ribbon cable on my protoboard didn't seem to be an issue.
    • It seemed to be related to which cog was running the interface, and which pins were selected.
    • I'm also wondering if bypassingle the SD socket is critical...without a cap maybe the SD card's output edges were sloppier?
    • If you are running your prop at > 100 MHz, then the single-bit-per-instruction mode will exceed the 25MHz SPI bus SD spec.
    Jonathan
  • jstjohnzjstjohnz Posts: 91
    edited 2012-08-17 22:53
    This isn't for an SD card, it's for talking to a wiznet ethernet module. I might try it just to see what happens.
Sign In or Register to comment.