Understanding pins better (or at all)

cheezuscheezus Posts: 244
edited 2019-02-04 - 07:13:11 in Propeller 2
With all the new tricks like the streamer, registered io (almost completely lost here) and whatnot I'm looking at different ways of rewriting P1 code. Simple bit-bashing like done on p1 would probably be the easiest to get working. I've also been going the OTHER route aka converting all ASM to Spin for fastspin.

The p1 asm engine is working (quite well) on the but it's going to require an entire rewrite to be compatible with P2. There's quite a few things that will need to change but for now i'm just trying to understand the bulk transfer loop, ie

ramtohub_loop           mov     data_16,ina             ' get the data                           
                        wrword  data_16,hubaddr         ' move data to hub                      
                        andn    outa,maskP20            ' clock 161 low                             
                        or      outa,maskP20            ' clock 161 high                              
                        add     hubaddr,#2              ' increment the hub address             
                        djnz    len,#ramtohub_loop      '                                    
                        or      outa,maskP16            ' memory /rd high  
                        jmp     #done                  ' ' tristate pins and listen for command


hubtoram_loop           and     outa,maskP16P31         '%11111111_11111111_00000000_00000000               
                        rdword  data_16,hubaddr         ' get the word from hub                          
                        or      outa,data_16            ' send out the byte to P0-P15                     
                        andn    outa,maskP17            ' set mem write low                               
                        add     hubaddr,#2              ' increment by 2 bytes = 1 word. Put this here for small delay while writes   
                        or      outa,maskP17            ' mem write high                                  
                        andn    outa,maskP20            ' clock 161 low                                   
                        or      outa,maskP20            ' clock 161 high                                  
                        djnz    len,#hubtoram_loop      ' loop this many times                           
                        jmp     #done                   ' tristate pins and listen for command   

hubtodisplay_loop       and     outa,maskP16P31         '%11111111_11111111_00000000_00000000      
                        rdword  data_16,hubaddr         ' get the word from hub                
                        or      outa,data_16            ' send out the byte to P0-P15       
                        andn    outa,maskP18P19            ' ILI write low                      
                        or      outa,maskP18P19            ' ILI write high                      
                        add     hubaddr,#2              ' one word               
                        djnz    len,#hubtodisplay_loop  ' do this many times             
                        or      outa,maskP19            ' CS high
                        jmp     #done   


Since these are all word transfers having the streamer handle hub -> pins makes sense but I'm drawing a blank on how to sync toggling clock pins with the streamer. What I'd really WANT to do isn't possible afaik since the streamer can't output it's clock but SW might be able to handle this?

My spin code for hubtodisplay needs to be cleaned up and clock pins handled better but currently testing on P1 with fastspin.
PRI LCD_Writ_Bus(LCDLong)
    LCDLong &= $0000_FFFF
    OUTA &= %11111111_11111111_00000000_00000000        ' set P0-P15 to zero ready to OR
    OUTA |= LCDLong                                     ' merge with the word to output
                                             ' send out the data
    LCD_CS_Low
    LCD_WR_Low 
    LCD_WR_High
    LCD_CS_High

PRI LCD_WR_Low
    OUTA &= !LCD_WR

PRI LCD_WR_High
    OUTA |= LCD_WR
    
PRI LCD_CS_Low
    OUTA &= !LCD_CS
   
PRI LCD_CS_High                                         
    OUTA |= LCD_CS
   

I really haven't done anything on the p2 with the new hardware since I'm trying to understand the pins still. What is really confusing me is the P2 Doc talks about pin delays but I thought this only applies to registered IO? I guess some expansion on registered IO and such would be nice. I should probably grab an updated version of the Instructions and Documentation.


*edit - fixed formatting in code

* slightly OT

I'm currently trying to find a SD card driver. I guess fsrw would work, I guess it's time to start learning fourth!

