i’ll post a template for arc development next week, basically just bare bones with some comments to make it easier to get started. in any case i found the framework very easy to use, it’s pretty self explanatory. take a look at skeleton\monome.h to get an idea of how to interact with grids/arcs.
in the meantime i’ve got a git/hub related question:
i’ve forked the official repo and added my orca code to my fork. i’ll move it into a separate repo at some point, but want to keep the fork in case i need to make any changes to the framework itself so that they can be pulled back into the original repo.
now i’ve made some commits to my fork, and there is a separate commit for the framework change. my question - is there a way via the github web UI to create a pull request for that specific commit only? or do i need to use the command line? tried poking around but could not find a way, if i try to create a pull request it seems to include all the commits to my fork.
You can make a new branch in your fork, and then cherry pick the framework commit. Then send out a pull request for that branch.
So you’ll need to do something like this:
# go back to an older commit upon which you'll base your branch
git checkout <commit before you started making changes>
# create and check out the new branch
git checkout -b framework-patch
# cherry-pick the commit with the framework changes
git cherry-pick <commit hash of framework change>
Then push your branch up to github, switch to in the UI and initiate a pull request, there should be a link for this when you visit your repo page after uploading the branch.
Hey @ether, any luck getting Xcode setup to build? EDIT: It seems X-AVR depends on avrdude, which I think only handles 8-bit MC’s? (at least CrossPack only does) so I’m not sure an X-code build is an option, at least with X-AVR (still a nice resource for 8-bit MC’s I guess). Does that mean I’m using gcc at a command line to build? I have some path(?) issues with gcc finding header files, might have to build my own avr32 tools instead of using the packaged installer. I’m learning a lot as I go here, feel like a bumbling moron, please forgive my ignorance. Any guidance is welcome.
@scanner_darkly, what did you use on windows? Decided to try installing and running Atmel Studio using Parallels, was able to get a project for the right at32uc3b0256 MCU, copied my code into main.c, and it builds. So now I guess I’m waiting for the MP to get here to see if that all actually worked. I’d still like to get it working in OSX.
I still haven’t gotten any feedback on the concept of adding an output matrix to MP’s functionality, which has me thinking the idea may be meritless. Still, I want to see through this little project (described in more detail) for the learning experience, and get a chance to actually play with the idea in action before I completely dismiss it.
I’ve been trying to build the firmware on a linux machine. The only way I can get them to compile is if I copy the avr32 headers into the folder I’m running make from. Is there something I need to do to ensure that these headers are sourced properly?
The error in question: ../xdk-asf-3.17.0/avr32/utils/compiler.h:62:22: error: avr32/io.h: No such file or directory
“It sounds like the compiler is not getting the right include paths set” was absolutely right. I copied the headers from avr32 into <AVR_TOOLCHAIN_LOCATION>/avr32/include and it works without the duplicated directory.
I’m probably guessing a simple way of standardisation - compiler config and paths can be a nightmare for the uninitiated. Olivier over at Mutable now supplies an entire dev environment - toolchain, compilers, configuration - as a Vagrantfile; it basically means you can guarantee anyone developing the code has exactly the same config as each other.
I love Vagrant, it’s a great way to make complex environments easily replicable.
I’m not sure Docker is really appropriate for most dev environments. Docker is designed to make immutable server instances. Dev environments are by nature mutable. It is possible to bend/twist Docker to work in a Vagrant-ish way for dev environments (and you can even use Docker with Vagrant), but when writing code I’d prefer to do without containers and just use Vagrant unless my goal is produce production server environments that need high availability, or to make it easy to reproduce very complex environments (say you wanted to create reproducible tests for a complex network topology or something).
It was easier to get docker running since I couldn’t find a precompiled version of the tool chain for OS X. What I’ve been doing is running ubuntu in a docker container that’s mounted to a workspace directory and use my standard dev environment with vim outside of the container. The same could be accomplished with Vagrant and sharing a directory with the host system.
# initialize the host virtualbox image
docker-machine create avr -d virtualbox
# Set the DOCKER_HOST and DOCKER_MACHINE environmental variables
docker-machine env avr
eval $(docker-machine env avr)
# clone the example gist
git clone firstname.lastname@example.org:46994b83c8a51fcb4781.git docker_mod_env
# build the docker container
docker build -t docker_mod_env .
# make workspace directory and clone mod repository
git clone email@example.com:tehn/mod.git ./workspace/mod
# run the docker container
docker run --volume $PWD/workspace:/root/workspace -it docker_mod_env /bin/bash
# build some things
Normally I’ll edit outside of docker and then switch to a window running bash inside of the container to compile and then run dfu-programmer on my host. I’m glossing over many of the details, I’ll try and get some better resources together if anyone is interested, though the docker website is pretty good.
Getting the avr32 tool chain running natively under Mac OS X isn’t actually that bad, @sam and I have been keeping this avr32-toolchain repo functioning.
Assuming you have Xcode, the command line developer tools, and homebrew installed building the complete toolchain from source using the instructions in that repository is two commands and a bit of time (while things compile).