Shop OBEX P1 Docs P2 Docs Learn Events
Bizzaro World PASM code — Parallax Forums

Bizzaro World PASM code

PhilldapillPhilldapill Posts: 1,283
edited 2009-04-17 22:59 in Propeller 1
I'm working on a PASM program and HAD it working... Now it doesn't. The old program is in the eeprom, so when I reset the chip and allow it to load from eeprom, it works fine, so I know it's not a fried chip or hardware issue. I've made some changes to the program, and have no idea what I messed up.

It's acting very strange. When I toggle the CLm pin (pin 0), the CSm (pin 2) toggles and not CLm!

When I wipe out any reference to the TV object, the DIm pin (pin 1) toggles and not CLm.

What the heck is going on?

CON
  _CLKMODE = XTAL1 + PLL16X 'Set to ext low-speed crystal, 4x PLL
  _XINFREQ = 5_000_000 'Frequency on XIN pin is 5 MHz 
  Sz            = 5
  buffSz        = 1<<(Sz)
  Vref          = 5000          'milliVolts 
                 
OBJ
  TV     : "TV_wText_db"
    
    
VAR
  byte cog
  long stack[noparse][[/noparse]100]
  byte  CPin
  byte  DPin
  byte  CSPin
  long  Sample
  long  buffer[noparse][[/noparse]buffSz]
 
PUB Main | Avg, i, index
  TV.Start(20)
  'Declare Pin assignments             
  Start(0,1,2)
  'Start the PASM program loop for gathering Samples  
  cog := cognew(@entry,@CPin)
  repeat
    waitcnt(clkfreq+cnt)      
 

'The basic pin assignment on startup
PUB Start(C, D, CS)
  CPin := C
  DPin := D
  CSPin := CS

DAT
              org       0
              
entry         mov       dataptrs, par
              rdlong    dcount,dataptrs
              shl       CLm,dcount                      'mask for Clock pin
              add       dataptrs,#4
              rdlong    dcount,dataptrs
              shl       DIm,dcount                      'mask for Data pin
              add       dataptrs,#4
              rdlong    dcount,dataptrs
              shl       CSm,dcount                      'mask for Chip Select pin
              add       dataptrs, #4              

              or        dira, CLm                       'make Clock an output
              or        dira, CSm                       'make Chip Select an output
              andn      dira, DIm                       'make DataIn an input
:mainloop
              or        outa, CLm                       'Set CS High
              nop
              andn      outa, CLm                       'Transition CS low to start conversion...
              jmp       #:mainloop
CLm           long      1                               'bit mask for clock pin
DIm           long      1                               'bit mask for data from adc pin
CSm           long      1                               'bit mask for cs pin
val           long      1
temp          long      1
dataptrs      res       1                               'hub start address for data
dataptr       res       1                               'current address for data
dcount        res       1                               'bit count, also temp during startup

FIT 496               

Comments

  • rokickirokicki Posts: 1,000
    edited 2009-04-17 22:39
    Well, at the very least you've defined CPin, CSPin, and DPin as bytes but you
    are reading them in assembly (rdlong) as though they were longs.

    Also, with a "byte" declaration they are probably not long-aligned, so you're
    probably not even reading where you think you are.

    Either make all three longs, or use rdbyte and increment the address by one,
    not four.
  • PhilldapillPhilldapill Posts: 1,283
    edited 2009-04-17 22:46
    Oh my my my... I can't believe I overlooked that 100 times. I remember changing that now. I thought "Why are these longs? The highest number I'm going to represent is 31, which is clearly a BYTE, not a LONG..."

    I have a feeling that will fix it. Thanks rokicki.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-04-17 22:55
    I'm not sure which way you were planning to fix this, but it won't do just to change your assembly code to rdbyte from rdlong. The reason is that the value passed to PAR gets its bottom two bits zeroed, which means that @CPin gets passed as the address of cog (i.e. CPin is not on a long boundary).

    -Phil
  • PhilldapillPhilldapill Posts: 1,283
    edited 2009-04-17 22:59
    That's right, Phil. I thought something seemed a little off about just changing the variables to bytes and correcting in the assembly. I tried it, however, and it didn't work. I changed the code and variables back to longs, and it works like a champ. Thanks guys.
Sign In or Register to comment.