xil_printf not working as expected (cont.)

Hello,

(first of all sorry for continuing in a new thread, but google wouldn't let me reply for several days now: "unable to retrieve message ..")

@BO: As i'v already mentioned i tried a lot of combinations of datatypes and (xil_)printf formatting-strings, including "%d". But nothing is beeing displayed.

I've tried using putnum, too. It works but merely submits the hex-values. Seeing putnum working irritates me even more, in the end everything is just a call to outbyte().

@JON: It is not my intention to submit long longs. I'm using Xuint32 or unsigned long, what is the same.

(When looking at my example i saw that i was pasting the wrong xil_printfs, but in the real code they are alright (using the according variables), just a sign of the many, many combinations i've tried...)

Regards Patrick

The xil_printf documentation states: >This function is similar to printf but much smaller in size (only
1KB). It
does not have support for floating point numbers. xil_printf also

does not

support printing of long long (i.e 64 bit numbers"This func is

similar to

printf but much smaller. It does not have support for floating pt

numbers or

long long. " >Try using %d instead of %l and see if you get *something*... >> Hello, >> >> i know this is a rather stupid question, but i'm somewhat

irritated.

> >> I'm triing to send some data per Uartlite. For normal >> characters/strings everything works fine, but if i try to send some >> integers or long integers they aren't displayed. >> >> (Short) example: >> >> ... >> >> /* global definitions, no pointers */ >> Xuint32 interrupt_count = 0; >> volatile Xuint32 jiffies = 0; >> >> ... >> >>/* values incrementd during pit-isr, pit works, pit running at 100HZ >> */ >> void pit_timer_int_handler(void * baseaddr_p) >> { >> jiffies++; >> interrupt_count++; >> >> XTime_TSRClearStatusBits(XREG_TSR_PIT_INTERRUPT_STATUS); >> } >> >> ... >> >> main(){ >> >> /* string displayed correctly */ >> xil_printf("\r\nRunning Mainloop"); >> >> while(1){ >> sleep(2); >> xil_printf("\nLoop"); >> >> /* here the values aren't displayed,but the "a"s and "b"s are

displayd

> */ >> xil_printf("\n %l a", i_interrupt_count); >> xil_printf("\n %l b", l_interrupt_count); >> /* giving the arguments as pointers won't help either */ >> xil_printf("\n %l a", &i_interrupt_count); >> xil_printf("\n %l b", &l_interrupt_count); >> } >> } >> >> >> i have tried different compinations with "%d","%D","%l","%ul" or

"%c"#

> as format-strings and different datatypes for the two variables >> (unisgned, int, long, unsigned long). >> >> i was looking at the xil_printf sources, too, to see what

characters

> after "%" are supported. >> >> I'm using an uartlite at 9600 baud, 8 databits, no parity. >> >> So, does someone might have an idea or hint what my mistake is? >> >> Regards >> Patrick
Reply to
Patrick
Loading thread data ...

I also had the same problem before. What I did to solve this problem is to include the system include/lib path BEFORE the project specific include/lib path. This is accomplished with a custom Makefile and a snippet of the Makefile is shown below:

################################################################# # SOFTWARE APPLICATION TESTAPP #################################################################

TestApp_program: $(TESTAPP_OUTPUT)

$(TESTAPP_OUTPUT) : $(TESTAPP_SOURCES) $(TESTAPP_HEADERS) $(TESTAPP_LINKER_SCRIPT) \ $(LIBRARIES) __xps/testapp_compiler.opt @mkdir -p $(TESTAPP_OUTPUT_DIR) $(TESTAPP_CC) $(TESTAPP_CC_OPT) $(TESTAPP_SOURCES) -o $(TESTAPP_OUTPUT) \ -IC:/EDK/gnu/microblaze/nt/microblaze/include \ -LC:/EDK/gnu/microblaze/nt/microblaze/lib \ $(TESTAPP_OTHER_CC_FLAGS) $(TESTAPP_INCLUDES) $(TESTAPP_LIBPATH) \ -xl-mode-$(TESTAPP_MODE) \ $(TESTAPP_CFLAGS) $(TESTAPP_LFLAGS) $(TESTAPP_CC_SIZE) $(TESTAPP_OUTPUT)

As you can see, the system include/lib path is hardcoded and appears BEFORE any other path. I know this is a hack, but it solves my problem for now! :)

To invoke this makefile, use: "make -f Makefile TestApp_program" et voila~!

Let me know if this helps you or if you need more help... :-)

Jung Ko

Reply to
kojung

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.