Shop OBEX P1 Docs P2 Docs Learn Events
An Observation on PASM Hub Operations — Parallax Forums

An Observation on PASM Hub Operations

jazzedjazzed Posts: 11,803
edited 2009-09-10 22:15 in Propeller 1
Over in the Sandbox dMajo and I had a little discussion about HUB operations.
This may be obvious to some PASM users, but it took a while for me to get it.

dat
org 0 ' blah blah blah

' just for demo sake assume val and ptr are defined and ptr is set to some address
' that can contain 0 or non-zero.

' this code creates a tight squarewave on P0 until the rdlong command results in zero
' there are only 2 instructions between hub ops, so the squarewave does not have jitter
:loop
  rdlong  val,   ptr wz
  xor      outa, #1
  if_nz    jmp   #:loop

' this code creates a squarewave on P0 at half the frequency of the previous :loop
' there are 3 instructions between hub ops, so missing the hub window makes the pulses wider
:loop2
  rdlong  val,   ptr wz
  xor      outa, #1
  nop
  if_nz    jmp   #:loop2

' what does this code do besides waste a lot of cycles?
' [b]It produces exactly the same squarewave on P0 as in example :loop2.
' Effectively, you get 12 more cycles to waste than you may have realized before :)[/b]
:loop3
  rdlong  val,   ptr wz
  xor      outa, #1
  nop
  nop
  nop
  nop
  if_nz    jmp   #:loop3



Hopefully, this will help new PASM users interested in performance in a small way.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve

Propeller Tools Post Edited (jazzed) : 9/10/2009 11:07:05 PM GMT

Comments

  • heaterheater Posts: 3,370
    edited 2009-09-10 19:41
    I guess it gives a jitter free square wave output at half the frequency of the first example.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-09-10 19:49
    Neither the 2nd nor the 3rd example should cause jitter. They should simply make the loop longer. Once the RDLONG executes the 1st time, the cog is synchronized with the hub and hub memory accesses can occur every 16 system clock cycles. If you miss the access window, the next one will occur 16 system clock cycles later. There's no jitter.
  • Agent420Agent420 Posts: 439
    edited 2009-09-10 19:49
    Coding video drivers as my foray into pasm, I am trying to be very disciplined in regards to timing.· I always estimate a worst case 22 cycles for a hub operation from an unknown state, and then attempt to keep track of where the hub from that point on.

    Another thing I try to do is to make full use of the 9 cycles between hub accesses by inserting two 4 cycle operations between them...· that results in any following hub commands only requiring 8 cycles and minimizes 'cycle waste'.

    edit -

    > Neither the 2nd nor the 3rd example should cause jitter. They should simply make the loop longer.

    You have a good eye ;-)

    As for the topic at hand, jitter could become an issue if you were using a seperate rdlong to obtain each pin state rather than simply xor'ing, and these rdlongs were not synchronized.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    Post Edited (Agent420) : 9/10/2009 8:00:06 PM GMT
  • jazzedjazzed Posts: 11,803
    edited 2009-09-10 20:13
    Those with an oscilloscope are sufficiently empowered to discover the jitter that happens in example 2.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve

    Propeller Tools
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-09-10 21:02
    I have a scope. Mike is right. Example 2 does not jitter, nor should it.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2009-09-10 22:02
    Ok it's not the point I was trying to make really, but I do stand corrected which in this case at least is a GoodThing(tm) [noparse]:)[/noparse] ... I suppose I've spent too much time looking at LMM loops where the non-symmetrical fetch loop caused jitter.

    The real point I was trying to make is: If you go over the "between hub access" the magic clock cycle limits, you get approximately 16 more cycles before the next "hub window" expires. I wanted to thank dMajo for helping me understand this better and share it with the greater forum especially since it's never really been brought up before that I know of.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve

    Propeller Tools
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-09-10 22:15
    jazzed said...
    If you go over the "between hub access" the magic clock cycle limits, you get approximately 16 more cycles before the next "hub window" expires.
    That is correct. If adding an instruction to the loop causes you to miss your previous access slot, you can add three more instructions without additional penalty.

    -Phil
Sign In or Register to comment.