@mindrobot/Rick
You have me flummoxed. Allow me to reveal by gullibility.
Are you just putting me on or do you really not have access to a scope?
I've worked with some programmers I could believe that about (but would rather not).
All
It going to take me a while to implement all the great ideas revealed by Stephan and Jazzed
so hang on for a day or two for the next post in which I hope the frequency of a signal will be
controlled by a potentiometer. You'll need a scope to look at it or reduce the frequency to hear it..
Jazzed
Do you mean the last PASM command in each cog (for each cog) or
the last PASM command in the entire program?
Harprit
I'm not sure I get the question. As an overview though:
A DAT section is used per COG - that is each COG should have it's own DAT section.
Each new DAT section should start with ORG (or ORG 0).
A PASM program for one COG goes into one DAT section and can be made of up to 496 instructions, long, and res. Instructions are all longs, longs used as variables all should have labels (names), some instructions have labels.
RES variables should be at the end of each DAT section. RES variables should have names. To keep ensure the combination of instructions, longs, and res are in the range of 496, use the fit directive at the end i.e. "fit 496".
Yes it does indeed. Very much so.
I thought that is what was meant but I was not absolutely sure. One needs to be absolutely sure.
Each Cog is independent and needs it constants and res 1 variables listed at its tail end.
I'm a materials guy myself, and my readers are often disappointed when I cannot help them with their electronic problems.
However I do really, really like to build stuff. I built a fully aerobatic single place airplane when I was 25!
Probably the youngest guy ever to do so singlehandedly. And I did not know how to fly and I did not know much about
aeroplanes and had never built anything that complicated before. Rudy Frasca of the Frasca flight simulators taught me
how to fly. A lot of it has to do with just plain hanging in there. Not quitting.
So this PASM beginner's book might get done yet. I'm getting lots of great help from some great guys on this forum.
I'm even starting to understand some of it!! Amazing.
Why will the 4 lines not go on and off in this program
VAR
long Shared
PUB Main
dira[0]~~
shared:=10
cognew(@newCog, @Shared)
repeat
!outa[0]
waitcnt(clkfreq/shared+cnt)
DAT
Org 0
newCog
mov dira, pin_07
:loop mov outa, pin_off
call #pause
mov outa, pin_on
call #pause
jmp :loop
pause mov time, delay 'the delay subroutine
add time, #$Ff 'delay added to skip past underflow of CNT
delay_loop sub time, #1 wz 'sub 1 from time and set flag if 0
if_nz jmp #delay_loop 'if flag not 0 go back to take4
pause_ret ret
pin_07 long %00000000_00000000_00000000_11111111
pin_off long %00000000_00000000_00000000_00000000
pin_on long %00000000_00000000_00000000_11110000
delay long 4000
mem res 1
time res 1
fit
dat
You do understand that all cog outputs are OR'd together, hence any cog can make an IO pin go high, despite what's happening in other cogs. You have two cogs manipulating IO pins and there's bound to be a conflict that causes confusing results.
You're also missing # in your jmp #:loop line.
And -- if I may, as you're insisting on writing a book for beginners -- suggest that you also include good formatting and documentation habits (which your code does not yet illustrate). I find that beginners create a lot of problems through sloppy formatting that ends up hiding logic errors.
Putting my money where my big mouth is, this is how I would have constructed that code (this works on Demo and QuickStart boards)
dat
org 0
newcog mov dira, PINS_23_16 ' make P23..P16 outputs
:loop mov outa, ON_23_20 ' activate P23..P20
mov timer, DLY_TICKS ' set delay
call #delay ' hold a bit
mov outa, ON_19_16 ' activate P19..P16
mov timer, DLY_TICKS
call #delay
jmp #:loop
delay add timer, cnt ' sync with system counter
waitcnt timer, #0 ' let it expire
delay_ret ret
PINS_23_16 long $00_FF_00_00
ON_23_20 long $00_F0_00_00
ON_19_16 long $00_0F_00_00
DLY_TICKS long 80_000_000 >> 2 ' 1/4 second @ 80MHz
timer res 1
fit
Note that the waitcnt instruction eliminates the need for running loops to create delays.
Well I did think I understood that.
Cog0 sets pin 0 as an output and does not bother any other pins
Cog1 also sets Pin 0 as an output also there should be no conflict on pin 0 and does blink just fine.
The 4 pins are pins 4 to 7 and they are independent of cog0
I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?
Cog0 sets pin 0 as an output and does not bother any other pins
Cog1 also sets Pin 0 as an output also there should be no conflict on pin 0 and does blink just fine.
I understand that; I just want to make sure that you understand that if either of the cogs make the pin high it will go high; this is useful (for signal gating) but can confuse beginners unless you are very careful in your explanation.
I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?
Not in my book. Why would use use loop counting when you have waitcnt which is far more effective? If you're going to teach Propeller programming, take advantage of Propeller features. And if you insist on counting down, you could simplify with djnz.
pause mov time, delay ' set delay
djnz time, $ ' decrement to 0
pause_ret ret ' return
Herein lies the oft-stated problem of being a beginner and writing a beginner's book: your lack of experience could cause your readers to suffer more than you ever intend. Sure, they'll learn along the way, but better they learn from your mistakes instead of by repeating them.
The problem for me is that I have to start the beginners very slowly for I lose them. That I know.
There are a million ways to get this done better and faster but if no one is reading the material after 10 pages,we
did not get it done and we can all go home.
As for the book. Lets wait and see what I come up with and see if it helps and if it meets your standards.
You are judging it from the code I write today. That is my learning process, not the finished product.
I hope that you will be pleasantly surprised. The beginners will like the book (and no doubt there will be some carping)
That's the way it is. Any one who can do it better is most welcome. This thing has been kicking around for a while.
I am talking high school kid, not engineers with expertise is C++. Amazon me, My books get 5 stars. See what they say.
From the experts....NO BOOKS YET. I don't think that you would rather that I quit?
Let me turn this around. I'm an actor, seeking to make a full-time living in the entertainment business. Should I take lessons from a youngster who's done a couple gigs in community theater or from a seasoned stage and screen veteran with dozens of movies, plays, and hundreds of TV episodes to his credit? Who do you think can give me the best guidance toward a career as a full-time actor? Someone who isn't, or someone who actually is? Of course, I'll stick with an expert (which I do; the second description above is of my acting teacher, a 45-year show-biz veteran).
I'm suggesting you develop some serious expertise before presenting yourself as one; whether you mean it to or not, your name on the cover of a book sets you up as an "expert."
My books get 5 stars.
Sorry, not from me. When asked, I steered a newbie AWAY from your Spin book because I felt it had too many errors and taught many bad habits. Mind you, this is just my opinion -- and if it matters, I've been writing for Nuts & Volts since 1997 and get a lot of very nice email about the column. I have my own book on Spin in the works, we'll see how it fairs. In fact, I'll sign a copy for you; that way you don't have to pay for the book and if I get famous, you can eBay my autograph for extra cash!
I used to subscribe to Nuts and Volts and always made it a point to read you stuff because, and I hate to say this, your stuff was simple enough for a novice like me to read and to understand. As I remember it was mostly PIC stuff. The stuff you guided me to on the propeller (that you had authored) was very good because I could understand it.
To follow up on your actor analogy, I am not aiming at professional programmers, my audience is tinkerers and beginners. If you want to be a profession programmer who writes compilers and search engines, you need a decent degree from a reputable school. Maybe even a math minor in set theory. There are a few good free lance programmers but they are not going to be reading my book. I am sure your book will be above the level of my audience and I very much look forward to reading your book. Let me know when you need my address. And good luck and best wishes on you success. And I hope you get really really famous.
Hurry up on your book, I'm 71 and it could be curtains any day now!
I think if there is a continous accompaniment of experts the book will be very good in the end.
Harprit is a beginner himself. This means he will encounter a lot of of the traps a beginner will step into.
Experts know the traps very well and as more as they get experts the more these experts are blind for those traps
They code it right without thinking anymore about it.
Especially about the command waitcnt:
What's so hard about understanding waitcnt stops the whole cog: Until the value "timer" is matched by the system-counter.
This leads me to an idea: How about using the propeller itself to illustrate how the propeller-hardware works?
How about coding a program that shows a model of the systemcounter counting up all the time (as a model is enough lets say from 0-99 wrapping around to 0)
Then a model of an animated cog executing commands and if the command WaitCnt is executed stopping the animation until the systemcounter matches the "timer"-value
and then the cog-animation continues.
Next best solution would be to create some graphics that are "snap-shots" of this animation
- executing normal commands
- executing the WaitCnt
- stop until match
- executing commands again.
It is all just a matter of how much time and effort are you taking on explaining anything.
Harprit if your product includes explanations like this the readers will call for 10 stars.
Anyway a waitcnt stops the whole cog. There are situations where a delay is needed and other things should run at the same time at high speed in the same cog
This is the place for using a counter like you did in the code above.
I have a more general question too: You are in an early stage of the book-project. The example-codes that you are posting are they just for your own learning ahead of explaining or
do you want to start your book with the code-samples you have posted?
If second it would be good to have headlines what the code will do or which new things (compared to the code-example before) the code includes.
keep the questions coming
best regards
Right now everything is my learning process. It will be very different as I myself start to understand the system.
I fully understand your point about experts coding it right the first time. They do not appreciate what the novice is going through in his mind. For him it has to be made simple. As you stated everything has to be illustrated and explained. I will try to do that as per your suggestions. You are a teacher so your opinions are very important.
Just follow and see what happens. It will be OK.
Harprit
PS
Though there have been some extremely helpful suggestions and posts, there have also been some posts by experts that are totally missing what beginner's need. IMHO.
@Jon
I am pretty sure you recommended the Parallax book in place of mine. If you think that book is for beginners, you have another think coming. I think experienced programmers are so eager to show what great stuff can be done with the propeller that they lose track of any teaching that might get done. I too think it is a fantastic engine but the learners don't say "Tell me what a great chip this is'". They say "I don't know where to start, can you help me?" Lets try to help them.
H
The stuff you guided me to on the propeller (that you had authored) was very good because I could understand it.
I appreciate that feedback; especially being a self-taught programmer. That said, I didn't start writing about programming until I had about 17 years of practical (nothing earth-shattering, but real-wold nonetheless) experience. I've waited this long to write a whole book on Spin because I really wanted to make sure I was good at the [practical] stuff that I like to teach.
As I remember it was mostly PIC stuff.
SX perhaps, using SX/B (which I helped with), but never the PIC. I've only used a PIC a couple times, and neither time was a lot of fun (hence I have never written about it).
it has to be made simple.
This statement is frequently [ab]used as an excuse for "quick and dirty" which I always say -- even in print -- is never quick and always dirty. In the end, your name is going on the book and you have to be responsible for its content. I am merely suggesting you can point newbies to the dangers of a cliff without pushing them off of one.
My SPIN book has over 120, yes well over 120 pages, pages of SPIN Code in it and each and every line is commented so that a beginner can understand it. There is nothing quick about that and no one has complained that there was any dirtiness or slop. Quite the contrary. On the other hand none of the experts has come anywhere near providing that level of coding and commenting. NOT even CLOSE. In most programs not even half the lines are commented. I suppose beginners will just have to divine what those lines mean.
So I very much look forward to a very well coded and commented book from you. In every way as good as the stuff you sent me.
...Especially about the command waitcnt...waitcnt stops the whole cog:
This resonates with me. Waitcnt is featured too often in code examples in the PM, and at the expense of more important matters. It's almost a worthless thing. The project I'm working on right now has 862 lines of code and not one Waitcnt. I couldn't possibly afford to stop execution in any of the cogs...not unless I can also stop The World.
My code is always clean and well-commented -- you know that from seeing my listings. To be fair (to me, that is), you cannot count magazine listings as they are in 2-column format and there is barely enough room in a column for code, hence no comments in magazine listings but there is a lot of descriptive text in my column. All of the programs I write -- whether they're published or not -- are documented; for reasons I just explained, sometimes the comments don't make it to print. This is why I work so hard at crafting code that is easy to follow; self-commenting to the degree I can.
I hope you will avoid newbie (quick and dirty) traps the fill your Spin code: things like embedding pin numbers, e.g.,
dira[16] := 1
Yes, it's quick. Yes, it works. Until someone comes along and has to change the layout and then has to look through the code to find all instances of the above line to fix them. Sure, there is global search-and-replace, but if one is smart enough to use that I have to assume that one is smart enough to create named constants where the are appropriate.
dira[LED] := 1
The other issue I take with your code is inconsistent formatting. Variables, for example: sometimes they're all lower case (even with two words in name), sometimes camel-case, sometimes start with an uppercase letter. The same inconsistencies exist with constant naming and method naming.
Again, it's your book, do as you will. I just think you owe it to your readers to produce a good book. Working code is just a start. You do newcomers no kindness by teaching them (through examples) bad habits. Even hobbyist programmers can learn to code well.
I am pretty sure you recommended the Parallax book in place of mine.
The only book I've ever recommended is the PE Labs book by Andy Lindsay, though I have the same "quick and dirty" commentary about it. Getting past that, there is useful code and it sufficiently coddles those that still send their laundry home to mother. <smirk> I'm not the coddling type.
I will bow out now as I don't think there is anything else I can offer.
not one waitcnt. I couldn't possibly afford to stop execution in any of the cogs.
That's not unheard of, but it is rare. Still, if you have any kind of timing constraints then you are using other -- dare I say more sophisticated and less beginner-friendly -- mechanisms. Peter Van der Zee is a master at programming timing-centric code without every stopping (he's scary good).
For example, I wanted to get my own grip on jmpret (it stumped me; remember, I'm an actor) until I just rewrote a demo for myself. This [silly] code does fairly precise timing of blinky LEDs without using waitcnt (again, not my original code, I just rewrote to "make it mine.").
dat
org 0
entry mov outa, #0 ' initialize to both off
mov dira, led1mask ' make LED1 pin an output
or dira, led2mask ' make LED2 pin an output
mov led2code, #led2 ' setup ping-pong multitasking
mov timer1, cnt ' initialize timers
mov timer2, timer1
led1 or outa, led1mask ' led 1 on
add timer1, led1ontix ' set led 1 on time
:wait1on jmpret led1code, led2code ' let led 2 have some time
mov t1, timer1 ' copy timer
sub t1, cnt ' compare with system cnt
cmps t1, #0 wc, wz ' timer expired?
if_a jmp #:wait1on ' loop if not done
andn outa, led1mask ' led 1 off
add timer1, led1offtix ' set led 1 off time
:wait1off jmpret led1code, led2code ' let led 2 have some time
mov t1, timer1 ' copy timer
sub t1, cnt ' compare with system cnt
cmps t1, #0 wc, wz ' timer expired?
if_a jmp #:wait1off ' loop if not done
jmp #led1
led2 xor outa, led2mask ' toggle led 2
add timer2, led2hctix ' set led 2 half-cycle time
:wait2 jmpret led2code, led1code ' let led 1 have some time
mov t2, timer2 ' copy timer
sub t2, cnt ' compare with system cnt
cmps t2, #0 wc, wz ' timer expired?
if_a jmp #:wait2 ' loop if not done
jmp #led2
' --------------------------------------------------------------------------------------------------
led1mask long 0-0 ' pin mask for LED 1
led1ontix long 0-0 ' on timing (ticks) for LED 1
led1offtix long 0-0 ' off timing (ticks) for LED 1
led2mask long 0-0 ' pin mask for LED 2
led2hctix long 0-0 ' half-cycle timing (ticks) for LED 2
timer1 res 1 ' state timers
timer2 res 1
led1code res 1 ' jump vectors
led2code res 1
t1 res 1 ' work vars
t2 res 1
fit 496
Definitely not for beginners, but I will be presenting this demo (among others) at DefCon next week while giving an overview presentation on the Propeller.
[waitcnt] It's almost a worthless thing. The project I'm working on right now has 862 lines of code and not one Waitcnt. I couldn't possibly afford to stop execution in any of the cogs...not unless I can also stop The World.
Isn't that a bit like saying my code has 700+ lines and not a single waitvid? If you don't need a particular instruction then dont' use it
I could agree with you on most examples being worthless but then I think examples aren't necessarily the best way to get the message across anyway.
I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?
The delay routine - while odd - does what it says on the tin. Your problem here is the jump using a register instead of a label. Register $001 (:loop) contains a reference to register $00C (pin_off) which is your real jump target. Given that you only have a small amount of SPIN code there isn't much in the way to stop execution (nops, some conditionals) your code runs until it hits the SPIN stack marker ($FFF9FFFF)A which is now interpreted as code (waitvid). The video h/w isn't initialised so the waitvid hangs (LEDs on).
Simple test, I initialised it (video h/w) before the rogue jump which allows execution to continue. The program counter wraps and restarts your program which then looks like it continues normally. But there are other side effects which stop execution again later (from the looks of it cnt dependent). Nothing to worry about right now. Just fix the jump target.
A This is due to the fact that the cog is always initialised with the same amount of longs even if your program has only say 20 lines. So any code/data following your program in hub memory (SPIN methods in this case) will make it into cog memory and is potentially interpreted as code.
Isn't that a bit like saying my code has 700+ lines and not a single waitvid? If you don't need a particular instruction then dont' use it
For sure! I've got nothing against the existence of a Waitcnt instruction, just its exclusivity in PM coding examples. It's frustrating primarily when something you do need is nowhere to be found.
Probably due to too few brain cells or insufficient interconnections, unlike you I really do like examples. Not puerile examples, but real world examples appropriately documented for the propeller neophyte.
@Jon: I'm a novice to the propeller, but not to real-time embedded control. In fact that's pretty much my only frame-of-reference wrt programming. I try to keep it that way.
In this book, I will assume that you have a serious interest in learning PASM. The book will follow the format, and the programs that were delivered in my book on learning SPIN. I will assume that you have the following resources available to you.
xor outa, pin
this instruction inverts the signal on pin 16 each time through the loop.
Harprit
This code may not work for me as listed here. I may be off on this one, but reaching deep into the gray matter, into the 8080/Z80 days, a fast trick to clearing the accumulator was to use XOR A producing all ZEROs in the accumulator. Refer to the logic truth table for XOR on p103 fig 2.56, Digital Logic and State Machine Design, Comer 3rd Ed. or other favorite reference. You can not perform a toggle function by an XORing a signal with itself. An XOR function is a difference detector. The only way to do this would be the PASM equivalent of negating the pin value on each pass through the loop to achieve the toggle function.
Frank
@localroger, I also have the Z80 book (paperback 4th printing 1980), and the aforementioned Comer book for hardware design. Built my long gone IMSAI 8080 one board at a time.....
I must admit that I am not following along with your example, however I am following this thread. My advice, don't get discouraged, I personally applaud your efforts, because there needs to be better documentation and well commented examples pertaining to PASM. From my own personal perspective, I would much rather buy a book written by an expert as compared to a novice, but that does not mean that a novice has nothing to contribute. Some of the most ingenious code I have ever seen was written by novices. Sure there were some improper coding techniques contained within the code, but nonetheless brilliant work.
To be perfectly honest, whatever the field of interest, many of the worlds experts on any given subject are often filled with a lot of hot air and some self-perceived idea of greatness, which is a big turn off for me, especially when I am attempting to learn something from the ground up. And there are many times when the so called expert truly has no concept of the facts. For example, several years ago I was unemployed, and having a high degree of interest in patents, I applied for a position as a paralegal for a patent attorney. During an interview, I showed this expert patent attorney a patent application that I had written. As he is flipping through the pages of the patent application, he insults me by saying that the drawings will never meet the United States Patent And Trademark Offices regulations. The fact of the matter is, he didn't know his Smile from a whole in the ground, because the drawings had already received approval from the USPTO. He was wrong about the proper margins required for drawings and he was wrong about a specific technique that I used in my drawings. I did not say anything at the time, but I thought to myself that I would never hire this idiot as my patent attorney. Needless to say, the margin requirements had changed and this expert was unaware of the changes, and as far as the technique used within the drawings, I took advantage of the USPTO rules and regulations and did something that I am certain is very rare in patent documents or has never been done before, but it still met the criteria of the USPTO, and a patent was granted.
Additionally, while being a far cry from what I consider being an expert electrician, I have a very fair degree of skill and knowledge in this trade. Every once in a while the new kid on the block will teach me a thing or two.
So I say to you Harprit, "Go for it!". Even if you do not succeed in this endeavor, hopefully you will draw enough attention to this thread to where some serious action will be taken.
Thanks.
I got out my demo board and ran your program.
Then..
I eliminated the last two lines of your program as I could not understand what they did.
I still works but I wondered of I had missed something. Did I do it right?
Can one say that the RES area has to list all variables that will be used in the program and
that all constants have to be listed as " value long 2000" which means that these are
the equivalent of the VAR and CON areas of a SPIN program?
I really appreciate your crisp input.
@stephan
Though I intend to learn to use a debugger later on, I am not sure that they are useful beginner's tools.
Too long a learning curve to allow them to use them effectively in the beginning stages.
Besides they want to learn PASM not debuggers. I think that comes later.
I may change my mind and (at this stage) I may well be wrong.
I say this because with all its mistakes in it, beginners still like my very simple SPIN book very much.
The criticisms are from people who already know SPIN rather well, but then the book is not for them!
I would like the PASM book to be similarly received.
Harprit
Yes, debuggers do have a learning curve. Which in my own experience is why I try to find a way to learn it early. If I can not probe or scope what is going on, then I am only guessing in the dark. And anyhow, no matter the scope or LSA you may own or have access to, it can not track the internal workings of your logic. Only a good trace can do that. You should consider using debugging along with your example code so that anyone wanting to actually follow the flow of the logic and its effects can see clearly what happens at each step in the trace. This will also serve to enhance the understanding of "unexpected features". Debugging is in many ways similar to the thought process of troubleshooting a misbehaving system.
Comments
Do you mean the last PASM command in each cog (for each cog) or
the last PASM command in the entire program?
Harprit
You have me flummoxed. Allow me to reveal by gullibility.
Are you just putting me on or do you really not have access to a scope?
I've worked with some programmers I could believe that about (but would rather not).
All
It going to take me a while to implement all the great ideas revealed by Stephan and Jazzed
so hang on for a day or two for the next post in which I hope the frequency of a signal will be
controlled by a potentiometer. You'll need a scope to look at it or reduce the frequency to hear it..
Harprit
I'm not sure I get the question. As an overview though:
A DAT section is used per COG - that is each COG should have it's own DAT section.
Each new DAT section should start with ORG (or ORG 0).
A PASM program for one COG goes into one DAT section and can be made of up to 496 instructions, long, and res. Instructions are all longs, longs used as variables all should have labels (names), some instructions have labels.
RES variables should be at the end of each DAT section. RES variables should have names. To keep ensure the combination of instructions, longs, and res are in the range of 496, use the fit directive at the end i.e. "fit 496".
Does that help at all?
--Steve
Yes it does indeed. Very much so.
I thought that is what was meant but I was not absolutely sure. One needs to be absolutely sure.
Each Cog is independent and needs it constants and res 1 variables listed at its tail end.
Thanks
Harprit.
A pleasure to flummox you!!
I've never owned a scope (until recently) and never really learned how to use one. I imagine they could be quite useful!!
My formal electronics education is lacking (nonexistent) in some areas.....
I do have a recently purchased DSO Nano pocket scope some place in a box in my office but I haven't had/taken the time to do anything with it yet.
I do have an old logic probe I made from a kit way back when that I've used.....
I've somehow survived through my building stages without a scope.....
I'm 75% software (and I guess 25% blinking lights!!)
Now that was really funny.
I'm a materials guy myself, and my readers are often disappointed when I cannot help them with their electronic problems.
However I do really, really like to build stuff. I built a fully aerobatic single place airplane when I was 25!
Probably the youngest guy ever to do so singlehandedly. And I did not know how to fly and I did not know much about
aeroplanes and had never built anything that complicated before. Rudy Frasca of the Frasca flight simulators taught me
how to fly. A lot of it has to do with just plain hanging in there. Not quitting.
So this PASM beginner's book might get done yet. I'm getting lots of great help from some great guys on this forum.
I'm even starting to understand some of it!! Amazing.
Harprit.
VAR long Shared PUB Main dira[0]~~ shared:=10 cognew(@newCog, @Shared) repeat !outa[0] waitcnt(clkfreq/shared+cnt) DAT Org 0 newCog mov dira, pin_07 :loop mov outa, pin_off call #pause mov outa, pin_on call #pause jmp :loop pause mov time, delay 'the delay subroutine add time, #$Ff 'delay added to skip past underflow of CNT delay_loop sub time, #1 wz 'sub 1 from time and set flag if 0 if_nz jmp #delay_loop 'if flag not 0 go back to take4 pause_ret ret pin_07 long %00000000_00000000_00000000_11111111 pin_off long %00000000_00000000_00000000_00000000 pin_on long %00000000_00000000_00000000_11110000 delay long 4000 mem res 1 time res 1 fit datHarprit
You're also missing # in your jmp #:loop line.
And -- if I may, as you're insisting on writing a book for beginners -- suggest that you also include good formatting and documentation habits (which your code does not yet illustrate). I find that beginners create a lot of problems through sloppy formatting that ends up hiding logic errors.
Putting my money where my big mouth is, this is how I would have constructed that code (this works on Demo and QuickStart boards)
dat org 0 newcog mov dira, PINS_23_16 ' make P23..P16 outputs :loop mov outa, ON_23_20 ' activate P23..P20 mov timer, DLY_TICKS ' set delay call #delay ' hold a bit mov outa, ON_19_16 ' activate P19..P16 mov timer, DLY_TICKS call #delay jmp #:loop delay add timer, cnt ' sync with system counter waitcnt timer, #0 ' let it expire delay_ret ret PINS_23_16 long $00_FF_00_00 ON_23_20 long $00_F0_00_00 ON_19_16 long $00_0F_00_00 DLY_TICKS long 80_000_000 >> 2 ' 1/4 second @ 80MHz timer res 1 fitNote that the waitcnt instruction eliminates the need for running loops to create delays.
Well I did think I understood that.
Cog0 sets pin 0 as an output and does not bother any other pins
Cog1 also sets Pin 0 as an output also there should be no conflict on pin 0 and does blink just fine.
The 4 pins are pins 4 to 7 and they are independent of cog0
I diagnosed the problem as in the delay routine of Cog1. Am I all wet? Is the delay part OK?
Harprit.
I'll work on the formatting
Thanks
Harprit
Thanks for the additional code
Its great to see a pro do it, that is what is missing most of the time, so simple stuff is never seen by beginners.
H
I understand that; I just want to make sure that you understand that if either of the cogs make the pin high it will go high; this is useful (for signal gating) but can confuse beginners unless you are very careful in your explanation.
Not in my book. Why would use use loop counting when you have waitcnt which is far more effective? If you're going to teach Propeller programming, take advantage of Propeller features. And if you insist on counting down, you could simplify with djnz.
pause mov time, delay ' set delay djnz time, $ ' decrement to 0 pause_ret ret ' returnHerein lies the oft-stated problem of being a beginner and writing a beginner's book: your lack of experience could cause your readers to suffer more than you ever intend. Sure, they'll learn along the way, but better they learn from your mistakes instead of by repeating them.
The problem for me is that I have to start the beginners very slowly for I lose them. That I know.
There are a million ways to get this done better and faster but if no one is reading the material after 10 pages,we
did not get it done and we can all go home.
As for the book. Lets wait and see what I come up with and see if it helps and if it meets your standards.
You are judging it from the code I write today. That is my learning process, not the finished product.
I hope that you will be pleasantly surprised. The beginners will like the book (and no doubt there will be some carping)
That's the way it is. Any one who can do it better is most welcome. This thing has been kicking around for a while.
I am talking high school kid, not engineers with expertise is C++. Amazon me, My books get 5 stars. See what they say.
From the experts....NO BOOKS YET. I don't think that you would rather that I quit?
Harprit.
I'm suggesting you develop some serious expertise before presenting yourself as one; whether you mean it to or not, your name on the cover of a book sets you up as an "expert."
Sorry, not from me. When asked, I steered a newbie AWAY from your Spin book because I felt it had too many errors and taught many bad habits. Mind you, this is just my opinion -- and if it matters, I've been writing for Nuts & Volts since 1997 and get a lot of very nice email about the column. I have my own book on Spin in the works, we'll see how it fairs. In fact, I'll sign a copy for you; that way you don't have to pay for the book and if I get famous, you can eBay my autograph for extra cash!
I used to subscribe to Nuts and Volts and always made it a point to read you stuff because, and I hate to say this, your stuff was simple enough for a novice like me to read and to understand. As I remember it was mostly PIC stuff. The stuff you guided me to on the propeller (that you had authored) was very good because I could understand it.
To follow up on your actor analogy, I am not aiming at professional programmers, my audience is tinkerers and beginners. If you want to be a profession programmer who writes compilers and search engines, you need a decent degree from a reputable school. Maybe even a math minor in set theory. There are a few good free lance programmers but they are not going to be reading my book. I am sure your book will be above the level of my audience and I very much look forward to reading your book. Let me know when you need my address. And good luck and best wishes on you success. And I hope you get really really famous.
Hurry up on your book, I'm 71 and it could be curtains any day now!
Harprit.
Harprit is a beginner himself. This means he will encounter a lot of of the traps a beginner will step into.
Experts know the traps very well and as more as they get experts the more these experts are blind for those traps
They code it right without thinking anymore about it.
Especially about the command waitcnt:
What's so hard about understanding waitcnt stops the whole cog: Until the value "timer" is matched by the system-counter.
This leads me to an idea: How about using the propeller itself to illustrate how the propeller-hardware works?
How about coding a program that shows a model of the systemcounter counting up all the time (as a model is enough lets say from 0-99 wrapping around to 0)
Then a model of an animated cog executing commands and if the command WaitCnt is executed stopping the animation until the systemcounter matches the "timer"-value
and then the cog-animation continues.
Next best solution would be to create some graphics that are "snap-shots" of this animation
- executing normal commands
- executing the WaitCnt
- stop until match
- executing commands again.
It is all just a matter of how much time and effort are you taking on explaining anything.
Harprit if your product includes explanations like this the readers will call for 10 stars.
Anyway a waitcnt stops the whole cog. There are situations where a delay is needed and other things should run at the same time at high speed in the same cog
This is the place for using a counter like you did in the code above.
I have a more general question too: You are in an early stage of the book-project. The example-codes that you are posting are they just for your own learning ahead of explaining or
do you want to start your book with the code-samples you have posted?
If second it would be good to have headlines what the code will do or which new things (compared to the code-example before) the code includes.
keep the questions coming
best regards
Stefan
Right now everything is my learning process. It will be very different as I myself start to understand the system.
I fully understand your point about experts coding it right the first time. They do not appreciate what the novice is going through in his mind. For him it has to be made simple. As you stated everything has to be illustrated and explained. I will try to do that as per your suggestions. You are a teacher so your opinions are very important.
Just follow and see what happens. It will be OK.
Harprit
PS
Though there have been some extremely helpful suggestions and posts, there have also been some posts by experts that are totally missing what beginner's need. IMHO.
@Jon
I am pretty sure you recommended the Parallax book in place of mine. If you think that book is for beginners, you have another think coming. I think experienced programmers are so eager to show what great stuff can be done with the propeller that they lose track of any teaching that might get done. I too think it is a fantastic engine but the learners don't say "Tell me what a great chip this is'". They say "I don't know where to start, can you help me?" Lets try to help them.
H
I appreciate that feedback; especially being a self-taught programmer. That said, I didn't start writing about programming until I had about 17 years of practical (nothing earth-shattering, but real-wold nonetheless) experience. I've waited this long to write a whole book on Spin because I really wanted to make sure I was good at the [practical] stuff that I like to teach.
SX perhaps, using SX/B (which I helped with), but never the PIC. I've only used a PIC a couple times, and neither time was a lot of fun (hence I have never written about it).
This statement is frequently [ab]used as an excuse for "quick and dirty" which I always say -- even in print -- is never quick and always dirty. In the end, your name is going on the book and you have to be responsible for its content. I am merely suggesting you can point newbies to the dangers of a cliff without pushing them off of one.
My SPIN book has over 120, yes well over 120 pages, pages of SPIN Code in it and each and every line is commented so that a beginner can understand it. There is nothing quick about that and no one has complained that there was any dirtiness or slop. Quite the contrary. On the other hand none of the experts has come anywhere near providing that level of coding and commenting. NOT even CLOSE. In most programs not even half the lines are commented. I suppose beginners will just have to divine what those lines mean.
So I very much look forward to a very well coded and commented book from you. In every way as good as the stuff you sent me.
H
This resonates with me. Waitcnt is featured too often in code examples in the PM, and at the expense of more important matters. It's almost a worthless thing. The project I'm working on right now has 862 lines of code and not one Waitcnt. I couldn't possibly afford to stop execution in any of the cogs...not unless I can also stop The World.
Sing it sister!
I hope you will avoid newbie (quick and dirty) traps the fill your Spin code: things like embedding pin numbers, e.g.,
Yes, it's quick. Yes, it works. Until someone comes along and has to change the layout and then has to look through the code to find all instances of the above line to fix them. Sure, there is global search-and-replace, but if one is smart enough to use that I have to assume that one is smart enough to create named constants where the are appropriate.
The other issue I take with your code is inconsistent formatting. Variables, for example: sometimes they're all lower case (even with two words in name), sometimes camel-case, sometimes start with an uppercase letter. The same inconsistencies exist with constant naming and method naming.
Again, it's your book, do as you will. I just think you owe it to your readers to produce a good book. Working code is just a start. You do newcomers no kindness by teaching them (through examples) bad habits. Even hobbyist programmers can learn to code well.
The only book I've ever recommended is the PE Labs book by Andy Lindsay, though I have the same "quick and dirty" commentary about it. Getting past that, there is useful code and it sufficiently coddles those that still send their laundry home to mother. <smirk> I'm not the coddling type.
I will bow out now as I don't think there is anything else I can offer.
That's not unheard of, but it is rare. Still, if you have any kind of timing constraints then you are using other -- dare I say more sophisticated and less beginner-friendly -- mechanisms. Peter Van der Zee is a master at programming timing-centric code without every stopping (he's scary good).
For example, I wanted to get my own grip on jmpret (it stumped me; remember, I'm an actor) until I just rewrote a demo for myself. This [silly] code does fairly precise timing of blinky LEDs without using waitcnt (again, not my original code, I just rewrote to "make it mine.").
dat org 0 entry mov outa, #0 ' initialize to both off mov dira, led1mask ' make LED1 pin an output or dira, led2mask ' make LED2 pin an output mov led2code, #led2 ' setup ping-pong multitasking mov timer1, cnt ' initialize timers mov timer2, timer1 led1 or outa, led1mask ' led 1 on add timer1, led1ontix ' set led 1 on time :wait1on jmpret led1code, led2code ' let led 2 have some time mov t1, timer1 ' copy timer sub t1, cnt ' compare with system cnt cmps t1, #0 wc, wz ' timer expired? if_a jmp #:wait1on ' loop if not done andn outa, led1mask ' led 1 off add timer1, led1offtix ' set led 1 off time :wait1off jmpret led1code, led2code ' let led 2 have some time mov t1, timer1 ' copy timer sub t1, cnt ' compare with system cnt cmps t1, #0 wc, wz ' timer expired? if_a jmp #:wait1off ' loop if not done jmp #led1 led2 xor outa, led2mask ' toggle led 2 add timer2, led2hctix ' set led 2 half-cycle time :wait2 jmpret led2code, led1code ' let led 1 have some time mov t2, timer2 ' copy timer sub t2, cnt ' compare with system cnt cmps t2, #0 wc, wz ' timer expired? if_a jmp #:wait2 ' loop if not done jmp #led2 ' -------------------------------------------------------------------------------------------------- led1mask long 0-0 ' pin mask for LED 1 led1ontix long 0-0 ' on timing (ticks) for LED 1 led1offtix long 0-0 ' off timing (ticks) for LED 1 led2mask long 0-0 ' pin mask for LED 2 led2hctix long 0-0 ' half-cycle timing (ticks) for LED 2 timer1 res 1 ' state timers timer2 res 1 led1code res 1 ' jump vectors led2code res 1 t1 res 1 ' work vars t2 res 1 fit 496Definitely not for beginners, but I will be presenting this demo (among others) at DefCon next week while giving an overview presentation on the Propeller.
I could agree with you on most examples being worthless but then I think examples aren't necessarily the best way to get the message across anyway.
Simple test, I initialised it (video h/w) before the rogue jump which allows execution to continue. The program counter wraps and restarts your program which then looks like it continues normally. But there are other side effects which stop execution again later (from the looks of it cnt dependent). Nothing to worry about right now. Just fix the jump target.
A This is due to the fact that the cog is always initialised with the same amount of longs even if your program has only say 20 lines. So any code/data following your program in hub memory (SPIN methods in this case) will make it into cog memory and is potentially interpreted as code.
For sure! I've got nothing against the existence of a Waitcnt instruction, just its exclusivity in PM coding examples. It's frustrating primarily when something you do need is nowhere to be found.
Probably due to too few brain cells or insufficient interconnections, unlike you I really do like examples. Not puerile examples, but real world examples appropriately documented for the propeller neophyte.
@Jon: I'm a novice to the propeller, but not to real-time embedded control. In fact that's pretty much my only frame-of-reference wrt programming. I try to keep it that way.
This code may not work for me as listed here. I may be off on this one, but reaching deep into the gray matter, into the 8080/Z80 days, a fast trick to clearing the accumulator was to use XOR A producing all ZEROs in the accumulator. Refer to the logic truth table for XOR on p103 fig 2.56, Digital Logic and State Machine Design, Comer 3rd Ed. or other favorite reference. You can not perform a toggle function by an XORing a signal with itself. An XOR function is a difference detector. The only way to do this would be the PASM equivalent of negating the pin value on each pass through the loop to achieve the toggle function.
Frank
@localroger, I also have the Z80 book (paperback 4th printing 1980), and the aforementioned Comer book for hardware design. Built my long gone IMSAI 8080 one board at a time.....
Harprit's original listing had this in it: "Pin Long |<16"
The odd syntax means "Pin Long 1 << 16" and PASM is case insensitive.
So in that case "xor outa, pin" should toggle the destination register outa bit 16.
Cheers.
Harprit
I must admit that I am not following along with your example, however I am following this thread. My advice, don't get discouraged, I personally applaud your efforts, because there needs to be better documentation and well commented examples pertaining to PASM. From my own personal perspective, I would much rather buy a book written by an expert as compared to a novice, but that does not mean that a novice has nothing to contribute. Some of the most ingenious code I have ever seen was written by novices. Sure there were some improper coding techniques contained within the code, but nonetheless brilliant work.
To be perfectly honest, whatever the field of interest, many of the worlds experts on any given subject are often filled with a lot of hot air and some self-perceived idea of greatness, which is a big turn off for me, especially when I am attempting to learn something from the ground up. And there are many times when the so called expert truly has no concept of the facts. For example, several years ago I was unemployed, and having a high degree of interest in patents, I applied for a position as a paralegal for a patent attorney. During an interview, I showed this expert patent attorney a patent application that I had written. As he is flipping through the pages of the patent application, he insults me by saying that the drawings will never meet the United States Patent And Trademark Offices regulations. The fact of the matter is, he didn't know his Smile from a whole in the ground, because the drawings had already received approval from the USPTO. He was wrong about the proper margins required for drawings and he was wrong about a specific technique that I used in my drawings. I did not say anything at the time, but I thought to myself that I would never hire this idiot as my patent attorney. Needless to say, the margin requirements had changed and this expert was unaware of the changes, and as far as the technique used within the drawings, I took advantage of the USPTO rules and regulations and did something that I am certain is very rare in patent documents or has never been done before, but it still met the criteria of the USPTO, and a patent was granted.
Additionally, while being a far cry from what I consider being an expert electrician, I have a very fair degree of skill and knowledge in this trade. Every once in a while the new kid on the block will teach me a thing or two.
So I say to you Harprit, "Go for it!". Even if you do not succeed in this endeavor, hopefully you will draw enough attention to this thread to where some serious action will be taken.
Bruce
Yes, debuggers do have a learning curve. Which in my own experience is why I try to find a way to learn it early. If I can not probe or scope what is going on, then I am only guessing in the dark. And anyhow, no matter the scope or LSA you may own or have access to, it can not track the internal workings of your logic. Only a good trace can do that. You should consider using debugging along with your example code so that anyone wanting to actually follow the flow of the logic and its effects can see clearly what happens at each step in the trace. This will also serve to enhance the understanding of "unexpected features". Debugging is in many ways similar to the thought process of troubleshooting a misbehaving system.