AVR-Chat

I agree with john, use the newer chips 48/88/168/328 all can be used with
the same footprint, plenty of scope for future proofing.
 
Regards
 


[Non-text portions of this message have been removed]

Hi all,

I've got a program that sends MIDI on an ATtiny2313.

http://ringbreak.dnd.utwente.nl/~mrjb/electro/midisender.c

I've also got a make file, as follows:
CC=avr-gcc
#HEADERS=-I /usr/src/linux-headers-2.6.24-19/include/asm-avr32/
CFLAGS=-g -Os -Wall -mcall-prologues -mmcu=attiny2313 $(HEADERS)
#CFLAGS=-g -Os -Wall -mcall-prologues -mmcu=atmega8 $(HEADERS)
OBJ2HEX=/usr/bin/avr-objcopy
UISP=/usr/local/bin/uisp
TARGET=midisender

program : $(TARGET).hex
         avrdude -c usbtiny -p m8 -e
         avrdude -c usbtiny -p m8 -U flash:w:$(TARGET).hex:i
%.obj : %.o
         $(CC) $(CFLAGS) $< -o $@

%.hex : %.obj
         $(OBJ2HEX) -R .eeprom -O ihex $< $@

clean :
         rm -f *.hex *.obj *.o

I want to use the code with an ATmega8 and have hooked up the
ATmega8 appropriately.

Now for the strange thing: I compiled the source with the
above makefile (for the wrong microcontroller: attiny2313) and
ran it on the ATmega8. It ran just fine.

I then proceeded to add ADC code and found out the Makefile was
wrong. To make sure all was still working, I removed the ADC code
again and compiled for ATmega8. No MIDI output. I commented the
ATmega8 line and restored the ATtiny2313 options, recompiled it
and wrote it to the ATmega8- it worked.

So if I compile it for ATtiny2313 and run it on ATmega8 it works.
But if I compile for ATmega8 and run the same code on ATmega8, I
get no MIDI output.

I'm baffled. Why does my code not work on ATmega8 if I compiled
for the ATmega8?

Thanks in advance,
Marc

On Dec 5, 2009, at 3:14 PM, Marc R.J. Brevoort wrote:

> Hi all,
>
> I've got a program that sends MIDI on an ATtiny2313.
>
> http://ringbreak.dnd.utwente.nl/~mrjb/electro/midisender.c
>
> I've also got a make file, as follows:
> CC=avr-gcc
> #HEADERS=-I /usr/src/linux-headers-2.6.24-19/include/asm-avr32/
> CFLAGS=-g -Os -Wall -mcall-prologues -mmcu=attiny2313 $(HEADERS)
> #CFLAGS=-g -Os -Wall -mcall-prologues -mmcu=atmega8 $(HEADERS)
> OBJ2HEX=/usr/bin/avr-objcopy
> UISP=/usr/local/bin/uisp
> TARGET=midisender
>
> program : $(TARGET).hex
> avrdude -c usbtiny -p m8 -e
> avrdude -c usbtiny -p m8 -U flash:w:$(TARGET).hex:i
> %.obj : %.o
> $(CC) $(CFLAGS) $< -o $@
>
> %.hex : %.obj
> $(OBJ2HEX) -R .eeprom -O ihex $< $@
>
> clean :
> rm -f *.hex *.obj *.o
>
> I want to use the code with an ATmega8 and have hooked up the
> ATmega8 appropriately.
>
> Now for the strange thing: I compiled the source with the
> above makefile (for the wrong microcontroller: attiny2313) and
> ran it on the ATmega8. It ran just fine.
>
> I then proceeded to add ADC code and found out the Makefile was
> wrong. To make sure all was still working, I removed the ADC code
> again and compiled for ATmega8. No MIDI output. I commented the
> ATmega8 line and restored the ATtiny2313 options, recompiled it
> and wrote it to the ATmega8- it worked.
>
> So if I compile it for ATtiny2313 and run it on ATmega8 it works.
> But if I compile for ATmega8 and run the same code on ATmega8, I
> get no MIDI output.
>
> I'm baffled. Why does my code not work on ATmega8 if I compiled
> for the ATmega8?
>
> Thanks in advance,
> Marc
>
> 
What compiler and what IDE?

