View previous topic :: View next topic |
Author |
Message |
TIMT
Joined: 02 Sep 2005 Posts: 49 Location: Nottingham, UK
|
printf question |
Posted: Wed Sep 07, 2005 5:25 am |
|
|
I'm just starting with CCS and I'm working my way through the introduction to ccs manual. I've set up the rs232 port to send data to my pc and I'm receiving it with the serial port monitor software in ccs. This works fine but this code - printf("Hello everybody"); just sends -
Hello everybo (no dy !) If I send longer strings it seems ok. I'm using the latest ccs version. Hello works fine - Am I missing something obvious? _________________ Tim |
|
|
Ttelmah Guest
|
|
Posted: Wed Sep 07, 2005 6:35 am |
|
|
You are missing something 'famous', but not 'obvious'. :-)
The key is that unlike a C routine in a PC, where you are being called from the outside 'OS', and when the routine finishes, have an OS to return to, in the PIC, your 'main' code is all that exists. If you code:
Code: |
main {
printf("Hello World");
}
|
When the code finishes sending the string to the hardware UART, it'll drop 'off the end', and effectively stop (CCS by default inserts a 'sleep' instruction at this point to prevent this overrun). Now the hardware UART, has 2+ characters of buffering, so this occurs with these characters still sitting in the hardware unsent. The processor goes to sleep, an the characters are never sent.
Normally if you write your code to be 'standalone', and never exit, this will not be a problem. You can prevent the code from running off the ed, by changing to:
Code: |
main {
printf("Hello World");
while (true) ;
}
|
The extra 'while' statement, prevents the routine from ever exiting, and stops this happening.
This is 'famous' (is the source of a couple of threads a year here on the forum), but until you get your head round the difference between a complete 'standalone' program, and one that is called from inside an OS, which stays running to actually complete the data transmission for you, is not 'obvious'.
Best Wishes |
|
|
TIMT
Joined: 02 Sep 2005 Posts: 49 Location: Nottingham, UK
|
|
Posted: Wed Sep 07, 2005 6:48 am |
|
|
Thanks ! Your reply was very useful. I tried a while loop and it worked. I would not have realised that in a million years! I think I have still got a lot to learn. Thanks again for your thorough reply... _________________ Tim |
|
|
Ttelmah Guest
|
|
Posted: Wed Sep 07, 2005 7:33 am |
|
|
I took the time to give a 'fullish' explanation, rather than just saying 'stick a while on the end', for two reasons. The first was that this particular question has not come up recently. The second though was that your question was almost a classic example of how to ask a question!. Your description was clear, example simple, and you described exactly what was happening. This makes it a million times easier to answer, and as such, I was glad to give the reply, especially since it is so very 'non' obvious!...
Best Wishes |
|
|
TIMT
Joined: 02 Sep 2005 Posts: 49 Location: Nottingham, UK
|
|
Posted: Wed Sep 07, 2005 7:52 am |
|
|
The thing I didn't realize is that ccs sends the hardware to sleep if it runs out code. I overlooked normal good practice just while I was experimenting with different functions. I forgot how unforgiving C can be!
Hope to be of help to you some day. Will be a long time yet I suspect! _________________ Tim |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Wed Sep 07, 2005 8:02 am |
|
|
If they didn't put the sleep in there think about what would happen. The code would continue to execute. Since nothing is programmed, they would be NOPs. Eventually, the program counter would wrap and the program would start over which could cause problems as well. |
|
|
TIMT
Joined: 02 Sep 2005 Posts: 49 Location: Nottingham, UK
|
|
Posted: Wed Sep 07, 2005 8:22 am |
|
|
It's interesting that no warning messages were generated when I compiled the code which sent the Program counter to an unknown loacation. I've been using assembly with mplab up until now and I think it usually comes up with an "unexpected end" warning message if I'd made the same mistake. Maybe I should have examined the assembly code the compiler generated to see what was actually happening. _________________ Tim |
|
|
|