Hello,

I cannot get the LCD to write on lines 2-4 using the initialload example. I've even tried using the lcd_goto_position(1, 0) lcd_goto_position(2, 0), and lcd_goto_position(3, 0), but I only ever see the "is alive!" string on line 1 of the LCD - the first three lines never display. Any tips?

Thanks,

Bill

UPDATE:

This initialload example worked on my MacBook Pro. Some notes regarding Arch Linux:

• the original problem occurred on my Arch Linux workstation, fully updated;
• the version of avr-gcc on Arch is 4.6.1;
• I had to hack the header file /usr/avr/include/avr/pgmspace.h per Michal Hlavinka at this site: https://bugzilla.redhat.com/show_bug.cgi?id=737449 (basically insert 'const' keyword)
• I also needed the separate flash command to avr-gcc (-e option), the delay (I used 1 second), and the addition of the -D option (to prevent flashing) on the actual line of the makefile per some suggestions in these forums.

After doing that on my Arch Linux workstation, the program compiled fine, and could write to the microprocessor, but exhibited the strange LCD display I mentioned in the previous post.

Notes for Mac OS:

• version 10.6.8, fully updated;
• avr-gcc version 4.3.0
• installed the latest USB->Serial driver from www.prolific.com version 1.4.0 (file PL2303_1.4.0.zip) for my version of Mac OS; the original does not work from the NerdKit downloads (osx-pl2303-0.3.1-10.4-universal.dmg) since (I'm guessing) it is intended for Mac OS 10.4, and is 32-bit only (I noted in the console log utility that the OS couldn't load the driver since it is 32-bit, and I believe that Mac OS 10.6.8 is 64-bit only - just a guess);
  • still needed the -e option to avr-gcc (flash), the delay, then the -D option mentioned above for Arch Linux.

After doing the above for Mac OS 10.6.8, initialload worked perfectly, so I'm going to try and find an Arch Linux package of avr-gcc version 4.3.0, since there is the known bug regarding the PSTR macro in version 4.6.1.

Mike and Humberto, maybe a good idea would be to provide a link to the prolific web site so that the user can download the correct driver for Mac OS X? That might help others out in the future.

Thanks, and have fun everybody :)

  Bill

Hi Bill,

Thanks for the suggestion. With the release of the new OS X the drivers are still sort of in flux and it is really hard to tell what driver is going to work on what system. We have so far found that most people have the most success with the one we currently link to, however I imagine that will change as more and more people upgrade or get new computers.

Humberto

Hi Humberto,

I'm just now going to try the initialload program on an Arch Linux virtual machine I have on my MacBook Pro just to rule out my Arch desktop causing problems. I'll probably have the same result, but want to make sure. At least building the apps under Mac OS X work, so I'm able to continue with the sample projects. I'll report back later.

P.S. After alot of researching today it does seem that there is a problem specifically with either gcc-avr or binutils-avr (some people aren't quite sure) on Arch systems, so hopefully it'll be fixed soon as I really prefer GNU/Linux for my development environment.

Bill

Update:

The initialload project exhibits the same strangeness using an Arch Linux virtual machine on my MacBook Pro, so I can rule out any problems with my Arch native desktop. There's definitely a problem with the avr compiler/library/tools/etc. under Arch Linux currently, so I'll just have to check again whenever there's any updates. The problems manifests itself as though characters written to the LCD all get shifted up by 3 lines, so all you see is whatever gets written to the 4th line, but appears on line 1 instead. I even removed the -g and -Os options (debugging/optimizations) just to see what would happen.

At least this is noted here so others can reference this if they have the same problem. I'll look into this off and on here and there (would rather hack on my NerdKit than research for hours!!).

Have fun,

  Bill

I've finally tracked down the problem - besides the 'const' keyword needed in the pgmspace.h header file, do this simple thing - delete the object files in the libnerdkits directory (the files delay.o, lcd.o, and uart.o). That's it!!! This will cause them to be rebuilt the next time you run 'make' for a project (since they are pretty much used anytime you use the lcd, time delays, or serial I/O). I'm guessing the existing object files were somewhat incompatible with my system in the state they were in. I should have checked that first thing, but... you know the saying... :-D

Bill

I'm having the same problem, where dose 'const' go in the pgmspace.h file? I'm trying to get on board with Linux but I'm still in frustration mode.

Get current software, Atmel toolchain 3.4.3 or better, and it's fixed already.

Otherwise the compiler will tell you the line that needs the const keyword added. I remember this happened to me after one of upgrades of avr-gcc a while back where I had to add the const keyword in some places in my collection of samples from the web. I don't remember for sure but I think it was all declarations of PROGMEM variables like strings in particular. Just add the const at the begining of the line when the compiler complains about it.