On Sun, 11 Jun 2017 16:34:21 +0200
Erwin Rol <mailinglists@...> wrote:
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 athttp://jira.zephyrproject.org/
On 10-6-2017 14:12, Paul Sokolovsky wrote:
On Sat, 10 Jun 2017 13:38:33 +0200
Erwin Rol <mailinglists@...> wrote:
Hey all (yeah there he is again),When you want time(NULL), what are your expectations? Because as you
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)
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,I guess a fair answer is that Zephyr will never work like Linux.
it ends up in an endless loop where gettimeofday calls
_gettimeofday_r and that calls gettimeofday again (see stack trace
Am I doing something wrong here (Zephyr configuration or something
like that) or is newlib support just not yet ready to use ?
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:
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.
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