Terminal for printing outputs?

Go To Last Post
86 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

azimmali wrote:
what are the options I have

TeraTerm

PuTTY

Bray

RealTerm

etc, etc, ...

 

EDIT

 

This is a very frequently recurring question; eg, http://www.avrfreaks.net/comment...

Last Edited: Thu. Oct 12, 2017 - 02:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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?

 

Last Edited: Thu. Oct 12, 2017 - 02:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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

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

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

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

No..:/

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

AVR memory? whats that? I am using the debugger. So this AVR memory is where I can see what's in those buffers?

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

azimmali wrote:
AVR memory? whats that?

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

 

Last Edited: Mon. Oct 16, 2017 - 08:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh no. I am sorry. Lol. I know that. I thought AVR memory is a tool on AS7 blush. So how do I examine whats in the AVR Memory? ref: clawson

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

azimmali wrote:
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

Last Edited: Thu. Oct 12, 2017 - 03:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok. Done.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

AS7 has a terminal. That's what the documentation says. Under View. But I dont see any on my AS7 here. Ugh!!!

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

Read #8 again.

 

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

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

 

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

ki0bk wrote:
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.

Last Edited: Thu. Oct 12, 2017 - 09:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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.

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

You  also have facilities to view your variables by name: http://www.atmel.com/webdoc/GUID...

 

EDIT

 

eg,

 

Last Edited: Fri. Oct 13, 2017 - 09:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found this yesterday. Thanks Neil!  :) I will keep you posted.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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).

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

I will keep track of both.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

clawson wrote:
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.

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

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

azimmali wrote:
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!!

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

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?

Last Edited: Sat. Oct 14, 2017 - 01:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

or, in fact, what any declaration is?

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

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

Last Edited: Mon. Oct 16, 2017 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It tells the compiler what the function parameters are, what return type, etc.,

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

I wanted to play with code. I am able to see whats going in the memory.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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

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. 

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

 

 

 

Update:

I changed the UCSRA and UDRE to how they are defined to in headers.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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.
 

Last Edited: Mon. Oct 16, 2017 - 05:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:
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.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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]

Last Edited: Mon. Oct 16, 2017 - 05:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

I changed UDR to UART_UDR and now I have one warning - mystdout defined but not used <-Wunused-variable>.

 

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

Never ignore warnings

 

That's a warning that most programmers always ignore.

When in the dark remember-the future looks brighter than ever.

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

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. 

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

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

 

 

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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++

 

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

Thanks clawson. :)

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

One more question: Should I be making these changes in the main.c or UART source file?

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

It's not clear to me what "changes" you are talking about.

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

Changes for a user supplied stdio stream.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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.

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

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.

Amateur programmer.
Believe when I tell you that my struggle on here is real.

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

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?

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

Pages