On line 195, you need to calculate the result of clkfreq/1000 before multiplying it by your delay time. When the result exceeds 2^31, you end up subtracting instead of adding the delay value to the cnt register in the waitcnt command. 107*20M is positive, but 108 x 20M is negative. If you instead divide clkfreq by 1000 first before multiplying it by your ms delay value, your ms pause times could be much larger than 107. (Max ~26.8k)
By convention, Parallax does not use the name start for a method unless it is a library file that is designed to launch a cog based on the parameters it receives. If a library object instead does work in the same cog, use config or init, but not start. When naming a method at the beginning of a top file, we typically use a name like go, or something that describes what the method is doing.
Try to keep the examples as concise as possible. Beginners will do better with several small examples to perform each task followed by one that integrates several. Also, a beginning text would do well to discussing variables, reading data in code and string operations. Good luck!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thomas Talbot, MD
Gunpowder, MD, USA
Will see if we cant work towards that.
The programs are short, the rest is mostly LCD support which I will move.
Thanks for the feedback.
All:
Here is program 5
3 pics
I used a PIC based programmable signal generator I made as the
radio signal substitute so not to pollute the airwaves.
Documentation is in the program so I will not repeat it here
A lot more discussion will be in the book, I have not written it yet.
Harpit thank you for your effort I am trying to devour every single thing I can get on the prop I am new as well and every effort is very much appreciated
Adjustments to the name of the top file's first method and clock configuration constants look good.·
A note on your PAUSE method.· clkfreq·returns the number of clock ticks in 1 second. If you want a result in milliseconds, divide clkfreq by 1000 in your waitcnt commands.
See I/O and Timing Lab, pages 7 through 11 for more information. Full PDF download is in the Propeller Education section on·the www.parallax.com/Propeller -> Downloads·page.· Reference information on the waitcnt command is also available·on pages 175-176 in·the Propeller Manual, which is also up for full PDF download from the Propeller Downloads page.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
Post Edited (Andy Lindsay (Parallax)) : 12/16/2008 10:58:08 PM GMT
Thanks for the feedback. Ive got a lot more coming for us beginners
Keep me posted. I need feedback.
Andy:
Thanks for keeping an eye on our progress. We need someone with some
experience to look over our shoulders. I try to follow what I get from you.
Please keep an eye on this site an keep your comments coming. I need
them.
All.
Sorry about the quality on Pic2 and Pic3. Here is Pic3 again but I already
took down the set up so I cant do Pic2 again. Pic1 pretty much covers the
same area.
While writing the next program that has to do with using 2 cogs I ran into the
need to refer to Methods located outside the programs. This has not been
explained so I am submitting a program that shows how to do this
This is Program6 which is exactly the same a Program5 with the Methods
that serve the LCD moved off to an OBJECT called "LCD Routines"
You need to study this program before you study program 7 which uses
two COGS in an introductory format. I will post it next
Programs
Program6 and LCDRoutines are attached
Load and Save them to the same file
Harpit if you get a chance can you tell me wich LCD you are using is it from Parallax I want to get the same one so I can use your interfacing schematic ·
I used a very generic 16x2 LCD with the Hitachi controller built in
Got mine at AllElectronics ($6 LCD117) but they have a minimum on shipping.
There are many other sellers. Get one with the pins in one line, the rest is not
so important.
For the rest of the readers, the next program runs a DC motor with three cogs.
I am having trouble with a segment of code designed to create a very simple PWM signal
that is easy to understand
The total cycle is 255 time frames long
So turn on for 255-PWM
and turn it off for PWM for a constant cycle length of 255
PWM is in Beta
Here is the code, unfortunately the tabs are suppressed
PUB COG_THREE(alpha, beta)
dira[noparse][[/noparse]alpha]~~
outa[noparse][[/noparse]alpha]~~
repeat
outa[noparse][[/noparse]alpha] :=0
UTIL.PAUSE(45) '<change is in this line
outa[noparse][[/noparse](alpha)] :=1
UTIL.PAUSE(255-beta)
The above code works but 45 needs to have a variable here
Here is the code again
PUB COG_THREE(alpha, beta)
dira[noparse][[/noparse]alpha]~~
outa[noparse][[/noparse]alpha]~~
repeat
outa[noparse][[/noparse]alpha] :=0
UTIL.PAUSE(beta) '<change is in this line
outa[noparse][[/noparse](alpha)] :=1
UTIL.PAUSE(255-beta)
this does not work
It works with a number where 45 is but fails if I put in the variable beta
You might be asking the cog for more stack space when you switch from a constant to a variable, so one possible problem could be that the number of elements in the stack array for the cog is no longer sufficient. Try increasing the number of elements in the stack array. Also, check to make sure each cog gets a different portion of the stack array (if you have one long stack array). Or, just declare a different stack array for each cog. Either way works.
I usually like to declare a large number for each stack array, and then trim out down as a final step. 40 is a pretty safe number that you are not likely to exceed unless you have a lot of nested methods, calculations, large arrays, etc. For more info, see the "How Much Stack Space for a·Method Launched into a Cog?" section in the Methods and Cogs·Propeller Education KitLab·for a write up on rough stack length calculations. Also, Project 2 in the Objects lab uses the Stack Length object from the Propeller Library to test an object to·find out·how many elements a cog uses in a stack array.
SIDE NOTE: For Spin, cognew should always be in the same object as the method it launches. Never try to use cognew to launch a method that lives in a different object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
Post Edited (Andy Lindsay (Parallax)) : 12/19/2008 11:01:32 PM GMT
This program allows you to control the speed of a DC motor in one direction
from a hobby R/C servo signal.
3 COGs undertake three different tasks. I did not pass any variable through
the COGS but rather used the general CON and VARs.
Program 10 will add reversibility.
I had a hard time coming up with the PWM routine.
I wanted a very simple one that was easy to understand
The waitcnt command is not suitable as I discovered after a lot of time input
Counters are too complicated for now. Did not want to use tricky commands
Photos also show the amplifier and motor I used.
Use listing to see where to connect what on the PROPELLER
I'll see what I can do on schematics. These programs are pretty simple and the
connections are obvious from the code, but yes schematics are nice. It takes
time to do them and I have only so much time to do this but I think your request
is totally legit so I need to do them. I will put one out late today.
Thanks for getting on me about it. Like all of us, I need a kick now and then.
Here is program 11 with requested schematic
It runs a motor under the control of a potentiometer
-100 to +100% of power, continuous control.
There was an error in previous programs
It had to do with having a variable have more than one value within a COG
Since we don't know when a value will be read by other COGs this can cause
problems. Schematic did not show resistors for the LEDs. These have been
added.
All values for all variables to be read by other COGs must be unambiguous at
all times! Meaning: Set only once in the home COG, do not modify in any other
COG.
I will not fix previous programs but the error does not continue here.
The next program will start on creating pulses at specified intervals.
We will create a musical metronome. You will need a transistor and a small speaker
or Piezoelectric horn
I did not work out extreme timing accuracy but you will get the idea.
You can improve on that if you like
If you don't have a speaker, you can speed things up about 100x and see
it all on an oscilloscope
The next skill we need is to generate frequencies so that is what we will do
Controlled by a potentiometer
Displayed on LCD and on an oscilloscope
No new parts will be needed
We are developing a nice set of skill now and can be thinking about reading
voltages next. We will build a thermometer. LM34DZ used.
Now that we have some of the skills we need to start working the the Propeller Chip
behind us. I need to know which direction we should move the programming and
the tutoring in.
Comments from both veterans and beginners are solicited. Comments from those
familiar with problems area in learning about parallel processing with the Propeller
would be especially useful.
I have about 60 pages done on the book. As it looks right now it will take between
200 and 250 pages.
Ill see what I can do about adding some bugs that are both easy and hard to fix.
My problem is that I too am new to the Propeller so it can hard for me to see
the forest for the trees. I know a little bit about all this so I need your feed back.
Then again parallel processing techniques are new
to me too so I am eager to listen to those that have gone before me. Most of
you know a lot more than all this than I do so please do not hesitate to lead
me in the right direction.
there are different aspects of parallel processing.
trying to divide a big job into smaller pieces and work parallel on them
to speed up the processing - no idea of how to do that.
Avoiding conflicts through accesses to variables at the same time
or mixing up IO-signals could be a theme
the basic thing might be to dedicate a cog to something timecritical
or randomly happening events that have to be recognized
or things that have to be updated fast and regurlarly
like scanning a matrix-wired keyboard
or updating an LED-matrix or more than one 7segment-displays by multiplexing them
code-examples for comparing "spaghetti-code" with well structured code showing the advanteges of well structured code
Developing philosophies:
My style of developing is to divide the code in small methods each method doing ONE thing.
And testing new methods in its own test-sourcecode before adding it to a complex sourcecode
Some execises with code-examples that show the advantage of this coding-style
Code-examples with small bugs causing problems that come up to the surface as strange behaviour
or at complete different points than they are coded (Method "A" has a bug which causes problems
in method "B" and with whih debug-methods you will find them quickly
other ideas:
software-debouncing of mechanical buttons and evaluating the limits of this method
software schmidt-triggering of analog signals and evaluating the limits of this method
software-comparator with hysteresis of analog signals and evaluating the limits of this method
low-high / high-low-transition-detecting methods
hardware-ideas:
IO-extension using shiftregisters
stepper-motor-driver
PLC-IO-picture-updater, PLC-IO-processing
creating a input-output-driver for more than one IO-Pin which is just using ONE cog
with functions like:
wait for input to go high-low with a timeout and if timeout occurs set a flag-variable
that the main-program can on the flag
make IO-Pins "blink" parameters blink-time, frequency
propeller-controlled accumulator discharge / charge with capacity measuring
cogs working as an oscilloscope or voltagemeter
other cogs as DACs driving a transistors-base and alltogether showing
the behavior of a transistor as measured voltages and currents displayed as numbers
next to a transistor symbol or other electronic components
Sorry for the dead time folks
I had some business that needed all my time to finish up
Its done, I'll have the next program on line in the next few days
Thanks you for your patience
Comments
By convention, Parallax does not use the name start for a method unless it is a library file that is designed to launch a cog based on the parameters it receives. If a library object instead does work in the same cog, use config or init, but not start. When naming a method at the beginning of a top file, we typically use a name like go, or something that describes what the method is doing.
For lots of examples of this, see the Propeller Education Kit Labs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
Post Edited (Andy Lindsay (Parallax)) : 12/16/2008 7:39:14 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thomas Talbot, MD
Gunpowder, MD, USA
Will see if we cant work towards that.
The programs are short, the rest is mostly LCD support which I will move.
Thanks for the feedback.
All:
Here is program 5
3 pics
I used a PIC based programmable signal generator I made as the
radio signal substitute so not to pollute the airwaves.
Documentation is in the program so I will not repeat it here
A lot more discussion will be in the book, I have not written it yet.
Harprit
Adjustments to the name of the top file's first method and clock configuration constants look good.·
A note on your PAUSE method.· clkfreq·returns the number of clock ticks in 1 second. If you want a result in milliseconds, divide clkfreq by 1000 in your waitcnt commands.
See I/O and Timing Lab, pages 7 through 11 for more information. Full PDF download is in the Propeller Education section on·the www.parallax.com/Propeller -> Downloads·page.· Reference information on the waitcnt command is also available·on pages 175-176 in·the Propeller Manual, which is also up for full PDF download from the Propeller Downloads page.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
Post Edited (Andy Lindsay (Parallax)) : 12/16/2008 10:58:08 PM GMT
Thanks for the feedback. Ive got a lot more coming for us beginners
Keep me posted. I need feedback.
Andy:
Thanks for keeping an eye on our progress. We need someone with some
experience to look over our shoulders. I try to follow what I get from you.
Please keep an eye on this site an keep your comments coming. I need
them.
All.
Sorry about the quality on Pic2 and Pic3. Here is Pic3 again but I already
took down the set up so I cant do Pic2 again. Pic1 pretty much covers the
same area.
HSS
need to refer to Methods located outside the programs. This has not been
explained so I am submitting a program that shows how to do this
This is Program6 which is exactly the same a Program5 with the Methods
that serve the LCD moved off to an OBJECT called "LCD Routines"
You need to study this program before you study program 7 which uses
two COGS in an introductory format. I will post it next
Programs
Program6 and LCDRoutines are attached
Load and Save them to the same file
Harprit
Runs two simple cogs at the same time
If you can not understand what is going on please report what it is
because this is critical to moving to the next level.
The next program will make the cogs talk to one another
Utilities OBJ is also attached. It contains some fo the Methods used.
Harprit
Attached
Demonstrates ease of displaying on one COG what is happening in the other
Harprit
·
I used a very generic 16x2 LCD with the Hitachi controller built in
Got mine at AllElectronics ($6 LCD117) but they have a minimum on shipping.
There are many other sellers. Get one with the pins in one line, the rest is not
so important.
For the rest of the readers, the next program runs a DC motor with three cogs.
Harprit
I am having trouble with a segment of code designed to create a very simple PWM signal
that is easy to understand
The total cycle is 255 time frames long
So turn on for 255-PWM
and turn it off for PWM for a constant cycle length of 255
PWM is in Beta
Here is the code, unfortunately the tabs are suppressed
PUB COG_THREE(alpha, beta)
dira[noparse][[/noparse]alpha]~~
outa[noparse][[/noparse]alpha]~~
repeat
outa[noparse][[/noparse]alpha] :=0
UTIL.PAUSE(45) '<change is in this line
outa[noparse][[/noparse](alpha)] :=1
UTIL.PAUSE(255-beta)
The above code works but 45 needs to have a variable here
Here is the code again
PUB COG_THREE(alpha, beta)
dira[noparse][[/noparse]alpha]~~
outa[noparse][[/noparse]alpha]~~
repeat
outa[noparse][[/noparse]alpha] :=0
UTIL.PAUSE(beta) '<change is in this line
outa[noparse][[/noparse](alpha)] :=1
UTIL.PAUSE(255-beta)
this does not work
It works with a number where 45 is but fails if I put in the variable beta
Harprit
You might be asking the cog for more stack space when you switch from a constant to a variable, so one possible problem could be that the number of elements in the stack array for the cog is no longer sufficient. Try increasing the number of elements in the stack array. Also, check to make sure each cog gets a different portion of the stack array (if you have one long stack array). Or, just declare a different stack array for each cog. Either way works.
I usually like to declare a large number for each stack array, and then trim out down as a final step. 40 is a pretty safe number that you are not likely to exceed unless you have a lot of nested methods, calculations, large arrays, etc. For more info, see the "How Much Stack Space for a·Method Launched into a Cog?" section in the Methods and Cogs·Propeller Education Kit Lab·for a write up on rough stack length calculations. Also, Project 2 in the Objects lab uses the Stack Length object from the Propeller Library to test an object to·find out·how many elements a cog uses in a stack array.
SIDE NOTE: For Spin, cognew should always be in the same object as the method it launches. Never try to use cognew to launch a method that lives in a different object.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Andy Lindsay
Education Department
Parallax, Inc.
Post Edited (Andy Lindsay (Parallax)) : 12/19/2008 11:01:32 PM GMT
This does not works
repeat '
outa[noparse][[/noparse]alpha1] :=0
PAUSE(beta)
outa[noparse][[/noparse](alpha1)] :=1
PAUSE(255-beta)
this works
repeat '
outa[noparse][[/noparse]alpha1] :=0
PAUSE(255-beta)
outa[noparse][[/noparse](alpha1)] :=1
PAUSE(beta)
It is not sensitive to the stack space allocated
The pause commands are just reversed in location but they are not changed.
Harprit
This program allows you to control the speed of a DC motor in one direction
from a hobby R/C servo signal.
3 COGs undertake three different tasks. I did not pass any variable through
the COGS but rather used the general CON and VARs.
Program 10 will add reversibility.
I had a hard time coming up with the PWM routine.
I wanted a very simple one that was easy to understand
The waitcnt command is not suitable as I discovered after a lot of time input
Counters are too complicated for now. Did not want to use tricky commands
Photos also show the amplifier and motor I used.
Use listing to see where to connect what on the PROPELLER
Harprit
connections are obvious from the code, but yes schematics are nice. It takes
time to do them and I have only so much time to do this but I think your request
is totally legit so I need to do them. I will put one out late today.
Thanks for getting on me about it. Like all of us, I need a kick now and then.
Harprit.
Same a 9 but with schematics
Schematics will be provided with all future programs per request from StateMachine
Thanks to all for feedback.
Here you see the benefit!
Program 10 will add reversing to the motor, in progress
Harprit
Full schematics
Full -100 to +100 speed control of PMDC motor
All little odds and ends cleaned up
OBJs used have been improved and re attached here
Next we will modify this program so it runs the motor from a 5K potentiometer
Harprit
It runs a motor under the control of a potentiometer
-100 to +100% of power, continuous control.
There was an error in previous programs
It had to do with having a variable have more than one value within a COG
Since we don't know when a value will be read by other COGs this can cause
problems. Schematic did not show resistors for the LEDs. These have been
added.
All values for all variables to be read by other COGs must be unambiguous at
all times! Meaning: Set only once in the home COG, do not modify in any other
COG.
I will not fix previous programs but the error does not continue here.
The next program will start on creating pulses at specified intervals.
We will create a musical metronome. You will need a transistor and a small speaker
or Piezoelectric horn
HSS
Post Edited (Harprit) : 12/26/2008 5:34:01 PM GMT
I did not work out extreme timing accuracy but you will get the idea.
You can improve on that if you like
If you don't have a speaker, you can speed things up about 100x and see
it all on an oscilloscope
The next skill we need is to generate frequencies so that is what we will do
Controlled by a potentiometer
Displayed on LCD and on an oscilloscope
No new parts will be needed
We are developing a nice set of skill now and can be thinking about reading
voltages next. We will build a thermometer. LM34DZ used.
Harprit
behind us. I need to know which direction we should move the programming and
the tutoring in.
Comments from both veterans and beginners are solicited. Comments from those
familiar with problems area in learning about parallel processing with the Propeller
would be especially useful.
I have about 60 pages done on the book. As it looks right now it will take between
200 and 250 pages.
Harprit
My problem is that I too am new to the Propeller so it can hard for me to see
the forest for the trees. I know a little bit about all this so I need your feed back.
Then again parallel processing techniques are new
to me too so I am eager to listen to those that have gone before me. Most of
you know a lot more than all this than I do so please do not hesitate to lead
me in the right direction.
Harprit
there are different aspects of parallel processing.
trying to divide a big job into smaller pieces and work parallel on them
to speed up the processing - no idea of how to do that.
Avoiding conflicts through accesses to variables at the same time
or mixing up IO-signals could be a theme
the basic thing might be to dedicate a cog to something timecritical
or randomly happening events that have to be recognized
or things that have to be updated fast and regurlarly
like scanning a matrix-wired keyboard
or updating an LED-matrix or more than one 7segment-displays by multiplexing them
code-examples for comparing "spaghetti-code" with well structured code showing the advanteges of well structured code
Developing philosophies:
My style of developing is to divide the code in small methods each method doing ONE thing.
And testing new methods in its own test-sourcecode before adding it to a complex sourcecode
Some execises with code-examples that show the advantage of this coding-style
Code-examples with small bugs causing problems that come up to the surface as strange behaviour
or at complete different points than they are coded (Method "A" has a bug which causes problems
in method "B" and with whih debug-methods you will find them quickly
other ideas:
software-debouncing of mechanical buttons and evaluating the limits of this method
software schmidt-triggering of analog signals and evaluating the limits of this method
software-comparator with hysteresis of analog signals and evaluating the limits of this method
low-high / high-low-transition-detecting methods
hardware-ideas:
IO-extension using shiftregisters
stepper-motor-driver
PLC-IO-picture-updater, PLC-IO-processing
creating a input-output-driver for more than one IO-Pin which is just using ONE cog
with functions like:
wait for input to go high-low with a timeout and if timeout occurs set a flag-variable
that the main-program can on the flag
make IO-Pins "blink" parameters blink-time, frequency
propeller-controlled accumulator discharge / charge with capacity measuring
cogs working as an oscilloscope or voltagemeter
other cogs as DACs driving a transistors-base and alltogether showing
the behavior of a transistor as measured voltages and currents displayed as numbers
next to a transistor symbol or other electronic components
maybe the tricks and trap document
http://forums.parallax.com/showthread.php?p=575479
could give themes with showing cases where the trap closes and
code-examples how to avoid those traps
best regards
Stefan
I had some business that needed all my time to finish up
Its done, I'll have the next program on line in the next few days
Thanks you for your patience
HSS
Keep up the good work···
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
··Thanks for any·
·
·
·
·
Sam
Reads a voltage into a Propeller
Thank you for the encouragement Sam
HSS
Harprit