AT90USB1287 Need IO Header File

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

I am trying to program my USB1287 in AVRStudio and none of the register defines work. I cannot set timers, ubrr, or anything.

I looked at io.h and it pointed me to iousb1287.h which has generic port descriptions (I can blink LED's fine) but their are none of the usual register defines as in other io headers!

For example from iom128.h:

/* USART0 Baud Rate Register Low */
#define UBRR0L    _SFR_IO8(0x09)

I could put them all in manually but my gods it would take a while. If their an update file I can download?

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

That's really weird. Where do these include files originate? I had assumed they were all from Atmel, but apparently not (who's Anatoly Sokolov?).

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

iousb1287.h includes iousbxx6_7.h and the all-wise have ordained that the single UART on that chip shall be called UART1.

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

Looks like all the meat is in iousbxx6_7.h which is included by iousb1287.h.

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

And, *drum rolls*, surprise, surprise, the datasheet (hint, hint), calls the USART USART1, too.

Quote:
If their an update file I can download?
Download the datasheet and read it.

Stealing Proteus doesn't make you an engineer.

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

Quote:

in AVRStudio and none of the register defines work.

So, then you mean you are using Atmel's AVRASM2 to do your development?

[AVRStudio isn't a C compiler. It doesn't have a C compiler. It can integrate with some C compilers.]

Did you mean you are using the WinAVR flavour of GCC for AVR targets? Then perhaps you should ask these embarrassing questions in their very own GCC forum and not air the dirty laundry here for all to see. Well, the price was right; G,FN.

[It sure would help, I think, to know the compiler version being used. perhaps it is a stub file from several years ago when the model was new?]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
And, *drum rolls*, surprise, surprise, the datasheet (hint, hint), calls the USART USART1, too.

While I often see it motivated to slap noobs slightly with the "read the sheet" remark, I think this specific case is tougher. Looking through my copy of the sheet for "USART1" finds it in 26 instances
- The block diagram on p5 (1)
- As part of the register bit name PRUSART1 in the section on power reduction (6)
- The interrupt vector table (6)
- The section on alternate port functions (9)
- The register summary (4)
Not in a single place in the USART section per se is there a note, warning, heads-up or whatever you'd like to call it that mentions this strange, illogical naming. While Atmels AVR data sheet are generally of a very high standard IMO, here they slipped slightly.

Granted, a search for just "USART" would have revealed the unfortunate naming.

Anyone have a rational explanation for naming it USART1, totally side-stepping the naming scheme for all other AVRs I've seen?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

With a quick look I only find 18 references to USART1. Still, I'd call that more than a hint. And all USART-related registers either have a placeholder 'n' or a '1' in the name. Never is there a 0.

And please note

Quote:
none of the register defines work. I cannot set timers, ubrr, or anything.
Non of the register defines work? Yeah, sure. Read the datasheet, instead of copying some random code "found" on the Internet.

JohanEkdahl wrote:
Anyone have a rational explanation for naming it USART1, totally side-stepping the naming scheme for all other AVRs I've seen?
USARTs on PORTD on other Atmegas (e.g. mega128) are called USART1, too.

Stealing Proteus doesn't make you an engineer.

Last Edited: Wed. May 26, 2010 - 09:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who lay off the guillotine eh I have read AVR chip datasheets many dozens of times but this was a random case of none of the register defines working for just this one chip.

I'm well aware of the naming convention they use and for example here is the code that did not work (directly out of this mysterious manual I didn't read)

#include 

void USART_Init( unsigned int baud ) {
	/* Set baud rate */
	UBRR1 = (unsigned char)baud;
	/* Enable receiver and transmitter */
	UCSR1B |= (1<<RXEN1)|(1<<TXEN1);
	/* Set frame format: 8data, 1stop bit */
	UCSR1C |= (3<<UCSZ12);
}

void USART_Transmit( unsigned char data ) {
	/* Wait for empty transmit buffer */
	while ( !( UCSR1A & (1<<UDRE1)) );
	/* Put data into buffer, sends the data */
	UDR1 = data;
}

unsigned char USART_Receive( void ) {
	/* Wait for data to be received */
	while ( !(UCSR1A & (1<<RXC1)) );
	/* Get and return received data from buffer */
	return UDR1;
}

int main() {
	USART_Init(207);  // 2400bps

	for(;;) {
		tmp = USART_Receive();
		USART_Transmit(tmp);
	}

	return 0;
}

