Hmm. Had a couple issues this time around with building. I was making a small change to the code, and wanted to share my issues, just for reference to others who might not be as experienced with the build process. Maybe someone else has some insight here.
So I did everything from the linux shell (because I’ve been pulling my hair out with eclipse&avr plugin). I used git to clone the repository. I could not clone the avrlib submodule via “git submodule update”. avrlib looks kind of like a symlink in the git structure? I’m not that familiar with Git. Anyway, I couldn’t build without the avrlib stuff present. Looked at github, and it appears to be part of the avril repository. So I cloned that inside of the shruthi-1 repository, and renamed avril to avrlib.
I then had to change the makefile.mk in avrlib to reference /usr/bin for AVRLIB_TOOLS_PATH. Could not find an /etc/ associated with AVRLIB, so I left it as-is. Now it compiles.
After compiling, size was 64734. My avr-gcc is 4.3.4. I guess I’ll get a different version and try again. What are you using these days, Olivier?
…currently building the GNU Tool Chain from source
I tried from a blank state and with a git clone firstname.lastname@example.org:pichenettes/shruthi-1.git ; cd shruthi-1 ; git submodule init ; git submodule update I was set. My bet is that you forgot the “git submodule init”.
I’m running 4.3.3 from Crosspack.
Tomorrow I’ll push a modification to the z-family oscillators code which allows 3 of them (zsync, zreso, ztri) to share some code at little CPU cost. Hopefully, this will squeeze the code enough. I just need to test it a bit more…
If you can’t wait, you could change the fuses to disable the bootloader and work on the full 65536 bytes of flash.
Hmm. I definitely did a ‘git submodule init’. It returned this:
Initialized empty Git repository in /home/smrl/shruthi-1/avrlib/.git/
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
Clone of ‘email@example.com:pichenettes/avril.git’ into submodule path ‘avrlib’ failed
However, one thing I did differently is this: when I initially cloned the repository I did a git clone https://github.com/pichenettes/shruthi-1.git
Seems possibly related to the HTTPS & encryption…
Anyway, I’ll definitely wait. I’m now descending into dependency hell and would rather find another strategy. Or I could push the code up to the repo and you could build it in? It’s just 5 lines of code…
Yes, sorry, the public link from github is git clone git://github.com/pichenettes/shruthi-1.git (what I gave in my previous message is the link for cloning a repo with R+W rights, and obviously only my machine is authorized for this).
If you have a github account you can push your changes to your private repo and I could pull them from there, build them, and send you the .hex / .mid
I’ve done more trimming down of the code and I’m now at 63466, so even with the extra code generated by the latest gcc you’ll be fine. Pushed to the master branch.
I’m planning some refactoring of the envelopes code that could save 400 or 500 bytes while allowing for a 2x wider range of time (very slowwww envelopes).
There’s a branch with the new envelopes code here
I still need to calibrate this so that the old and the new version have roughly the same times for values up to 100 (so that most of the patches are untouched).
It’s simpler and would make it much easier to control the individual A/D/R times in the mod matrix. And if you’re of the hacker type you can easily customize the envelopes response curve.
I’ve updated the submodule URLs in the Shruthi-1 project to refer to publicly accessible repositories. The git submodule init, git submodule update should work now on any computer/account (and not only all those whose ssh keys I have whitelisted on github).
Now I feel less stupid about git. Super helpful page