AVR Freaks

So are you running your code in the simulator or not?

Are you serious?!

The AVR has 3 types of memory:

1. RAM - where your variables, stack, etc, go;
2. Flash - where your code goes;
3. EEPROM.

EDIT

EDIT 2

typo

#AVRMemories #AVRArchitecture

That's one of the fundamental tools of the AS7 debugger - in fact, of any debugger.

I think you need to spend some time reviewing the documentation and available tutorials for Atmel Studio ...

There's a whole load of resources - including videos - linked from the Atmel Studio pages on the Atmel & Microchip websites.

EDIT

To get you started: https://www.google.co.uk/search?q=atmel+studio+inspect+memory

There used to be a 'terminal' program in AS, but it was never any good!

You can only use a terminal program(see list above) with real hardware, not with a simulator.

It will require some interface hardware as well, most likely a USB to serial TTL cable like this: http://www.ebay.com/itm/USB-To-R...

Note this has TTL outputs, not RS-232 outputs, you also need one in which the TTL signal levels match your VCC level, either 3.3v or 5.0v, the cables come in both versions, use the correct one for your project.

These will create a COM port when plugged into a PC, set your terminal program to use that COM port, connect the TX,RX and GND pins only to your AVR, like this:

PC - AVR

TX - RX

RX - TX

gnd-gnd

Now you should have serial comms between your PC and your AVR.   NOTE: the AVR needs a xtal in order to have an accurate and stable clock for async comms to work well!

Jim

In case it's not clear what I am suggesting is that in either hardware debugging or simulation you use:

http://www.atmel.com/webdoc/GUID...

If you direct this to the location of "Rx_Buffer" or whatever your UART buffer is called you can immediately see the characters/bytes in the buffer.

You do not need to employ a UART to send them "out" of the AVR or a terminal program to take them "in" and display them.

The memory view in AS7 will let you "see" the buffer contents directly.

Does this AVR have two UARTs then?
.
As to the error, do you know what a "function declaration" is in C and why we need/use them?

In your screenshot in your post #25 you try to use usart_putchar_printf() (in the macro call to FDEV_SETUP_STREAM) before you actually define it.

Swap those two. First the definition, then do the macro call.

Any function must be "seen", either by a definition (i.e. complete implementation) or by its declaration (its definition or just its prototype) before it is being used (referenced). This is absolutely basic C knowledge. IIRC we've advised you in the past to get a C textbook and read. That advice still stands.

+1 .

Never ignore warnings. Just because they are warnings (rather than errors) does not mean they are always benign.

Try actually reading the data sheet. The datasheet for atmega 64 tells you that it has two UART so it has UCSR0A and UCSR1A. Equally it has UDR0 and UDR1. 

two things:

1) you do know there is a user manual?

http://www.nongnu.org/avr-libc/u...

2) so what you are looking at has to be read in context:

#if defined(__DOXYGEN__)
/**
   \brief Setup a user-supplied buffer as an stdio stream

   This macro takes a user-supplied buffer \c stream, and sets it up
   as a stream that is valid for stdio operations, similar to one that
   has been obtained dynamically from fdevopen(). The buffer to setup
   must be of type FILE.

   The arguments \c put and \c get are identical to those that need to
   be passed to fdevopen().

   The \c rwflag argument can take one of the values _FDEV_SETUP_READ,
   _FDEV_SETUP_WRITE, or _FDEV_SETUP_RW, for read, write, or read/write
   intent, respectively.

   \note No assignments to the standard streams will be performed by
   fdev_setup_stream().  If standard streams are to be used, these
   need to be assigned by the user.  See also under
   \ref stdio_without_malloc "Running stdio without malloc()".
 */
#define fdev_setup_stream(stream, put, get, rwflag)
#else  /* !DOXYGEN */
#define fdev_setup_stream(stream, p, g, f) \
	do { \
		(stream)->put = p; \
		(stream)->get = g; \
		(stream)->flags = f; \
		(stream)->udata = 0; \
	} while(0)
#endif /* DOXYGEN */

DOXYGEN is the program that creates the documentation in (1) from this header file. What the above section of code says is that "when parsing this header, if generating the documentation then use the first part, but for building your "normal" AVR programs use the second part". So the #define you referred to is simply a dummy one for documentation purposes. The true definition that is used is:

#define fdev_setup_stream(stream, p, g, f) \
	do { \
		(stream)->put = p; \
		(stream)->get = g; \
		(stream)->flags = f; \
		(stream)->udata = 0; \
	} while(0)

So you create a FILE stream object then use this function to populate the function pointers and flags within it.

As to the difference between the upper case and lower case versions. While there are subtle differences the actual intention is that FDEV_SETUP_STREAM is used in C and fdev_setup_stream() in C++. The latter has to exist because the former uses a feature of C (Named initialisers) that is not in C++

http://c-faq.com/decl/decldef.html