Debug and displaying "*" at a specific location
tronsnavy
Posts: 70
Need just a little help.· Trying to display a "*" at a "x, y" location on the debug screen.
I tried to use CRSRXY (2 based on "FullDuplexSerialPlus") but it generates a "constant" error when I use variables i.e. "x, y"
Debug.str(string(2, x, y, "*"))
Any suggestions on displaying a "*" at a variable location (x, y)???
Thanks a bunch.
Bob
·
I tried to use CRSRXY (2 based on "FullDuplexSerialPlus") but it generates a "constant" error when I use variables i.e. "x, y"
Debug.str(string(2, x, y, "*"))
Any suggestions on displaying a "*" at a variable location (x, y)???
Thanks a bunch.
Bob
·
Comments
The error is complaining about the syntax... This is how you would achieve sending the string, but probably is not the whole solution you are after.
debug.str(string("2,")
debug.dec(x)
debug.tx(",")
debug.dec(y)
debug.tx("*")
Of course you could make this a routine and pass it the parameters from a single line call.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
debug.tx(2) debug.tx(x) debug.tx(y) debug.tx("*")To move it from that location, be sure to do a CRSRLF, followed by a " ", first, to erase if from its current position.
-Phil
I think what you are trying to do is display a * on the debug screen but at a particular location.
It is not that you are trying to display a * and then the values of the variables X and Y....no?
If that is the case then what you did does not work. Because the Debug.Str() would send that
stuff as bytes to be displayed to the screen.
What you need is to send COMMANDS to the Parallax Serial Terminal whose codes are 2 then the X value then the
Y value. This will position the cursor to the X,Y coordinate THEN you send it the * as a character to display
You have to transmit to the Parallax Serial Terminal the following sequences
·· Debug.Tx(Debug#CRSRXY)····· 'command to position the cursor at X,Y....its code is 2
·· Debug.Tx(X)························ 'actual X
·· Debug.Tx(Y)························ 'actual Y
·· Debug.Tx("*")······················ 'print *
So you do not have to do this every time you can have a method to do this e.g.
Pri XY_Char(X,Y,C)
·· Debug.Tx(Debug#CRSRXY)····· 'command to position the cursor at X,Y
·· Debug.Tx(X)························ 'actual X
·· Debug.Tx(Y)························ 'actual Y
·· Debug.Tx(C)·· ····················· 'print the character
You can then use the method as you need eg. XY_Char(X,Y,"*")
Regards
Samuel
I am using the propeller.· Thanks.
Will try all suggestions up to this point.· Thanks.
Bob
It doesn't matter which controller is sending data to the PC. All that matters is what's running on the PC to interpret that data. I frequently use the BASIC Stamp DEBUG screen with the Prop, since it's able to interpret those special commands. I assume the Propeller Terminal is the same, but I don't use it, so I can't comment with any authority.
-Phil
I just got home and wrote this program to illustrate what you want to do
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ Debug : "FullDuplexSerialPlus" PUB Main|x Debug.Start(31,30,0,115200) waitcnt(ClkFreq*2+cnt) 'wait a bit to give time to activate the Serial terminal repeat x from 0 to 10 XY_Char(x,x,"*") Pub XY_Char(X,Y,C) Debug.Tx(Debug#CRSRXY) Debug.Tx(X) Debug.Tx(Y) Debug.Tx(C)Regards
Samuel
Samuel,
Thanks!!! Your code worked as advertised. As you might have guessed, I am trying to convert an object from BS2 to spin. The object is "PING)))Dar". Go to "forums", "stamps in class", "stamps in class, mini projects", "PING)))Dar, a radar style display". I saw this a few weeks ago and have proceeded very well in converting the code. At least until I tried to convert polar coordinates (d > angle) to Cartesian coordinates (x,y).· I looked for a post that might have done this already, but came up empty.· But that's alright; I am learning a lot.
I have attached my spin code to this post. This code is just an experiment for the conversion process (polar to Cartesian). I will post the finally code when I get everything working. The code produces a "*" at erratic locations. I know the problem has to do with Float32, and my syntax.· I am trying to produce an "ARC" across the debug screen. This is the last piece of the puzzle.·· I have PING scanning and ranging, with a resolution of about 2.8 degrees. I hope that some of you "higher" intellects might be able to provide a solution. Thanks in advance for any and all assistance. Have a good (cold) one.
Bob
My last post contained spin code with multiple errors.· This one should compile.
Bob
you have to do ALL the math in float. You mixed up integer and float
the constant pi is already a float. So ywith ur codeline
x := (pi/180) * angle ' convert to radians in order to use float32 sin/cosyou already get wrong results.
a 32bit INTEGER all 32bits mean 2^0 + 2^1 + 2^2 + 2^3 .... 2^32
In the floatroutines 32bit represent something complete different than an integer.
some of the 32bits represent a floating-point-value and some others represent a 10^x-factor
best regards
Stefan
Post Edited (StefanL38) : 10/10/2009 6:35:37 AM GMT
(pi/180) * angle
is compiled as
( fp-constant-3.14159 integer-division int-constant-180 ) integer-mult integer-variable-angle
Now "pi/180" is a constant expression, so you can write it as "constant(pi/180.0)" (the compiler can do fp arithmetic in constant expressions).
The multiplication by angle is more difficult. You have to convert angle to floating-point and then call a floating-point multiply routine:
f.fmul( constant(pi/180.0), f.ffloat(angle) )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
I did a search through the math-objects in the obex and found
Dynamic Math Lib - Nav Optimized
which provides the following functions:
PUB StrToQval(strP) : qV Action: Converts a String to Qs15_16 (Qvalue) format Parameters: Pointer to zero terminated ASCII string Result: Number in Qs15_16 Fixed-point Qvalue format PUB QvalToStr(qV) : strP Action: Converts a Qs15_16 (Qvalue) number into ASCII string Parameters: Number in Qs15_16 format Result: Pointer to zero terminated ASCII string PUB Qval(intP) Action: Converts a LONG Integer into Qs15_16 Fixed-point format Parameters: LONG number Result: Number in Qs15_16 Fixed-point format PUB IntFracToQval(intP, fracP) Action: Converts 2 LONG registers containing Integer and Fraction parts of a number into Qs15_16 Fixed-point format in one 32-bit register Parameters: - Integer part of the number - Fraction part of the number as (fracP x 64K). E.g. 0.5 is 0.5*64K=32K Result: Number in Qs15_16 Fixed-point Qvalue format PUB IangleToQval(iA) Action: Converts iAngle (4K=2Pi) into Qs15_16 Fixed-point Qvalue in degrees Parameters: Iangle as LONG integer (4096=2Pi) PUB QvalToIangle(qV) Action: Converts Qs15_16 Qvalue Angle [noparse][[/noparse]deg] to iAngle format Angle Parameters: Angle [noparse][[/noparse]deg] in Qs15_16 Fixed-point format Result: Angle in iAngle (Index of Angle) format (4K=2Pi) PUB DegToRad(dg) Action: Converts an angle in degrees into radians Parameters: Angle as Qs15_16 Fixed-point format Qvalue Result: Angle in radians in Qs15_16 Fixed-point format PUB RadToDeg(dg) Action: Converts an angle in radians into degrees Parameters: Angle in radians as Qs15_16 Fixed-point format Qvalue Result: Angle in degrees in Qs15_16 Fixed-point format PUB Q_EQ(arg1, arg2, eps) Action: Checks equality of two Qvalues within epsilon Parameters: - Value1 - Value2 - Epsilon Result: True if (ABS(Value1-Value2) < Epsilon) else False PUB Q_GT(arg1, arg2, eps) Action: Checks that Value1 is greater or not than Value2 with a margin of Epsilon Parameters: - Value1 - Value2 - Epsilon Result: TRUE if (Value1-Value2)>Epsilon else FALSE PUB Qmul(arg1, arg2) : qV Action: Multiplies Qs15_16 Fixed-point numbers Parameters: Multiplicand and Multiplier in Qs15_16 Fixed-point format Result: Product in Qs15_16 Fixed-point format PUB Qdiv(arg1, arg2) : qV Action: Divides Qs15_16 Fixed-point Qvalue numbers Parameters: Divider and Dividant are in Qs15_16 Fixed-point format Result: Quotient in Qs15_16 Fixed-point format PUB Qmuldiv(arg1, arg2, arg3) : qV Action: Multiplies 2 Qvalues and divides the result with a Qvalue Arg1 * Arg2 Result = ------------- Arg3 Parameters: Multiplier, multiplicand and divisor in Qs15_16 Fixed-point format Result: Result in Qs15_16 Fixed-point format PUB Qsqr(arg) : qV Action: Calculates the square root of a Qs15_16 Fixed-point number Parameters: Argument in Qs15_16 Fixed-point format Result: Square-root of argument in Qs15_16 Fixed-point format PUB SIN_Deg(qVd) Action: Calculates sine of Angle Parameters: Angle [noparse][[/noparse]deg] in Qs15_16 Fixed-point format (Qvalue) Result: Sine of Angle in Qs15_16 Fixed-point format (Qvalue) PUB COS_Deg(qVd) Action: Calculates cosine of Angle Parameters: Angle [noparse][[/noparse]deg] in Qs15_16 format Result: Cosine of Angle in Qs15_16 format PUB TAN_Deg(qVd) Action: Calculates tangent of Angle [noparse][[/noparse]deg] Parameters: Angle [noparse][[/noparse]deg] in Qs15_16 Fixed-point format Result: Tangent of Angle in Qs15_16 Fixed-point format PUB Deg_ASIN(qVs) : qV Action: Calculates Angle of a Sine Parameters: Sine input value Qs15_16 Fixed-point format Result: Angle in degrees in Qs15_16 Fixed-point format PUB Deg_ACOS(qVc) : qV Action:Calculates Angle of a Cosine Parameters: Cosine input value Qs15_16 Fixed-point format Result: Angle in degrees in Qs15_16 Fixed-point format PUB Deg_ATAN(qVt) Action: Calculates Angle of a Tangent Parameters: Tangent value in Qs15_16 Fixed-point format Result: Angle in degrees in Qs15_16 Fixed-point format PUB Deg_ATAN2(qX, qY) : qV Action: Calculates Arc Tangent of an Angle in [noparse][[/noparse]deg] between [noparse][[/noparse]-180,180] from the X, Y rectangular coordinates Parameters: X, Y rectangular coordinates in Qs15_16 iValue format Result: Angle [noparse][[/noparse]deg] in Qs15_16 format PUB Qradius(qX, qY) : qR Action: Calculates Distance of point (X,Y) from the origo Parameters: X, Y Descartes coordinates in Qs15_16 Fixed-point format Result: Distance from the origo in Qs15_16 Fixed-point formatfor more details see additional info inside the sourcecode
best regards
Stefan
The key to using integer math where fractions are involved is scaling. For example, the sine table is 2049 samples ranging from 0 to 90 degrees; there's an "extra" sample in there for end rollover so that a full circle is 8192 ticks. You could simply normalize that as your unit of angular measure, or even pick a higher number and use linear interpolation on the table. Similarly, the output of the table which should range from 0 to 1 is scaled to range from 0 to 65536 instead.
So, as a practical example, let's say you want to display a radar blip on your display; you know it's at 220.45 degrees from north and 11.865 miles out, and your display is a 40 mile square scaled to 200 pixels square. First, you have to scale the inputs to integers; you can usually do this by stripping the decimal point. Remember the result must fit in a long, which is pretty generous since those can go to +- 2 billion or so. So we take 22045 of 36000 as our angle. To scale this for our 8192 tick table we would normally multiply by 8192, then divide by 36000; this is equivalent to a single multiplying by 0.2275555... which we can't do, because it's a fraction. But there's a much better way! The ** operator does a 32 by 32 bit multiplication and returns the high 32 bits of the 64 bit result, effectively dividing the result by 2^32. So we can scale our fraction UP 2^32, which gives us the constant 977_343_669. We can therefore say index := angle ** 977_343_669, and boom! We get our scaled sin and cosine directly from the example routines in the Prop manual.
Now again, our sin and cos tables are normalized to increments of 1/65536. We would normally take the sine and cosine results and multiply by our screen size and divide by our physical territory size, san sin(n)*11.865*200/40, to figure out where to plot the point. But since our sine values are scaled, we must also divide by 65536, and since our miles are scaled we must divide by 1000, or result * 200 / 40 / 65536 / 1000, or result * 7.629E-8. You see where I'm going with this, right? We multiply that fraction by 2^32 to get 328, and so given our sin/cos lookup results * 11865 ** 328 should give us the pixel position to plot the result. Polar to cartesion conversion, no floating point, and only·three multiply operations.
Iterating through all the angles, this example will plot a circle 59 pixels in radius -- you can check by plugging 65536, the "1" value for sine and cosine, and doing the math.
In more complicated operations the main trick is making sure that our intermediate results fit in a long, and that they never scale down so far that we lose too much resolution. Sometimes this requires some shifting and/or additional application of ** to bring things in range. We have a bit of a bottleneck like that in the example, but it's OK because the relatively coarse final answer of 0-59 is our final result; if we were going to do more operations we might scale it higher, say by using 327_680 instead of 328 in that last operation; this would give us an output in 0.001 pixel increments, which we could later plot by dividing by 1000 or ** by (0.001 * 2^32).
Post Edited (localroger) : 10/10/2009 4:14:18 PM GMT
WOW... My head is still spinning after reading your post.· I will have to re-read multiple times to decipher your reasoning.· Your "scaling" procedure makes a lot of sense.· Staying with integer math (rather than FP), certainly, makes more sense because of speed.· However, at this point, I used STEFANL38'S suggestion (although FLOAT32 probably would have worked as well).
·
Attached to this post is the polar to Cartesian object that I previously posted (with some changes).· It displays the arc that I was looking for.· Hopefully, it will be fast enough to process the PING object that I have already written.· Thanks to all for your help.· You have certainly advanced my goal.· I just wish I had more time to dedicate to this as I have a full time job, for which I am VERY thankful for (considering the economic climate).·I also have a family that, of course, requires much of my free time.·
·
I can not say enough good things about this forum.· Good people are willing to give up their precious time to help us less knowledgeable folks.· THANKS!!!
·
Bob
that's pretty cool short.
best regards
Stefan
localroger,
In the OBEX there is a portion of a program very similar to your 'testarcint.spin'
obex.parallax.com/objects/48/
If you download the above object, and look at the spin file named 'HM55B Compass Module_Serial Demo_V1.1.spin',
there is a section within the code under 'PUB DrawCompassCircle' that does essentially what 'testarcint.spin' does.
Perhaps this will still help...
PUB DrawCompassCircle|_Deg,X,Y,X_Size,Y_Size,X_Center,Y_Center X_Size := 30 Y_Size := 15 X_Center := 50 Y_Center := 15 repeat _Deg from 0 to 360 step 5 X := X_Center + (GetSine(Deg2Bit13(_Deg))* X_Size)/ 65535 Y := Y_Center + (GetCoSine(Deg2Bit13(_Deg))* Y_Size)/ 65535 CRSRXY(X,Y) ser.tx("+")▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
The DrawCompassCircle method also doesn't demonstrate the very important ** scaling operator, which is essential for applications where your input scales are arbitrary. (I have also noticed in further reading that it's 65535, not 65536, that is 1 in the trig tables, a trivial thing to adapt for with **.) In fact, your example would be faster and smaller if you replaced * ?_size / 65535 with ** constant(?_size / 65535 * 2^32).
Post Edited (localroger) : 10/11/2009 8:49:43 PM GMT
I haven't actually tested the speed differences between between the two methods, but I really wasn't going for speed with the demo... the way I did it was based from a derivative of something my dad showed me when I was about 12 years old. He wrote a small program on the Atari computer to draw a circle using a basic Deg to Rad conversion ( Rad = (Deg/180)* Pi ) , a Sine/co-Sine lookup table, and a little bit of scaling here and there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
·
I downloaded your object this morning but didn't get a chance to look at it till now.· Spent the afternoon with the family at the beach.· Anyway, this just gets better and better.··Thanks for·sharing your vast knowledge.· I tried the FLOAT32 stuff with my PING object, but it ran very slow.· I implemented·your scaling technique·in·my ping object and it worked a little·faster (I have PING rotation (incrementing) and ranging in a separate cog, but still was slow with FLOAT32).· I have PING rotating with accurate angular measure and plotting the "*" accurately, at max distance (x=50, y=25).· However, I still have to figure out ranging.· I have "pointers" assigned to "PingDir" for angle and "range" for distance.· I am getting good centimeter distance from PING, by using "debug.dec(range)", with a max of 100 (range := <#=100)".· But implementing it, using you scaling technique, will take a little work.· Then, I can work on speeding up the whole process.· I might have to sacrifice some resolution for speed.· Will keep you posted.·
·
I don't think it's said enough... Thanks for your Support.
·
Bob
Lets see now... surf or code?· Most of us would have chosen the "Fun" option... CODING... NOT.· Anyway, thanks for all your help.· My mini-radar is working perfectly.· Thought I had a timing problem... turns out, it was a power supply problem.· Ping would rotate for about 10 or 20 degrees, and then stop.· I was pulling my hair out (even though I don't have any).· I was feeding the 5 volt regulator (for ping and the prop) with about 5.2 volts.· The output of the regulator was about 4.8 volts.· I didn't think ping would mind... only 2/10's of a volt difference.··Well, it turns out that ping·WANTS to see 5 volts.· So, I feed him 5.2 volts.· He sure liked it.· Working perfectly now.· I will add a schematic in the top object and finish adding comments.· Then will post.· Not sure where... maybe in the "propeller" forum, or in the "stamps in class" forum (where I found the original BS2 code).· Thanks again, and "watch that rip current".·
Bob
Bob
·
Been very busy at work and finally got time to decipher your code.· You are·the man!· At first, I considered your code like a C++ program... put something into an object, and understand what you should get out of an object(OOP).· I really did not understand the inter-workings of what your process did.· I originally performed some x,y graphs using 0-1920 (0-180 deg) against another graph of 410-2330 (0-180 deg); and came up the math that performed "scaling" that I expected.· After a power supply problem, the program worked great (although, I have some changes in mind that will reduce redundancy). Well, I got off work today and sent the family to go see "Where the wild things are". So, (over a cold one), I had a chance to step through your code.· This is amazing!· I plugged in some values corresponding to 30, 60, 90 and 135 degrees... and finally figured out how you did it!· I think your code needs to be in the OBJECT EXCHANGE, not only to exemplify how to use "INTEGER MATH", but also, how to access the "SIN TABLE".· What do you think?· I also need to explain the code a little better, than when I originally posted it a few days ago.· Hope you are doing well.· My hope is that I understand this "**" stuff as well as you.· It may take a few years, but I'm dedicated.· Have a great weekend; “SURFS-UP”, at least on the right coast (what about·the left?)… J.
·
Bob