Jim Wagner
Oregon Research Electronics

[Non-text portions of this message have been removed]

On Sat, 5 Dec 2009, Jim Wagner wrote:

>> I've also got a make file, as follows:
>> CC=avr-gcc
>> [snip]

> What compiler and what IDE?

As the Makefile shows, the compiler is avr-gcc.
I'm not using an IDE.

Best,
Marc

Hi,

To answer my own question- it seems like the cause
is a possible bug in the avr-gcc toolset in file

/usr/avr/include/avr/iom8.h

This file states

#define UCSRC	_SFR_IO8(0x20)
#define UBRRH	_SFR_IO8(0x20)

(Twice the same definition for different ports?
Suspicious...)

To make ATmega8 USART functionality work for avr-gcc,
I changed these two lines to the following:

#define UCSRC   _SFR_IO8(0x03)
#define UBRRH   _SFR_IO8(0x02)

After these changes, I can compile my code (which
used to work on ATtiny2313) with -mmcu=atmega8 and
it will work on the ATmega8.

Hope this helps someone!

Best,
Marc

If I recall correctly, those two DO share the address and require a  
data bit to distinguish which is which. It is NOT a compiler error.

Jim Wagner
Oregon Research Electronics
On Dec 6, 2009, at 9:34 AM, Marc R.J. Brevoort wrote:

> Hi,
>
> To answer my own question- it seems like the cause
> is a possible bug in the avr-gcc toolset in file
>
> /usr/avr/include/avr/iom8.h
>
> This file states
>
> #define UCSRC	_SFR_IO8(0x20)
> #define UBRRH	_SFR_IO8(0x20)
>
> (Twice the same definition for different ports?
> Suspicious...)
>
> To make ATmega8 USART functionality work for avr-gcc,
> I changed these two lines to the following:
>
> #define UCSRC _SFR_IO8(0x03)
> #define UBRRH _SFR_IO8(0x02)
>
> After these changes, I can compile my code (which
> used to work on ATtiny2313) with -mmcu=atmega8 and
> it will work on the ATmega8.
>
> Hope this helps someone!
>
> Best,
> Marc
>
>
> 



[Non-text portions of this message have been removed]

Jims right,
 
these 2 defines do share the same location, when accessing the UCSRC Reg you
set the the ursel bit in the register when writing to the UCSRC else you are
writing to the UBBRH register .
 
Regards

  _____  

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Marc R.J. Brevoort
Sent: 06 December 2009 18:31
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] avr-gcc ATMega8 USART trouble, was: Compile problem


  

On Sun, 6 Dec 2009, Jim Wagner wrote:

>> #define UCSRC _SFR_IO8(0x20)
>> #define UBRRH _SFR_IO8(0x20)
> If I recall correctly, those two DO share the address and require a
> data bit to distinguish which is which. It is NOT a compiler error.

Thanks for your input, Jim.

I originally used the USART C code from the data sheet,
which worked fine with ATtiny2313.

The C code in the data sheet for the ATmega8 is identical,
and as such I'd expect the program to port cleanly between
these microcontrollers by simply specifying a different
-mmcu flag.

Strangely, the code didn't work on atmega8 as soon as I
specified -mmcu=atmega8, but it did when I specifield
-mmcu=attiny2313.

After the changes that I outlined in my previous post,
the code ports and works transparantly on either uC, as
I would have expected.

If the ATmega8 would need setting a data bit to
distinguish between UCSRC and UBRRH, then my proposed
change to the header file would not have made it work;
this evidence suggests that there was, in fact, a bug
in the mentioned header file.

As the ATmega8 *does* send data through the USART now,
I wonder if I'm overlooking something trivial?

Best,
Marc





[Non-text portions of this message have been removed]

On Sun, 6 Dec 2009, Jim Wagner wrote:

>> #define UCSRC   _SFR_IO8(0x20)
>> #define UBRRH   _SFR_IO8(0x20)
> If I recall correctly, those two DO share the address and require a
> data bit to distinguish which is which. It is NOT a compiler error.

Thanks for your input, Jim.

I originally used the USART C code from the data sheet,
which worked fine with ATtiny2313.

The C code in the data sheet for the ATmega8 is identical,
and as such I'd expect the program to port cleanly between
these microcontrollers by simply specifying a different
-mmcu flag.

Strangely, the code didn't work on atmega8 as soon as I
specified -mmcu=atmega8, but it did when I specifield
-mmcu=attiny2313.

After the changes that I outlined in my previous post,
the code ports and works transparantly on either uC, as
I would have expected.

If the ATmega8 would need setting a data bit to
distinguish between UCSRC and UBRRH, then my proposed
change to the header file would not have made it work;
this evidence suggests that there was, in fact, a bug
in the mentioned header file.

As the ATmega8 *does* send data through the USART now,
I wonder if I'm overlooking something trivial?

Best,
Marc

> When code was compiled for atmega8 AND ran on an atmega8,
> it simply did not work (until I hacked iom8.h).
When you (incorrectly) modified iom8.h, you disguised the problem.  The addresses that you changed to in iom8 refer to the TWI hardware on the mega8 but they do refer to UCSRC and UBRRH (separate registers) in the tiny2313.  With that change, your code compiled for the mega8 is no longer clobbering the UBBRH register.  That is probably why it appears to be working correctly.

You should always take the example code in the datasheets as a general suggestion rather than guaranteed-to-work code.  Further research is always necessary to confirm that the code is correct and complete.  I've seen many complaints about cases where it appears that example code was simply copied from one datasheet to another without consideration for differences in the underlying hardware or was simply incorrect due to human error.

Reading the special sub-section of the mega8 datasheet USART section entitled "Accessing UBRRH/UCSRC Registers" reveals what you need to do:
UCSRC = (1<<URSEL) | flags;

Without the URSEL bit, you'd actually be writing to the UBBRH register rather than the UCSRC register as desired.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

On Sun, 6 Dec 2009, Steven Holder wrote:

> Jims right,
>
> these 2 defines do share the same location, when accessing the UCSRC Reg you
> set the the ursel bit in the register when writing to the UCSRC else you are
> writing to the UBBRH register .

All right, if that's the case, I stand corrected.
So even though I have something that works right now,
it is not the correct way to solve the problem.

Of course, then, the next question is: If the
datasheets for ATtiny2313 and ATmega8 show identical
example code for USART_Init, what else is needed to
make this example code work on both ATtiny2313 and
ATmega8? I have verified the resulting assembly code
for ATtiny2313 and ATmega8, and the only difference
was in the way USART_Init was compiled for the
previously mentioned registers. When code was
compiled for atmega8 AND ran on an atmega8, it
simply did not work (until I hacked iom8.h).

Suggestions?

Best,
Marc

On Sun, 6 Dec 2009, Don Kinzer wrote:

> Reading the special sub-section of the mega8 datasheet
> USART section entitled "Accessing UBRRH/UCSRC Registers"
> reveals what you need to do:
>
> UCSRC = (1<<URSEL) | flags;
>
> Without the URSEL bit, you'd actually be writing to
> the UBBRH register rather than the UCSRC register as desired.

Thanks Don, I'll give that a try.

Best,
Marc

On Mon, 7 Dec 2009, Marc R.J. Brevoort wrote:

>> Reading the special sub-section of the mega8 datasheet
>> USART section entitled "Accessing UBRRH/UCSRC Registers"
>> reveals what you need to do:
>>
>> UCSRC = (1<<URSEL) | flags;
>>
>> Without the URSEL bit, you'd actually be writing to
>> the UBBRH register rather than the UCSRC register as desired.
>
> Thanks Don, I'll give that a try.

Works like a charm!

Thanks again,
Marc