Problems with printk() function

[Gedare Bloom]

On Mon, Dec 19, 2011 at 4:24 AM, Hoover, Victor P CTR NAVAIR, AIR
4.1.3.3 <victor.hoover.ctr at navy.mil> wrote:
>> -----Original Message-----
>> From: rtems-users-bounces at rtems.org [mailto:rtems-users-
>> bounces at rtems.org] On Behalf Of Sebastian Huber
>> Sent: Monday, December 19, 2011 3:59
>> To: rtems-users at rtems.org
>> Subject: Re: Problems with printk() function
>>
>> On 12/19/2011 09:25 AM, Hoover, Victor P CTR NAVAIR, AIR 4.1.3.3 wrote:
>> > I'm having a couple of problems with the printk() function.
>> >
>> > a)  The optional precision value doesn't seem to be supported for
>> >      hexadecimal values (types x and X).  Then again, I haven't
>> played with
>> >      it enough yet to see if precision is supported at all...
>>
>> printk() is used normally for debug output and/or contexts which allow
>> no
>> printf() (e.g. interrupt context, exception handler).  It doesn't
>> support all
>> formats available via printf().
>
> I understand its purpose and it obviously isn't supporting the precision
> value in this case.  I questioned this because all of the existing debug
> code in the network.c module I'm debugging uses %2.2x for displays.  I
> would think that if the precision field wasn't supported then the original
> code wouldn't be trying to use it.
>
> I couldn't find anything specific to this searching through the mailing
> list and the bugzilla data base.  However I do recall seeing a posting
> somewhere saying that printk() should support all sprint() capabilities.
> The question really becomes, is it supposed to support precision values.
>
>> >
>> > b)  If the format string does not end with a newline character, no
>> output is
>> >      displayed.
>>
>> This is probably a problem with the program which displays the output.
>
> I'm not clear on what program you're referring to here.  I'm working with
> the MVME162 BSP.  Originally it did not have low level support for printk()
> in the BSP; I added it.  The function that gets called to handle the output
> accepts and displays a single character at a time.  The problem would have
> to be at a higher level than the BSP code to exhibit this behavior.
>
If you are connecting over a serial line with something like telnet,
it may not be flushing the output buffer until a new line is sent or
received (depending whether the issue is host or client side). Just a
thought...

>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>> Phone   : +49 89 18 90 80 79-6
>> Fax     : +49 89 18 90 80 79-9
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>