arduino support? #752

Open
pencilcheck opened this Issue Jan 19, 2013 · 23 comments

Comments

Projects
None yet
7 participants

As indicated in the title, wonder when there will be support for arduino?

Is it possible?

Member

bovi commented Jan 19, 2013

It is possible on some Arduino compatible boards. Have a look here: http://d.hatena.ne.jp/kyab/ This guy has made some sketches for Arduino in mruby during the last couple of days.

Oh nice, so mruby can be compiled for avr already and it works on Arduino Mega. It seems like the blog author just moved mruby source code into MPIDE IDE library directory and compile without a problem.

But I'm getting some errors from the latest build

In file included from /Arduino/libraries/mruby/mruby.h:38,
from /Arduino/libraries/mruby/array.c:7:
/Arduino/libraries/mruby/mruby/value.h:193: error: width of 'flags' exceeds its type
/Arduino/libraries/mruby/mruby/value.h:199: error: width of 'flags' exceeds its type
In file included from /Users/penn/Documents/Arduino/libraries/mruby/array.c:8:
/Arduino/libraries/mruby/mruby/array.h:21: error: width of 'flags' exceeds its type
In file included from /Users/penn/Documents/Arduino/libraries/mruby/array.c:10:
/Arduino/libraries/mruby/mruby/string.h:35: error: width of 'flags' exceeds its type
In file included from /Users/penn/Documents/Arduino/libraries/mruby/array.c:11:
/Arduino/libraries/mruby/mruby/class.h:15: error: width of 'flags' exceeds its type

In closer inspection, it seems like flag is using 21 bits of the bit-field, and avr-gcc is complaining that 16 bits is all it can have.

Oh, and btw, I'm using avr-gcc 4.6.1 from homebrew

Owner

matz commented Jan 20, 2013

@pencilcheck can I close this issue?

Sure, I guess I will just change the size of bit field for flag into the value that my avr-gcc like

Thanks for the pointer though.

Actually I still can't compile mruby for arduino. No matter how I tried to fix, there are always something that pops up. For example, <strings.h> not found, EXIT_FAILURE not found, now internal error: out of range error

Contributor

kyab commented Jan 30, 2013

Hi, I've succeeded to build mruby for Arduino "compatible" board. http://d.hatena.ne.jp/kyab/20121231/1356976514 .
I tried with Arduino "compatible" board named chipKit Max32.
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,892,894&Prod=CHIPKIT-MAX32

With chipKit Max32 you should be able to compile and run mruby code.
Sketchs for chipKit Max32 can call all Arduino standard api/library like analogRead, digitalWrite,,,, so those api could be called from mruby.

I think there are mainly 2 issues to be solved, to mruby to run on standard Arduino board.

1.mruby requires around 70-80 kb RAM to load. Arduino Uno/Mega does not have such big RAM.(chipKit Max32 has 128kb RAM!)

2.on avr-gcc, sizeof int is not 4. so many error occures(chipKit Max32 use PIC32. so sizeof int = 4)

Member

bovi commented Jan 30, 2013

Hi @kyab,

I went over your articles and was also able to compile it for my ChipKit. Great work! I specially like your idea of uploading the bytecode via serial.

Regards
Daniel

Owner

matz commented Jan 30, 2013

@kyab what is the size of int on avr-gcc?

netmask commented Jan 31, 2013

im working with this

#define MRB_OBJECT_HEADER
enum mrb_vtype tt:8;
unsigned int color:3;
unsigned int flags:16;
struct RClass *c;
struct RBasic *gcnext

but still cant get a working version :/

Contributor

kyab commented Jan 31, 2013

@matz for some arduino boards sizeof int is 2, for other arduinos, it is 4.
@bovi thanks for reading my posts!

Contributor

monaka commented Feb 22, 2013

Hm... As far as I know. the deault value of sizeof(int) in avr-gcc is 2. And with -mint8 option, sizeof(int) will be 1. (see also http://gcc.gnu.org/wiki/avr-gcc )

And it may be sizeof(int) == 4 on broadly-defined Arduinos (bus pins compatible but CPU is not AVR, like GR-Sakura, ChipKit32, Enzi, ... ).

So I think it's hard to port mruby on AVR (strict Arduino).

Contributor

monaka commented Mar 8, 2013

@pencilcheck, is this issue closable?

If mruby is supporting arduino, then I think it would be better to leave it open. :)

Member

bovi commented Mar 8, 2013

I added some time ago a build configuration based on @kyab''s version in mruby under examples. With this it is possible to compile to Arduino. In case we keep this ticket open we would have to define what is the task here? Which problems do you have with the current Arduino support? If the question is more related to the Arduino API, I think the mruby repo is the wrong place. This should be handled in the mruby-arduino GEM instead.

Contributor

monaka commented Mar 8, 2013

I wrote FAQ. https://github.com/mruby/mruby/wiki/FAQ-%28General-Topic%29
Appending/Rewriting to that article is welcome.

As my patch to rakefiles was accepted, it's easier to create BSP (board support package) GEMs.
So it's good idea to prepare a BSP GEM based on @kyab's patch.

And if you do so, you should remind there are considerable differences between each Arduino-pin-compatibles.
It's possible they have source level compatibility. But their build step is not same.

I recommend you don't name "mruby-arduino". Better to be "mruby-bsp-pickit32" or something.

