Hi, I have recently switched over to a Mac, and something weird is happening. This would never happen when I was using Windows. When I go to the Terminal, and type make, I get the following error:

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

I am really weirded out. I have rebuilt the NerdKit following the directions in the guide several times, and the error would not go away. I have also switched USB ports, but it would not help. Should I change the /dev/cu.PL2303-191 to /dev/tty.PL2303? Any help is appreciated.

Hi n1cl3,

Change the makefile to whatever it is listed in the /dev directory. If both are present, try both. If that doesn't work, try the driver that is referenced in this thread.

If that doesn't work, try adding a delay between the read and write cycles in your Makefile discussed in this thread. A lot is discussed there, the fix to the makefile is suggested by mrobbins on January 25th. Hopefully one of those things get you going!

Humberto

I was having this problem on linux, and the above suggestions didn't help. I found the oddest thing that does help, I'll add it here in case any other linux users are looking.

change

        AVRDUDEFLAGS=-c avr109 -p m168 -b 115200 -P /dev/ttyUSB0

to

        AVRDUDEFLAGS=-v -v -v -v -c avr109 -p m168 -b 115200 -P /dev/ttyUSB0

for some reason, after getting the error and making the above change, then a power cycle. all is good.

hope it helps somebody

Thanks for the help, but neither of these work! Is there a particular reason it wouldn't work on a white iBook G3?

Humberto,

Does it matter if the USB header is plugged into a USB port that is USB 2.0 or 1.1? That could be the problem.

-Dan

Both the ports are the same, USB 2.0.

In the Mac Control Panel, check out your communication settings. There may be something there that is jacking you up.

BM

There doesn't seem to be anything unusual there. Perhaps it is a problem with the chip or cable? The same hardware worked when I was using window$, so I think it may be the OS.

Thanks to tooth. Your linux suggestion worked for me.

I had this same issue on Linux, where AVRDude went through the read cycle without error, but failed on the write cycle. This fix allowed the Make script to complete without error. Yay! However, when I switch back to "run" mode, and power-cycle, I'm only getting the last line of the welcome message at the top of the LCD (" is alive! "). Using all standard code from a fresh Nerdkit example install, and only modifying the AVRDUDEFLAGS of the Makefile to include the "-v -v -v -v" at the beginning. Hmmm Any ideas?

Ok, found this thread: http://www.nerdkits.com/forum/thread/2118/#post18932

Disabling the make optimizations fixed the problem (changing -oS to -o0 in the Makefiles for libnerdkits and initialload, deleting the .o and .hex files, then remaking).

Then making the change suggested to lcd.c and re-enabling the optimizations also worked.

That thread references it as an issue on MacOS, but also an issue on Linux (with avr-gcc v.4.7.2).

Working again! Yay! Thanks everyone for posting solutions!

I'm trying to switch over to Linux, and am getting mixed up in what the makes files should be and the changes I need to make to get the LCD to workd correctly. I'm getting the 'butterfly_recv(): programmer is not responding' problem then when I add the "-v -v -v -v" the comand window goes crazy but seems to work. any help?

Use current or near current versions of the tools. I use avrdude 6.0.1 and avr-gcc 4.8.1. The toolchain I downloaded from Atmel is version 3.4.3.

Giving all those -v's to avrdude just tells it to log lots of information. The result should still be the same but maybe you don't see the error message with all the extra stuff displayed.

I haven't used the nerdkits bootloader in a long time but as I recall the driver for their usb cable is already in linux so about all it could be is specifying the correct tty (/dev/ttyUSB0?) and baud for avrdude. When I have trouble like this I just run avrdude in terminal mode instead of using the make file until I get it figured out. It's a lot easier for me to hit the up arrow and change the command line than editing the make file to try a different tty or baud.

You can also use the command

dmesg | grep tty

to list tty devices and see which one has pl2303 associated with it.

Last night I got it to work, but I’m not sure if it’s because I updated avr-gcc because I don’t think I did it correctly but I did change the ‘-oS to -o0 in the Makefiles’ which I tried before but maybe not correctly. I was in the mists of XP Linux change over so I had files everywhere and wasn’t doing a good job keeping things straight. Now when I get home I will straighten everything out and be back calibrating the torque wrench. Thanks every one

One last thing with the Linux switch over, I used to have all the #inlcudes at the top of each program put into one .h file then I would just include that file so when it compiled it would essentially copy the

