Another printf() question

[admin]

Hi all,

I developing on an -S08AW16, and I just want to shove a couple of variables out the serial port where I can look at them with HyperTerm.  I wrote my own TERMIO_PutChar function, and printf *mostly* seems to be working.  Here's my code:

( void )printf("SP %u\n\r", dtTarget );

where dtTarget is an unsigned int.

On Hyperterm, I see

SP 0

I have already checked (through the emulator), and dtTarget is always non-zero.  I've looked at my serial buffer, and the "SP 0" is in there, so the problem is somewhere in printf().

Any suggestions?

Thanks,

Tomahawk

[admin]

I did some more research, and here's what I found:

printf() (in embedded.c) calls va_start() (a macro) which looks like it should get the number arguements for printf, but it just gets 0 for mine.

Any help?

[CrasyCat]

Hello

Did you include stdio.h in the source file where you are using printf?

CrasyCat

[admin]

Yes I did.  Everything compiles just fine, and like I said in my original message, printf *mostly* works.

[J2MEJediMaster]

OK, I'll admit this is grasping at straws, but:

1) Try something other than a %u. Perhaps %c, or try %lu, and see if something different comes out.

2) Why is the statement prefaced with (void)? I can see that for a function declaration, but not when actually making the function call. Sorry if that's a dumb statement, I've been using a Java a lot lately.

---Tom

[admin]

1) I've tried %u, %d, %x, %i and even specifying digits, i.e. %5d, %4u, etc (this just insterts spaces in my output, i.e. "SP      0").

2) I prefaced the function call with ( void ) to tell the compliler I don't care about the return value (otherwise I get a warning).

Thanks,

Tomahawk

[CompilerGuru]

strange case.

First, you say that dtTarget is a unsigned int, and I belive you. But because of the lack of any argument checking for printf, I would actually cast it to unsigned int anyway.
( void )printf("SP %u\n\r", (unsigned int)dtTarget );

Then, did you modify the default type sizes? Especially configuring int as 4 byte would explain it, unless you did recompile the library with this option.

The va_start() macro in printf does actually compute the address of the first non specified argument of an open parameter list. 0 does not really make sense here as pointer value.

Can you show us the code the compiler generated for your code snippet (with the context menu disassemble)?

Otherwise, can you provide a complete project showing the problem?

Daniel

[admin]

---

CompilerGuru wrote:
strange case.

First, you say that dtTarget is a unsigned int, and I belive you. But because of the lack of any argument checking for printf, I would actually cast it to unsigned int anyway.
( void )printf("SP %u\n\r", (unsigned int)dtTarget );

Then, did you modify the default type sizes? Especially configuring int as 4 byte would explain it, unless you did recompile the library with this option.

---

I haven't modified the default type sizes.  I'll work on getting the generated code (I back-burnered this for awhile).

-Tomahawk

[admin]

Generated code as requested:

  190:           ( void )printf("SP %u\n\r", dtTarget );
  004e 5500     [4]             LDHX  dtTarget
  0050 89       [2]             PSHX 
  0051 8b       [2]             PSHH 
  0052 450000   [3]             LDHX  @"SP %u\012\015"
  0055 89       [2]             PSHX 
  0056 8b       [2]             PSHH 
  0057 cd0000   [6]             JSR   printf
  005a a704     [2]             AIS   #4

[CompilerGuru]

I get exactly the same code when I compile the code below in the tiny memory model (well I also get the same code in the small memory model when I explicitely allocate bufpos in the zero page).
Did you allocate bufpos in the zero page? If not, this would explain it. What does the code below generate for you?
It redirects the printf output to a buffer to separate the SCI code from the printf one.



#include <hidef.h>
#include <stdio.h>
char buf[20];
int bufpos;
void TERMIO_Init(void) {
}
void TERMIO_PutChar(char ch) {
buf[bufpos]= ch;
bufpos++;
if (bufpos >= sizeof(buf)) {
bufpos -= sizeof(buf);
}
}
int dtTarget= 2;
void main(void) {
(void)printf("SP %u\n\r", dtTarget );

while (1) { _FEED_COP(); }
}

PS: This Html view kills the indendation, sorry :smileysad:

[admin]

---

CompilerGuru wrote:
I get exactly the same code when I compile the code below in the tiny memory model (well I also get the same code in the small memory model when I explicitely allocate bufpos in the zero page).
Did you allocate bufpos in the zero page? If not, this would explain it.

---

Tell me of the bufpos of which you speak (I don't think I did it).

[CompilerGuru]

Oh, I was using the wrong variable name. I meant dtTarget.
Your code is accessing it with direct addressing, so I just wanted to double check that this variable is indeed in the zero page.
Which memory model are you using? Which compiler version? Does sprintf work,
oh, and before I forget it, do you have enough stack space to use printf?
Try to increase your stack, especially the floating point version of printf does need much stack.
Having not enough stack is probably the most common problem with printf, happens even more often than arguments not matching the pattern.

Daniel

[admin]

1)  Tiny

2) I've got CodeWarrior 5.7.0.  How do I find out the compiler version?

3) It appears as if I have plenty of stack.

[CompilerGuru]

How much stack do you have, why are you sure you have enough? The longer I think of the problem, the more it remembers me of a stack overflow one.

I dont think it is a compiler problem, you showed the coded of the printf call, and it was ok.

Anyway, the compiler version can be found in the Compiler Settings, there is a n About button which opens the compiler's own version dialog. Something like "... Compiler for HC12 V-5.0.30 Build 6037, Feb 7 2006".

The product version is in the main CW about box, click installed products, and then all installed products and service packs are listed on top. Something like "... HC12 4.5 build 6037".

Things to try on your side:
Can you try my snippet (with sprintf)?
Can you try to increase the stack?
Can you try to run it in the simulator? (it might give more hints on what's wrong than the HW...)
Can you try to create a new project with the wizard, include your termio functions, and add a printf in there?

In the end, I probably need a complete, compilable sample to check. printf works for me.....

Daniel