The problem was that none of the defines (UBBR1, UCSR1A/B/C, UDR1, etc) where recognized and my io include file had no other inclusions which is why I posted a problem.

I have put an include line in the usb1287's header file to include iousbxx6_7.h and now everything works as expected.

Calm discussion solves problems be they valid problems or noob errors. If you don't want to reply to something you think is simple and a RTFM will fix then please don't troll your own form.

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

So the question becomes, why didn't your copy of iousb1287.h contain the include of the other file? Is your AVR Studio up to date?

FYI, here is the section from iousb1287.h that includes the other file:

/* $Id: iousb1287.h,v 1.2.2.5 2008/10/17 23:27:53 arcanum Exp $ */

/* avr/iousb1287.h - definitions for AT90USB1287 */

#ifndef _AVR_AT90USB1287_H_
#define _AVR_AT90USB1287_H_ 1

#include 

/* Constants */
#define SPM_PAGESIZE 256
#define RAMEND       0x20FF
#define XRAMEND      0xFFFF
#define E2END        0xFFF
#define E2PAGESIZE   8
#define FLASHEND     0x1FFFF
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'd call that more than a hint.

My point was that there where no such hints in the USART section of the sheet. And if you don't know that you should look for USART1 instead of USART0 then it gets harder (but not necessarily very hard).

Quote:

And all USART-related registers either have a placeholder 'n' or a '1' in the name. Never is there a 0.

So what? Why should the fact that the USART is named "USART1" be revealed only by inspection of register- and/or register-bit-names? What stopped Atmel from naming the USART section "USART1"? Other sheets (not necessarily all) have their only USART section named "USART0".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
So what? Why should the fact that the USART is named "USART1" be revealed only by inspection of register- and/or register-bit-names?
Why not? You want to work with a register, inspect the register name. Don't guess it.

Quote:
What stopped Atmel from naming the USART section "USART1"?
Money.
Quote:
Other sheets (not necessarily all) have their only USART section named "USART0".
Since the beginning of time Atmel uses generic periphery descriptions. The same description gets either copied or included in several datasheets. Which saves them money. The USART section is such a generic section, only using the placeholder 'n'.

Stealing Proteus doesn't make you an engineer.

Last Edited: Wed. May 26, 2010 - 09:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason I knew about it was I tried UART0 on my RZUSBSTICK and then had to drill down to see why it didn't work. Who among us has the excess brain capacity to read all the data sheets AHEAD of time!

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

No matter what they choose to call the USART if your looking in the datasheet and see UCSRnB and you are unsure if it should be UCSR0B, UCSR1B or UCSRB you just go down to the Register Summary page and you find out what it is suppose to be called. Easy provided you have read past the peripheral descriptions and know their is a register and instruction set summary.

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

I do however have a problem with the code above.

I have the usb1287 hooked up to JTAG in debug mode and autostep. As expected the program waits on while ( !(UCSR1A & (1<<RXC1)) ); in the receive function. I can press a key in the terminal and the debug will continue through the transmit. In the transmit function I have UDR1 = 0x41; which is an A back to the PC.

The problem is UDR1 remains empty on receive and transmit. The RXC1 and TXC1 flags work as expected the data is just not being read/written to the register or something. Anybody know whats up with that?

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

Quote:

The USART section is such a generic section, only using the placeholder 'n'.

Simply not true for all sheets, so it seems that Atmels choice to save or waste money is wobbly..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

frostblu3710 wrote:

The problem is UDR1 remains empty on receive and transmit. The RXC1 and TXC1 flags work as expected the data is just not being read/written to the register or something. Anybody know whats up with that?

What JTAG debugger are you using?

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

I am using the Dragon for JTAG and debugging.

Running the program normally I send any character between 0 and J and I get a 0x80 in response anything else and I get no response at all.

The debugger shows it stepping through the code on any character send but watching the contents of UDR1 it never changes from 0x00.

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

I have no clue, maybe smarter people will respond :)

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

Quote:

watching the contents of UDR1 it never changes from 0x00.

The view in the debugger is the transmit holding register, not the receive register. You will only see a value in UDR1 for one opcode after UDR1=n, the byte is then transferred into the internal buffer register and UDR1 shows 0x00 again. To see the UDR1 receive register you need to read it into a CPU register then inspect that with the debugger (the likelihood is that your polling or interrupt receive routine is going to be doing this anyway - so just breakpoint after UDR1 has been collected into Rn