define F_CPU 14745600

include <stdio.h>

..

..

..

into the file so I would not have to see it in each program file when I was developing code, I would also make some functions and put them in another .h file just to make my code not so long. Anyways I cant seem to get this to work, for example. Here is the Lib.h file:

#define F_CPU 14745600

#include <stdio.h>

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/io_328p.h"

and the initial load program calling it:

inlcude "Lib.h"

// PIN DEFINITIONS:
//
// PC4 -- LED anode

int main()
{

    // LED as output
    DDRC |= (1<<PC4);

    // turn on LED
    PORTC |= (1<<PC4);

    // fire up the LCD
    lcd_init();
    lcd_home();

    // print message to screen
    //           20 columns wide:
    //                     01234567890123456789
    lcd_line_one();
    lcd_write_string(PSTR("  Congratulations!  "));
    lcd_line_two();
    lcd_write_string(PSTR("********************"));
    lcd_line_three();
    lcd_write_string(PSTR("  Your USB NerdKit  "));
    lcd_line_four();
    lcd_write_string(PSTR("      is alive!    "));

    // turn off that LED
    PORTC &= ~(1<<PC4);

    // busy loop
    while(1);

    return 0;
}

Looks ok, what is the error you are getting?

I had to make some changes to the make file as mentioned abouve but here are the error message:

