That was only a code fragment to demonstrate code tag usage. You wouldn't even be able to call it from SPIN as local labels can't be referenced.
Anyway, I think what jazzed is referring to is that you set bits as outputs but then don't use them. You're only driving some clock/data lines above 24.
@Harprit: What is the rationale behind using call/ret rather excessively? Is this part of the exercise? Just wondering because as you only have one instruction in the subroutine the whole operation now takes 3 times as long (12 instead of 4 cycles). Also, shouldn't there be some form of speed control, i.e. can the external h/w run at that (clock) speed?
@Kuroneko
Even I could have made the code a lot faster but the purpose is not fast code. It is learning the code and feeling that your could read it effortlessly. Making the reader feel that it was easy.
That builds confidence and interest in continuing with the learning process. And that is my goal. Really its the only goal for an introduction.
Things have to be repeated for beginners. There was some carping from the learned ones re my SPIN book but I let it ride. Its not for them.
Once one learns, one can pick up the exotic commands and the short hand, but not now. Maybe even never in a beginner's book.
Hope that answers it.
@ Kuroneko
Another one...
You will have noticed that almost everyone posting agreed that the MUX commands were hard to understand and hard to use well.
Yet the feeling was that I needed to use them to do it fast and tricky. I was very interested, for me, BUT...
To me it meant "Don't even think about putting that in a beginner's book
Find a simple way every one will understand. Make it EASY. As easy as you can make it and then repeat it.
Its really about how you think about the teaching problem philosophically. After its all said and done, it has to WORK.
Its not simple and its not about WHIZ-BANG. I think its best to go slowly.
Even I could have made the code a lot faster but the purpose is not fast code. It is learning the code and feeling that your could read it effortlessly. Making the reader feel that it was easy.
Fair enough. That's why I asked. That said, I still think that flipping a bit in a subroutine is wrong. If you want to introduce call/ret pick a different example, e.g. multiply by 5 which is realised as val*4+val and use this on an input array in a loop. Just a thought.
I'm not saying that people wont change their style when they advance but I have the feeling that certain patterns are kept because the book said so. Probably too pessimistic on my part.
@ Kuroneko
Another one...
You will have noticed that almost everyone posting agreed that the MUX commands were hard to understand and hard to use well.
Yet the feeling was that I needed to use them to do it fast and tricky. I was very interested, for me, BUT...
Not sure I follow you here. If it's about my complaint (#85) then that was because you shouldn't use them for the sake of it (or when there are easier solutions). So I tried to come up with a different example (when it's beneficial to use mux & Co).
@kuroneko
No complaints re #85. My apologies if you felt that way.
All these examples will be polished up by the time I get to the end of the editing.
Many many more will be added. This is just the beginning.
Also I too am just starting to learn this language. Wait a bit, things should improve.
@Steve (Jazzed)
I did that because if I leave that line out it would not work!
Kuroneko left this line out in his earlier example and his example works!
I could not figure it out so I left it in.
Something else made it not work Setting DIRA bits 0..11 in the PASM should not "make it work." HOWEVER, doing that in PASM can make it fail in one situation, and that is:
If you set pins in your spin with DIRA[0..11]~~, that COG which is where the spin interpreter is running will set those bits to outputs and you can use OUTA[blah] to change the bit-states. If you also set those bits in a second COG, you must be careful not to set the OUTA from both COGS otherwise you won't see the OUTA pins go low. The reason for that is the OR nature of COG OUTA.
MUXZ is harder to understand than MUXC for newbies. Still, it all comes down to RTFM.
MUXZ is harder to understand than MUXC for newbies.
agreed
Still, it all comes down to RTFM.
Here I have a different opinion:
The main-purpose of a beginners book is to make it easier to understand than the manual.
I suggest showing all the places (DIRA-register, value it should get (destination and souce)
that are important for understanding what the command does as binary, or decimal values depending on what is done
showing state of status-flag C and Z etc.
All this before executing the command and after executing the command.
To understand the principle of the command IMHO you need a minimum of three examples shwon in this detailed way to make the beginner understand the pattern
As long as a beginner doesn't knows anything I think it is better to show several examples and then add a paper and pencil exercise: write down the result or write an example-code that does ...
or maybe to use a setup with 8 LEDs that will show the changes of some bits or branching to sub-routine LED1 or subr LED2 or making the LEDs blink at different rates.
I had hoped that some beginner would participate but so far no one has.
Beginners would lend a different perspective.
Harprit
Be careful what you wish for. I think many would agree that I have a different perspective.
I like building things with my hands. Programming is a necessary pain in the ***_ to complete my projects, and unfortunately pasm is sometimes needed. So I spend too much time going through boring tutorials about flashing an led and using a simulator. So much time, that I feel like I spent all my time that I allotted for my project has been totally wasted, spending that time learning pasm.
And yet pasm is more logical, and that appeals to me. But those dam boring, boring tutorials about flashing an led and using a simulator, used in so many books, about any language with that small step by step format!----I'm not trying to insult these authors, but I firmly believe that the builders have a different mindset than programmers.
Build Something right away, and learn as you go. That's my perspective. I learned the most by completing a lcd project using the SX. I believe Jon Williams Spin lcd code is an excellent first project. Beginning with how Jon's code is used to initialize the lcd, and then how pasm handles the same task.
Everything that happens within an lcd is in small steps. With Jon's code you can use all the little procedures as stepping stones. Then add the boring stuff along the way. The benefit to using Jon's code, is that it comes straight out of the OBEX, and is a known quantity vs possibly your own code---there is just too many different 4 & 8 bit examples.
Builders need lcd's, because they represent a first stem towards what they are trying to accomplish. I tried a serial lcd, and found them too slow for good rpm display.
A next step would be an SPI interface for an ADC, and so on.
If kuroneko wrote a book about PASM, I would definitely buy one.
Me, too, and the point is valid: I want to learn from a person who has real, practical experience and has figured out how to navigate the hurdles I face. That said, not every expert is skilled at conveying information to those less skilled (this is no knock on Marko, just a comment; Marko is exceptionally helpful).
I had hoped that some beginner would participate but so far no one has. Beginners would lend a different perspective.
I was going to, but did not, in anticipation of something like:
Still, it all comes down to RTFM.
The response "RTFM" is probably the ideal way to kill further discussion, especially coming from a respect expert, directed at n00b that's confused. The issue is "I did RTFD, and I still have a question." In all fairness, you don't want to answer, please don't respond; the non-answer is worse than no answer at all.
A better answer would be "Reference X Page X paragraph X covers this, what part are you having trouble with?" Not nearly as condescending and rude. Also, the discussion can point out short comings in the reference, which then can be addressed.
Ah..so what we should do a create a PASM book out of pretty much every post by Kuronecko regarding PASM. Most of his PASM snippets make you think, anything but boring
This is probably the brilliant suggestion of the week. Of course, the intent is not (necessarilly) to replace all the existing dull boring references, but to give a leg up so the boring references are usable. We just need somebody smart to organize them into some kind of logical order, and identify gaps.....
I sure do agree with Capt. Quirk. My first PASM project used all eight cogs of eight Propellers in an effort to solve a cryptography problem by brute force. Reading a very wordy manual just to learn how to toggle LEDs was insufferable! Thank goodness for Heater, Kuroneko, daSilva, Graham Stabler, Potatohead, Phil's Tricks 'n Traps, Mike, and some great programming examples by Lonesock.
The few examples in the manual just made me irritated.
Thank goodness for Heater, Kuroneko, daSilva, Graham Stabler, Potatohead, Phil's Tricks 'n Traps, Mike, and some great programming examples by Lonesock.
Please do not forget to include JonnyMac, because he always has something to contribute to the PASM posts and threads.
Please do not forget to include JonnyMac, because he always has something to contribute to the PASM posts and threads.
You are absolutely right, of course. Jazzed is also a great resource, as are the tools he has provided. His critiques even in this thread are remarkable. Dave Hein is another consummate programmer who has contributed extensively.
BTW, it isn't my intention to knock Harprit's project. His sample code is a big improvement over the few PASM examples in the manual. I have no doubt he is filling a needed gap, and it has been my observation that no such attempt to explain the Propeller has ever gone to waste.
Interestingly I have almost never used that 4 letter word in all my posts.
If you don't know how to RTFM, you will always be a beginner.
When I see more commitment to reading, i'll site manual references.
You did that time. And this time. In fact, all your posts on this page of the thread do. Not to pick on you, (ok, maybe just a little), but you did bring it up.
Perhaps swearing and belittling those who know less then oneself helps impart knowledge, to some degree; maybe not.
I suggest that there are other methods that work better. I'm not very successful with the swearing and belittling bit, so I try to focus on listening and "re-stating more clearly this time" as my technique of choice. But that's just me, I'm no professional educator.
The code I published in #88 (page 5) has been cleaned up and reformatted as per suggestions here
in the discussion forum and re-posted there.
It is now easier to read and follow. Thanks for all the suggestions.
The code reads channel 0 of a MCP3208 A2D converter and displays the results on 12 LEDs
on a Professional Development Board. (Propeller)
I would tend to be in the camp that thinks "that reading the manual is an all revealing experience" as being a bit strong.
I have read the PM many times over and am still at a loss about a lot of commands. Specially so in PASM.
In the PM in particular, there is an extreme lack of good, easy to understand code examples.
What little there are are miserly one and two line snippets. Not close to enough for beginners
There is lot of guidance that just is not in the average manual. That said it is a must to read the manual and use it as your
primary source of information. I cannot think of anything that might be gained by ignoring the manual.
I would tend to be in the camp that thinks "that reading the manual is an all revealing experience" as being a bit strong. I have read the PM many times over and am still at a loss about a lot of commands. Specially so in PASM. In the PM in particular, there is an extreme lack of good, easy to understand code examples. What little there are are miserly one and two line snippets. Not close to enough for beginners
Can you give me an example (for a difficult instruction)? I have the feeling that relying on examples to get the message accross is the wrong way.
Can you give me an example (for a difficult instruction)? I have the feeling that relying on examples to get the message accross is the wrong way.
PAR LOCK.family Counters. High end video control.
But its not just the commands, its how to put them together in an elegant way. How does a beginner write a serial interface?
PAR LOCK.family Counters. High end video control.
But its not just the commands, its how to put them together in an elegant way. How does a beginner write a serial interface?
I read that as par(ameter) register, lock instructions, counters etc. Correct me if I'm wrong.
And now I'm guessing. I never used the manual when I started (datasheet only). So chime in when you disagree.
When I look at the latest manual I find nothing wrong with how par is described. The (size/4n) limitations are listed and it even has an example rather similar to what was presented here in the thread (the one in the SPIN section is slightly better). As for lock instructions, the PASM section is less verbose than the one for SPIN but at least it refers to the SPIN example section. In both cases you get all the info you need.
Counters, phsx limitations are listed (dst vs src). Everything else are just registers which you can r/w. Same for waitvid, it tells you what you need to know to deal with that instruction (it's basically an add nr with some special wait h/w).
This is really low level info. We are talking PASM here. That's as low as it gets and you should know that you have more responsibility down here (you're just pushing bits around). Now you want to put them together in an elegant way. That's where IMO application notes come inA. We had only one initially (counters), now there are more and lets hope their number will increase.
A while back I started puzzle threads which may be worth looking into. Perhaps you find something useful in there re: problem solving. They are not specifically for beginners though.
A ... or preferably your imagination, pick a goal and get there (let someone here help you by declaring it as impossible first). Look at all the (mis)uses of waitvid, counter based serial links (multipliers even) people here came up with.
Improvements to the pot reader program to speed things up.
We can make the program considerably shorter by eliminating some instructions that we added to make it easier to read the program. In the routines that set the bits, the 4 lines can be reduced to 2 as follows
Chip_Sel_Lo mov temp, outa 'Get the OUTA register
andn temp, chs_Bit 'makes chip select low
mov outa, temp 'put it back in OUTA register
Chip_Sel_Lo_ret ret 'return from this subroutine
this reduces to
Chip_Sel_Lo andn outa, chs_Bit 'makes chip select low
Chip_Sel_Lo_ret ret 'return from this subroutine
We can do this because we can access the OUTA register directly without having to go through a temp register. OUTA can be addresses just like any other register.
In the early part of the program we are reading channel1 which is specified with 000 in D0, D1 and D2. We specify this by making D0, D1, D2 (on to the null bit) low and toggling them all in with the Clocking bit. Because the Dout line is low in all these transfers we can eliminate a number of lines by toggling just the Clock bit shown below
Original code
call #Din_lo 'D2 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Din_Lo 'D1 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Din_Lo 'D0 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Din_lo 'blank bit needs a clock cycle, next
call #Tog_Clk 'toggle clock line hi then low to read in the data
'next toggle is for the null bit, nothing read
call #Tog_Clk 'toggle clock line hi then low to read in the data
Reduced code
call #Din_lo 'D2 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
Keep in mind that when we read channels 2 to 8 we will have to put their addresses in D0, D1 and D2 and will not be able to eliminate all the lines like we did above.
And now I'm guessing. I never used the manual when I started (datasheet only). So chime in when you disagree.
This is a telling statement. The First Person sited as the expert, from a long list of experts, did NOT read the manual.
This person comes equipped with knowledge/experience base which allows jumping directly to the data sheet to make amazing progress.
Now consider a little kid. Kid does NOT know what a datasheet is, nor how to read a manual. Kid is used to having grandma ask for help programming the VCR sorry I mean DVR and it just works. Conditioning has been "manual is not necessary".
Now consider an adult that also does not know what a datasheet is, and has had prior experience that manuals are translated badly from Chinese and make no sense anyway. Adult is in almost the same boat as kid, but due to life experience is a stubborn old geezer that thinks he knows everything (braino raises hand).
The critical aspect of the "for beginners mode" is "teach how to use the provided references". This teaching must include:
* the references exist
* list the "standard set" of references we use
* what we talk about and the way we talk about it
* the references have the information (initially our experience with other manuals is evidence to the contrary, so we have to demonstrate this is true)
* the information can be found and used successfully
As I recall, this learning occurred for me the first time I was asked to write a driver routine for one of the new Winchester hard drives. I declined, saying I never read a data sheet and did not know how to start. My boss took me through the data sheet and I had it running in an afternoon. That day, I started to become an engineer. I was never afraid of having to read a data sheet after that point.
This is what I try to bear in mind when I create training materials and references.
As I remember the data sheet did not become available for some time after the manual.
Besides, a detailed description suitable for beginners is not in the instruction set as revealed in the data sheet.
But we are moving away from the needs of beginners....
This is a telling statement. The First Person sited as the expert, from a long list of experts, did NOT read the manual.
This is very silly. It seems to be one of the most manipulative and egregious mis-characterizations I've seen recently. Seems you are in a habit of misunderstanding these days though, so if your mis-characterization was an accident, then I'll forgive and forget.
A datasheet IS a manual.
Both are required reading to advance beyond beginner stage.
Everyone has to "begin" somewhere - it helps if you already know something.
Kuroneko and other's only need the datasheet because it is concise.
I truly wish that everyone had such a great learning curve.
Kuroneko and a few others are just pure genius. We should all be proud that they care.
This thread is becoming an interesting study in so many things that may or may not be helpful to Harprit and his efforts. This posting certainly follows those lines!
1) All of us have a different idea of who qualifies as a beginner. Harprit needs to identify his audience and write to them. Assembler isn't for everyone and certainly not for someone who hasn't programmed before. Yes, it can be learned but the road along the way needs to build a foundation in binary math, general hardware organization and computer structure, programming concepts, hardware specifics for the hardware you are learning and probably other concepts before you get down to understanding your first mov instruction. There's a reason CS101 isn't Assembly Language Programming in any course of study. I went out to Amazon and read reviews for a number of the Assembler Programming books available - it was interesting to see who was buying them, what they expected and what they got from the books they bought. Good market research to target your audience and develop your content.
2) I don't know Kuroneko but respect his knowledge and talent and genius. I assume he didn't just walk in one day from being a frustrated musician and decide to download the Propeller datasheet and start writing complex PASM code. Apologies if that's the case, some people can do that. People learn differently and looking at the datasheet, there is enough information in the datasheet to learn PASM if you can digest technical information being flooded into your brain from a fire hose, if not, then you can stare at the datasheet all day and not come away with anything.
3) Duh, people learn differently! Some can read, assimilate and produce, others need to touch and feel, others need to be lead, others can't program in ANYTHING no nmatter how many books you beat them over the head with. Some people are better at teaching and explaining to different types of learners. This goes back to Harprit's target market and his teaching/explaining strengths. Some things I just know I can't do at a professional level - I will pursue them for personal enjoyment but nothing more.
4) Everybody has an opinion and has a way they learn and it may or may not be shared with anyone else. I'll stop here on opinions.
5) Some people can teach and explain. Others can't. I can't.......ask my daughter!
6) Today, I decided to read through Potatohead's and deSilva's PASM guides. I've done lots of assembler on various machines but never really done anything with PASM. Am I a beginner? So far, I'm glad I'm reading these guides. Somethings I already know, some things I'm learning. Have I read the datasheet? Yes. Have I read the Manual, not cover to cover. Will I be able to read/write PASM by the end of the day? Yes, much better than I can now.
7) I would see Harprit's PASM book as a follow on to his SPIN book. Usually people want to program in assembler to better use the resources of their processor: decrease processing time in critical code paths, decrease the memory footprint, exploit a feature more easily than you can in high level language, etc. Not many people wake up one day with a strong urge to write an application in assembler just "because". Some do and they are able to learn it from the data sheet and the manual. Others want to learn PASM to augment their SPIN code. Maybe show them how to do things they did in your first book in PASM instead of SPIN. Maybe get into WHY PASM? Maybe get into identifying places where PASM has benefit and how to gain those benefits. These are the things the experts can help with and give insight with their bit crafting.
Enough of my lunchtime ramblings.....at least it's good for a laugh!
I'm a believer of RTFineManual and then ask questions for the most part. maybe try it first, then read, then ask. If the manual can be improved, GREAT! Some folks just never read or can't read or can't understand....that's fine too!
Comments
#38
H
Anyway, I think what jazzed is referring to is that you set bits as outputs but then don't use them. You're only driving some clock/data lines above 24.
Even I could have made the code a lot faster but the purpose is not fast code. It is learning the code and feeling that your could read it effortlessly. Making the reader feel that it was easy.
That builds confidence and interest in continuing with the learning process. And that is my goal. Really its the only goal for an introduction.
Things have to be repeated for beginners. There was some carping from the learned ones re my SPIN book but I let it ride. Its not for them.
Once one learns, one can pick up the exotic commands and the short hand, but not now. Maybe even never in a beginner's book.
Hope that answers it.
Regards
H
Another one...
You will have noticed that almost everyone posting agreed that the MUX commands were hard to understand and hard to use well.
Yet the feeling was that I needed to use them to do it fast and tricky. I was very interested, for me, BUT...
To me it meant "Don't even think about putting that in a beginner's book
Find a simple way every one will understand. Make it EASY. As easy as you can make it and then repeat it.
Its really about how you think about the teaching problem philosophically. After its all said and done, it has to WORK.
Its not simple and its not about WHIZ-BANG. I think its best to go slowly.
H
I'm not saying that people wont change their style when they advance but I have the feeling that certain patterns are kept because the book said so. Probably too pessimistic on my part.
No complaints re #85. My apologies if you felt that way.
All these examples will be polished up by the time I get to the end of the editing.
Many many more will be added. This is just the beginning.
Also I too am just starting to learn this language. Wait a bit, things should improve.
H
If you set pins in your spin with DIRA[0..11]~~, that COG which is where the spin interpreter is running will set those bits to outputs and you can use OUTA[blah] to change the bit-states. If you also set those bits in a second COG, you must be careful not to set the OUTA from both COGS otherwise you won't see the OUTA pins go low. The reason for that is the OR nature of COG OUTA.
MUXZ is harder to understand than MUXC for newbies. Still, it all comes down to RTFM.
Here I have a different opinion:
The main-purpose of a beginners book is to make it easier to understand than the manual.
I suggest showing all the places (DIRA-register, value it should get (destination and souce)
that are important for understanding what the command does as binary, or decimal values depending on what is done
showing state of status-flag C and Z etc.
All this before executing the command and after executing the command.
To understand the principle of the command IMHO you need a minimum of three examples shwon in this detailed way to make the beginner understand the pattern
As long as a beginner doesn't knows anything I think it is better to show several examples and then add a paper and pencil exercise: write down the result or write an example-code that does ...
or maybe to use a setup with 8 LEDs that will show the changes of some bits or branching to sub-routine LED1 or subr LED2 or making the LEDs blink at different rates.
best regards
Stefan
Be careful what you wish for. I think many would agree that I have a different perspective.
I like building things with my hands. Programming is a necessary pain in the ***_ to complete my projects, and unfortunately pasm is sometimes needed. So I spend too much time going through boring tutorials about flashing an led and using a simulator. So much time, that I feel like I spent all my time that I allotted for my project has been totally wasted, spending that time learning pasm.
And yet pasm is more logical, and that appeals to me. But those dam boring, boring tutorials about flashing an led and using a simulator, used in so many books, about any language with that small step by step format!----I'm not trying to insult these authors, but I firmly believe that the builders have a different mindset than programmers.
Build Something right away, and learn as you go. That's my perspective. I learned the most by completing a lcd project using the SX. I believe Jon Williams Spin lcd code is an excellent first project. Beginning with how Jon's code is used to initialize the lcd, and then how pasm handles the same task.
Everything that happens within an lcd is in small steps. With Jon's code you can use all the little procedures as stepping stones. Then add the boring stuff along the way. The benefit to using Jon's code, is that it comes straight out of the OBEX, and is a known quantity vs possibly your own code---there is just too many different 4 & 8 bit examples.
Builders need lcd's, because they represent a first stem towards what they are trying to accomplish. I tried a serial lcd, and found them too slow for good rpm display.
A next step would be an SPI interface for an ADC, and so on.
Bill M.
Ah..so what we should do a create a PASM book out of pretty much every post by Kuronecko regarding PASM.
Most of his PASM snippets make you think, anything but boring:)
Bruce
Me, too, and the point is valid: I want to learn from a person who has real, practical experience and has figured out how to navigate the hurdles I face. That said, not every expert is skilled at conveying information to those less skilled (this is no knock on Marko, just a comment; Marko is exceptionally helpful).
Beyond any doubt, Marko is one of the friendliest and most helpful people I have found in the forum.
Bruce
I was going to, but did not, in anticipation of something like:
The response "RTFM" is probably the ideal way to kill further discussion, especially coming from a respect expert, directed at n00b that's confused. The issue is "I did RTFD, and I still have a question." In all fairness, you don't want to answer, please don't respond; the non-answer is worse than no answer at all.
A better answer would be "Reference X Page X paragraph X covers this, what part are you having trouble with?" Not nearly as condescending and rude. Also, the discussion can point out short comings in the reference, which then can be addressed.
This is probably the brilliant suggestion of the week. Of course, the intent is not (necessarilly) to replace all the existing dull boring references, but to give a leg up so the boring references are usable. We just need somebody smart to organize them into some kind of logical order, and identify gaps.....
Can I nominate Heater again?
The few examples in the manual just made me irritated.
Please do not forget to include JonnyMac, because he always has something to contribute to the PASM posts and threads.
Bruce
You are absolutely right, of course. Jazzed is also a great resource, as are the tools he has provided. His critiques even in this thread are remarkable. Dave Hein is another consummate programmer who has contributed extensively.
BTW, it isn't my intention to knock Harprit's project. His sample code is a big improvement over the few PASM examples in the manual. I have no doubt he is filling a needed gap, and it has been my observation that no such attempt to explain the Propeller has ever gone to waste.
You did that time. And this time. In fact, all your posts on this page of the thread do.
Perhaps swearing and belittling those who know less then oneself helps impart knowledge, to some degree; maybe not.
I suggest that there are other methods that work better. I'm not very successful with the swearing and belittling bit, so I try to focus on listening and "re-stating more clearly this time" as my technique of choice. But that's just me, I'm no professional educator.
in the discussion forum and re-posted there.
It is now easier to read and follow. Thanks for all the suggestions.
The code reads channel 0 of a MCP3208 A2D converter and displays the results on 12 LEDs
on a Professional Development Board. (Propeller)
Harprit
I would tend to be in the camp that thinks "that reading the manual is an all revealing experience" as being a bit strong.
I have read the PM many times over and am still at a loss about a lot of commands. Specially so in PASM.
In the PM in particular, there is an extreme lack of good, easy to understand code examples.
What little there are are miserly one and two line snippets. Not close to enough for beginners
There is lot of guidance that just is not in the average manual. That said it is a must to read the manual and use it as your
primary source of information. I cannot think of anything that might be gained by ignoring the manual.
Regards
Harprit.
PAR LOCK.family Counters. High end video control.
But its not just the commands, its how to put them together in an elegant way. How does a beginner write a serial interface?
Harprit
And now I'm guessing. I never used the manual when I started (datasheet only). So chime in when you disagree.
When I look at the latest manual I find nothing wrong with how par is described. The (size/4n) limitations are listed and it even has an example rather similar to what was presented here in the thread (the one in the SPIN section is slightly better). As for lock instructions, the PASM section is less verbose than the one for SPIN but at least it refers to the SPIN example section. In both cases you get all the info you need.
Counters, phsx limitations are listed (dst vs src). Everything else are just registers which you can r/w. Same for waitvid, it tells you what you need to know to deal with that instruction (it's basically an add nr with some special wait h/w).
This is really low level info. We are talking PASM here. That's as low as it gets and you should know that you have more responsibility down here (you're just pushing bits around). Now you want to put them together in an elegant way. That's where IMO application notes come inA. We had only one initially (counters), now there are more and lets hope their number will increase.
A while back I started puzzle threads which may be worth looking into. Perhaps you find something useful in there re: problem solving. They are not specifically for beginners though.
A ... or preferably your imagination, pick a goal and get there (let someone here help you by declaring it as impossible first). Look at all the (mis)uses of waitvid, counter based serial links (multipliers even) people here came up with.
We can make the program considerably shorter by eliminating some instructions that we added to make it easier to read the program. In the routines that set the bits, the 4 lines can be reduced to 2 as follows
Chip_Sel_Lo mov temp, outa 'Get the OUTA register
andn temp, chs_Bit 'makes chip select low
mov outa, temp 'put it back in OUTA register
Chip_Sel_Lo_ret ret 'return from this subroutine
this reduces to
Chip_Sel_Lo andn outa, chs_Bit 'makes chip select low
Chip_Sel_Lo_ret ret 'return from this subroutine
We can do this because we can access the OUTA register directly without having to go through a temp register. OUTA can be addresses just like any other register.
In the early part of the program we are reading channel1 which is specified with 000 in D0, D1 and D2. We specify this by making D0, D1, D2 (on to the null bit) low and toggling them all in with the Clocking bit. Because the Dout line is low in all these transfers we can eliminate a number of lines by toggling just the Clock bit shown below
Original code
call #Din_lo 'D2 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Din_Lo 'D1 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Din_Lo 'D0 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Din_lo 'blank bit needs a clock cycle, next
call #Tog_Clk 'toggle clock line hi then low to read in the data
'next toggle is for the null bit, nothing read
call #Tog_Clk 'toggle clock line hi then low to read in the data
Reduced code
call #Din_lo 'D2 Low to load input line selection sequence 000 for line 0
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
call #Tog_Clk 'toggle clock line hi then low to read in the data
Keep in mind that when we read channels 2 to 8 we will have to put their addresses in D0, D1 and D2 and will not be able to eliminate all the lines like we did above.
Harprit
This is a telling statement. The First Person sited as the expert, from a long list of experts, did NOT read the manual.
This person comes equipped with knowledge/experience base which allows jumping directly to the data sheet to make amazing progress.
Now consider a little kid. Kid does NOT know what a datasheet is, nor how to read a manual. Kid is used to having grandma ask for help programming the VCR sorry I mean DVR and it just works. Conditioning has been "manual is not necessary".
Now consider an adult that also does not know what a datasheet is, and has had prior experience that manuals are translated badly from Chinese and make no sense anyway. Adult is in almost the same boat as kid, but due to life experience is a stubborn old geezer that thinks he knows everything (braino raises hand).
The critical aspect of the "for beginners mode" is "teach how to use the provided references". This teaching must include:
* the references exist
* list the "standard set" of references we use
* what we talk about and the way we talk about it
* the references have the information (initially our experience with other manuals is evidence to the contrary, so we have to demonstrate this is true)
* the information can be found and used successfully
As I recall, this learning occurred for me the first time I was asked to write a driver routine for one of the new Winchester hard drives. I declined, saying I never read a data sheet and did not know how to start. My boss took me through the data sheet and I had it running in an afternoon. That day, I started to become an engineer. I was never afraid of having to read a data sheet after that point.
This is what I try to bear in mind when I create training materials and references.
As I remember the data sheet did not become available for some time after the manual.
Besides, a detailed description suitable for beginners is not in the instruction set as revealed in the data sheet.
But we are moving away from the needs of beginners....
Harprit
A datasheet IS a manual.
Both are required reading to advance beyond beginner stage.
Everyone has to "begin" somewhere - it helps if you already know something.
Kuroneko and other's only need the datasheet because it is concise.
I truly wish that everyone had such a great learning curve.
Kuroneko and a few others are just pure genius. We should all be proud that they care.
1) All of us have a different idea of who qualifies as a beginner. Harprit needs to identify his audience and write to them. Assembler isn't for everyone and certainly not for someone who hasn't programmed before. Yes, it can be learned but the road along the way needs to build a foundation in binary math, general hardware organization and computer structure, programming concepts, hardware specifics for the hardware you are learning and probably other concepts before you get down to understanding your first mov instruction. There's a reason CS101 isn't Assembly Language Programming in any course of study. I went out to Amazon and read reviews for a number of the Assembler Programming books available - it was interesting to see who was buying them, what they expected and what they got from the books they bought. Good market research to target your audience and develop your content.
2) I don't know Kuroneko but respect his knowledge and talent and genius. I assume he didn't just walk in one day from being a frustrated musician and decide to download the Propeller datasheet and start writing complex PASM code. Apologies if that's the case, some people can do that. People learn differently and looking at the datasheet, there is enough information in the datasheet to learn PASM if you can digest technical information being flooded into your brain from a fire hose, if not, then you can stare at the datasheet all day and not come away with anything.
3) Duh, people learn differently! Some can read, assimilate and produce, others need to touch and feel, others need to be lead, others can't program in ANYTHING no nmatter how many books you beat them over the head with. Some people are better at teaching and explaining to different types of learners. This goes back to Harprit's target market and his teaching/explaining strengths. Some things I just know I can't do at a professional level - I will pursue them for personal enjoyment but nothing more.
4) Everybody has an opinion and has a way they learn and it may or may not be shared with anyone else. I'll stop here on opinions.
5) Some people can teach and explain. Others can't. I can't.......ask my daughter!
6) Today, I decided to read through Potatohead's and deSilva's PASM guides. I've done lots of assembler on various machines but never really done anything with PASM. Am I a beginner? So far, I'm glad I'm reading these guides. Somethings I already know, some things I'm learning. Have I read the datasheet? Yes. Have I read the Manual, not cover to cover. Will I be able to read/write PASM by the end of the day? Yes, much better than I can now.
7) I would see Harprit's PASM book as a follow on to his SPIN book. Usually people want to program in assembler to better use the resources of their processor: decrease processing time in critical code paths, decrease the memory footprint, exploit a feature more easily than you can in high level language, etc. Not many people wake up one day with a strong urge to write an application in assembler just "because". Some do and they are able to learn it from the data sheet and the manual. Others want to learn PASM to augment their SPIN code. Maybe show them how to do things they did in your first book in PASM instead of SPIN. Maybe get into WHY PASM? Maybe get into identifying places where PASM has benefit and how to gain those benefits. These are the things the experts can help with and give insight with their bit crafting.
Enough of my lunchtime ramblings.....at least it's good for a laugh!
I'm a believer of RTFineManual and then ask questions for the most part. maybe try it first, then read, then ask. If the manual can be improved, GREAT! Some folks just never read or can't read or can't understand....that's fine too!
For being the same, we sure are all different!!
MOV OUTA, PEACE :nerd: