makefile help 'UBRR' undeclared

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i've tried compiling some of the UART code that you guys are working on in other channels, unfortunately i cant generate obj files let alone coff files becuase of the errors i get

i use the sample makefiles from winavr, and i have gotten the LED sample to work on my microcontroller

the problem i get with the UART samples on this forum is this

i first type 'make' and get this

'UBRR' undeclared (first use in this function)
'UCR' undeclared

i thought maybe i was lacking an include statement, but i tried adding anything i could
what gives?
thanks for your help

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tell us the exact type of AVR you're compiling for. I remember having faced the same errors once in the past where using a 90S2333 (i think), where some definitions were lacking from the include files.

-- Thilo

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some AVR models don't have a UCR (rather UCSRx). Some also
don't have a UBRR (rather UBRRH/UBRRL), though I thought the .h
file took care of this(?).

As above: Check the "-mmcu=" option in your build vs. the MCU your
code was (originally) run on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mckenney wrote:
Some AVR models don't have a UCR (rather UCSRx). Some also
don't have a UBRR (rather UBRRH/UBRRL), though I thought the .h
file took care of this(?).

You're right: it should take care of this. If there is a UBRRH/UBRRL pair and there is no corresponding UBRR defined in the header file, then file a bug report to the avr-libc project so it can be added.

mckenney wrote:

As above: Check the "-mmcu=" option in your build vs. the MCU your
code was (originally) run on.

I suspect something like this also.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A certain someone should make sure to look at the spec sheets a little more carefully.
UBRR is undeclared, becuase it does not in fact exist, i do however have UBBRH and UBBRL

i really apologize for asking such an idiotic question
at the same time, i really relaly really really really appreciate all the replies i've gotten, you guys are really out to support AVR users, what a great community

yeah...i think i'm gonna stay here for a while
who needs a pic (just kidding to all you pic users :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

scoot334 wrote:
A certain someone should make sure to look at the spec sheets a little more carefully.
UBRR is undeclared, becuase it does not in fact exist, i do however have UBBRH and UBBRL

Yes, you are correct, according to the data sheet, there is no such thing as UBRR, when there are UBRRH and UBRRL.

As a convenience to the programmer, the maintainers of avr-libc define a 16 bit psuedo-register, UBRR, that covers the same addresses as UBBRH (the High portion) and UBRRL (the Low portion). That way, a programmer can access both registers simultaneously and treat it as a logical, complete value.

If one of the IO header files does not have such a psuedo-register, only when there are High and Low portions available, then it should be added.

But you still haven't mentioned which processor you're using....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EW wrote:

You're right: it should take care of this. If there is a UBRRH/UBRRL pair and there is no corresponding UBRR defined in the header file, then file a bug report to the avr-libc project so it can be added.

Would it be a bug? My guess it's just not possible. UBRRH and UBRRL are not like most 16 bit registers, they typically live in 2 entirely different locations (non-sequential), so the normal 16bit paradigm will not work, without a hack in the compiler. In fact UBRRH is sometimes multiplexed with UCSRC, requiring special bit settings to select which register is being accessed.

The solution here would be to prvide a macro in the header file SET_UBRR(), which would then expand it out to the separate UBRRH and UBRRL ports, or simply redirect it to UBRR for parts that only have an 8 bit UBRR. This of course breaks the conveniance of setting it like any other port or global variable.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:

Would it be a bug? My guess it's just not possible. UBRRH and UBRRL are not like most 16 bit registers, they typically live in 2 entirely different locations (non-sequential), so the normal 16bit paradigm will not work, without a hack in the compiler. In fact UBRRH is sometimes multiplexed with UCSRC, requiring special bit settings to select which register is being accessed.

The solution here would be to prvide a macro in the header file SET_UBRR(), which would then expand it out to the separate UBRRH and UBRRL ports, or simply redirect it to UBRR for parts that only have an 8 bit UBRR. This of course breaks the conveniance of setting it like any other port or global variable.

Duh. Of course you're right. :oops:
I was thinking of the general model of L and H registers being together. I didn't do my homework and look up the specific registers in question. Sorry for the hassle, and thanks for pointing this out.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hehehe, it's easy to forget, as it is different from pretty much all other 16 bit IO registers on the AVR. We can't rember everything ;)

To be honest, I had to look it up as well, to be sure, as I was beginning to doubt myself.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using the ATMega32

i'm sure there's no UBRR, because of UBRRH sharing the same address as UCSRC on the atmega32

i decided to try and get this UART working the old fashion way, with assembly code

i think i'm having trouble with setting my baud rate, or maybe UCSRC isn't getting set up correctly....i don't know, the atmega32 runs at 16 MHz by default, right? so my uc should be running at 16mhz...right?
i used this equation (16mhz)/(16*19200)-1=51.0833, which is 33 hex, so i set UBRRH to 0, and UBRRL to 0x33

but i don't know if UBRRH stays at zero cause i try and set UCSRC, or i dont' know if UCSRC is set correctly because of me trying to set UBRRH

fortunately, I do know that my lcd screen works. i can talk to it using a pc terminal program, with the settings of 19200baud, 8 bits, 1 stop bit, no parity bit, no handshake

i included my assembly code, its very short, can someone take a look at it and help me out, thanks

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for the tip on the fuse bit settings, i found where to set my atmega32 to 8Mhz
so now i have calculated (8*10^6)/(16*19200)-1=25.0417= 0x19hex, and i put that into UBRRL
now i get some strange results, i do get characters on the lcd screen, but not the ones i intend to get

for instance i type i want to send the char 'B' to the screen, and instead of printing 'B', i get '/'

'U' sends correctly, but nothing else does

here is a list of hex values sent to the lcd screen, and hex values of the character displayed on the screen, the stars represent characters i don't know the value for

(42,2F)
(43,5E)
(44,*)
(45,5D)
(46,2E)
(47,*)
(48,*)
(49,5B)
(50,*)
(51,57)
(52,2B)

i would think that by looking at the bit values, a pattern would show up, but i can't figure it out

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two Questions.

Can you successfully write to the LCD directly from your code, not over the serial port?

Can you successfully transmit characters from the AVR to your PC over the serial link, and echo back characters sent from the PC to the AVR back to the PC?

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well, i got my oscilloscope hooked up, and thats telling me some good news
or wait a second, no its not
i can make sense of it when i uart out 0x00, or 0xff , and constantly barage UDR so it never gets a brake

i can see the 10 bits required in a transmit

i tried to constantly send hex 31 to the lcd screen, which the lcd screen displays as if it recieved hex 67

i look at the oscilloscope to see why it might logically see a 0x67, but WTF!!! the scope see something that could neither be 31 or 67

I have one question, for 19200 baud, each bit has a time length of 50microseconds, right?
cause thats what i got

i'm gonna try and use codevision now, my book, which uses it, shows that i can send a whole dang string in like 3 lines of code

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The LSb is sent first with RS232, rather than MSb first. Have you taken that into account when you looked at it on a scope?

And yes, 50us is about right for 19200bps. 52us to be more precise.

/* John Butera */

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

here is an exerp of the codevision code

UCSRA=0x00;
UCSRB=0x18;
UCSRC=0x86;
UBRRL=0x19;
UBRRH=0x00;

printf("\n\rYabba Dabba Do"); // print phrase

the registers are exactly the way i set them up before
i compiled this code and sent it into avrstudio and programmed the chip
it printed out japanese characters, different from what would have printed out in my ASM code manually
i'm gonna break down and cry

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The bit time is 52.083333 microseconds so you are correct.

I used your program with a ATmega32 on my STK-500 and it worked. Hyperterminal displays the ASCII characters. The only change I made was:

   
; Set Baud rate   (8Mhz)/(16*19200)-1=25
   ldi R17, HIGH(25)
   ldi R16, LOW(25)

I have the "Int. RC Osc. 8 MHz; Start-up time: 6CK+ 4ms [CKSEL=0100 SUT=01]" fuse programmed.

The delay you are using will output 13 characters a second. Can your LCD keep up with that?

You are sending all 256 values out the serial port, does your LCD handle non-printable characters? Maybe you should just output the printable characters - 0x20 to 0x7E.

   inc r19
   cpi R19,0x7F  ; go past last character?
   brlo UART_OUT  ; branch if not
   ldi R19,0x20  ; restart with space character
UART_OUT:
   out UDR, r19
   jmp IncrementChar
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I got my scope out and looked at the waveform and got a little puzzled. The timing was off but not enough to cause Hyperterminal problems. I then programmed the Int Osc 4 MHz fuse and changed Hyperterminal's baud rate to 9600 bps and I got no characters. Looked at the bit timing and it was pretty far off.

Completely puzzled, I RTFM'd and saw this in the OSCCAL section

Quote:

During Reset, the 1 MHz calibration value
which is located in the signature row High Byte (address 0x00) is automatically loaded
into the OSCCAL Register. If the internal RC is used at other frequencies, the calibration
values must be loaded manually.

Could your 1 MHz OSCCAL value be so far off for the 8 MHz value? For my part, 1 MHz is 0xBD and 8 MHz is 0xB7. The 4 MHz is 0xB6 so I guess every bit counts. I read these with AVRStudio's STK500 programming utility. It is on the Advanced tab and in the Oscillator Calibration Byte group.

On the scope, does the '1' character look like a 0(start bit),1,0,0,0,1,1,0,0? Is the low time for the start bit the same duration as the high time for the following bit?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, you might want to use a crystal at least to get everything working. I'm thinking that a PC serial port could be more forgiving of a slightly mismatched baudrate than an LCD. Using the internal RC oscillator just adds another variable to the equation. At least with a crystal you know (hopefully) what frequency you're getting.

/* John Butera */

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Stupid me. i forgot that rs232 didn't work with TTL or CMOS logic levels (0-5V)
i knew there was a reason i placed a MAX232 chip on my breadboard way back when and haven't moved it since, now all i have to do is use it!!!!

well, i hope that solves it, cause i've spent way too much time mucking around,
once again, thanks for all the help