You have 3 choices ...
1) Live with the inconvenience of a long line and the awkward scrolling left and right.
2) Split the lookup into several shorter statements selected either with a case statement of a series of if statements
3) Use an EEPROM data table and the READ statement to access entries in it. You can have a series of DATA statements which each fit on a convenient display line.
>Use an EEPROM data table and the READ statement to access entries in it. You can have a series of DATA statements which each fit on a convenient display line.
Thanks. I guess I need to learn to do that anyways since now that I started using the LOOKUP my sequences stop playing when I shut off the pc.
Without posting your code it would be difficult to see what you have a problem with. I just ran the following program on my BS2 and it runs fine. It displays all numbers in the LOOKUP table sequentially on the DEBUG screen.· My guess would be you're not defining a variable name you're using.
' {$STAMP BS2}
' {$PBASIC 2.5}
index VAR Byte
temp VAR Byte
FOR index = 0 TO 15
LOOKUP index, [noparse][[/noparse]23, 56, 31, 45, 98,
76, 42, 11, 83, 69,
65, 54, 57, 33, 22], temp
DEBUG DEC temp, CR
PAUSE 1000
NEXT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Chris Savage Parallax Tech Support
I get the error message when I try to run this with stamp2.exe :
It works when I put all values of c on one line.
serout 0,6,[noparse][[/noparse]"!PWMSS",255]
x var byte:y var nib
c var byte:n var nib
dt var word
d1 var byte:d2 var byte
play
for x=0 to 29:for y=0 to 3
lookup x,[noparse][[/noparse]20,24,18,20, 20,24,18,18, 20,24,18,20,
16,18,20,20, 24,18,20,20, 24,18,20,20,
24,18,20,20, 16,18,20],c
lookup y,[noparse][[/noparse]1,4,3,4],n
dt=7272/(c*n)
d1=dt//256:d2=dt/256
serout 0,6,[noparse][[/noparse]"!PWMM1",d1,d2,d1,d2]
freqout 1,300,c*22,c*33
next[noparse]:next:[/noparse]goto play
'listening to pin 12 (through a 680 Ohm resistor)
'summed with pin 1 (through a 220 Ohm resistor)
'plugged into my stereo
serout 0,6,[noparse][[/noparse]"!PWMSS",255]
x var byte:y var byte
c var byte:n var nib
chord data 16,12,9,12, 12,12,9,12, 16,12,9,9
data 12,12,16,12, 16,12,9,12
notes data 1,4,3,4
dt var word:d1 var byte:d2 var byte
play
for x=0 to 19:for y=20 to 23
read x,c:read y,n
dt=3636/(c*n)
d1=dt//256:d2=dt/256
serout 0,6,[noparse][[/noparse]"!PWMM1",d1,d2,d1,d2]
freqout 1,250,c*22,c*33
next[noparse]:next:[/noparse]goto play
'listen to pin 12 (through a 680 Ohm resistor)
'summed with pin 1 (through a 220 Ohm resistor)
'plugged into a mono hi-fi (with attendent attenuation)
serout 0,6,[noparse][[/noparse]"!PWMSS",255]
x var byte:y var nib
c var byte:n var nib
dt var word
d1 var byte:d2 var byte
play
for x=0 to 29:for y=0 to 3
lookup x,[noparse][[/noparse]20,24,18,20, 20,24,18,18, 20,24,18,20, 16,18,20,20, 24,18,20,20, 24,18,20,20, 24,18,20,20, 16,18,20],c
lookup y,[noparse][[/noparse]1,4,3,4],n
dt=7272/(c*n)
d1=dt//256:d2=dt/256
serout 0,6,[noparse][[/noparse]"!PWMM1",d1,d2,d1,d2]
freqout 1,300,c*22,c*33
next[noparse]:next:[/noparse]goto play
'listening to pin 12 (through a 680 Ohm resistor)
'summed with pin 1 (through a 220 Ohm resistor)
'plugged into Cris's stereo.
I point it out purely as a learning exercise for those new to programming because it is one of the most prevalent bugs one can introduce to code. Somehow I just wanted to teach something this morning as well,
Syntactically correct but code that returns data the programmer did not expect.
There are only 15 data items in the list. The for next loop is actually trying to read 16 values. This is a common thing to overlook as lists typically start with the first element offset as Zero. This would then be corrected with the last element being 14 instead of 15 as 0 to 14 equals 15 elements.
The function LOOKUP however does not give an out of bounds error when trying to read element 15 (the sixteenth element because it does not exist) so it does not read in or change the variable TEMP. It leaves it in this case the number 22, the last value assigned to TEMP.
One way to datacheck a table like this would be to initialize TEMP to 0. If the function returned 0 you know it was out of bounds. Better though would be to check the lookup index number for minimum and maximum values to pass to the lookup function.
Other languages doing the same function might read the next byte in memory outside the table boundary's and return that in the variable TEMP.
The reason this is important is if a user is inputting values that your program is looking up in a table. User data should always be tested for boundary's before using it. Languages like C for example use typecasting as well to help the programmer find errors in the type of data he or she is working with.
Somebody said...
Without posting your code it would be difficult to see what you have a problem with. I just ran the following program on my BS2 and it runs fine. It displays all numbers in the LOOKUP table sequentially on the DEBUG screen. My guess would be you're not defining a variable name you're using.
' {$STAMP BS2}
' {$PBASIC 2.5}
index VAR Byte
temp VAR Byte
FOR index = 0 TO 15
LOOKUP index, [noparse][[/noparse]23, 56, 31, 45, 98,
76, 42, 11, 83, 69,
65, 54, 57, 33, 22], temp
DEBUG DEC temp, CR
PAUSE 1000
NEXT
Chris Savage
Parallax Tech Support
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
The edge of the visible screen is not the end of a command line. As I remember, a command line can go for 255 or 256 characters.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
for x=0 to 255
lookup x,[noparse][[/noparse] 255 numbers separated by commas here ],n
next
Yes, I can keep going and the screen shifts to accomidate the long line, but this makes it awkward to revue the numbers.
Post Edited (hitsware) : 4/22/2007 4:32:49 PM GMT
1) Live with the inconvenience of a long line and the awkward scrolling left and right.
2) Split the lookup into several shorter statements selected either with a case statement of a series of if statements
3) Use an EEPROM data table and the READ statement to access entries in it. You can have a series of DATA statements which each fit on a convenient display line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
Thanks. I guess I need to learn to do that anyways since now that I started using the LOOKUP my sequences stop playing when I shut off the pc.
Ahhh ! Much more expedient ! [noparse]:)[/noparse]
I get a "expected variable etc. etc." error message ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Parallax Tech Support
It works when I put all values of c on one line.
serout 0,6,[noparse][[/noparse]"!PWMSS",255]
x var byte:y var nib
c var byte:n var nib
dt var word
d1 var byte:d2 var byte
play
for x=0 to 29:for y=0 to 3
lookup x,[noparse][[/noparse]20,24,18,20, 20,24,18,18, 20,24,18,20,
16,18,20,20, 24,18,20,20, 24,18,20,20,
24,18,20,20, 16,18,20],c
lookup y,[noparse][[/noparse]1,4,3,4],n
dt=7272/(c*n)
d1=dt//256:d2=dt/256
serout 0,6,[noparse][[/noparse]"!PWMM1",d1,d2,d1,d2]
freqout 1,300,c*22,c*33
next[noparse]:next:[/noparse]goto play
'listening to pin 12 (through a 680 Ohm resistor)
'summed with pin 1 (through a 220 Ohm resistor)
'plugged into my stereo
Post Edited (hitsware) : 4/22/2007 6:52:33 PM GMT
Line continuaton only works with new versions of the PBASIC Stamp Editor, and Stamp2.exe is an older version.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Thank You!
serout 0,6,[noparse][[/noparse]"!PWMSS",255]
x var byte:y var byte
c var byte:n var nib
chord data 16,12,9,12, 12,12,9,12, 16,12,9,9
data 12,12,16,12, 16,12,9,12
notes data 1,4,3,4
dt var word:d1 var byte:d2 var byte
play
for x=0 to 19:for y=20 to 23
read x,c:read y,n
dt=3636/(c*n)
d1=dt//256:d2=dt/256
serout 0,6,[noparse][[/noparse]"!PWMM1",d1,d2,d1,d2]
freqout 1,250,c*22,c*33
next[noparse]:next:[/noparse]goto play
'listen to pin 12 (through a 680 Ohm resistor)
'summed with pin 1 (through a 220 Ohm resistor)
'plugged into a mono hi-fi (with attendent attenuation)
x var byte:y var nib
c var byte:n var nib
dt var word
d1 var byte:d2 var byte
play
for x=0 to 29:for y=0 to 3
lookup x,[noparse][[/noparse]20,24,18,20, 20,24,18,18, 20,24,18,20, 16,18,20,20, 24,18,20,20, 24,18,20,20, 24,18,20,20, 16,18,20],c
lookup y,[noparse][[/noparse]1,4,3,4],n
dt=7272/(c*n)
d1=dt//256:d2=dt/256
serout 0,6,[noparse][[/noparse]"!PWMM1",d1,d2,d1,d2]
freqout 1,300,c*22,c*33
next[noparse]:next:[/noparse]goto play
'listening to pin 12 (through a 680 Ohm resistor)
'summed with pin 1 (through a 220 Ohm resistor)
'plugged into Cris's stereo.
I point it out purely as a learning exercise for those new to programming because it is one of the most prevalent bugs one can introduce to code. Somehow I just wanted to teach something this morning as well,
Syntactically correct but code that returns data the programmer did not expect.
There are only 15 data items in the list. The for next loop is actually trying to read 16 values. This is a common thing to overlook as lists typically start with the first element offset as Zero. This would then be corrected with the last element being 14 instead of 15 as 0 to 14 equals 15 elements.
The function LOOKUP however does not give an out of bounds error when trying to read element 15 (the sixteenth element because it does not exist) so it does not read in or change the variable TEMP. It leaves it in this case the number 22, the last value assigned to TEMP.
One way to datacheck a table like this would be to initialize TEMP to 0. If the function returned 0 you know it was out of bounds. Better though would be to check the lookup index number for minimum and maximum values to pass to the lookup function.
Other languages doing the same function might read the next byte in memory outside the table boundary's and return that in the variable TEMP.
The reason this is important is if a user is inputting values that your program is looking up in a table. User data should always be tested for boundary's before using it. Languages like C for example use typecasting as well to help the programmer find errors in the type of data he or she is working with.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Think Inside the box first and if that doesn't work..
Re-arrange what's inside the box then...
Think outside the BOX!