make -C ../libnerdkits
make[1]: Entering directory `/home/garrett/Downloads/Code/libnerdkits'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/garrett/Downloads/Code/libnerdkits'
avr-gcc -g -Os -Wall -mmcu=atmega328p -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm -o initialload.o initialload.c ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o Lib.h
initialload.c:8:2: error: invalid preprocessing directive #inlcude
make: *** [initialload.hex] Error 1

and the current make file, although it works when I just insert the stuff in the Lib.h

GCCFLAGS=-g -O0 -Wall -mmcu=atmega328p
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm
AVRDUDEFLAGS=-c avr109 -p m328p -b 115200 -P /dev/ttyUSB0
LINKOBJECTS= ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o Lib.h

all:    initialload-upload

initialload.hex:    initialload.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o initialload.o initialload.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex initialload.o initialload.hex

initialload.ass:    initialload.hex
    avr-objdump -S -d initialload.o > initialload.ass

initialload-upload: initialload.hex
    avrdude ${AVRDUDEFLAGS} -e
    sleep .5
    avrdude ${AVRDUDEFLAGS} -D -U flash:w:initialload.hex:a

include not inlcude

computer are so picky

Lib.h is not a link object.

scooter--

Just a note, regarding includes (like for FPU)... put your #define after the system includes. That way if it's defined by a system include, you will override it with your own.

In other words:

#define F_CPU 14745600                 // This line...

#include <stdio.h>

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <inttypes.h>

// <-- should be moved here

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/io_328p.h"

BM

F_CPU is not defined in any system includes. I put my definition of F_CPU and others like it on the avr_gcc command line in the make file which comes before anything else in the sequence.

A good habit to acquire is to look at all warning messages from a build so you will be aware of redefinitions and anything else that may prevent your code from working as expected. I like to fix my code so there are not even warnings which makes a good clean compile.

@Noter: That is true, but what I'm suggesting is a good rule of thumb. Local defines should normally follow foreign defines. There are good reasons for this. I just reference the one variable because it was in the example code.

BM

But it's not a good rule of thumb.

Take this case specifically, F_CPU is used by <delay.h> so it needs to be defined before the include. If <delay.h> is not used then it doesn't matter but it's a good habit to always put it first.

A good rule of thumb is to fix your code so there are no warnings. Even if you choose not to do that, at least review warnings so you will always be aware of potential problems.

@Noter,

delay.h is not a rule, it's an exception. If you note, I said 'generally'. I did not say in every case. The reason I say this is because C compilers (all of them) operate in a serial fashion.

What that means is that if you do all your defines ahead of your includes, you may not get what you're expecting if an include ends up redefining a constant, a variable, a function, a macro, or something else in your code.

Most non-assembly-language compiled-language developers assume they are writing code for a given chip. They're not. They are writing a text file with a very specific grammar for a compiler. The idea being that they can communicate with the compiler well enough that they can control how it outputs the code for the chip.

BM

I'm just speaking from experience, decades of coding under my belt, and I have never come across a situation where defines ahead of includes created a problem of any sort so I don't see the reason for your general rule. It is more likely to create problems for less experienced coders if they are not aware of specific requirements like F_CPU where the define must precede the include and they haven't yet developed the habit of looking at compiler warnings. For that matter, all includes that allow customization via defines require the user define ahead of the include file.

The only way to know if you have overridden or attempted reuse of a system value is to look at warming messages produced by the compiler. I think we can agree that it's not good to have these conflicts so look at those warnings and work the code until they are all gone. That's the best rule of thumb.

Noter,

Did you just get up on the wrong side of the bed? I thought I was very reasonable. I didn't say in every case.

You yourself admitted your experience is limited, because you've never run into such a situation. Accept that fact. It isn't because you've seen it all and done it all. It's because you haven't.

You can argue that point, but you'll just be arguing with yourself.

BM

Gee, I didn't think we were arguing. You may be very reasonable but the fact is there is not even one case where it's a good idea to put defines after includes simply to avoid potential conflicts. That's the point I am making.

So regardless of qualifications, if you can describe an example to demonstrate where your general rule is useful I for one will be happy to see it otherwise clearly you are joking or something.

Noter,

I think you're still missing my point. My point, stated another way is this-- the order in which you place your front-end framework (constants, typedefs, enums, etc) and includes, determines how things are overridden. You may not find this valuable or useful, but it is. This isn't a simple case of 'avoiding potential conflicts'. That isn't what I'm talking about.

For your example, this is in fact how C++ was originally introduced on C-only compilers. A second example is that C was in fact designed to allow this ability to redeclare and redefine things as needed to override supplied code, to ensure total flexibility.

And contrary to what you think, not all compilers give all warnings; and not in every case is it possible to remove all warnings. That's just reality.

BM

That's odd, how do you know what I think about all compilers and warnings in every case? Are you a mind reader?

Yes, I agree, I am missing your point. Can you give a simple example from your past where you used your general rule? Something like name, include file, override value, and what it accomplished. I'm sure that would drive home your point.

If not that is okay because at this point I don't think you know what you're talking about anyway. But you probably already know that since you are a mind reader.

LOL!

Noter,

No point in responding, further to thsi. You're not interested in what I'm saying, you just want to be right. Sad.

BM

The sad part is you don't know how to discuss without telling others (me in this case) what they are thinking, have done, or, as of now, are interested in. Well you have been wrong on all counts, and most importantly I do want to see your example if you can provide one. Just so you don't guess, I don't think you have an example to drive home your point, thus the end.

For the record for everyone else, I wrote 'And contrary to what you think' and actually meant to write 'And contrary to what you may think'. Based on Noter's repeated statements about compiler warnings.

What I'm discussing is typical and well understood in the industry. Pascal Stang relied on this technique, as do most professional developers. Look at your own AVRLib includes, and you'll find many examples in the headers where they tell you not to modify what is in a header, but rather redefine and redeclare things in your own local header files to override what the library presents (uart.h is just one example). As such this is, as I tried to explain earlier in this thread, a defacto example that the order in which you define and include and declare things does in fact matter, and there is generally a proper hierarchy/order to do it in. Which is all I was trying to express. delay.h is an anomaly, due to the multi-target nature of the library, and this is why clock frequency (if not defined on the CLI) must be defined prior to delay.h being included. That doesn't in any way contradict what I've expressed. Among a huge number of other things, I've written compilers, debuggers, profilers, and assemblers for high-level languages like Pascal and C in production and commercial environments for products sold in over 28 countries. So when I offer advice on something in this venue, it isn't a guess or an observation, it's because I understand things at a designer level.

If I have any fault, it is only in that I had a typo, and failed to use the word 'may' in my sentence, in a phrase that is very contemporary in our language.

What was sad to me, was that instead of presenting any argument at all, Noter simply attacked my position, told me it was wrong, tried to school me in good technique, then tried to overwhelm me with 'decades of experience'. I gave him the benefit of the doubt, assuming he'd misunderstood my point. Then, when he devolved to being condescending under the guise of being clever, I realized his true intent and decided that trying for a 3rd time to present examples would also be ignored.

I dislike bully's that try to use force over intellect, and then gloat when they feel they've won. Like others, I now see why NK is dying.

I for one, won't be back. My friends on here know how to reach me privately.

BM