PBASIC ARCTAN function
 

FWIW, I just saw the following message on the BasicStamps list. I'm guessing that ARCTAN is new with the Beta version of the editor. How many of you would have used this this year if you had know about it?

How is this accomplished?
 

How did they pull this off?

Do they download a table if you use this function? Do they use some of the clever approximation techniques we have discussed on these forums?

I can see how they can add IF-THEN-ELSE because they already had all the stuff in the ROM mask to do it, they just needed their compiler to actually do it. Somehow adding new functions (especially a pretty complicated function like ARCTAN) seems more of a stretch.

I am very curious.

As to your question, Yes, I think I might have used it. Not on our RC Stamp2 but on the Stamp2 we had on our auxiliary board -- our Virtual Compass board. It could have been very useful.

Joe J.

It's actually for a dual-axis accelerometer manufactured by Memsic but made by parallax. The source code is at the bottom of the page. It's the last thing in the "Dual.bs2" source file.


If we follow the link we get: this.



Note that you need to fill in the tans table when you write your code for the algoritm to calculate properly.

No. That's not it. This paper describes the undocumented arctan (ATN) function as well as an undocumented hypotenuse (HYP) function.

I still wonder how they do it...
 

I can see how to use ATN but I don't know how they implemented it.

Do they put a table in EEPROM space if you use the function?

Do they put in a mini-loop to successively approximate the function?

Do they do a mini-table in EEPROM plus a calculation to refine the number to an 8 bit number?

If you know, please explain...

Joe J.

There is a Taylor series approximation for arctan out there that is nothing more than repeated multiplications, divisions, additions, and subtractions. That's probably how they do it.

Doubtful...
 

I don't think they are doing a Taylor Series approximation, but they could be.

Taylor Series approximations are nice in theory but are not the best for rapid convergence which is what you want when computations cost you code space and computation time.

Anyway, I am still curious how Parallax actually pulled off this function.

If you know, tell us please.

Joe J.

A couple things I've learned (or deduced):[list=1][*]The editor DOES NOT download a lookup table into EEPROM. (I verified this by examining the memory map in the editor.)[*]My initial guess was incorrect that ATN is new with the 2.0 beta version of the editor. It IS supported in all currently available versions (both Windows and DOS) of the editor for all versions of the BASIC Stamp 2. (It is not supported by the DOS editor for the BS1.)[*]ATN is NOT implemented in the editor (other than that it knows how to tokenize it for the BASIC Stamp.) It IS implemented in the BASIC Stamp interpreter chip.[/list=1]I still don't know HOW they implemented it.... (But then why should I care as long as it works.:)) Joe, was your concern due to the fact that you thought it was implemented in the editor, and were therefore afraid that it would steal code space from you? If that's not it, I'm curious why you're not equally concerned about SIN and COS. Do you know of methods for calculating SIN and COS that are more efficient than any that you're aware of for ATAN?

code space, curiosity, & backward compatibility
 

Here is why I care HOW:

If the functions were available sin the ROM of a STAMP2 since Adam & Eve ate the apple, why have we been sufferring so long without it?

If it is a new function in the ROM, then how far back can I go on my controllers before the ATN function won't work?

In 1998 we had our first type of swerve, I have retroactively fit a 2000 (the first year for IFI) controller on that robot. Can I use ATN on that STAMP2?

Don't know.

I also am curious just because I am curious. Did they keep backward compatibility with older ROM's OR did they keep down code space on the current systems OR are they very clever sheep and do both (perhaps they look at the ROM version, download a table if they have an older ROM and use a newly available tolkenized implementation if they have a newer ROM)?

That is the sum total of my reason for asking HOW.

Joe J.

email text from gwross' first post
This seems to imply that the function has been around (not sure how long, but possibly always), but just wasn't documented. If you want to know 'why' it wasn't documented ... well, I can offer a few conspiracy theories, but I don't think they'll help :)

A taylor series might not be too innacurate when you are dealing with answers ranging from 0-255, right?

As has been discussed before, the Stamp 2sx is basically just a glorified Ubicom SX microcontroller. The interesting thing about that is that the SX doesn't include SIN or COS either, so something about the extra cicuitry included with the Stamp allows them to implement these things in very minimal program space (the ATN function doesn't seem to take up much more space than a simple +). How exactly this works, I have no idea :).

It works like this: The BASIC Stamp has an interpreter chip (firmware in ROM) which the SX executes.The SX microcontroller interprets tokens in EEPROM by executing this interpreter firmware. The firmware contains instructions to calculate SIN and COS and ATN. The PBASIC program (in EEPROM) only needs to include a token, and the interpreter does the rest.

Might there be an ATAN op-amp or PIC inside the RC? It would seem rather peculiar for there to be one, especially if it has not been documented...

Are there any identities to calculate ATAN based on other trig functions? I only know of applicable ones for hyperbolic arctangent.

My money is still on a Taylor series.

Unfortunately, it will take a very large amount of terms for a Taylor Series to converge if your angle is far away from your starting point. After about the 3rd term the powers exceed the ability of the stamp.

Some of the algorithms by the author on this page might serve as a nice approximation of the angle, but the looping makes it less efficient than many would like. It basically approximates the angle first by assuming that, instead of having an arc between (1,0) and (0,1), there's a straight line, like that of a triangle. Then, it uses the "guess and check" method using the cosine equation to converge on the angle.