Robot arm ported to C++

JasonDorie · 2013-03-27 00:21

I know cross posting is generally frowned upon, but I thought the folks writing the gcc port deserved some kudos. I ported the Spin code for the robot arm I'm working on over to C++ in a couple hours, including the installation and first use of the compiler and environment. It's now running WAY faster than it was before, and the use of float math is MUCH simpler. Awesome work!

Check out post #8 here for a clip.

Jason

Heater. · 2013-03-27 00:55

Jason,

That's a great looking piece of work. Love the sound as well:)

Well done on the conversion to C++. Many here argued with me that C++ was not suitable for Propeller or other MCU use. You showed the otherwise.

David Betz · 2013-03-27 07:13

JasonDorie wrote: »

I know cross posting is generally frowned upon, but I thought the folks writing the gcc port deserved some kudos. I ported the Spin code for the robot arm I'm working on over to C++ in a couple hours, including the installation and first use of the compiler and environment. It's now running WAY faster than it was before, and the use of float math is MUCH simpler. Awesome work!

Check out post #8 here for a clip.

Jason

I'm glad you had success with PropGCC! Thanks for letting us know! Also, please report any problems you might run into so we can further improve PropGCC.

David

JasonDorie · 2013-03-27 12:32

I did submit a single bug (to do with sqrtf() vs sqrt() and using 32-bit floats), but otherwise setup and use was surprisingly easy. My biggest gripe at the moment is the IDE's lack of support for tabs and auto-indent (I'm spoiled).

I'm going to stick with C++ for development on the arm, so you'll probably hear more from me as I progress. I think the next thing I'm going to want to figure out is how to launch a function in a cog (if that's possible). Anything you can point me at to give me a head start would be great.

*Edit* - Never mind - Found the docs on cogstart() referenced in another post. I'll start there.

David Betz · 2013-03-27 13:24

JasonDorie wrote: »

I did submit a single bug (to do with sqrtf() vs sqrt() and using 32-bit floats), but otherwise setup and use was surprisingly easy. My biggest gripe at the moment is the IDE's lack of support for tabs and auto-indent (I'm spoiled).

Steve will say for sure but I'm pretty sure he told me that later versions of SimpleIDE had a way to indent a block of text. I'm not sure about auto-indent though. You can always use your favorite editor and the command-line tools for building. That's what I do.

I'm going to stick with C++ for development on the arm, so you'll probably hear more from me as I progress. I think the next thing I'm going to want to figure out is how to launch a function in a cog (if that's possible). Anything you can point me at to give me a head start would be great.

*Edit* - Never mind - Found the docs on cogstart() referenced in another post. I'll start there.

Yeah, that's a good place to start. Let us know if you need help.

jazzed · 2013-03-27 15:39

I'm very happy that your project ported easily. The video is impressive - Thanks for sharing that.

Regarding starting LMM code cogs with cogstart - that's a good idea if you will never need external memory. At the moment though, the transition with that model from LMM to XMMC is not possible. It is better to stay with PASM COGs if possible. We have looked at making XMM modes multi-cog capable, but there is no defined plan that I know of. David is the one to ask.

BTW CMM support was added to version 0-8-5, so if you exhaust LMM memory, try CMM which works the same as LMM except for being smaller and a little slower although faster than SPIN.

David Betz wrote: »

Steve will say for sure but I'm pretty sure he told me that later versions of SimpleIDE had a way to indent a block of text. I'm not sure about auto-indent though. You can always use your favorite editor and the command-line tools for building. That's what I do.

I don't discourage using SimpleIDE just because I have my own favorite editor (vim) - can't imagine why not LOL! I need as many users as Parallax can get to make sure the experience is good for everyone. An update is coming soon.

I use QtCreator for SimpleIDE development because that is the tool that makes my life easy in that task - I'd like to think that SimpleIDE makes Propeller-GCC development easy for most people. If it doesn't, that's fine too. Use the tool that makes you happy, or provide support for one like SRLM (CodeBlocks) and Rayman (VisualStudio) are doing.

In SimpleIDE version 0-8-5, tabs are converted to spaces. This will change because I don't want to mess with people's existing files especially if they are source-controlled. SimpleIDE uses "soft-tabs" exclusively for edits (tabs expanded to a number of spaces set in the Properties -> General Tab area). If I have time later, I may test a tab version.

The tabkey-block indent/outdent was added and in most cases works good in Windows (version 0-8-5). Tabkey-block indent/outdent is a disaster in Linux - it is removed in the new release. There are some valid bugs filed on the feature now under Windows too that I would like to resolve, but it's hard to say if that feature will make the cut. We'll see.

I'm under tons of stress here guys. Please be patient.

Thanks,
--Steve

JasonDorie · 2013-03-27 15:52

I didn't realize SimpleIDE was yours, Jazzed. I write a lot of end-user tools for work, and I know how hard it is. It looks like you've done a lot of work on it, so don't take anything I said as criticism.

Block indent works sometimes, depending on the current selection. I noticed some odd behavior depending on what I had selected when I did the indent - the last chunk of text on the preceding line would move over, for example. And block un-indent seemed to work sometimes and not others. It's certainly not a show stopper, and aside from those two niggles it looks to be pretty solid.

RayMan has a Visual Studio plugin? Tell me more....

JasonDorie · 2013-03-27 16:01

Oh, and in response to my cogstart question, I'm not sure whether I'll need external memory or not, or even exactly what I'll be doing with the other cogs.

At the moment, the code is all on a single cog, and least I assume it is - is float math on a cog, or just function calls? I precompute a bunch of parameters required for acceleration / deceleration using float, then use 24.8 fixed point during the actual move.

All the code executing the motion is integer math, so it's a good candidate for moving into a worker cog. I'd probably pre-calc the accel/decel parameters for moves over a period of time, and shove them into a queue to be executed by the motion cog. I may try to convert that to straight C, compile it in COG mode, and see if I can just load / run that. If I were to try that, is there a way to map HUB variables between the different C modes (LMM & COG)?

Whether I'll need external RAM or not depends entirely on how big the code ends up. I don't actually remember how big it is right now but I'll check tonight.

jazzed · 2013-03-27 16:16

Jason, We are logging bug issues in the propside.googlecode.com project if you want to add your observations for the old version. All reports from any version 0-8-5 are welcomed. We have several known issues related to the tabkey-block stuff now.

COGC is a pretty tough mode to use for non-trivial code, but it is usable, and can share variables with the main thread. Any shared variables (used with any COG/thread) must be volatile though. Here is a wiki page on using COGC: https://code.google.com/p/propgcc/wiki/COGModeExperiences

Variables to share with other COGs should be global scope in addition to volatile.

Yes, all code is single-cog unless you use cogstart or cognew. API cogstart is a variant on _start_cog_thread - cogstart has a slightly different usage.

Robot arm ported to C++

Comments