NanoVMARduino is the Arduino porting of the nanovm. Its goal is to fully support Arduino Mega 2560. Since the Arduino Mega 2560 has much bigger flash and RAM than the original avr support. We will implement on the fly download and upgrade via serial or wireless link.

Please checkout the master folder

You can send pull requests via GitHub. Patches should:

1. Follow the style of the existing code.
2. One commit should do exactly one thing.
3. Commit messages should start with a summary line below 80 characters followed by a blank line, and then the reasoning/analysis for why the change was made (if appropriate).
4. Commits that fix a bug in a previous commit (which has already been merged) should start with fixup! and then the summary line of the commit it fixes. If you are writing your commit message in TextMate then type fix⇥ to get the prefix and a menu allowing you to pick the summary line from one of the last 15 commits.
5. Rebase your branch against the upstream’s master. We don’t want to pull redundant merge commits.

Developing patches should follow this workflow:

1. Fork on GitHub (click Fork button)
2. Clone to computer: git clone git@github.com:«github account»/NanoKong.git
3. cd into your repo: cd NanoKong
4. Set up remote upstream: git remote add -f upstream git://github.com/wukong-m2m/NanoKong.git

1. Create a branch for the new feature: git checkout -b my_new_feature
2. Work on your feature, add and commit as usual

Creating a branch is not strictly necessary, but it makes it easy to delete your branch when the feature has been merged into upstream, diff your branch with the version that actually ended in upstream, and to submit pull requests for multiple features (branches).

8. Push branch to GitHub: git push origin my_new_feature
9. Issue pull request: Click Pull Request button on GitHub

If a lot of changes has happened upstream you can replay your local changes on top of these, this is done with rebase, e.g.:

git fetch upstream
git rebase upstream/master

This will fetch changes and re-apply your commits on top of these.

This is generally better than merge, as it will give a clear picture of which commits are local to your branch. It will also “prune” any of your local commits if the same changes have been applied upstream.

You can use -i with rebase for an “interactive” rebase. This allows you to drop, re-arrange, merge, and reword commits, e.g.:

git rebase -i upstream/master