Thread: terminal output not showing output properly

  1. #1
    Registered User
    Join Date
    Jul 2004
    Posts
    222

    terminal output not showing output properly

    I'm not sure if this is a hardware/software timing problem, but I am not having newline operator working properly on my usart_str_write function as shown in http://www.mikroe.com/forum/viewtopic.php?t=12380. I'm very sure that the problem comes from my usart_str_write function. I'm not sure if it's my pointer/strlen method not working properly, or if I am not adding newline operator properly. In usart_str_write() function, there's a predefined Usart_write(char data) function that writes a character to the terminal. Any insights would be helpful. Thanks.

  2. #2
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by stanlvw View Post
    I'm not sure if this is a hardware/software timing problem, but I am not having newline operator working properly on my usart_str_write function as shown in http://www.mikroe.com/forum/viewtopic.php?t=12380. I'm very sure that the problem comes from my usart_str_write function. I'm not sure if it's my pointer/strlen method not working properly, or if I am not adding newline operator properly. In usart_str_write() function, there's a predefined Usart_write(char data) function that writes a character to the terminal. Any insights would be helpful. Thanks.
    I see nothing wrong with that code. The while(strlen(string))... is unneeded, and I see that you've commented it out. Your loop writes each character of the string, until it reaches the end, then writes a newline. That all looks correct.

    Your problem is probably somewhere else.

  3. #3
    Registered User
    Join Date
    Jul 2004
    Posts
    222
    Thank you for your reply, brewbuck. So are you saying the problem could be coming from how mikroC terminal reacts to usart_write()?

  4. #4
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by stanlvw View Post
    Thank you for your reply, brewbuck. So are you saying the problem could be coming from how mikroC terminal reacts to usart_write()?
    I really couldn't say. I just wouldn't blame the string-writing function. I don't know anything about the library you are using so I can't really help much more than that.

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Have you tried other line endings, such as \r\n or just \r

    You've previously stated that you're writing for an embedded target, so normal end-of-line translations do not apply, you get exactly what you asked for.

    Does your terminal s/w have a 'hex dump' mode to show you exactly what bytes you're receiving?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Registered User
    Join Date
    Jul 2004
    Posts
    222
    I'm not entirely sure if the terminal software support a "hex dump" mode. I haven't looked into \r b/c I wasn't aware that there's a carriage return operator that would apply to an embedded application. But I will get back to you on whether it supports that.

  7. #7
    Registered User
    Join Date
    Jul 2004
    Posts
    222
    I've just tried using '\r' in my code in place of '\n' and also in conjunction with '\n' as such in my usart_str_write function as shown below. But I still have no luck solving the terminal's style of showing the output of usart. Any more ideas?

    Code:
    void usart_str_write(char* string)
    {
         //while ((*string) != '\0'){
         while (strlen(string)){
           Usart_Write((char) (*string));
           ++string;
         }
         Usart_Write('\n');               // add a new line to every string
         Usart_Write('\r');               // add a carriage return to terminal
    }

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Exactly what is the problem with the output? Do you get any text in your terminal? If not, is the baudrate the same at both ends? If you think they are, but you still don't get anything, is the handshaking OK - for example, hardware handshaking won't work unless BOTH sides use it.

    If all else fails, hook up an oscilloscope or logic analyzer to the RX/TX lines and verify that your baudrate is what you think it is. Best if you send a U (0x55) continuously, as that will form a nice square-wave of ones and zeros in a long sequence, so it's easy to count for example 10 cycles and get a good average. Check both sides (create a file and send it as a "transmit text file" from your terminal, file should have a HUGE amount of U in it).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    I found some code (never mind the link, it's a gigantic PDF document) that uses
    Code:
    Usart_Write(13);
    to write a newline, which should be the same as '\r', but try it anyway. You never know.

    That sample code does seem to indicate that printing a newline is possible with this function, so you're okay on that point.

    Other suggestions: print every character from 0 to 255 inclusive like so:
    Code:
    printf("[[[%c]]]", c);
    Maybe you'll be able to figure out what character is a newline that way, although I can't see it as being anything other than '\n' or '\r'.

    Maybe it doesn't use ASCII?

    [edit] matsp's response sounds a lot more scientific, better have a look at it. [/edit]
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Actually, re-reading the ORIGINAL question, it's probably true to say that my answer is for a different problem than the original question.

    You should print '\r', '\n' or characters 13, 10 to form a "new line". 13 is "Carriage return" which brings the cursor (originally the "carriage of the printhead" to the beginning of the line), and the 10 is "line feed", whcih originally meant "bring the paper up one line", but in modern systems means move the cursor down one line (scroll the screen if need be).

    If that doesn't work, it's back to debuggin what is ACTUALLY happening [and here you could make use of a digital storage oscilloscope and make sure that you are sending the right values].

    You could also (perhaps) disassemble the code for your "write newline" code to see that the value for '\r' and '\n' are actually 13 and 10 (0x0d, 0x0a respectively if you have hex in your disassembly).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Jul 2004
    Posts
    222
    According to the assembler file produced from the source build, '\r' and '\n' are indeed written as passing 13 and 10 in the asm file. According to the hex/decimal dump mode in mikroC terminal, I am getting the newline operator properly (whether it's '\r' or '\n'). Should I still proceed with checking the data pin from the mcu to the host computer for its usart signal pattern?
    Last edited by stanlvw; 11-17-2007 at 07:01 PM.

  12. #12
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    If your terminal program isn't printing a new line when you send it a newline, then you need to fix that, rather than your program.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  13. #13
    Registered User
    Join Date
    Jul 2004
    Posts
    222
    Thanks for your reply. Guess it's time for me to talk to mikroC.

  14. #14
    Registered User
    Join Date
    Jul 2004
    Posts
    222
    It appears that the problem is solved if I use Windows hyperterminal rather than mikroC terminal. Once again, I appreciate for all the help received.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Formatting output into even columns?
    By Uncle Rico in forum C Programming
    Replies: 2
    Last Post: 08-16-2005, 05:10 PM
  2. Base converter libary
    By cdonlan in forum C++ Programming
    Replies: 22
    Last Post: 05-15-2005, 01:11 AM
  3. why this output?
    By dredre in forum C Programming
    Replies: 4
    Last Post: 05-08-2004, 04:09 PM
  4. Need help fixing bugs in data parsing program
    By daluu in forum C Programming
    Replies: 8
    Last Post: 03-27-2003, 06:02 PM
  5. Control different DA output value!
    By Hunterhunter in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 03-13-2003, 12:11 PM