|
Hey Anas, On 12-6-2017 19:45, Nashif, Anas wrote: Not following how this is related to Posix and feature of 1.9.
AFAIK, What is missing is a hook for gettimeofday in
lib/libc/newlib/libc-hooks.c which can then get the needed information
from the underlying hardware. We could provide a dummy and a way to
connect this to RTC drivers or the kenel timers for example... Yeah newlib offers hooks for a lot of things, but that not just means changing Zephyr, but also the toolchains (if I understood correctly). And here is where the 1.9 features come in, if 1.9 will have big changes to both API's and toolchain building I'll rather wait until that is done (or at least started) before trying to apply patches now. For now I rather focus on stuff like missing drivers, I got a prototype eth_stm32_hal driver for Ethernet. I will need something to do LIN-like RS485 (BREAK as sync on a half duplex bus) and I need CAN. Those things I could use under other OSes (like FreeRTOS or RTEMS) too, which gives me a possibility to contribute to Zephyr and have a backup plan for my work. Even though I am complaining (we Dutch always have something to complain), Zephyr really surprised me in a positive way. It was real easy to add the olimex_stm32_e407 bsp, and the Ethernet drivers wasn't that difficult apart from understanding the alternate function setup of the GPIO's. - Erwin
|
|
|
Not following how this is related to Posix and feature of 1.9.
AFAIK, What is missing is a hook for gettimeofday in lib/libc/newlib/libc-hooks.c which can then get the needed information from the underlying hardware. We could provide a dummy and a way to connect this to RTC drivers or the kenel timers for example...
Anas
toggle quoted messageShow quoted text
-----Original Message----- From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Paul Sokolovsky Sent: Monday, June 12, 2017 9:42 AM To: Erwin Rol <mailinglists@...> Cc: zephyr-devel@... Subject: Re: [Zephyr-devel] C-lib status Hello Erwin, On Sun, 11 Jun 2017 16:34:21 +0200 Erwin Rol <mailinglists@...> wrote: Hey Paul,
time() was just the first thing I tried to see how well newlib works,
and the results was it doesn't. And that it compiles without warning
and than hangs in an endless loop sounds like a bug to me, no matter
how useful/useless a time() call would be. I'm sure everyone would agree, so it's worth considering how to "fix" it (even it will be a workaround or incomplete fix) and do that. But your point about version 1.9 is interesting, "POSIX API Layer",
"BSD Socket Support", "Build and Configuration System", and "Zephyr
SDK NG" sound like very big changes to how Zephyr can/should be used. Well, it's true that Zephyr currently undergoes extensive (vs intensive) growth, with a lot of functionality being both added and planned. But there may be omissions, gaps, and plain bugs in that functionality. While all that's not ideal, I (even though I'm just an engineer) personally think that, given the competitive RTOS landscape, it's the best approach so far - try to offer more functionality and support than other RTOSes and by that, attract wide community so "any bug becomes shallow". I think I'll wait for that release (when it really comes in August) to
reevaluate if Zephyr is usable for me or if it would be better to put
energy and effort in for example RTEMS. Sounds good, but unfortunately we aren't yet have enough eyes (and hands) to proverbially make any bug shallow, so if you consider that time() would be really useful for Zephyr applications, or its current behavior very problematic, I'd encourage you to do something about it - at the very least, submit a bug for it at http://jira.zephyrproject.org/
- Erwin
On 10-6-2017 14:12, Paul Sokolovsky wrote:
Hello Erwin,
On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:
Hey all (yeah there he is again),
I was wondering what the status and planning is for the C-library?
I tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL) When you want time(NULL), what are your expectations? Because as you
know, what it's supposed to do is to return number of seconds since
1970-01-01. Does your board even have an idea how long ago 1970 was?
I own ~ couple of dozens of MCU boards, and none of them has
battery-backed RTC as required to know when 1970-01-01 was. The
remaining alternative is to pray that a board has MCU-internal RTC
which doesn't reset with MCU reset, and set it up (usually manually)
on each power up, which is hardly practical.
function), so I selected newlibc. That compiles but doesn't work,
it ends up in an endless loop where gettimeofday calls
_gettimeofday_r and that calls gettimeofday again (see stack trace
below).
Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ? I guess a fair answer is that Zephyr will never work like Linux.
Otherwise, functions which make sense for MCU boards get tried in
one by one manner, issues found and fixed (e.g. errno didn't work
for newlib few weeks ago:
https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19).
Otherwise, if you read TSC planning notes for 1.9, they include
"POSIX API". It's not very clear what that means, but making time()
work somehow would fit that line, but as usual would require
stakeholders interested to RFC and implement it.
Otherwise, Zephyr has native time API which you can use to measure
duration between events, etc.
- Erwin
[] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ Zephyr-devel mailing list Zephyr-devel@... https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hello Erwin, On Sun, 11 Jun 2017 16:34:21 +0200 Erwin Rol <mailinglists@...> wrote: Hey Paul,
time() was just the first thing I tried to see how well newlib works,
and the results was it doesn't. And that it compiles without warning
and than hangs in an endless loop sounds like a bug to me, no matter
how useful/useless a time() call would be. I'm sure everyone would agree, so it's worth considering how to "fix" it (even it will be a workaround or incomplete fix) and do that. But your point about version 1.9 is interesting, "POSIX API Layer",
"BSD Socket Support", "Build and Configuration System", and "Zephyr
SDK NG" sound like very big changes to how Zephyr can/should be used. Well, it's true that Zephyr currently undergoes extensive (vs intensive) growth, with a lot of functionality being both added and planned. But there may be omissions, gaps, and plain bugs in that functionality. While all that's not ideal, I (even though I'm just an engineer) personally think that, given the competitive RTOS landscape, it's the best approach so far - try to offer more functionality and support than other RTOSes and by that, attract wide community so "any bug becomes shallow". I think I'll wait for that release (when it really comes in August) to
reevaluate if Zephyr is usable for me or if it would be better to put
energy and effort in for example RTEMS. Sounds good, but unfortunately we aren't yet have enough eyes (and hands) to proverbially make any bug shallow, so if you consider that time() would be really useful for Zephyr applications, or its current behavior very problematic, I'd encourage you to do something about it - at the very least, submit a bug for it at http://jira.zephyrproject.org/
- Erwin
On 10-6-2017 14:12, Paul Sokolovsky wrote:
Hello Erwin,
On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:
Hey all (yeah there he is again),
I was wondering what the status and planning is for the C-library?
I tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL) When you want time(NULL), what are your expectations? Because as you
know, what it's supposed to do is to return number of seconds since
1970-01-01. Does your board even have an idea how long ago 1970
was? I own ~ couple of dozens of MCU boards, and none of them has
battery-backed RTC as required to know when 1970-01-01 was. The
remaining alternative is to pray that a board has MCU-internal RTC
which doesn't reset with MCU reset, and set it up (usually manually)
on each power up, which is hardly practical.
function), so I selected newlibc. That compiles but doesn't work,
it ends up in an endless loop where gettimeofday calls
_gettimeofday_r and that calls gettimeofday again (see stack trace
below).
Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ? I guess a fair answer is that Zephyr will never work like Linux.
Otherwise, functions which make sense for MCU boards get tried in
one by one manner, issues found and fixed (e.g. errno didn't work
for newlib few weeks ago:
https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19).
Otherwise, if you read TSC planning notes for 1.9, they include
"POSIX API". It's not very clear what that means, but making time()
work somehow would fit that line, but as usual would require
stakeholders interested to RFC and implement it.
Otherwise, Zephyr has native time API which you can use to measure
duration between events, etc.
- Erwin
[] -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
|
Hey Paul,
time() was just the first thing I tried to see how well newlib works,
and the results was it doesn't. And that it compiles without warning and
than hangs in an endless loop sounds like a bug to me, no matter how
useful/useless a time() call would be.
But your point about version 1.9 is interesting, "POSIX API Layer", "BSD
Socket Support", "Build and Configuration System", and "Zephyr SDK NG"
sound like very big changes to how Zephyr can/should be used.
I think I'll wait for that release (when it really comes in August) to
reevaluate if Zephyr is usable for me or if it would be better to put
energy and effort in for example RTEMS.
- Erwin
toggle quoted messageShow quoted text
On 10-6-2017 14:12, Paul Sokolovsky wrote: Hello Erwin,
On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:
Hey all (yeah there he is again),
I was wondering what the status and planning is for the C-library? I
tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL) When you want time(NULL), what are your expectations? Because as you
know, what it's supposed to do is to return number of seconds since
1970-01-01. Does your board even have an idea how long ago 1970 was? I
own ~ couple of dozens of MCU boards, and none of them has
battery-backed RTC as required to know when 1970-01-01 was. The
remaining alternative is to pray that a board has MCU-internal RTC
which doesn't reset with MCU reset, and set it up (usually manually)
on each power up, which is hardly practical.
function), so I selected newlibc. That compiles but doesn't work, it
ends up in an endless loop where gettimeofday calls _gettimeofday_r
and that calls gettimeofday again (see stack trace below).
Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ? I guess a fair answer is that Zephyr will never work like Linux.
Otherwise, functions which make sense for MCU boards get tried in one by
one manner, issues found and fixed (e.g. errno didn't work for newlib
few weeks ago:
https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19).
Otherwise, if you read TSC planning notes for 1.9, they include
"POSIX API". It's not very clear what that means, but making time()
work somehow would fit that line, but as usual would require
stakeholders interested to RFC and implement it.
Otherwise, Zephyr has native time API which you can use to measure
duration between events, etc.
- Erwin
#0 gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#1 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#2 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#3 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#4 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#5 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#6 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#7 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#8 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#9 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#10 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#11 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#12 0x080008ee in time (t=t@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/time/time.c:46
#13 0x0800094a in main ()
at /home/erwin/zephyr/samples/hello_world/src/main.c:43 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|
Hello Erwin, On Sat, 10 Jun 2017 13:38:33 +0200 Erwin Rol <mailinglists@...> wrote: Hey all (yeah there he is again),
I was wondering what the status and planning is for the C-library? I
tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL) When you want time(NULL), what are your expectations? Because as you know, what it's supposed to do is to return number of seconds since 1970-01-01. Does your board even have an idea how long ago 1970 was? I own ~ couple of dozens of MCU boards, and none of them has battery-backed RTC as required to know when 1970-01-01 was. The remaining alternative is to pray that a board has MCU-internal RTC which doesn't reset with MCU reset, and set it up (usually manually) on each power up, which is hardly practical. function), so I selected newlibc. That compiles but doesn't work, it
ends up in an endless loop where gettimeofday calls _gettimeofday_r
and that calls gettimeofday again (see stack trace below).
Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ? I guess a fair answer is that Zephyr will never work like Linux. Otherwise, functions which make sense for MCU boards get tried in one by one manner, issues found and fixed (e.g. errno didn't work for newlib few weeks ago: https://github.com/zephyrproject-rtos/zephyr/commit/8cc6f6ddd6e0ff882ec5bd10700058df345cea19). Otherwise, if you read TSC planning notes for 1.9, they include "POSIX API". It's not very clear what that means, but making time() work somehow would fit that line, but as usual would require stakeholders interested to RFC and implement it. Otherwise, Zephyr has native time API which you can use to measure duration between events, etc.
- Erwin
#0 gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#1 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#2 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#3 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#4 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#5 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#6 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#7 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#8 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#9 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#10 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720
<_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#11 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>,
ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>,
ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#12 0x080008ee in time (t=t@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/time/time.c:46
#13 0x0800094a in main ()
at /home/erwin/zephyr/samples/hello_world/src/main.c:43 _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
-- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
|
Hey all (yeah there he is again),
I was wondering what the status and planning is for the C-library? I
tried a simple example and I guess I directly hit a problem. The
"buildin" mini C-lib doesn't offer much (I wanted the time(NULL)
function), so I selected newlibc. That compiles but doesn't work, it
ends up in an endless loop where gettimeofday calls _gettimeofday_r and
that calls gettimeofday again (see stack trace below).
Am I doing something wrong here (Zephyr configuration or something like
that) or is newlib support just not yet ready to use ?
- Erwin
toggle quoted messageShow quoted text
#0 gettimeofday (ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#1 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>, ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#2 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#3 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>, ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#4 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#5 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>, ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#6 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#7 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>, ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#8 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#9 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>, ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#10 0x0800093c in gettimeofday (ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/syscalls/sysgettod.c:12
#11 0x0800091c in _gettimeofday_r (ptr=0x20000008 <impure_data>, ptimeval=ptimeval@entry=0x20001720 <_main_stack+4052>, ptimezone=ptimezone@entry=0x0)
at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/reent/gettimeofdayr.c:71
#12 0x080008ee in time (t=t@entry=0x0) at /usr/src/debug/newlib/2.4.0-r0/newlib-2.4.0/newlib/libc/time/time.c:46
#13 0x0800094a in main () at /home/erwin/zephyr/samples/hello_world/src/main.c:43
|
|
|
