My wife got me an Orangutan for Father’s Day (is she cool or what?). I have the avrgcc toolchain up and running on my Mac, with an AVRISP mkII, and long experience with C (though it’s been a while since I’ve had to use makefiles!), so in theory I should be in good shape.
But I’ve hit a stumbling block right away. I downloaded orangutan-lib-0.3 and orangutan-examples-0.1 from http://orangutan-lib.sourceforge.net/. Each of the examples appears to have a prebuilt .hex file (how nice!), so moving into the lcd-only/default directory, I did:
avrdude -p m168 -c avrispmkII -P usb -U flash:w:lcd-only.hex:i -v
This installed the program, which began to run immediately on the Orangutan, writing stuff on the LCD. However, I only see stuff on line 1 – I’m sure I saw a second line with the default program. And the source code is clearly attempting to use line 2.
So I have two questions:
Is this good example code or not? Searching the forums, I saw much confusing talk about how to drive the LCD, whether examples were needed or not, etc. And I saw mention that those problems were fixed in orangutanlib-0.2, but it looks like orangutan-examples doesn’t actually use orangutan-lib. So maybe this sample code was never updated?
(If not, maybe this could be made clearer on the orangutan-lib site, so as to not lead other newbies astray.)
Where’s the .hex file for the default program that was preinstalled on the orangutan? I know the good folks at Pololu were not eager to share the source, but that’s fine with me – I’d be happy to install the hex file and get it back into its factory state.
Incidentally, while I was typing this, I was also avrduding the lcd-test.hex file within the orangutan-lib distribution. This one seems to work fine.
Thanks very much to the guys behind orangutan-lib – it looks really nice, and the prebuilt hex files are a really nice touch, letting a newbie like me get into the water slowly rather than having to dive in head-first with both feet.
In answer to #1, no, the example code is out of date and suffers from the LCD issue I alluded to when posting about the release of Orangutan-lib 0.3. The examples are in much need of fixing. I’ll get on that tonight and try to have a new version out tonight or tomorrow morning.
You should be able to go into orangutan-lib and open the lcd-test project in there. That has the new LCD code, and should drive both lines on the LCD. (It looks like you already caught that.)
Glad you like the .hex files. I had second thoughts about including those in the distribution, but I’m not having doubts about it now. It was the right decision.
Let me know how re-compiling those projects goes. I had some snafus with AVR Studio using absolute pathnames to stuff, so anyone who downloaded 0.2 got a good look at the nasty directory layout on my laptop. The 0.3 release was hand-edited to remove all the absolute pathnames.
Thanks again for catching the problem with the example code. It actually dates back to orangutan-lib 0.1, so it’s in dire need of an upgrade.
It looks pretty clean on the whole – all I’ve had to do so far is change the definition of CC from avr-gcc.exe to avr-gcc (though I’m considering making a symbolic link from avr-gcc.exe to avr-gcc so I can run the default makefile). It generates a .hex file (along with the intermediate files) This is not identical to the one in the distribution, but it seems to work fine.
But it generates errors too:
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O ihex lcd-test.elf lcd-test.eep
avr-objcopy: there are no sections to be copied!
avr-objcopy: --change-section-lma .eeprom=0x00000000 never used
make: *** [lcd-test.eep] Error 1
I don’t know what this is trying to do, or why it’s failing. Any insight?
Are you using a Windows machine or a Linux machine?
If you’re using a Linux (or any UNIX) machine, on a clean unpack of the .zip file, try running “winavr-to-unix” at the head of the directory tree. That should tweak all the makefiles so they’re happy with avr-gcc. There’s more than one gotcha with the makefiles, and the script should catch both. (If it doesn’t, let me know.) The errors you’re seeing look familiar, and make me think that might be the problem.
Looking through the source tree, it looks like every single example in orangutan-examples-0.1.zip is out of date. So to answer your earlier question, err… no. No, it’s not good example code. Dang.
I can’t guarantee I can have a new rev of the examples out tonight. That’s more coding than I was after. But it either needs to be updated or removed.
So here’s the question:
When the whole Orangutan-lib thing started, the idea was to have two separate projects. One was a library of code that could be reused (the library itself). The other was to have some single-file examples to demonstrate some stuff that could be done with the Orangutan without too much pulling of teeth. Fortunately or unfortunately, most of the coding effort went toward the library, and the examples kinda went by the wayside.
I’d still like to offer some one-file examples, especially for folks who are new to programming in general. But if you think having the examples – which don’t use the library at all – is confusing, let me know.
In the meanwhile I’ll at least start bringing them up to date so people don’t get the LCD error you saw and get discouraged.
Thanks again for catching this. It’s been a while since I’ve looked at the examples.
Yes, I caught that in the readme file after my post, and ran it. It does change the definition of CC, but at least on the lcd-test makefile, it doesn’t change anything else (I checked). And I still get the avr-objcopy errors (I tried several different examples after running winavr-to-unix, and they all produce the same errors).
What is this avr-objcopy step trying to do? I suspect that it’s trying to install the file onto the device, since that would seem to be all that’s left after the hex file is generated. I install files with avrdude. Perhaps the makefiles are not set up to work with that?
We once got an error like this when we had incompatible versions of WinAVR and AVR Studio running. If I recall correctly, it happened when I updated my WinAVR without also updating AVR Studio; the new WinAVR was outputting files that were not compatible with older versions of AVR Studio. Updating my AVR Studio fixed the problem.
I’m not sure what your setup is like on a Mac, but it could be a compatibility issue for you as well, or maybe just a bugged version of WinAVR. I would suggest first making sure you have the latest versions of whatever you’re using and if that doesn’t work, perhaps try rolling back to earlier versions.
You also might find some good information if you google “change-section-lma .eeprom=0x00000000 never used”.
Well, it certainly can’t be the latter – WinAVR runs only under Windows. I do have the latest version of all the tools, but I don’t think earlier versions would work any better. I know that orangutan-lib is developed under WinAVR, so I think there’s something in the makefile that’s still not compatible with the gcc/avrdude toolchain.
That’s a good idea. This post suggests that it may be a bug in avr-binutils. Hmm.
Actually, yeah, I think Ben nailed it. Those makefiles were generated by an older version of AVR Studio. What version of avr-gcc are you running?
The next to most recent version of avr-gcc had some changes that required an upgrade of AVR Studio to a beta version. The earlier version of AVR Studio generated makefiles that caused problems with the newer version of avr-gcc. Now there’s an even newer version of avr-gcc out, but I expect the behavior would be the same.
At one point I upgraded my copy of AVR Studio and WinAVR (the Windows port of avr-gcc), but that caused problems with people running the older rev of AVR Studio, so I went back to the last stable release of Studio and the compatible version of WinAVR.
If you’re running the latest greatest, I’m guessing the makefiles aren’t happy. Shoot.
As for the other stuff the winavr-to-unix script does, you’re right. It only makes the one change in the makefile (avr-gcc.exe -> avr-gcc). But it also deletes some files that AVR Studio generates that caused me grief when building on a Linux machine.
One of the guys in our local club also runs on OSX, so I’ll get with him and try out all three toolchains (OSX, Linux, Windows/Studio). There’s got to be a happy middle ground that’ll let it work on all three platforms.
Any chance you’ve got Subversion installed on your Mac? The source tree for Orangutan-lib is a Subversion tree that’s available on Sourceforge. Fair warning, I really do check in broken stuff sometimes, so it’s not the best way to have a working development environment. But it’s the quickest way to catch bugs.
Heh! Yep, I’m running avr-gcc 3.4.6. So it’s likely a version incompatibility with the makefiles AVR Studio spit out.
I’ll go ahead and upgrade my toolchain for Windows and Linux and roll a new set of makefiles. I’m pretty sure OSX and Linux environments are quite similar, so I’ll test with the latest version of avr-gcc and let you know how it goes.