Contributor

kyab commented Mar 8, 2013

Nice FAQ.

I don't understand what is changed by @monaka's patch.
So what should I do?
I think it would be better ,that there to be mruby-arduino, which is board-neutral wrapper for Arduino API, and some BSP GEM which support chipKIT Max32.

Contributor

monaka commented Mar 8, 2013

My patch on #961 enables to build loadable binary in addition to mrbc,mirb,mruby.
And you can build target dependent loadable binary Using this in MRuby::CrossBuild configuration rules.

Basically, widely defined Arduinos start from compiled stetch routine, as you know.
So, before my patch applied, you must link your sketch and libmruby.a at the outside of rake build.
In the new world, you can link your loadable binary at rake build inside.

I'm going to write BSP for MIPS bare-metal. It'll be an example. (I push myself to publish within this weekend. ;)

And it's no issue you make board-neutral wrapper GEM named mruby-arduino.
Of course It must be rejected board dependencies carefully, as you know.

Contributor

cadwallion commented Apr 23, 2013

I have been working on identifying the problems with cross-building mruby using avr-gcc for Arduino Mega 2560 (instead of using the Arduino Due or the Pic32-based controllers), with the idea of working on improvements to mruby to facilitate it in some form. The biggest hurdles I came across:

  • mruby sets the flags to 21. This must be set to 16 for AVR. reference
  • mruby requires sys/types.h, and AVR does not have it. reference
  • mruby hardcodes a minimum of 32bit environment. reference
  • AVR does not define EXIT_FAILURE and EXIT_SUCCESS

If I set the flags to 16, replace the include 'sys/types.h' with 'stddef.h', remove the hardcoded exception for 16bit environments, and defined EXIT_FAILURE / EXIT_SUCCESS, the crossbuild succeeds. I have not experimented with the side effects of removing the 16bit environment exception yet, I will be doing so tonight.

The build_config.rb I used to test is below. This is on OSX 10.8.3 with Arduino.app installed:

MRuby::CrossBuild.new('ArduinoMega2560') do |conf|
  toolchain :gcc
  conf.gem :github => 'cadwallion/mruby-arduino', :branch => 'mega2560'

  ARDUINO_PATH = "/Applications/Arduino.app/Contents/Resources/Java/hardware"
  conf.cc do |cc|
    cc.command="#{ARDUINO_PATH}/tools/avr/bin/avr-gcc"
    cc.include_paths << [
      "#{MRUBY_ROOT}/include",
      "#{ARDUINO_PATH}/tools/avr/lib/gcc/avr/4.3.2/include",
      "#{ARDUINO_PATH}/tools/avr/avr/include",
      "#{ARDUINO_PATH}/arduino/cores/arduino",
      "#{ARDUINO_PATH}/arduino/variants/mega"
    ]

    cc.flags << "-g -Os -w -ffunction-sections -fdata-sections"
    cc.flags << "-DARDUINO=103 -mmcu=atmega2560 -DF_CPU=16000000L"
    cc.compile_options = "%{flags} -o %{outfile} -c %{infile}"
  end

  conf.archiver do |archiver|
    archiver.command = "#{ARDUINO_PATH}/tools/avr/bin/avr-ar"
    archiver.archive_options = "rcs %{outfile} %{objs}"
  end

  conf.bins = []
end
Contributor

monaka commented Apr 24, 2013

AVR does not define EXIT_FAILURE and EXIT_SUCCESS
mruby requires sys/types.h, and AVR does not have it.

mruby requires C99 compatible compilers (or MSVC).
It maybe C99 means hosted. Not freestanding.
If your compiler isn't have them, you may define them by yourself.

mruby sets the flags to 21. This must be set to 16 for AVR.

Could you tell us more detail? I tested with a simple sketch and there seems be no error.

struct foo {
  uint32_t a:21;
  uint32_t b:8;
} bar;

void
setup()
{
    bar.a = 10;
}

void
loop()
{
}
Contributor

monaka commented Apr 24, 2013

mruby hardcodes a minimum of 32bit environment.

You might already tested. There will be no side effect when you run mruby with small Ruby scripts.

There are some mallocs with uint32_t. This is the major reason why I set limitation macro.

When you succeed to run mruby on AVR. We will refine load.c. As maybe considerable guys will use mruby on Arduino.

(BTW, I didn't know MegaRAM/QuadRAM shield. I changed my opinion. It's possible to run mruby on Arduino.)

Contributor

cadwallion commented Apr 24, 2013

Interesting. If I reset the MRB_OBJECT_HEADER flags property back to 21, it compiles without error. That was not the case while I was testing yesterday, but it must have been a symptom of something else. That can be crossed off the list.

I ran into a problem last night getting the Arduino IDE to handle linking mruby before compilation, so today I will write my own build script so I can test mruby on AVR. I will report back what I find.

@monaka monaka referenced this issue Apr 25, 2013

Merged

Clean up load.c #1214

Contributor

monaka commented Apr 26, 2013

@cadwallion , you should add -DMRB_INT16 to the compile option.
It is not only for performance but for avoiding overflows in type casts.

Contributor

cadwallion commented Apr 26, 2013

@monaka, I will add that option, thank you. I have not had an opportunity to continue working on testing Arduino support this week, but I will be making time this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment