Hi,
I am trying to use the IAR (ver 5) lib printf function to output debug messages
to UART1.
I followed the instruction to override the __write() function in the template
file. When I step into printf("hello"), it resolves correctly to the function
__write().
However, one of the parameter in the __write(), size_t size, is always 1
regardless of the different string I use. Hence only 'h' gets written
out and the function returns.
Why is that so? Is there something wrong with my environment setting etc?
When I use the function __write(1, "hello", 6) directly, the whole string does
get output to the UART1.
Pls advise. Thks
Jason
IAR printf issue
Started by ●October 21, 2008
Reply by ●October 21, 20082008-10-21
On Tue, Oct 21, 2008 at 9:45 AM, wrote:
> Hi,
>
> I am trying to use the IAR (ver 5) lib printf function to output debug
> messages to UART1.
> I followed the instruction to override the __write() function in the
> template file. When I step into printf("hello"), it resolves correctly to
> the function __write().
> However, one of the parameter in the __write(), size_t size, is always 1
> regardless of the different string I use. Hence only 'h' gets written out
> and the function returns.
>
> Why is that so? Is there something wrong with my environment setting etc?
>
> When I use the function __write(1, "hello", 6) directly, the whole string
> does get output to the UART1.
>
Hi Jason,
Have you took a look at the "Library low-level interface
implementation" option in "General option" configuration for your
project?
EWB 5 introduced the "semihosted" option that drives stdout/stderr
through the JTAG device (very handy btw).
May be is this that breaks your implementation.
Best regards
Pietro
> Hi,
>
> I am trying to use the IAR (ver 5) lib printf function to output debug
> messages to UART1.
> I followed the instruction to override the __write() function in the
> template file. When I step into printf("hello"), it resolves correctly to
> the function __write().
> However, one of the parameter in the __write(), size_t size, is always 1
> regardless of the different string I use. Hence only 'h' gets written out
> and the function returns.
>
> Why is that so? Is there something wrong with my environment setting etc?
>
> When I use the function __write(1, "hello", 6) directly, the whole string
> does get output to the UART1.
>
Hi Jason,
Have you took a look at the "Library low-level interface
implementation" option in "General option" configuration for your
project?
EWB 5 introduced the "semihosted" option that drives stdout/stderr
through the JTAG device (very handy btw).
May be is this that breaks your implementation.
Best regards
Pietro
Reply by ●October 21, 20082008-10-21
Hi Pietro,
Thank you for the heads up on the semihosted feature. I tried that and it
works by printing to the Terminal I/O console.
However, I think I know what happens with my printf problem. Apparently,
there is no real issue. Printf indeed sent just a single byte to the __write
function. There is an internal repetition loop that will load the next
character to __write() after __write() returns and will do so until the end
of the string.
I think printf() works this way is because in the file DLib_Defaults.h, the
following option is configured:
#define _DLIB_PRINTF_CHAR_BY_CHAR 1
Please let me know if I got the understanding wrong.
Cheers
Jason
On Tue, Oct 21, 2008 at 6:33 PM, Pietro Maggi wrote:
> On Tue, Oct 21, 2008 at 9:45 AM, wrote:
> > Hi,
> >
> > I am trying to use the IAR (ver 5) lib printf function to output debug
> > messages to UART1.
> > I followed the instruction to override the __write() function in the
> > template file. When I step into printf("hello"), it resolves correctly to
> > the function __write().
> > However, one of the parameter in the __write(), size_t size, is always 1
> > regardless of the different string I use. Hence only 'h' gets written out
> > and the function returns.
> >
> > Why is that so? Is there something wrong with my environment setting etc?
> >
> > When I use the function __write(1, "hello", 6) directly, the whole string
> > does get output to the UART1.
> > Hi Jason,
>
> Have you took a look at the "Library low-level interface
> implementation" option in "General option" configuration for your
> project?
> EWB 5 introduced the "semihosted" option that drives stdout/stderr
> through the JTAG device (very handy btw).
>
> May be is this that breaks your implementation.
>
> Best regards
> Pietro
>
Thank you for the heads up on the semihosted feature. I tried that and it
works by printing to the Terminal I/O console.
However, I think I know what happens with my printf problem. Apparently,
there is no real issue. Printf indeed sent just a single byte to the __write
function. There is an internal repetition loop that will load the next
character to __write() after __write() returns and will do so until the end
of the string.
I think printf() works this way is because in the file DLib_Defaults.h, the
following option is configured:
#define _DLIB_PRINTF_CHAR_BY_CHAR 1
Please let me know if I got the understanding wrong.
Cheers
Jason
On Tue, Oct 21, 2008 at 6:33 PM, Pietro Maggi wrote:
> On Tue, Oct 21, 2008 at 9:45 AM, wrote:
> > Hi,
> >
> > I am trying to use the IAR (ver 5) lib printf function to output debug
> > messages to UART1.
> > I followed the instruction to override the __write() function in the
> > template file. When I step into printf("hello"), it resolves correctly to
> > the function __write().
> > However, one of the parameter in the __write(), size_t size, is always 1
> > regardless of the different string I use. Hence only 'h' gets written out
> > and the function returns.
> >
> > Why is that so? Is there something wrong with my environment setting etc?
> >
> > When I use the function __write(1, "hello", 6) directly, the whole string
> > does get output to the UART1.
> > Hi Jason,
>
> Have you took a look at the "Library low-level interface
> implementation" option in "General option" configuration for your
> project?
> EWB 5 introduced the "semihosted" option that drives stdout/stderr
> through the JTAG device (very handy btw).
>
> May be is this that breaks your implementation.
>
> Best regards
> Pietro
>