Propeller doing odd things when programming with PASM
hayden12w3
Posts: 4
Hello all!
I've been taking a swing at assembly coding in the Propeller for a project I've been working on. I have gotten a few individual codes to work well, my favorite being code that controls a '595 shift register. Once I start increasing the complexity of any code (more CMP, if_z, stuff like that) everything goes south. Currently I'm working on code that reads two pins and shifts out a number based on which pins are high and how many times a certain pin has pulsed. The code works well if I just compare the inputs to one number, but once I write in the code to do something based on other stages of the input, random parts of the code stop working. This code is mainly testing certain aspects of assembly coding so that I can make my main project work. What I need to know is what exactly is causing the code to act funny. I'll attach my code and also some pictures of the oscilloscope screen describing what is happening. Also, I'm new to this forum so let me know if there's a way to streamline my posts better with image and code attachments. Thanks!
I've been taking a swing at assembly coding in the Propeller for a project I've been working on. I have gotten a few individual codes to work well, my favorite being code that controls a '595 shift register. Once I start increasing the complexity of any code (more CMP, if_z, stuff like that) everything goes south. Currently I'm working on code that reads two pins and shifts out a number based on which pins are high and how many times a certain pin has pulsed. The code works well if I just compare the inputs to one number, but once I write in the code to do something based on other stages of the input, random parts of the code stop working. This code is mainly testing certain aspects of assembly coding so that I can make my main project work. What I need to know is what exactly is causing the code to act funny. I'll attach my code and also some pictures of the oscilloscope screen describing what is happening. Also, I'm new to this forum so let me know if there's a way to streamline my posts better with image and code attachments. Thanks!
Comments
btw, just a little point but if "zero" is always meant to be zero then why not say "#0" rather than allocating a register for it?
Thanks again! Have a good one!
A couple things, besides declaring a zero variable, what's the intention of
cmp zClear, zero wz cmp inputs, #$3 wzBoth instructions affect the Z flag, the 1st will always clear the flag, and the 2nd will overwrite the 1st regardless.For your time delays:
mov Time, cnt add Time, Pulse waitcnt Time, Pulse xor outa, #$8 mov Time, cnt add Time, Delay waitcnt Time, Delay add iter, #1is perfectly fine for fixed delays, however you can produce synchronized delays with:mov Time, Pulse add Time, cnt ' Establish 1st delay waitcnt Time, Pulse ' Wait, automatically increments Time with Pulse xor outa, #$8 waitcnt Time, Pulse ' Wait pulse duration from previous waitcntThe Prop manual has a decent writeup under the waitcnt section, page 220.Welcome to the forum.
Chris
loop_a mov iter, #8 mov time, pulse add time, cnt :loop or outa, #$08 waitcnt time, delay andn outa, #$08 waitcnt time, pulse djnz iter, #:loop jmp #cycleIn a synchronized loop the cnt register is accessed just before entering the loop -- everything is a delta from that, and waitcnt simplifes what you want to do. Since you seem to want distinct high and low timing values for pin 8, I would suggest dropping xor for andn (low) and or (high). The djnz instruction is optimized for looping, so that's another way to simplify the loop code.I may be missing some bits as I'm kind of doing a drive-by to clear my head of a Propeller schematic I'm working on. Hopefully, though, some of this is helpful.
In Spin, this fragment sends one bit every 104us plus the amount of time it takes to twiddle the IO pin:
repeat 10 waitcnt(104us + cnt) sendBitwhereas a synchronized delay might look like:delayTime := 104us + cnt repeat 10 waitcnt(delayTime) delayTime := delayTime + 104us sendBitThis sends a bit every 104us regardless of the amount of overhead...provided that it returns to the waitcnt prior to the next interval, otherwise it'll wait for the cnt to roll around again.If you ever encounter a problem where the code seems to hang for ~53 seconds, this's likely to be the problem.
In PASM, the waitcnt instruction waits the delay specified by the 1st operand, and then automatically adds the 2nd operand to the 1st. is similar to
waitcnt delay,0 add delay,nextBoth types of delay have their uses, right tool for the right job and all.Y'all are the best!