PASM beginner questions
g3cwi
Posts: 262
Hi all
I have been looking at someone's demo programs to blink an LED in PASM. There are a couple of things that I could do with some help on. My verbose comments on the program show them, one is the use of OR instead of MOV in two places (MOV does work there too) and some sort of indirect addressing that I don't grasp yet.
(CODE DELETED)
Any clues will be welcome.
Thanks
Richard
I have been looking at someone's demo programs to blink an LED in PASM. There are a couple of things that I could do with some help on. My verbose comments on the program show them, one is the use of OR instead of MOV in two places (MOV does work there too) and some sort of indirect addressing that I don't grasp yet.
(CODE DELETED)
Any clues will be welcome.
Thanks
Richard
Comments
By indirect addressing perhaps you mean the accessing of HUB RAM with RDLONG? Or perhaps the use of the # in the JMP instruction? I can't really guess.
It was this code that was (perhaps) indirect addressing:
add t1, #4 ' point to "on" ticks
rdlong ontix, t1 ' read on timing
Not sure how that work.
Regards
Richard
Cheers
Richard
I prefer to be clear and not just say "variable" - here we are talking about the address of the variable blinkpin (in hub RAM) being passed to the cog via the PAR register. Sometimes people talk about a variable meaning the address, sometimes the current value, and sometimes as an abstract thing which can be changed (which under the hood always means the address is being used to do the updating and reading).
In case its not clear to a newcomer the cog runs in its own separate RAM (which is 32-bit wide) which cannot be accessed from outside the cog. Each cog can access the hub ram (which is byte-addressed) via rdbyte/rdword/rdlong/wrbyte/wrword/wrlong instructions.
The cog RAM itself contains the instructions of the cog as well as the data, and allows self-modifying code as a result. cog RAM addresses increase by 1 for each long, unlike hub RAM which is byte-addressed.
The PAR register gets passed only 14 bits from the COGNEW instruction, being bits 2 to 15 (enough to address cog RAM on long-word boundaries).
For example: "PAR is pin number passed by COGNEW"
Nope. PAR holds the hub address of the pin number and is passed to the cog. This gets copied into t1 (which can be modified, PAR is read-only) for use with the rdlong instruction which READS a LONG from an address in the hub.
I won't bother detailing all the other errors in your comments but will ask that you sift back through so as not to undo your intention of helping other newcomers. You can in fact edit your own posts to correct mistakes or make clarifications (I do this all the time).
I know that my program comments tend to be brief; as programmers we get paid to write code, not comments, so my opinion is that comments should serve to describe the purpose of the code, not simply replicate the often self-evident purpose of an instruction. For those that may think me insensitive to newcomers, I'm not -- that listing is from one of my N&V columns where all of the code is described in great detail.
As a beginner in PASM I can't hope to spot all my errors - that's the nature of being a beginner. However, I have taken your advice and deleted all the code so that other beginners don't miss out on the fun.
By the way, I'm a teacher, not a programmer. So from one profession to another can I suggest that "self evident" is not something that I would ever assume when teaching.
Cheers
Richard
No doubt some silly mistake(s).
Cheers
Richard
-Phil
That does not work so there is something else up.
Cheers
Richard
-Phil
Edit - changing the value passed to pin0 gives the expected results. Changing the value passed to pin1 does nothing.
Cheers
Richard
-Phil
I noticed the cog variable is not used consistently between the start and stop routine. In the start routine you are setting it to the return value from cognew, which is 0 to 7 if it succeeds and -1 if it fails. The stop routine assumes the value is 1 through 8 if the cog is active, and 0 if it is not.
I have realised that it is a Prop BoE thing. I had not realised that some LEDS are active low and some are active high. It was only after writing here that I started to wonder if the problem was hardware related. I was convinced my software was at fault. Now I'm back on track - thanks.
Re the start and stop problem - thanks for that. I did not write the core code so someone else is responsible for that problem!
Cheers
Richard
-Phil
All is working now.
Regards
Richard
I tend to make the dangerous assumption that those interested in programming have a willingness to crack open the manual! A failing on my part, I'm sure. But just as my automobile doesn't have instructions printed on the steering wheel as to what it does, my listings don't tend to explain what an instruction does, rather its intent for the program which I think is more valuable for those using my listings.
IMHO, more verbose is not always simpler. Here's how you can have two pins doing the same thing -- and only one additional cog variable is used (mask for the second pin). Note, too, that as the pins and timing variables are not needed after the .start method, those can be disposed of, too.
Commenting the intent makes the program very discoverable, and that's really the goal as anyone can run tests, look up the instruction definitions, etc...
"ADD" is pretty self evident. What is being added and why isn't.