Native Execution

[nixpulvis]

Motivation

I was thinking a lot about this project today. I've used Dino a little bit in the past and find it really fun to work with, however at a high level it seems a little backwards. Taking the ability to perform logic away from the Arduino and giving it to another computational unit. The true power of the AVR is it's ability to compute, and a library designed to interface and control the Arduino should leverage this power.

Approach

I am by no means suggesting that Dino be in charge of compiling ruby code into C, this is outside the scope of the project. However I think with some cleaver thought it should be possible to dynamically move some common computational tasks to the Arduino.

Consider the task of matrix multiplication, though the same argument could be made for many tasks. Having a dedicated processing unit grants some benefits in terms of timing, and for some applications this is very helpful. Leaving them on the Arduino could make sense. But how would this be done without injecting or compiling C code into the mix.

Dino Native Function

By developing a C++ class to in effect wrap a function, a user could write his/her own C code to be run natively as individual functions for example matrix_multiply, and then the wrapper class communicates this with Dino upon setup to establish available functions, and exposing them through a ruby class. This is what I feel is a good compromise between attempting to compile ruby into C, and leaving users hanging without a means to control C code running on the Arduino.

Next

An even more complete implementation would be able to wrap full classes in C++ allowing for example, a C++ Matrix class that has defined on it the operator * allowing for lines in C like,

Matrix result = matrix1 * matrix2;

When this whole class is wrapped the previous example could be executed from ruby on the Arduino as,

matrix1 * matrix2  #=> #<Dino::Native::Matrix:0x007ff0048003a8>

This is by no means a small task, and I'm mainly writing this here because I wanted to document my thinking. Thoughts and improvements are more then welcome :smile:

[cdcarter]

I feel like the purpose of Dino is to let us use an Arduino (a very affordable off the shelf part) as a GPIO board for a more powerful computer. Really the AVR chip is just being a middleman and letting my computer do the dirty work. Which I think is good and a good scope for the project.

I wonder what you think the real life use cases for this functionality would be? I think it's an interesting idea but I don't think its within the "vision" of Dino, or at least what I believe Dino to be.

[nixpulvis]

I kinda agree I just feel like it's a waste to use the AVR as simply an interface for pin, it is very capable of doing computations.

[vickash]

@nixpulvis I've spent a fair amount of time making the sketches run faster with the precious (when compared to even a $20 router) resources available on the Arduino . Given that, I just can't understand how you could suggest something which is so clearly a waste of those resources.

For example, I, and probably others, want IR blasting capability. For that, you absolutely DO want the Arduino to handle timing. That single operation, from Ruby's perspective, will block the Arduino from doing other things for longer than any command we can currently send to it. Finding ways to keep the board responsive is already a challenge. The more functionality we add, the more difficult it becomes.

Do you really mean to suggest that I wait around while it does matrix arithmetic instead of interacting with hardware? (The one thing we need it to do the most) Especially when, by the technical requirements of making it work at all, I already have a high level language like Ruby and a more powerful machine at my disposal?

No thanks. I'd rather spend my time wringing every bit of IO performance possible out of the Arduino code. With the unmodified dino sketch loaded, an Arduino Due can already spit out data for 3 12-bit analog inputs @ 1kHz. That's race data logging territory. On a $45 board. And it will only get faster.

Not to mention that this suggestion is exactly 180º from the stated purpose of the project:

@cdcarter:

I feel like the purpose of Dino is to let us use an Arduino (a very affordable off the shelf part) as a GPIO board for a more powerful computer.

I'd add "using an enjoyable high level language" to the end of that, but it is, in a sentence, the vision @austinbv outlines for this project in his first talk. Here's a link if you haven't watched it: http://www.youtube.com/watch?v=oUIor6GK-qA

[nixpulvis]

My suggestion is not a waste of the AVR's resources unless the user deems it worthy. It requires no overhead unless the user specifically invokes it. Frankly your response is a bit harsh considering the fact that the user may want more possessing on the AVR and may not care for 1kHz data from 3 12 bit analog inputs. It's great that it's possible to get that if you need it, I was simply suggesting another option for ways to spend clock cycles, by giving them to the user.

Your response really put me off. I wasn't demanding anyone implement it. I just wanted to see if it resonated with anyone. It didn't and that's fine.

[cdcarter]

@vickash

I'd add "using an enjoyable high level language" to the end of that [...]

Would it be beneficial to include a vision statement in the repo? I'm going to think about this and maybe submit a PR for you and @austinbv.

[nixpulvis]

Or add a CONTRIBUTING file.