Any chance you could team up with dwelch67 about raspiarduino HOT 7 OPEN

yes :) I have also thought much of the bare metal possibilities. It will not at all be hard to convert the lib to talk bare metal. I already have some nice sources on how to access the USB as well. Will need to look into it more to be able to determine how could the whole thing work together (reload the sketches from IDE).

from raspiarduino.

@KeithSloan Many thanks for query. Would you be able to describe some example use cases where a "Raspbian free" version of PiDuino might be used? What features in it would you see as beneficial above and beyond the version that is currently available running on Raspbian?

from raspiarduino.

@nkolban any real-time usage. It is turned into a micro-controller of a sort...
No kernel scheduler to mess up timings and such. It's like Arduino for real

from raspiarduino.

Hi Neil

I would see the benefit of a bar metal implementation as you don't have
to worry that your sketch being subject to interrupts.
That is one could be much more assured with things which have critical
timing.

Should be easier to setup as no need to disable features in Raspbian.

Just seems to me to be a cleaner solution

Keith

On 08/02/16 11:33, Neil Kolban wrote:

@KeithSloan https://github.com/KeithSloan Many thanks for query.
Would you be able to describe some example use cases where a "Raspbian
free" version of PiDuino might be used? What features in it would you
see as beneficial above and beyond the version that is currently
available running on Raspbian?

—
Reply to this email directly or view it on GitHub
#44 (comment).

from raspiarduino.

Cleaner for certain situations. Currently you have access to all that linux can offer. Bare Metal is Bare :) there is no linux there. You do your own networking and all. No Shell to execute scripts or other goodies that come with OS. SO they are both for really different situations.
I do agree that there is a way to make the framework work on both Linux and BareMetal, but do see majority of the users benefitting from having the OS in the background.

from raspiarduino.

Well in your shoes I would look at offering both.

For me if I have sketches developed for Arduino or chipKit pi I would
definitely choose the bare metal option.

I was under the assumption that one would be restricted to what the
Arduino API supports so no SPI-Slave etc.
So how does one access the Linux function

On 08/02/16 11:52, Me No Dev wrote:

Cleaner for certain situations. Currently you have access to all that
linux can offer. Bare Metal is Bare :) there is no linux there. You do
your own networking and all. No Shell to execute scripts or other
goodies that come with OS. SO they are both for really different
situations.
I do agree that there is a way to make the framework work on both
Linux and BareMetal, but do see majority of the users benefitting from
having the OS in the background.

—
Reply to this email directly or view it on GitHub
#44 (comment).

from raspiarduino.

Using this project in it's current state is just like writing a C++ app for any linux distro + access to the BCM peripheral hardware. If you export your libraries from the Pi, you can link to any lib and use it in your code (libusb for example or the libs for interfacing with the camera module). You can also load kernel modules and use them as well.
And I am interested in trying to offer both. Will see what I can do.

from raspiarduino.