Getting Started - Spin vs Pasm

Dr_Acula · 2009-10-14 12:44

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:

    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.

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

Rayman · 2009-10-14 13:07

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

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

Baggers · 2009-10-14 13:20

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

·

heater · 2009-10-14 13:36

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.

Dr_Acula · 2009-10-14 22:25

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

Yes, that fixed it. Many thanks!

I put this at then end

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

Cluso99 · 2009-10-14 23:00

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 ICs·and a·TriBladeProp 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

Mike Green · 2009-10-14 23:17

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

stopMe cogid stopMe
           cogstop stopMe

Dr_Acula · 2009-10-14 23:51

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.

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

Dr_Acula · 2009-10-15 04:44

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.

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

MagIO2 · 2009-10-15 06:40

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' [noparse]:o[/noparse])

PUB Main
    cognew(@[s]PHigh[/s][color=red]PASMEntry[/color], 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
[color=red]PASMEntry[/color]

        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

Dr_Acula · 2009-10-15 09:20

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

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

Cluso99 · 2009-10-15 09:50

Drac: re your schematic...

It is·a good idea to·use a gate pin on·the 74xx138 as when the input lines change (because of inherant delays) you are likely to get·unwanted glitches on the '138's outputs.

You can double up·using SDA or SCL to free up a pin for the gate on the '138. If gate pin·has 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 ICs·and a·TriBladeProp 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

Cluso99 · 2009-10-15 10:24

Looking at your older code... some things already discussed...

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

[color=red]PASMentry[/color]
        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 [color=red]mov outa,ReadWrite      ' initial value for when dira enabled (dr=wr=1, latch=0)[/color]
        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

        [color=red]'now you need to do the /RD or /WR[/color]
Address_Ret ret

'endlessloop
'        jmp #endlessloop        
        
        ' dira all to zero again when ends - or does stopping cog do this anyway
        [color=red]' stopping the cog places dira to all inputs (for this cog only).[/color]
        ' if pins all go tristate when cog stops then ? need pullups on /rd and /wr and the 138 inputs?
        [color=red]' either /G2A or /G2B gate on the '138 will require pullups. As you must disable the '138, you will not need [/color]
[color=red]        '   to put pullups on /wr and /rd although this is preferable.[/color]
' 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 cog·code 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 ICs·and a·TriBladeProp 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

Dr_Acula · 2009-10-15 12:20

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

MagIO2 · 2009-10-15 12:34

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)

Dr_Acula · 2009-10-15 12:48

This sort of thing?

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

Cluso99 · 2009-10-16 03:05

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 ICs·and a·TriBladeProp 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

Dr_Acula · 2009-10-16 05:13

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

Getting Started - Spin vs Pasm

Comments