C-lib status


Erwin Rol
 

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

#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


Paul Sokolovsky
 

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/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Erwin Rol
 

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

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


Paul Sokolovsky
 

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/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog


Nashif, Anas
 

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

-----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/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Erwin Rol
 

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