Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

arduino support? #752

Open
pencilcheck opened this Issue · 23 comments

7 participants

@pencilcheck

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

Is it possible?

@bovi

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.

@pencilcheck

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

@matz
Owner

@pencilcheck can I close this issue?

@pencilcheck

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.

@pencilcheck

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

@kyab

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)

@bovi

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

@matz
Owner

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

@netmask

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 :/

@kyab

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

@monaka

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).

@monaka

@pencilcheck, is this issue closable?

@pencilcheck

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

@bovi

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.

@monaka

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.

@kyab

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.

@monaka

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.

@cadwallion

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
@monaka

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()
{
}
@monaka

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.)

@cadwallion

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
Merged

Clean up load.c #1214

@monaka

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

@cadwallion

@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
Something went wrong with that request. Please try again.