|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/23/2019 8:00am-9:00am, Please RSVP
#cal-reminder
Reminder: Zephyr Project: Dev Meeting
When: Thursday, 23 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/993312203
An RSVP is requested. Click here to
Reminder: Zephyr Project: Dev Meeting
When: Thursday, 23 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/993312203
An RSVP is requested. Click here to
|
By
devel@lists.zephyrproject.org Calendar <devel@...>
·
#5995
·
|
|
Re: Moving external components out of the main tree
Hi,
The first HAL (QMSI) was removed from the tree and the west manifest has been updated. Please make sure you run `west update` to update your trees.
Anas
Hi,
The first HAL (QMSI) was removed from the tree and the west manifest has been updated. Please make sure you run `west update` to update your trees.
Anas
|
By
Nashif, Anas
·
#5994
·
|
|
Moving external components out of the main tree
Hi,
Most of you already use the west tool for various things already, including building, flashing, signing and other common operations. One of the main reasons west was introduced was to support
Hi,
Most of you already use the west tool for various things already, including building, flashing, signing and other common operations. One of the main reasons west was introduced was to support
|
By
Nashif, Anas
·
#5993
·
|
|
Re: submitting contributions to Zephyr
That's coming! But that's the easy part. Making core Zephyr 64-bit clean
is the bulk of the work.
That's wonderful! Go figure why I didn't find it when looking exactly
for such a thing.
That's coming! But that's the easy part. Making core Zephyr 64-bit clean
is the bulk of the work.
That's wonderful! Go figure why I didn't find it when looking exactly
for such a thing.
|
By
Nicolas Pitre
·
#5992
·
|
|
Re: submitting contributions to Zephyr
Hi Nicholas!
I for one am definitely excited about a 64-bit RISC-V port of Zephyr!
You might be interested in this tool from GitHub called ‘hub’: https://hub.github.com/ It provides a command-line
Hi Nicholas!
I for one am definitely excited about a 64-bit RISC-V port of Zephyr!
You might be interested in this tool from GitHub called ‘hub’: https://hub.github.com/ It provides a command-line
|
By
Nathaniel Graff
·
#5991
·
|
|
submitting contributions to Zephyr
Hello,
This is my first post here, however it probably won't be the last.
For a while I've been working on making Zephyr to compile for and run on
64-bit targets. That currently works with the
Hello,
This is my first post here, however it probably won't be the last.
For a while I've been working on making Zephyr to compile for and run on
64-bit targets. That currently works with the
|
By
Nicolas Pitre
·
#5990
·
|
|
Re: [Zephyr-builds] zephyr build env for external module
Qipeng,
You should be posting to the devel@ mailing list instead.
To answer your question, this is not supported in zephyr.
Anas
From:<builds@...> on behalf of "Zha, Qipeng"
Qipeng,
You should be posting to the devel@ mailing list instead.
To answer your question, this is not supported in zephyr.
Anas
From:<builds@...> on behalf of "Zha, Qipeng"
|
By
Nashif, Anas
·
#5989
·
|
|
Upcoming Event: Zephyr Project: APIs - Tue, 05/21/2019 9:00am-10:00am, Please RSVP
#cal-reminder
Reminder: Zephyr Project: APIs
When: Tuesday, 21 May 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/177647878
An RSVP is requested. Click here to
Reminder: Zephyr Project: APIs
When: Tuesday, 21 May 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/177647878
An RSVP is requested. Click here to
|
By
devel@lists.zephyrproject.org Calendar <devel@...>
·
#5988
·
|
|
Re: Logging with a string via %s
Why must we support high-speed deferred logging of C strings? Really what is this use-case so compelling that we have to leave sharp edges to developers like this? Is there precedent for this in other
Why must we support high-speed deferred logging of C strings? Really what is this use-case so compelling that we have to leave sharp edges to developers like this? Is there precedent for this in other
|
By
Boie, Andrew P
·
#5987
·
|
|
Re: Logging with a string via %s
Hi,
Logger was redesigned to work in deferred mode (string processing and transport deferred to idle stage) to be capable of handling multiple backends and to be less intrusive than standard in-place
Hi,
Logger was redesigned to work in deferred mode (string processing and transport deferred to idle stage) to be capable of handling multiple backends and to be less intrusive than standard in-place
|
By
Chruściński, Krzysztof
·
#5986
·
|
|
Re: Logging with a string via %s
There's a violation of the "Least Astonishment" principle but it's not with the '%s'. The '%s' traditionally refers to the type of the argument only, it says nothing about memory management. I don't
There's a violation of the "Least Astonishment" principle but it's not with the '%s'. The '%s' traditionally refers to the type of the argument only, it says nothing about memory management. I don't
|
By
Marc Herbert
·
#5985
·
|
|
Re: Logging with a string via %s
It has it's pros and cons. Personally I don't mind it as long as it is well understood and can be turned off.
Here I totally agree. I think that formatting of strings is such a well known standard
It has it's pros and cons. Personally I don't mind it as long as it is well understood and can be turned off.
Here I totally agree. I think that formatting of strings is such a well known standard
|
By
pawel.dunaj@...
·
#5984
·
|
|
Re: Logging with a string via %s
Hello,
"lairdjm" <jamie.mccrae@...> wrote:
Opinions vary on that matter, some people think that the logging was
actually "regressed" and not "improved". Literally, it became
Hello,
"lairdjm" <jamie.mccrae@...> wrote:
Opinions vary on that matter, some people think that the logging was
actually "regressed" and not "improved". Literally, it became
|
By
Paul Sokolovsky
·
#5983
·
|
|
Re: Logging with a string via %s
Hello,
"Boie, Andrew P" <andrew.p.boie@...> wrote:
Some people think that asynchronous logging, forced on unsuspecting
users, is pretty bad idea and make bets when CONFIG_LOG_IMMEDIATE
Hello,
"Boie, Andrew P" <andrew.p.boie@...> wrote:
Some people think that asynchronous logging, forced on unsuspecting
users, is pretty bad idea and make bets when CONFIG_LOG_IMMEDIATE
|
By
Paul Sokolovsky
·
#5982
·
|
|
Re: Logging with a string via %s
Such a "sharp tool" should at least not look exactly like the slow but safe version used absolutely everywhere else.
http://www.catb.org/~esr/writings/taouu/html/ch01s03.html#rule-surprise
On the
Such a "sharp tool" should at least not look exactly like the slow but safe version used absolutely everywhere else.
http://www.catb.org/~esr/writings/taouu/html/ch01s03.html#rule-surprise
On the
|
By
Marc Herbert
·
#5981
·
|
|
Re: Logging with a string via %s
Hi,
I think what confused me is that I was reading about the ‘improved logging’ from this guide:https://foundries.io/insights/2018/08/14/zephyr-logging-part-2/ which doesn’t mention anything
Hi,
I think what confused me is that I was reading about the ‘improved logging’ from this guide:https://foundries.io/insights/2018/08/14/zephyr-logging-part-2/ which doesn’t mention anything
|
By
lairdjm
·
#5980
·
|
|
Re: Logging with a string via %s
For an operating system that aims to support various functional safety certifications, asynchronous rendering of %s is a terrible idea.
I think %s capability should be dropped from the logger’s
For an operating system that aims to support various functional safety certifications, asynchronous rendering of %s is a terrible idea.
I think %s capability should be dropped from the logger’s
|
By
Boie, Andrew P
·
#5979
·
|
|
Re: Logging with a string via %s
Hi,
To optimize time of log processing message construction is deferred. For this reason you cannot use arrays that will not live long enough for logger thread to see them.
In other words you can
Hi,
To optimize time of log processing message construction is deferred. For this reason you cannot use arrays that will not live long enough for logger thread to see them.
In other words you can
|
By
pawel.dunaj@...
·
#5978
·
|
|
Re: [NRF52840] GPIO 1 problem
Hi,
NRF_GPIO_PIN_MAP will effectively change pin number from 6 to (32+6). This would be ok if you use nrfx but when you use Zephyr GPIO API you should use pin id as is. So you should write to
Hi,
NRF_GPIO_PIN_MAP will effectively change pin number from 6 to (32+6). This would be ok if you use nrfx but when you use Zephyr GPIO API you should use pin id as is. So you should write to
|
By
pawel.dunaj@...
·
#5977
·
|
|
Upcoming Event: Zephyr Project: Dev Meeting - Thu, 05/16/2019 8:00am-9:00am, Please RSVP
#cal-reminder
Reminder: Zephyr Project: Dev Meeting
When: Thursday, 16 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/993312203
An RSVP is requested. Click here to
Reminder: Zephyr Project: Dev Meeting
When: Thursday, 16 May 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/993312203
An RSVP is requested. Click here to
|
By
devel@lists.zephyrproject.org Calendar <devel@...>
·
#5976
·
|