Avrbuddy - New Yun Project

I am developing a new project that offers linux services to sketches ‘32u4’ on the Yun from the WRT environment on the AR9331. I have everything in beta, but basically working. See the attached diagram for basic explanation.

Any suggestions would be appreciated.

For anyone interested in playing with the code: cd to someplace, say /var/tmp and do
git clone GitHub - cephalotus/avrbuddy: IPC based data interchange and transport for arduino yun

@heggood, it' interesting work. I need to reflect on your design. I'll get back to you later today. I'm sure others will chime int.

TIA Jesse

This looks very interesting. I do have one question. Would this replace using the Bridge funcitons? I have recently, found that using the Bridge (specifically Bridge.put) to transfer data to a web page is slow. This appears to be a faster way of transferring data between the two.

@heggood,

The attached images is what I see. Is this correct? This is what I see as the data path. This based on your text description.

Jesse

avr_buddy.png

justGreg,

Yes, it can replace both the bridge and process functions, as well as adding an on-demand database. I'm not willing to speak on the speed aspect of it yet. I suspect there may be a 64 byte buffer associated with the serial library that I need to investigate. If true, transmission from linux to micro will have to use software flow control of some description.

Jesse,

Assuming the 'implied' means on-demand from the linux shell and not started by avr_init your data flowchart seems correct except for the fact that although your illustration shows the sqlite and system process dedicated to the tty process, factually any two process in the group can exchange messages.

One idea that I'm toying with is a way to have the '32u4 be able to send a request to have a new sketch overlaid on the current one with a sketch server process. Another idea is to have a program say avr_cron with lots of command line options that can be invoked from shell or crontab that joins the queue, and messages one of the processes. Lot's of possibilities.

heggood: Jesse,

1) Assuming the 'implied' means on-demand from the linux shell and not started by avr_init your data flowchart seems correct except for the fact that although your illustration shows the sqlite and system process dedicated to the tty process, factually any two process in the group can exchange messages.

2) One idea that I'm toying with is a way to have the '32u4 be able to send a request to have a new sketch overlaid on the current one with a sketch server process.

3) Another idea is to have a program say avr_cron with lots of command line options that can be invoked from shell or crontab that joins the queue, and messages one of the processes. Lot's of possibilities.

heggood, on #1 I used the word "implied" because you did NOT state in any certains terms how that would work. I assumed it would NOT be via the sys_init, but beyond that I'm guessing. You did not describe - so I'm just adding words with how of a better explanation.

on #2 swapping out one sketch for another would be handy.

on #3 You're getting out hand. We you say "Lot's of possibilities." I get chills thinking about "feature creep". You might want to define that, but I can see good ideas coming out of this -- such as a controlled roll over.

But seriously, on #3 the Yun is a fine machine, but with the next two years it's likely to be replaced. As such, ambition has an enemy named TIME

Othewise, I'll be happy to give it a try once you have an Alpha verion.

Jese

heggood: ::::SNIP::::

How about how Torvalds works, fork it, submit it, and hope for approval by the one in control?

I will forego comment. Jesse

But seriously, on #3 the Yun is a fine machine, but with the next two years it's likely to be replaced. As such, ambition has an enemy named TIME

Yep, they all have and end of life cycle, but I and am sure others, besides myself have been waiting for something in the micro-controller arena that has linux capabilities out of the box. The Yun did that and to boot did it with co-processors! Yeah, the Yun may go away, but I'm sure now that the cat is out of the bag, a 'Yun' type is here to stay!

heggood: You're getting out hand. We you say "Lot's of possibilities." I get chills thinking about "feature creep". You might want to define that, but I can see good ideas coming out of this -- such as a controlled roll over.

How about the way Torvalds handles it, fork it, submit it, and hope for approval by the one in control?

I will forego comment. Jesse

Thanks.

Othewise, I'll be happy to give it a try once you have an Alpha verion.

Beta comes after Alpha, It already is beta.

heggood: Beta comes after Alpha, It already is beta.

I prefer tarballs, but github or source forge will work.

Jesse

I prefer tarballs, but github or source forge will work.

See heggood.com/FILES