DSP Robotics Support

Thanks for sharing Trog!
Very nice visualizing

Hi

Cheers for this master class Trogg! some stuff learned from it already

oh and i love all the arrows and text boxes! nice touch! looks minted m8

Regards

Thanks guys - glad you're liking the widgets; they should make it much easier and quicker to make tutorials and module "user guides" - no more messing with OpenOffice, Photoshop, folders of images to manage etc.!

If anyone fancies using those graphics themselves, here's a very quick guide....
Text notes - L-click to edit the text, R-click for a context menu where you can select colours and turn the background and/or border on and off.
"Empty" Boxes - R-click on the border line for a context menu to change the colour and line style.
Arrows - L-click on the arrow and drag to change the direction. R-click the arrow to change color and width. The "fine" width creates the "boxout" line with a little blob on the end.

Arranging them takes a bit of practice, as they are really just modules with some transparency and the borders switched off - you will sometimes have to hunt a bit with the mouse to find a "handle" when you want to move or re-size them. Mouse events don't "fall through" the transparent parts either, so try to have some space available to move them out of the way - for example, if you need to edit stuff that's "inside" one of the box icons. To get the layering right, you can bring an item to the top by cutting it (Ctrl-X) and pasting it straight back in (Ctrl-V).

How's anyone getting on with the "cartoon strip" feel? It was a bit of an experiment, so I just wonder if anyone else share's tester's opinion that "all on one page" is a bit clunky.

thank you trog, great stuff to learn from very interesting!

Big Thanks TROG for this tutorial/ lesson !

The 'comic' layout is very easy to follow along. The graphic high-lites and text boxes seemed very intuitive to follow.

Really nice presentation. Thank-you for taking the time doing this.

As to the actual testing of the various routines ... some great stuff for me to study [of course].

I do have a question, though

It seems that clicking the 'trigger' to start the test will yield different output times [most notably the very last test routine]. I get timing results like this:

1. 0.0310001
2. 0.0149994
3. 0.0159998
4. 0.0310001
5. 0.0159988

etc ... what would this be attributed to ??

Thanks again

hi guy's ,

I test your benchmark trog well and thank you for this nice work

I wanted to test how quickly a dll following (and respecting your code of course)

see how time put with a dll.

and the result is interesting outright I see attached below the fsm and the project dll to prove my good faith: p

a screen capture on my pc to the result obtained



and now the project file and the fsm



C + + is faster is normal this is not an interpreted language but I will think that to load a dll in memory have done it but not waste time

wow its about 5 times faster here on my computer, thank you very much for providing this example!

Wow! - thanks a lot, Mmix, that is a excellent demonstration - the perfect completion of the benchmark comparison.

RJHollins wrote:It seems that clicking the 'trigger' to start the test will yield different output times [most notably the very last test routine]. I get timing results like this:

There are a few reasons for this...

- The RTC timer is using green triggers to start and stop, so the precise moment will be missed by a short amount as the triggers are processed.
- Your CPU is doing other things besides running the test schematic - so the times vary according to the CPU's task switching.
- There will be times when Ruby's garbage collector has to come along and free up the memory used by temporary Ruby objects. This only happens occasionally when Ruby feels it is running short of space on its memory heap - so once in a while you just get unlucky. Something similar possibly goes on behind the scenes with 'Green' trigger management.

You will generally get more reliable times if you increase the count. I kept the number fairly low for the download because I don't know what CPUs people will be testing on - if the number is too big, Ruby goes splat!

no problem if I can bring a stone to the edifice, I will bring my help