Problems with printk() function

Hoover, Victor P CTR NAVAIR, AIR 4.1.3.3 victor.hoover.ctr at navy.mil
Mon Dec 19 09:24:35 UTC 2011


> -----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.

> --
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5218 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20111219/ba87d10c/attachment-0001.bin>


More information about the users mailing list