Sorry, looks like it's more complex than my quick fix. Worth a shot though...I'm pretty sure my patch produces some kind of effect however, but it might not be the desired one then
Well there was some suspicious-looking code, but I don't know enough to tell if it was intentional or has other side effects I sent Julian a patch to check - it's in the 'shuffle' branch in my repo if anyone else wants look - but in the meantime, y…
Yeah, try it with the latest makefiles from Julian's reposistory, looks like LXR-Fusion doesn't have the latest ones. But it should also work if you set AVR_TOOLKIT_ROOT instead of relying on the executables being found in the path.
The leds supplied in my kit were coloured flat top units (3mm diameter) and they are flush with the surface of the panel.
Lol, maybe I needed new lenses then, they somehow seem larger...
Excellent... I meant to take a look at the warnings, but ran out of time...IIRC some gcc versions were broken regarding aliasing warnings, but it looks like the warning was warranted in this case though...
Glad to help. Let me know if there's anything else...
Apparently a few people have booted a firmware built this way, so chances are good.Although there's always the risk of missing #defines or something...
@julian Heh, both versions appear work here, but your version is indeed simpler...I seem to have provided a 'printenv' target to find this kind of problem, but apparently forgot about it instantly 8-}
Hm, that looks there's an issue if you don't set ARM_TOOLKIT_ROOT and rely on the path. I'll take a look and see if I did something silly in the makefile...
We could add a 'prepare' target to the root makefile to download the recommended compilers if it doesn't find them on the path and the env variables aren't set?
Is it worth making the "version" string configurable overrideable for private builds?I o…
@rudeog great, thanks.
Not sure if I still have a Windows install to test it with, but I don't think they'll work for Windows out of the box. I used some shell commands (find) and the firmwareBuilder project uses the local 'CXX'...Might be easier ju…
Had to give it another try:
git clone git@github.com:rudeog/LXR.git && cd LXRgit remote add pld https://github.com/patrickdowling/LXR.gitgit fetch pldgit checkout -b mybuildgit cherry-pick d45348f5d7^..a2e69e81a9
Not sure how well you can pu…
Narf, there's conflicts merging with rudeog's repo, so don't try that yet...I'll try and remember to push the path fixes to mine later, or just use egnouf's repo or your shell-voodoo.There should be a way to do it with cherry-pick or rebase, but I t…
Heh, I spend too long typing There's probably at least two ways to do it with git:
git clone https://github.com/SonicPotions/LXR.git && cd LXRgit remote add pld https://github.com/patrickdowling/LXR.gitgit fetch pldgit checkout -b mybuild pl…
Wow, great work Just a few quick notes:You can probably simplify things a bit: the {AVR|ARM}_TOOLKIT_ROOT settings should be all that's needed, so you don't have to update your PATH, and they can be passed directly to make without adding them to you…
I thought a VM might be quicker or less painful than everyone fiddling with their Eclipse install, but you're right, maintenance would probably be tricky, so I'd just go with makefiles for now.But I suppose it might depend on what @julian has planne…
Looks like you're mixing the compilers and projects Files in mainboard/DrumSynth_FPU should use only arm-none-eabi-gccFiles in front/AVR should use only avr-gccThat last avr-gcc call is compiling DrumSynth_FPU/src/main.c... (but it also doesn't have…
I kept the backslash fixes in the separate branch (path_fixes) to avoid conflicts -- I think by now enough people have made those changes I was offline when I got far enough for it to matter, otherwise I would have used rudeog's version
https://github.com/patrickdowling/LXR/tree/makefiles
If you have avr-gcc and arm-none-eabi-gcc etc. in your path, you should just be able to run "make" in the LXR directory, or you can do something like this:
AVR_TOOLKIT_ROOT=/usr/local/CrossPack-AV…
I've used CMake for some projects, but nothing cross-platform. It makes some things easy and it sounds really cool, but 9/10 have ended up generating makefiles anyway And as @rudeog says, we don't really have massive dependencies that have to be re…
There's an equivalent toolchain for mac, but Eclipse apparently hard-codes the toolchain into the .cproject (org.eclipse.cdt.cross.arm.gnu.windows.elf.release.607043204) which causes pain when you open it elsewhere...