Hey people,
I would like to see what a program is printing on a terminal. Does AS7 have any inbuilt terminals? If yes where? Otherwise, what are the options I have?
Azim
Hey people,
I would like to see what a program is printing on a terminal. Does AS7 have any inbuilt terminals? If yes where? Otherwise, what are the options I have?
Azim
what are the options I have
TeraTerm
PuTTY
Bray
RealTerm
etc, etc, ...
EDIT
This is a very frequently recurring question; eg, https://www.avrfreaks.net/comment...
I have TeraTerm installed. Can I print data without the hardware? I need to see what certain line of code are printing. If yes, how?
You mean you're running your code in a simulator, and want to see its UART output ?
EDIT
Is that specifically the Atmel Studio simulator?
So, I have this code that uses a circular buffer. It receives incoming bytes in these UART buffers. I want to know what these incoming bytes are. In my previous post I had inquired on how I can assign dummy values to those buffers but in vain. The project does a dummy capture. I am frustrated with this now. I just dont know what to do and whom to approach for such (maybe) trivial questions.
I do not know much about the ATMEL simulator. I was debugging the project to find out the flow of the program. But as usual its stuck in a while loop.
So are you running your code in the simulator or not?
Why not use the DEBUGGER to do this - stop at any moment and you can actually examine what is in the buffers in actual AVR memory - no need to "print" the contents
No..:/
AVR memory? whats that? I am using the debugger. So this AVR memory is where I can see what's in those buffers?
AVR memory? whats that?
Are you serious?!
The AVR has 3 types of memory:
EDIT
EDIT 2
typo
#AVRMemories #AVRArchitecture
Oh no. I am sorry. Lol. I know that. I thought AVR memory is a tool on AS7 . So how do I examine whats in the AVR Memory? ref: clawson
how do I examine whats in the AVR Memory?
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
Ok. Done.
AS7 has a terminal. That's what the documentation says. Under View. But I dont see any on my AS7 here. Ugh!!!
Read #8 again.
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
You can only use a terminal program(see list above) with real hardware, not with a simulator.
No, that's not necessarily true.
eg, Keil has a simulator[1] which can send the simulated UART output to a COM port. So you could loop that back to a terminal on another real COM port, or use something like com0com to do it "virtually"
http://com0com.sourceforge.net/
However, given chips with on-board debug, I found it just as easy to use a real devboard - and that was over ten years ago.
Nowadays, given devboards with the debugger and virtual COM port built-in, it would be even more so.
[1] Of course, not an AVR simulator - but the principle applies.
EDIT
But, as pointed out in #8, a serial port and terminal is not the way to do what the OP is asking anyhow.
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.
You also have facilities to view your variables by name: http://www.atmel.com/webdoc/GUID...
EDIT
eg,
I found this yesterday. Thanks Neil! :) I will keep you posted.
I guess it's horses for courses but for "buffers" I think you are going to find a memory window rather than a variable watch is more useful for this kind of thing.
(well I do).
I will keep track of both.
for "buffers" I think you are going to find a memory window rather than a variable watch is more useful for this kind of thing.
Probably a combination of both - a memory view to see the content, and watches for the read & write indexes.
A watch can also be useful when you're interested in a particular buffer entry - eg, my_buffer[87] - rather than having to manually count through a memory view.
I want to use a printf() function for serial printing. I added the stdio.h header. I was trying to define a stream based on a reference online. But its' showing me this error.
I want to use a printf() function for serial printing
Why??
After it's been amply demonstrated that you really do not need to do that!!
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?
or, in fact, what any declaration is?
Here's the UART definitions from the header
//UART define //------------------------------------------------------------------- //#define UART_DBG //debug UART0 #ifdef UART_DBG #define UART_RECV_VECTOR SIG_UART0_RECV #define UART_TX_VECTOR SIG_UART0_DATA #define UART_UDR UDR0 #define UART_UDRE (1<<UDRE0) #define UART_UDRIE (1<<UDRIE0) #define UART_UCSRA UCSR0A #define UART_UCSRB UCSR0B #define UART_UCSRC UCSR0C #define UART_UBRRL UBRR0L #define UART_TXC TXC0 #define UART_RXC RXC0 #define UART_TXEN TXEN0 #define UART_RXEN RXEN0 #define UART_ERRORS ((1<<FE0)|(1<<DOR0)|(1<<UPE0)) #define UART_UCSRB_INIT ((1<<RXCIE0) | (0<<UDRIE0) | (1<<RXEN0) | (1<<TXEN0)) #define UART_UCSRC_INIT ((1<<UCSZ01) | (1<<UCSZ00)) #else #define UART_RECV_VECTOR USART1_RX_vect #define UART_TX_VECTOR USART1_UDRE_vect #define UART_UDR UDR1 #define UART_UDRE (1<<UDRE1) #define UART_UCSRA UCSR1A #define UART_UCSRB UCSR1B #define UART_UCSRC UCSR1C #define UART_UBRRL UBRR1L #define UART_SPEED 51 #define UART_ERRORS ((1<<FE1)|(1<<DOR1)|(1<<UPE1)) #define UART_UCSRA_INIT ((1<<TXC1) | (1<<U2X1)) #define UART_UCSRB_INIT ((1<<RXCIE1) | (0<<UDRIE1) | (1<<RXEN1) | (1<<TXEN1)) #define BL_UCSRB_INIT ((1<<RXEN1) | (1<<TXEN1)) #define UART_UCSRC_INIT ((1<<UCSZ11) | (1<<UCSZ10)) #define UART_TXC TXC1 #define UART_RXC RXC1 #endif
I could only locate UART definitions defined under the else condition in the project.
It tells the compiler what the function parameters are, what return type, etc.,
I wanted to play with code. I am able to see whats going in the memory.
So the firmware in the embedded board starts functioning based on commands from an application software (AS). So, the AS issues an opcode 02 03 11 12 03. I want to make the board independent of the application software. Forget the board, atleast the firmware. For now the firmware is doing a dummy capture. I would like the firmware to do a real time operation and be able to identify multiple modulation schemes and process that data accordingly. I tried inputting the opcode on a terminal like termite and its displaying some random values; all numbers.
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.
Ok. I changed that.
static int uart_putchar(char c, FILE *stream); static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, NULL, _FDEV_SETUP_WRITE); static int uart_putchar(char c, FILE *stream) { if (c == '\n') uart_putchar('\r', stream); loop_until_bit_is_set(UCSRA, UDRE); UDR = c; return 0; }
I have these two errors. I would shamelessly accept that my exposure to C in real world is less (I would say programming in general). This project has got me hooked on it now. Yes, I also have a text book on C. but Embedded C is completely new to me.
Update:
I changed the UCSRA and UDRE to how they are defined to in headers.
RE: post #34
7 of the warnings there say "This header file is obsolete" talking about your use of <avr/signal.h>. The message even says use <avr/interrupt.h> instead. Why on earth are you ignoring things like this?!?
As for UCSRA being undeclared. It should be (a) if you use the <avr/io.h> as you should and (b) you are actually building for a model of AVR that has a register called UCSRA
This is a complete guess but I think you probably do include the io.h header so presumably the AVR you are using is one that does not have UCSRA. Is it a "modern" AVR like mega48/88/168/328 or perhaps mega164/324/644/1284? Those models have UCSR0A not UCSRA for the first (sometimes only) UART. The same is true if UDR. The register is probably UDR0 in fact.
In #29 you posted some code (without any explanation) that mentions things like UCSR0A, UCSR1A, UDR0 and UDR1. That seems to confirm that you may be building for a "modern" (like last 10 years) model of AVR. The code you have found using UCSRA/UDR is probably from a 10+ year old AVR
Just start by telling us which model of AVR it is you are trying to use.
The message even says use <avr/interrupt.h> instead. Why on earth are you ignoring things like this?!?
+1 .
Never ignore warnings. Just because they are warnings (rather than errors) does not mean they are always benign.
Are you referring to the MCU? If yes, atmega64, 8 bit. The avr/interrupt.h warning. I have replaced the avr/signal.h with the avr/interrupt.h in all the program files. It still shows this error SOMETIMES, which is kind of weird. I have been noting this for sometime : whenever I add a new piece of code to the program, I get that error.
I changed UDR to UART_UDR and now I have one warning - mystdout defined but not used <-Wunused-variable>.
Never ignore warnings
That's a warning that most programmers always ignore.
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.
I was going through the avr library manual and came across #defines in uppercase and lowercase like this one below. Can anyone tell me what's the difference?
#define fdev_setup_stream(stream, put, get, rwflag)
#define FDEV_SETUP_STREAM(put, get, rwflag)
Thanks
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++
Thanks clawson. :)
One more question: Should I be making these changes in the main.c or UART source file?
It's not clear to me what "changes" you are talking about.
Changes for a user supplied stdio stream.
I would be tempted to keep that with the UART stuff. Maybe just make it part of uart_init() that stdin/stdout are connected to the local uart_getchar() and uart_putchar() routines so you main can look like:
#include "uart.h" int main(void) { uart_init(); // maybe pass a baud rate here? printf("hello"); }
That keeps main() very "clean" so there's no knowledge of the connection to stdout here.
OTOH you might want to retain control of whether stdout connects to the UART output channel. Some libraries choose to do it more like:
#include "uart.h" int main(void) { uart_init(); // maybe pass a baud rate here? uart_connect_to_stdio(); printf("hello"); }
so that the connection is more obvious and also so it can optionally be removed.
So yesterday, I put a main in the main.c file and the obvious happened; the program didn't compile. I am guessing defining the function for serial printing could be done in the uart source file. The init_uart() you are talking about is defined as UARTIni() under level4.c source file with its declarations and macros defined in level4.h. I am guessing I have create that function for serial printing in UART source file.
You do know about things like extern and function declarations etc?
Ultimately the code in a single C file can be split in any way you choose. But often it takes a little effort to get "cross links" between files working. For data you will need "extern" declarations so the non-implementing file can "see" the data in the other. For functions you do it by a split of function declaration and definition with the declarations usually being placed in a shared header file. Were you doing this?