+ Reply to Thread
Results 1 to 18 of 18

Thread: Getting Started - Spin vs Pasm

  1. #1

    Default Getting Started - Spin vs Pasm

    I wonder if someone would be kind enough to look at the attached code. This is for a board with a number of latches. I started with Spin, then translated it to Pasm, and had it at one stage able to latch three of the latches independently in pasm. The code was built up one line at a time and worked perfectly every line. Then, something went wrong with the code and it all stopped working. I've progressively commented out bits of code till there is almost nothing left. I've narrowed it down to two pieces of code - one is Spin and one is Pasm and I think they ought to do the same thing - set pins 0-7 high. Spin works but the Pasm code sets these pins low?!

    Full code is below (warts and all, mostly commented out now), but for testing purposes, I'm commenting out one or other of these lines:
    Code:
        cognew(@Address, 0)           'Launch new cog and run Latch program
    '    Send_Test_Byte



    I'm learning heaps as I go and it is great fun.

    I'm sure there is a simple explanation, and help would be most appreciated.

    Code:
    CON
      _clkmode = xtal1 + pll16x
      _xinfreq = 5_000_000
    
    VAR
      ' list of variables
    
        byte Output_Byte 
    OBJ
      ' list of objects to include and their names  
    
    PUB Main
        Setup_138
    '    A16_18Low
        cognew(@Address, 0)           'Launch new cog and run Latch program
    '    Send_Test_Byte
        repeat                      ' if just end then leaves pins tristated and this puts random bytes into latches and makes debugging harder
    
    
    PRI Setup_138
        DIRA :=%00000000_00000000_00011100_11111111    ' setup data lines and HC138 lines as outputs
    
    PRI A16_18Low
        OutLong := Zero                      ' Data byte to 00000000
        OutLong := Outlong | AddressHigh     ' Logical OR with Address High HC138 address
        OUTA    := OutLong                   ' send it out
        OutLong := Outlong & HC138Mask       ' Logical AND set HC130 to zero and keep data as is
        OUTA    := OutLong                   ' send it out
        OUTA    := Zero                      ' set pins back to zero - not really needed                                         
    
    PRI Send_Test_Byte
        Outlong := TestByte
        OUTA :=OutLong
    
    DAT
    
            ORG 0                   ' Begin at Cog RAM addr 0
    Address                         ' change A0-A15 (A16-18 always low)
            mov OutLong, TestByte    ' put the address into the output long
    '        or OutLong, HC138Mask   ' happens to be the right one eg high byte =zero
    '        or OutLong, AddressLow  ' sets HC138 to 010 and sets low A0-A7 address latch low 
            mov outa, OutLong        ' send it out
    '        nop
    '        nop
    '        nop
    '        and OutLong,HC138Mask   ' set 138 back to 0 but leave data as is, latches on +ve pulse
    '        mov outa,OutLong        ' send it out
    '        nop
    '        nop
    '        nop
    
            
    '        mov OutLong,TestByte    ' send out a byte to the middle address A8-A15
    '        shr OutLong,#8         ' shift right by 8 bits
    '        or OutLong,AddressMid   ' or with the 138 address
    '        mov outa,OutLong        ' send it out
    '        and OutLong,HC138Mask   ' set 138 back to 0 but leave data as is, latches on +ve pulse
    '        mov outa,Outlong        ' send it out
            ' dira all to zero again when ends
    
            
     'terminates here and cog finishes
    ' data tables and assembly code
    
    'variable1     long      0       ' variable 1 = 4 bytes
    HC138Mask    long  %00000000_00000000_00000000_11111111 ' Mask for 138 xxx000xx chip to reset with an and
    Zero         long  %00000000_00000000_00000000_00000000
    TestByte     long  %00000000_00000000_00000000_11111111  ' test byte for output
    TestAddress  long  %00000000_00000000_11111111_10101011  ' test sending out this Word
    OutLong      long  %00000000_00000000_00000000_00000000  ' the output pins - working register
    AddressLow   long  %00000000_00000000_00001000_00000000  ' xxx010xx is low address
    AddressMid   long  %00000000_00000000_00001100_00000000  ' xxx011xx is mid address
    AddressHigh  long  %00000000_00000000_00010000_00000000  ' xxx100xx is high address  (always 000 for 64K CP/M)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  2. #2

    Default

    You need to end your assembly with either Cogstop or an infinite loop....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: http://www.rayslogic.com/propeller/propeller.htm
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  3. #3

    Default

    Dr_Acula,

    Firstly, you need to setup DIRA also in the PASM section as that will be in another COG, and they start as INPUT.
    Secondly, you need to put an infinite loop at the end of the PASM code, otherwise it'll execute whatever is in memory after it.
    If you use a COGSTOP it will not only stop the cog, but will clear DIRA and OUTA.

    Hope that helps,
    Baggers.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    http://www.propgfx.co.uk/forum/home of the PropGFX Lite

    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  4. #4

    Default

    I think you need some stack for the parameter to cognew.

    Scratch that you are starting PASM there.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  5. #5

    Default

    Firstly, you need to setup DIRA also in the PASM section

    Yes, that fixed it. Many thanks!

    I put this at then end
    Code:
    endlessloop
            jmp #endlessloop



    Down the track I'd be wanting to stop the cog though. Is there a 'correct' way to do this? Eg if multiple cogs are running and I just grab the next available one to run this code on, do I need to get the cogid before stopping the cog and do I then need a long delclared somewhere to store this id before doing a cogstop? Is there a standard bit of code that does this?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 10/14/2009 10:33:26 PM GMT
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  6. #6
    Cluso99's Avatar
    Location
    Sydney/Brisbane Australia or 'sailing on the high seas'
    Posts
    10,118

    Default

    James: I see that others have already mentioned the missing end loop and setting the direction, so these have been fixed.

    I think what you want is a cog that can be told to set a set of latches with values?
    If so, then look at the TriBlade driver (or patatoheads TV driver). They just wait for a command and then execute it and return to wait for the next command.

    Can you post a block diag of the latching sections?

    If you want you can email me or phone today.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    Home of the MultiBladeProps: TriBlade,RamBlade, RetroBlade,TwinBlade,SixBlade, website
    Single Board Computer:3 Propeller ICsand aTriBladeProp board (ZiCog Z80 Emulator)
    Prop Tools under Development or Completed (Index)
    Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
    Search the Propeller forums(uses advanced Google search)
    My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  7. #7

    Default

    This would work and wouldn't require any other location. The COGID can overwrite itself because it won't be executed again.

    Code:
    stopMe cogid stopMe
               cogstop stopMe
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  8. #8

    Default

    Thankyou for all the quick replies. Making lots of progress now - managed to latch lots of pins correctly. No doubt there will be optimisations, but this is partially a learning experience!

    Next little problem is how to do calls. See the attached code. If I comment out the call and endless loop at the beginning, and include the endless loop at the end of the code, it all works correctly just falling through the code from top to bottom.

    But if I have the code as posted, it compiles ok but the latch code is not working. I worked out the _ret bit from the manual and putting in the #, but I think I might be missing something else with respect to calls.

    Attached is the schematic (rename as a pdf) which is essentially a workaround to get more pins.

    Code:
    CON
      _clkmode = xtal1 + pll16x
      _xinfreq = 5_000_000
    
    VAR
      ' list of variables
    
        byte Output_Byte 
    OBJ
      ' list of objects to include and their names  
    
    PUB Main
        cognew(@Address, 0)           'Launch new cog and run Latch program
        repeat                      ' if just end then leaves pins tristated and this puts random bytes into latches and makes debugging harder
    
    
    
    DAT
                                    ' pin 0-7=data bus, pin 8=/RD, pin 9=/WR, pin 10-12= 1 of 8 138 decoder
            ORG 0                   ' Begin at Cog RAM addr 0
            call #Address          ' Set up the address and data pins based on long in DataAddress
                                    ' now toggle /rd plus /cs or /wr plus /cs depending on read or write 
    endlessloop
            jmp #endlessloop
            
    Address mov dira,PinEnable      ' does low, mid high address latches then the data
            mov OutLong, DataAddress' put the address into the output long
            and OutLong, AddressMask' Mask low byte
            or OutLong, AddressLow  ' sets HC138 to 010 and sets low A0-A7 address latch low and rd/wr high
            mov outa, OutLong       ' send it out
            and OutLong,HC138Mask   ' set 138 back to 0 but leave data as is, latches on +ve pulse
            mov outa,OutLong        ' send it out
            
            mov OutLong,DataAddress ' send out a byte to the middle address A8-A15
            shr OutLong,#8          ' shift right by 8 bits
            and OutLong,AddressMask ' mask low byte
            or OutLong,AddressMid   ' or with the 138 address and sets rd/wr high
            mov outa,OutLong        ' send it out
            and OutLong,HC138Mask   ' set 138 back to 0 but leave data as is, latches on +ve pulse
            mov outa,OutLong        ' send it out
    
            mov OutLong,DataAddress ' Get data and address
            shr OutLong,#16         ' shift right by 16 places to get high address A16+
            and OutLong,Addressmask ' mask low byte
            or OutLong,AddressHigh  ' or with 138 address and keeps rd/wr high
            mov outa,OutLong        ' send it out
            and OutLong,HC138Mask   ' set 138 back to 0 and leave data bus as is, latches on +ve pulse
            mov outa,OutLong        ' send it out
    
            mov OutLong,DataAddress ' get data and address
            shr OutLong,#24         ' shift right by 24 places to get the data byte
            and OutLong,AddressMask ' mask low byte
            or OutLong,ReadWrite    ' keep read and write high
            mov outa,OutLong        ' send out the data
    Address_Ret ret
    
    'endlessloop
    '        jmp #endlessloop        
            
            ' dira all to zero again when ends - or does stopping cog do this anyway
            ' if pins all go tristate when cog stops then ? need pullups on /rd and /wr and the 138 inputs?
        
    ' data tables and assembly code
    
    PinEnable    long  %00000000_00000000_00011111_11111111  ' setup data lines,rd/wr and HC138 lines as outputs
    AddressMask  long  %00000000_00000000_00000000_11111111  ' Mask for low address byte
    HC138Mask    long  %00000000_00000000_00000011_11111111  ' Mask for 138 xxx000xx chip to reset with an and
    TestByte     long  %00000000_00000000_00000000_11111111  ' test byte for output
    DataAddress  long  %00000000_11111111_00000000_11111111  ' data_high_mid_low bytes
    OutLong      long  %00000000_00000000_00000000_00000000  ' the output pins - working register
    AddressLow   long  %00000000_00000000_00001011_00000000  ' xxx010xx is low address and xxxxxx11 =rd/wr
    AddressMid   long  %00000000_00000000_00001111_00000000  ' xxx011xx is mid address and xxxxxx11 = rd/wr
    AddressHigh  long  %00000000_00000000_00010011_00000000  ' xxx100xx is high address  (always 000 for 64K CP/M)
    ReadWrite    long  %00000000_00000000_00000011_00000000  ' xxxxxx11 for high wr and rd

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    Attached Files Attached Files
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  9. #9

    Default

    I've stripped it right back to the simplest way of demonstrating the problem. Without the call to testcall, the 8 pins go high. With the call, they don't (actually a few do - pins 2,4 and 5. The others stay open circuit). I'm obviously not grasping something with Call (though it looks similar to other code I can find). Many thanks for any help with this.

    Code:
    CON
      _clkmode = xtal1 + pll16x
      _xinfreq = 5_000_000
    
    PUB Main
        cognew(@PHigh, 0)           'Launch new cog and run Latch program
        repeat                      ' if just end then leaves pins tristated and this puts random bytes into latches and makes debugging harder
    DAT
            ORG 0                   ' Begin at Cog RAM addr 0
            call #TestCall
    
    PHigh         mov dira,PinHigh        ' set pins 0-7 as output
                  mov outa,PinHigh        ' set pins 0-7 high
    
    endlessloop
                  jmp #endlessloop        
    
    TestCall      nop                     ' test a call
    TestCall_ret  ret                     ' return from call
    
    PinHigh      long %00000000_00000000_00000000_11111111 ' pins 0 to 7 high

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  10. #10

    Default

    Maybe it would be a good idea to add another label which is in front of the call statement and use that in your cognew? ;o)

    The adress you use in cognew is the adress where cognew starts to load the code from. So, in your code you don't have the call instruction in the COG RAM at all. Same in the post before ... no call, no endless loop.
    The other problem is that this way you loaded code into COG-RAM adress 0 which originally was meant for adress 1. So, all used in the PASM no longer match with the location. For example mov dira, PinHigh no longer points to PinHigh-label but to the long following PinHigh. The label Endlessloop has been compiled to be 3, but you load the jmp to adress 2. So, it's no longer an endless-loop, it jumps to the nop ... and the ret goes to 'who knows' :o)

    Code:
    PUB Main
        cognew(@PHighPASMEntry, 0)           'Launch new cog and run Latch program
        repeat                      ' if just end then leaves pins tristated and this puts random bytes into latches and makes debugging harder
    DAT
            ORG 0                   ' Begin at Cog RAM addr 0
    PASMEntry
    
            call #TestCall
    
    PHigh         mov dira,PinHigh        ' set pins 0-7 as output
                  mov outa,PinHigh        ' set pins 0-7 high
    
    endlessloop
                  jmp #endlessloop        
    
    TestCall      nop                     ' test a call
    TestCall_ret  ret                     ' return from call
    
    PinHigh      long %00000000_00000000_00000000_11111111 ' pins 0 to 7 high

    Post Edited (MagIO2) : 10/15/2009 6:46:15 AM GMT
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  11. #11

    Default

    Ah, that makes sense. Checking it out now...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  12. #12
    Cluso99's Avatar
    Location
    Sydney/Brisbane Australia or 'sailing on the high seas'
    Posts
    10,118

    Default

    Drac: re your schematic...

    It isa good idea touse a gate pin onthe 74xx138 as when the input lines change (because of inherant delays) you are likely to getunwanted glitches on the '138's outputs.

    You can double upusing SDA or SCL to free up a pin for the gate on the '138. If gate pinhas a pullup and you use an inverted gate select, then the '138 will output all 1's when de-gated.

    I see others have already found your pasm call problem.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    Home of the MultiBladeProps: TriBlade,RamBlade, RetroBlade,TwinBlade,SixBlade, website
    Single Board Computer:3 Propeller ICsand aTriBladeProp board (ZiCog Z80 Emulator)
    Prop Tools under Development or Completed (Index)
    Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
    Search the Propeller forums(uses advanced Google search)
    My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  13. #13
    Cluso99's Avatar
    Location
    Sydney/Brisbane Australia or 'sailing on the high seas'
    Posts
    10,118

    Default

    Looking at your older code... some things already discussed...
    Code:
    DAT
                                    ' pin 0-7=data bus, pin 8=/RD, pin 9=/WR, pin 10-12= 1 of 8 138 decoder
            ORG 0                   ' Begin at Cog RAM addr 0
    
    PASMentry
            call #Address          ' Set up the address and data pins based on long in DataAddress
                                    ' now toggle /rd plus /cs or /wr plus /cs depending on read or write 
    endlessloop
            jmp #endlessloop
            
    Address mov outa,ReadWrite      ' initial value for when dira enabled (dr=wr=1, latch=0)
            mov dira,PinEnable      ' does low, mid high address latches then the data
            mov OutLong, DataAddress' put the address into the output long
            and OutLong, AddressMask' Mask low byte
            or OutLong, AddressLow  ' sets HC138 to 010 and sets low A0-A7 address latch low and rd/wr high
            mov outa, OutLong       ' send it out
            and OutLong,HC138Mask   ' set 138 back to 0 but leave data as is, latches on +ve pulse
            mov outa,OutLong        ' send it out
            
            mov OutLong,DataAddress ' send out a byte to the middle address A8-A15
            shr OutLong,#8          ' shift right by 8 bits
            and OutLong,AddressMask ' mask low byte
            or OutLong,AddressMid   ' or with the 138 address and sets rd/wr high
            mov outa,OutLong        ' send it out
            and OutLong,HC138Mask   ' set 138 back to 0 but leave data as is, latches on +ve pulse
            mov outa,OutLong        ' send it out
    
            mov OutLong,DataAddress ' Get data and address
            shr OutLong,#16         ' shift right by 16 places to get high address A16+
            and OutLong,Addressmask ' mask low byte
            or OutLong,AddressHigh  ' or with 138 address and keeps rd/wr high
            mov outa,OutLong        ' send it out
            and OutLong,HC138Mask   ' set 138 back to 0 and leave data bus as is, latches on +ve pulse
            mov outa,OutLong        ' send it out
    
            mov OutLong,DataAddress ' get data and address
            shr OutLong,#24         ' shift right by 24 places to get the data byte
            and OutLong,AddressMask ' mask low byte
            or OutLong,ReadWrite    ' keep read and write high
            mov outa,OutLong        ' send out the data
    
            'now you need to do the /RD or /WR
    Address_Ret ret
    
    'endlessloop
    '        jmp #endlessloop        
            
            ' dira all to zero again when ends - or does stopping cog do this anyway
            ' stopping the cog places dira to all inputs (for this cog only).
            ' if pins all go tristate when cog stops then ? need pullups on /rd and /wr and the 138 inputs?
            ' either /G2A or /G2B gate on the '138 will require pullups. As you must disable the '138, you will not need 
            '   to put pullups on /wr and /rd although this is preferable.
    ' data tables and assembly code
    
    PinEnable    long  %00000000_00000000_00011111_11111111  ' setup data lines,rd/wr and HC138 lines as outputs
    AddressMask  long  %00000000_00000000_00000000_11111111  ' Mask for low address byte
    HC138Mask    long  %00000000_00000000_00000011_11111111  ' Mask for 138 xxx000xx chip to reset with an and
    TestByte     long  %00000000_00000000_00000000_11111111  ' test byte for output
    DataAddress  long  %00000000_11111111_00000000_11111111  ' data_high_mid_low bytes
    OutLong      long  %00000000_00000000_00000000_00000000  ' the output pins - working register
    AddressLow   long  %00000000_00000000_00001011_00000000  ' xxx010xx is low address and xxxxxx11 =rd/wr
    AddressMid   long  %00000000_00000000_00001111_00000000  ' xxx011xx is mid address and xxxxxx11 = rd/wr
    AddressHigh  long  %00000000_00000000_00010011_00000000  ' xxx100xx is high address  (always 000 for 64K CP/M)
    ReadWrite    long  %00000000_00000000_00000011_00000000  ' xxxxxx11 for high wr and rd

    Don't forget, each time you load the cog to do this, you are re-loading 496 longs from hub, even if your cogcode is short. So you are best to let it continue to run in one form or another.

    The other issue you will run into shortly, is trying to pass parameters to "DataAddress" from spin. You have to pass the address of a variable "varDataAddress"via par and use rdlong to get at it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    Home of the MultiBladeProps: TriBlade,RamBlade, RetroBlade,TwinBlade,SixBlade, website
    Single Board Computer:3 Propeller ICsand aTriBladeProp board (ZiCog Z80 Emulator)
    Prop Tools under Development or Completed (Index)
    Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
    Search the Propeller forums(uses advanced Google search)
    My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  14. #14

    Default

    Hi MagIO2, yes that fixed the errors. Well spotted. The logic makes perfect sense.

    To Cluso, yes studying the internal gate structure of the HC138 now www.futurlec.com/74HC/74HC138.shtml

    Propogation delays *ought* to be the same , and indeed it does latch correctly at PASM speeds, but I can see your point too.

    Hmm - if you use the gate to turn the 138 on and off, (either 4,5 or 6), and there are two free pins on the HC138 (Y0 and Y7), then instead of defaulting to Y0 which is not connected, you could put /WR on Y0 and /RD on Y7, gate with the now free pin 13 on the prop, and this leaves pin 14 free on the prop. Hmm - that could be useful for an analog input or output.

    And good points re keeping the cog running. And yes, soon I might be asking about how to pass parameters (though I think there are other active threads on this topic). First, I want to send a byte to a ram chip and read it back.

    If the /write line is high, is the standard way to toggle it to do an xor with 0001000 and then another xor with 0001000? Uses one less long than doing an AND with 1110111 then an OR with 0001000 as you only need to store one mask, right?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 10/15/2009 12:28:55 PM GMT
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  15. #15

    Default

    You can use OR and ANDN. Use OR for switching on and ANDN for switching off ... also uses the same mask but the advantage is that you can be sure to switch it on if you want it to be on and off if you want it to be off. Using XOR works of course, but you have to keep in mind which state the pin had before. Makes life easier for bugs ;o)
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  16. #16

    Default

    This sort of thing?
    Code:
    ToggleWrite
            andn outa,WriteMask      ' set bit to 0 WriteMask  %00000000_00000000_00000010_00000000  /WR line
            nop                     ' as per Cluso's code tiny delay
            or outa,WriteMask      ' set bit back to 1
    ToggleWrite_ret
            ret



    It seems to work. Same length of code as xor, but more 'definite', as you say. I like that!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  17. #17
    Cluso99's Avatar
    Location
    Sydney/Brisbane Australia or 'sailing on the high seas'
    Posts
    10,118

    Default

    Yes, magio is correct. This is safest.

    Re the 138. IIRC you have the /CS to the ram on the 138, so you cannot also have the /rd & /wr there as well.

    Re your toggle code above... the nop delay is probably not required, depending on the ram, as you have already set up the data and /cs, so the /wr can be shorter. Biggest thing is to make sure you do not have /rd (/oe) selected and cause a bus conflict on the data pins (prop out and ram out).

    Remember, you can use 1 (not both) SDA or SCL because you need to ensure you do not accidentally send a correct sequence to the eeprom. See the RamBlade schematic.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    Home of the MultiBladeProps: TriBlade,RamBlade, RetroBlade,TwinBlade,SixBlade, website
    Single Board Computer:3 Propeller ICsand aTriBladeProp board (ZiCog Z80 Emulator)
    Prop Tools under Development or Completed (Index)
    Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
    Search the Propeller forums(uses advanced Google search)
    My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

  18. #18

    Default

    Hmm, yes CS or RD/WR. I'll stick with the current schematic just for testing purposes. There are all sorts of cunning optimisations down the track if it is too slow, eg most of the time when reading bytes they are sequential so you could check if n=n+1 and call a much shorter sequence that increments the address.

    I'll test it without the delay and see how it goes.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
    Last edited by ForumTools; 09-30-2010 at 05:04 AM. Reason: Forum Migration

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts