[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with printk() function
- Date: Mon, 19 Dec 2011 16:48:23 -0500
- From: gedare at rtems.org (Gedare Bloom)
- Subject: Problems with printk() function
On Mon, Dec 19, 2011 at 4:24 AM, Hoover, Victor P CTR NAVAIR, AIR
18.104.22.168 <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 22.214.171.124 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
>> 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
>> 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
> rtems-users mailing list
> rtems-users at rtems.org