gets stuck while trying to start a cog
I'm getting closer to my goal,
In my object working2 , I have a call to a method (Button24) that works , but sometimes I have to hold the button down for a few seconds.
I· want to make it run in its own cog, so it will always be reading the button ,but when I wrote it (Button24_A) it just hangs, Also how would I make it cycle thru the different lightshows?
Thanks BillS
PS
updated the Button_A Method ,,,, sent the wrong one before
Post Edited (lockadoc) : 11/10/2009 7:29:55 AM GMT
In my object working2 , I have a call to a method (Button24) that works , but sometimes I have to hold the button down for a few seconds.
I· want to make it run in its own cog, so it will always be reading the button ,but when I wrote it (Button24_A) it just hangs, Also how would I make it cycle thru the different lightshows?
Thanks BillS
PS
updated the Button_A Method ,,,, sent the wrong one before
Post Edited (lockadoc) : 11/10/2009 7:29:55 AM GMT
Comments
The code above will run and then the Cog will stop since there is no more code to excute the cog will
just stop.
you may want to put the stuff in a·repeat block
eg.
Pub Button24
· repeat
···· if ina[noparse][[/noparse]24] ==1
······· lightshow7.Lightshow7
···· outa[noparse][[/noparse]0..7] :=%00000000
to give you some guidance with questions like Sokrates:
How can you count up a variable with the basic structure of your button-method ?
How can you execute different lightshows depending on the value of a that variable ?
Your Button-method will have to be improved for working comfortable.
You have to detect:
1) button-state CHANGE from 0 to 1 (button pressed down) then increment variable
2) do nothing else until button-state CHANGE from 1 to 0 is detected. (button is left alone)
If detected do 1)
The only thing that is REALLY true about computers
Computer do ALWAYS what humans have coded. If they do something different then you expected
you don't understand your own coding.
Reasons why you don't understand it
bug in your code ("created" by you caused by a lack of understanding or lack of knowing traps)
bug in the compiler ("created" by the author of the compiler)
bug in the hardware of the microprocessor ("created" by the manufacturer of the chip)
Parallax did develop the propeller-chip 8 years long. And no single hardware-bug was ever detected
So the propability for a hardware-bug inside a new manufactured chip is extremely low
No bugs detected in the compiler so far
So the propability for a compiler-bug is extremely low
means 99.9% of strange behaviour is coded and caused by your own code or damaging the hardware.
Another hint: Don't test this new things in your complete software
Make a NEW SMALL testprogramm with debugoutput to the PC using fullduplexserial to see what is happening
I promise - you will get faster to a complete working program this way then putting the new code into your big DoItAll.spin-file
best regards
Stefan