Re: [riot-devel] printing uint64_t

2015-03-09 Thread Oleg Hahm
Hi Ralph!

 Is there something I'm doing that's obviously wrong?

I guess this problem is related to the Newlib-Nano [1] we're using if the
toolchain supports it. This library doesn't support 64-bit printing. If it's
required for you, you could try to disable it in the Makefile
(e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may
run into memory problems then.

Cheers,
Oleg

[1] https://github.com/32bitmicro/newlib-nano-1.0
-- 
/*
 *   Should be panic but... (Why are BSD people panic obsessed ??)
 */
linux-2.0.38/net/ipv4/ip_fw.c


pgpGPfDCkGzFQ.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


[riot-devel] printing uint64_t

2015-03-09 Thread Ralph Droms (rdroms)
I'm testing three different boards and native mode RIOT.  It seems I may have a 
problem with printing 64 bit ints (for example, an EUI-64 address).  Here's the 
code fragment (modified from examples/hello-world.c):

   uint64_t longnum = 0x1234567812345678;

   puts(Hello World!);

   printf(You are running RIOT on a(n) %s board.\n, RIOT_BOARD);
   printf(This board features a(n) %s MCU.\n, RIOT_MCU);

   printf(longnum %016PRIx64 %016llx\n, longnum, longnum);

Here's a summary of the output from the 4 devices:

  cc2538dk: longnum 1234567820001350 1234567812345678
  samr21-xpro:  longnum 000lx 000lx
  redbee-econotag: longnum 1234567812345678 1234567812345678
  native:   longnum 1234567812345678 1234567812345678

and the compilers I'm using for each:

  cc2538dk:gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66)  
  samr21-xpro: gcc version 4.9.3 20141119 (release) 
[ARM/embedded-4_9-branch revision 218278] (GNU Tools for ARM Embedded 
Processors) 
  redbee-econotag: gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) 
  native:  gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)


Is there something I'm doing that's obviously wrong?

- Ralph

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] printing uint64_t

2015-03-09 Thread Ralph Droms (rdroms)

 On Mar 9, 2015, at 8:55 AM 3/9/15, Oleg Hahm oliver.h...@inria.fr wrote:
 
 Hi Ralph!
 
 Is there something I'm doing that's obviously wrong?
 
 I guess this problem is related to the Newlib-Nano [1] we're using if the
 toolchain supports it. This library doesn't support 64-bit printing. If it's
 required for you, you could try to disable it in the Makefile
 (e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may
 run into memory problems then.

Ah, OK.  Is printing the only limitation to use of 64-bit datatypes?

- Ralph

 
 Cheers,
 Oleg
 
 [1] https://github.com/32bitmicro/newlib-nano-1.0
 -- 
 /*
 *   Should be panic but... (Why are BSD people panic obsessed ??)
 */
linux-2.0.38/net/ipv4/ip_fw.c
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel


Re: [riot-devel] printing uint64_t

2015-03-09 Thread Oleg Hahm
Hi Ralph!

  I guess this problem is related to the Newlib-Nano [1] we're using if the
  toolchain supports it. This library doesn't support 64-bit printing. If it's
  required for you, you could try to disable it in the Makefile
  (e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may
  run into memory problems then.
 
 Ah, OK.  Is printing the only limitation to use of 64-bit datatypes?

Yes, everything else regarding 64-bit datatypes should work as expected.

Cheers,
Oleg
-- 
printk(Penguin %d is stuck in the bottle.\n, i);
linux-2.0.38/arch/sparc/kernel/smp.c


pgpREyXDy5tPW.pgp
Description: PGP signature
___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel