Of course there will be peer reviews. After publication. As soon your peers buy them there will be reviews posted here and elsewhere I'm sure. Is it not better to shake out the bugs prior to publication?
If there are errors? So readers can pay again? An addendum requiring readers to flip back and forth between two documents or online and a book? What would be so wrong with a reasonable assurance of product quality such as has NOT been demonstrated throughout the run of this thread? In spite of the advise and assistance of some of whom will always be far more advanced than I.
Have our expectations of quality product fallen so far? Mine have not. When a document leads me to expect quality and value and the author stands behind his work with his personal guarantee, then I will be happy to support the efforts with my hard earned cash. Not before, certainly not with this author.
If there are errors? So readers can pay again? An addendum requiring readers to flip back and forth between two documents or online and a book? What would be so wrong with a reasonable assurance of product quality such as has NOT been demonstrated throughout the run of this thread? In spite of the advise and assistance of some of whom will always be far more advanced than I.
Have our expectations of quality product fallen so far? Mine have not. When a document leads me to expect quality and value and the author stands behind his work with his personal guarantee, then I will be happy to support the efforts with my hard earned cash. Not before, certainly not with this author.
Frank Freedman
I'm getting a bit tired of your replies. Would you please be a little more polite? If I can learn one new thing from this book, I'll be more than happy. If all the examples in the book are tested, I'm sure it can be a useful resource. I like to have code snippets so I can take a look to see how feature "x" works. The more there is documentation on the Propeller, the better it is. For a complete newbie, a book like this is what it takes to get going with prop asm.
I'm getting a bit tired of your replies. Would you please be a little more polite? If I can learn one new thing from this book, I'll be more than happy. If all the examples in the book are tested, I'm sure it can be a useful resource. I like to have code snippets so I can take a look to see how feature "x" works. The more there is documentation on the Propeller, the better it is. For a complete newbie, a book like this is what it takes to get going with prop asm.
Fred
Hear, hear!!!!!
Thank you Harprit for doing something that is NEEDED and that no-one else has bothered to do....which reminds me, I was serious when I suggested getting together with Bean to help put PropBASIC where it needs to be :-)
@FredBlais: I do not believe that I have been impolite (a standard of judgment based mainly on one's own perception) in any way over the course of this thread. Certainly I am not alone in this point of view. However, facts are stubborn things and my opinions are based on the content of this thread. I will only recommend potential buyers review the contents of this thread even disregarding any input by me personally.
I'm getting a bit tired of your replies. Would you please be a little more polite? If I can learn one new thing from this book, I'll be more than happy. If all the examples in the book are tested, I'm sure it can be a useful resource. I like to have code snippets so I can take a look to see how feature "x" works. The more there is documentation on the Propeller, the better it is. For a complete newbie, a book like this is what it takes to get going with prop asm.
@Heater. Yes there will be reviews but they will be by users. I hope many readers will post lengthy critiques. There is no need to shake things out. The programs are simple and I run each and every one of them before pasting them directly into the book. They are tested and they will work.
@ Rayman and other supporters Thanks again guys you keep me going.
@ Frank F. I went over the entire forum subject and revisited the many helpful things you provided to the discussion. I don't understand why you are hung up on your present tirade. Just plain tone deafness I guess. You're OK with me.
@ Mickster. One thing at a time. I'll get with Bean. He may think differently.
@Ttailspin. Yes and I want the darn thing out of here as soon as possible.
A note. The return on the books I have written, (Search me in Amazon) so far is about a dollar an hour for the time they take. That is why no one does it.
So the question is.... why do I?
I do it to keep my 73 year old brain from going bonkers. For that I need something I know nothing about. PASM was a good fit. Some of the simple programs took me days in the beginning but I tend not to give up and it has gotten much better as I learn what its all about!
@Harprit, put me down for a copy. Also would like to ask if you could make a list of hardware and components used in the book. So I can see if I have the stuff already or if I need to order somethings. I found with your book on spin I didn't have some of the hardware/components, would like to be ready when the book is released.
Word has an index generation capability. I tried it. I thought it stinks.
Well, There's your problem. Word isn't for writing (at least it's not too good for it). Try LyX. It's actually made for writing documents with a focus on technical documentation. Select words for index entries, and add index entries by/for them. At the end of the document, insert an "Index." When you Compile the document (create a PDF), it will produce the index for you with proper page numbers, and everything.
Run this code. It turns pin 20 on.
Look at the display terminal PST and note that more than one bit is on on the first line.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
bits = 32
Vars = 8
VAR
long stack1[55]
long P_Val[8]
byte pot_sub
OBJ
fds : "FullDuplexSerial"
PUB Go|x
fds.start(31,30,0,115200) 'start PST console at 115200 for output
cognew(@init, @p_Val) 'use address to start Cog
repeat
fds.tx(16) 'clear screen
fds.str(string("Display results")) 'heading
fds.str(string(" ")) 'two spaces to erase old data overflow
fds.tx(1) 'home
fds.tx($d) 'new line
fds.tx($d) 'new line
pot_sub:=0
repeat vars 'loop to display data
fds.bin(P_val[pot_sub], bits) 'print to the PST in binary
fds.str(string(" ")) 'two spaces to erase old data overflow
fds.dec(P_val[pot_sub]) 'print value as decimal value
fds.str(string(" ")) 'two spaces to erase old data overflow
fds.dec(pot_sub) 'print value as decimal value
fds.str(string(" ")) 'three spaces to erase old data overflow
fds.tx($d)
pot_sub:=(pot_sub)+1 'increment display counter
waitcnt(clkfreq/60+cnt) 'wait 1/20 for everything to stabilize.
x:=x+1 'increment counter. (This routine clears up the screen )
if x>100 'decision point (by erasing extraneous lines of )
fds.tx(16) 'clear screen (bottom of PST display every 100 loops)
x:=0 'reset counter (needed only once in most cases. )
DAT org 0
init mov mem, par 'Read Par
mov dira, set_dir_out 'Set directions
mov outa, set_dir_bit 'set pins
mov temp, ina 'Read ina into temp
wrlong temp, mem 'store temp in hub #0
rest jmp #init 'stop program.
'constants and variables
set_Dir_out long 000000_00010000_00000000_00000000
set_Dir_bit long 000000_00010000_00000000_00000000
temp res 1
mem res 1
Now if you run your finger along the prop inputs you will see that other pins come on even though they have been set as inputs and there is no input to them from the circuitry.
The stray capacitance turns the lines on and this could be a big problem when they are read.
If however the pins are set up as outputs, this does not happen.
Does this mean that I need to tell beginners that all the pins that are not going to be used as inputs must be set up as outputs. On start up all pins are inputs so it needs handling.
Since I am not an electronics guy, need someone more knowledgeable than me to make the call.
You really should consider putting your code between tags [ code ] and [ /code ] (without the spaces) if you want popel to get something from it. Spin is an indent-sensitive language so presentation formatting becomes important.
If a pin is an input and left floating, not pulled high or to ground, its value when read is random as you have noticed. My solution is not to read unused pins.
There are some interesting implications to what you have said. Does this mean that before we start a program we should set all the outputs as being low, and then set the direction as being outputs. Will this ensure that you have started out with a safe situation, even if some of the outputs are short to ground. Note that we are setting the outputs first and activating them second. I asked this because I want to make sure that I get it right for beginners.
The other thing of interest is that you say you never read unused output pins. I can see that there would be no problem with doing that but I wonder if there are times when pins get read in groups, and that this could causes problems even if you are not using certain pins. From this follows the fact that all readings of pins have to be masked to eliminate all unnecessary pins before the information is used.
If I have made some silly assumptions here. Please make a correct me. You will have noticed that there is some pressure on me, on this forum, to get it right!
I think it's fine to leave unused pins floating. However, if I were really worried about saving power, I might put a pull-up or pull-down resistor on them, maybe a 100k, just so they wouldn't be doing work in the silicon inside. Making them outputs would do the same thing. But, for beginners, I think leaving them floating is best.
Well, There's your problem. Word isn't for writing (at least it's not too good for it). Try LyX. It's actually made for writing documents with a focus on technical documentation. Select words for index entries, and add index entries by/for them. At the end of the document, insert an "Index." When you Compile the document (create a PDF), it will produce the index for you with proper page numbers, and everything.
Agree Totally, Lyx takes some getting used to, but once you get familiar with it, you will never use anything else.
It lays out documents perfectly and consistently, and is awesome for pasting code into a document from another Lyx document.
Its one of those programs you have to use to see just how good it is.
And its free, but nice to donate to the developers.
If you want to give advices to beginners, then I'd propose this one:
If possible use resistors directly behind any pin, before attaching some other device. (say 100-200Ohm). This protects the Propeller in case you produce a "shortcut" - either when rewiring your hardware as well as when you have a software bug.
I am in the process of going over the book and updating and cleaning up all the code to make sure it includes everything that I learned. During this process I learned that it makes a difference as to what sequence one starts the various cogs. This is especially true if the methods needed are in exterior objects specified under OBJ.
What I would like to know is, is there a recommended way to start the system so that all the cogs will come on and do their job as expected. It seems that having a delay after all the cogs have been started is not enough.
IMHO, you should have a chapter on this. The COG start order really depends on the dependencies the COGS have with one another, various timing factors and how they communicate. There is no simple rule.
Frankly, I find developing that text challenging. IMHO, the optimal approach is one where some COG samples are developed that communicate in a few different ways that can be combined to illustrate the basic concepts needed in the text. There is the single producer, multiple consumer model and it's a simple one. There is the handshake. There is COGS operating in sequence, with an initalization protocol required to synchronize them. In fact, synchronization is a topic by itself...
Comments
Have our expectations of quality product fallen so far? Mine have not. When a document leads me to expect quality and value and the author stands behind his work with his personal guarantee, then I will be happy to support the efforts with my hard earned cash. Not before, certainly not with this author.
Frank Freedman
I'm getting a bit tired of your replies. Would you please be a little more polite? If I can learn one new thing from this book, I'll be more than happy. If all the examples in the book are tested, I'm sure it can be a useful resource. I like to have code snippets so I can take a look to see how feature "x" works. The more there is documentation on the Propeller, the better it is. For a complete newbie, a book like this is what it takes to get going with prop asm.
Fred
Hear, hear!!!!!
Thank you Harprit for doing something that is NEEDED and that no-one else has bothered to do....which reminds me, I was serious when I suggested getting together with Bean to help put PropBASIC where it needs to be :-)
Mickster
-Tommy
I would be more than happy to purchase the first edition.
Thank you very much for putting this together. I know i could not do it.
Regards,
Rich
Have a good weekend,
Frank
H
@ Rayman and other supporters Thanks again guys you keep me going.
@ Frank F. I went over the entire forum subject and revisited the many helpful things you provided to the discussion. I don't understand why you are hung up on your present tirade. Just plain tone deafness I guess. You're OK with me.
@ Mickster. One thing at a time. I'll get with Bean. He may think differently.
@Ttailspin. Yes and I want the darn thing out of here as soon as possible.
A note. The return on the books I have written, (Search me in Amazon) so far is about a dollar an hour for the time they take. That is why no one does it.
So the question is.... why do I?
I do it to keep my 73 year old brain from going bonkers. For that I need something I know nothing about. PASM was a good fit. Some of the simple programs took me days in the beginning but I tend not to give up and it has gotten much better as I learn what its all about!
H.
If possible, I would love to receive a PM when you have it available.
@Harprit, put me down for a copy. Also would like to ask if you could make a list of hardware and components used in the book. So I can see if I have the stuff already or if I need to order somethings. I found with your book on spin I didn't have some of the hardware/components, would like to be ready when the book is released.
Thanks
Ron
H
I forget. Senior moment!
H
Look at the display terminal PST and note that more than one bit is on on the first line.
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 bits = 32 Vars = 8 VAR long stack1[55] long P_Val[8] byte pot_sub OBJ fds : "FullDuplexSerial" PUB Go|x fds.start(31,30,0,115200) 'start PST console at 115200 for output cognew(@init, @p_Val) 'use address to start Cog repeat fds.tx(16) 'clear screen fds.str(string("Display results")) 'heading fds.str(string(" ")) 'two spaces to erase old data overflow fds.tx(1) 'home fds.tx($d) 'new line fds.tx($d) 'new line pot_sub:=0 repeat vars 'loop to display data fds.bin(P_val[pot_sub], bits) 'print to the PST in binary fds.str(string(" ")) 'two spaces to erase old data overflow fds.dec(P_val[pot_sub]) 'print value as decimal value fds.str(string(" ")) 'two spaces to erase old data overflow fds.dec(pot_sub) 'print value as decimal value fds.str(string(" ")) 'three spaces to erase old data overflow fds.tx($d) pot_sub:=(pot_sub)+1 'increment display counter waitcnt(clkfreq/60+cnt) 'wait 1/20 for everything to stabilize. x:=x+1 'increment counter. (This routine clears up the screen ) if x>100 'decision point (by erasing extraneous lines of ) fds.tx(16) 'clear screen (bottom of PST display every 100 loops) x:=0 'reset counter (needed only once in most cases. ) DAT org 0 init mov mem, par 'Read Par mov dira, set_dir_out 'Set directions mov outa, set_dir_bit 'set pins mov temp, ina 'Read ina into temp wrlong temp, mem 'store temp in hub #0 rest jmp #init 'stop program. 'constants and variables set_Dir_out long 000000_00010000_00000000_00000000 set_Dir_bit long 000000_00010000_00000000_00000000 temp res 1 mem res 1Now if you run your finger along the prop inputs you will see that other pins come on even though they have been set as inputs and there is no input to them from the circuitry.
The stray capacitance turns the lines on and this could be a big problem when they are read.
If however the pins are set up as outputs, this does not happen.
Does this mean that I need to tell beginners that all the pins that are not going to be used as inputs must be set up as outputs. On start up all pins are inputs so it needs handling.
Since I am not an electronics guy, need someone more knowledgeable than me to make the call.
H
H
Here is one answer http://forums.parallax.com/showthread.php/100677-Unused-pins-on-Propeller-chip and another http://forums.parallax.com/showthread.php/121060-Reducing-propeller-power-consumption
John Abshier
There are some interesting implications to what you have said. Does this mean that before we start a program we should set all the outputs as being low, and then set the direction as being outputs. Will this ensure that you have started out with a safe situation, even if some of the outputs are short to ground. Note that we are setting the outputs first and activating them second. I asked this because I want to make sure that I get it right for beginners.
The other thing of interest is that you say you never read unused output pins. I can see that there would be no problem with doing that but I wonder if there are times when pins get read in groups, and that this could causes problems even if you are not using certain pins. From this follows the fact that all readings of pins have to be masked to eliminate all unnecessary pins before the information is used.
If I have made some silly assumptions here. Please make a correct me. You will have noticed that there is some pressure on me, on this forum, to get it right!
Thank you
Yes.
From the propeller manual: All the OUTA register’s bits default to zero (0) upon cog startup.
John Abshier
Agree Totally, Lyx takes some getting used to, but once you get familiar with it, you will never use anything else.
It lays out documents perfectly and consistently, and is awesome for pasting code into a document from another Lyx document.
Its one of those programs you have to use to see just how good it is.
And its free, but nice to donate to the developers.
Cheers,
Chris
If possible use resistors directly behind any pin, before attaching some other device. (say 100-200Ohm). This protects the Propeller in case you produce a "shortcut" - either when rewiring your hardware as well as when you have a software bug.
THIS SAVES PROPELLER LIVES!
;o)
I will certainly do that. Thank you.
H
[h=3]Running MCP3208.spin continously in a cog[/h]Post Number 7
re reading the 3208 in PASM that might be of interest to beginners
I did not want to re-post here again to keep down the clutter.
H
What I would like to know is, is there a recommended way to start the system so that all the cogs will come on and do their job as expected. It seems that having a delay after all the cogs have been started is not enough.
H
Frankly, I find developing that text challenging. IMHO, the optimal approach is one where some COG samples are developed that communicate in a few different ways that can be combined to illustrate the basic concepts needed in the text. There is the single producer, multiple consumer model and it's a simple one. There is the handshake. There is COGS operating in sequence, with an initalization protocol required to synchronize them. In fact, synchronization is a topic by itself...