Comments

  • cheezuscheezus Posts: 244
    edited 2019-02-04 - 07:13:36
    I guess I just have to hook up the logic analyzer and start playing around.
  • jmgjmg Posts: 13,902
    cheezus wrote: »
    ...
    Since these are all word transfers having the streamer handle hub -> pins makes sense but I'm drawing a blank on how to sync toggling clock pins with the streamer. What I'd really WANT to do isn't possible afaik since the streamer can't output it's clock but SW might be able to handle this?

    I think the intended approach on P2, is to generate CLKs on one smart pin, and attach the streamer to that clock.
    Chip was going to look into getting a CLK out at SysCLK speeds, because right now a smart pin cannot export at SysCLK (only /2,/3..) but the streamer can run at SysCLK, so there is a blindspot there.
    Not sure of the status of that fix ?

  • jmg wrote: »
    cheezus wrote: »
    ...
    Since these are all word transfers having the streamer handle hub -> pins makes sense but I'm drawing a blank on how to sync toggling clock pins with the streamer. What I'd really WANT to do isn't possible afaik since the streamer can't output it's clock but SW might be able to handle this?

    I think the intended approach on P2, is to generate CLKs on one smart pin, and attach the streamer to that clock.
    Chip was going to look into getting a CLK out at SysCLK speeds, because right now a smart pin cannot export at SysCLK (only /2,/3..) but the streamer can run at SysCLK, so there is a blindspot there.
    Not sure of the status of that fix ?

    I am going to talk to Wendy about this.
  • cheezuscheezus Posts: 244
    edited 2019-02-05 - 13:56:22
    jmg wrote: »
    cheezus wrote: »
    ...
    Since these are all word transfers having the streamer handle hub -> pins makes sense but I'm drawing a blank on how to sync toggling clock pins with the streamer. What I'd really WANT to do isn't possible afaik since the streamer can't output it's clock but SW might be able to handle this?

    I think the intended approach on P2, is to generate CLKs on one smart pin, and attach the streamer to that clock.
    Chip was going to look into getting a CLK out at SysCLK speeds, because right now a smart pin cannot export at SysCLK (only /2,/3..) but the streamer can run at SysCLK, so there is a blindspot there.
    Not sure of the status of that fix ?


    While being able to output @ sysclock using the streamer would be nice, I don't think it's really necessary for what I want to do. The devices on the bus have max clock < 20mhz so even bit-bashing @ 160mhz will probably be sufficient to get maximum bandwith on the bus. I was thinking that having the streamer handle hub -> pins would free up the cog for pre-processing the hub data before the streamer did it's thing, I'm not sure how much this would really improve things. The biggest bottleneck is, was and will always be the SD card! :|

    From what I understand, it should be possible to setup a smartpin as a clock and then setup the streamer with the same period. Then you'd phase align the NCOs, enable streamer and then enable the clock output. Maybe the streamer would need a "dummy clock" or two to allow time to enable the smartpin? I guess I should go through the smartpin docs again because the more I think about it there's got to be a mode for "output x number of clocks". If this is possible for sysclock/2 or /4 or even /16 or something I might try it at some point. Am I even close??? LOL


  • jmgjmg Posts: 13,902
    cheezus wrote: »
    .. I guess I should go through the smartpin docs again because the more I think about it there's got to be a mode for "output x number of clocks".
    Yes, smart pin modes should do that,
    eg the DOCs say this

    %00100 = pulse/cycle output

    This mode overrides OUT to control the pin output state.
    X[15:0] establishes a base period in clock cycles which forms the empirical high-time and low-time units.
    X[31:16] establishes a value to which the base period counter will be compared to on each clock cycle, as it counts from X[15:0] down to 1, before starting over at X[15:0] if decremented Y > 0. On each clock, if the base period counter > X[31:16] and Y > 0, the output will be high (else low).
    Whenever Y[31:0] is written with a non-zero value, the pin will begin outputting a high pulse or cycles, starting at the next base period.
    Some examples:
    If X[31:16] is set to 0, the output will be high for the duration of Y > 0.
    If X[15:0] is set to 3 and X[31:16] is set to 2, the output will be 0-0-1 (repeat) for the duration of Y > 0.
    IN will be raised when the pulse or cycles complete, with the pin reverting to low output.
    During reset (DIR=0), IN is low, the output is low, and Y is set to zero.


    I think that translates to mean this
    Cycles Generated = Y[31:0] Zero disables/stops
    Period = SysCLK/X[15:0] (but 0,1 are illegal ?)
    DutyCycle = X[31:16]/X[15:0]
    cheezus wrote: »
    ... If this is possible for sysclock/2 or /4 or even /16 or something I might try it at some point.

    The above mode should be valid for SysCLK/2../2^15 in steps of 1, with odd numbers not having 50% clock duty cycles.

  • cgraceycgracey Posts: 11,697
    edited 2019-02-06 - 19:03:23
    There is also a mode where you set up the base period and then do a WXPIN/WYPIN with the number of transitions you'd like to have output.
  • I think we decided at some point that a double circuit could be used to get sysclock from sysclock/2...
    Prop Info and Apps: http://www.rayslogic.com/
  • jmgjmg Posts: 13,902
    Rayman wrote: »
    I think we decided at some point that a double circuit could be used to get sysclock from sysclock/2...

    Do you mean adding external components ? Yes, that is possible, but requires the user design the PCB with that in advance, and rather defeats the 'Smart Pins' moniker.
    Those external parts also add a delay to the clock.
Sign In or Register to comment.