Hexdump via logging is supposed to be human-readable for
debug information. Therefore, it should actually print
in human-readable form (well... after some magical decoder
has processed the raw MIPI Sys-T output).
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
GPIOTE channel was not freed when pin was reconfigured. This lead to
channel pool draining when pin was frequently reconfigured.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
If ARM semihosting is selected, automatically enable the pyOCD feature.
This way the console output is directly available on the telnet port.
Signed-off-by: Casper Meijn <casper@meijn.net>
This is the matching commit to the previous one that swaps the
protocol used for window logging for sys_winstream.
The advantage is especially clear for the reader. The old protocol
was complicated and race-prone, requiring whole-buffer reads for
reliability. The new one is tiny and fast.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The newer sys_winstream utility is considerably simpler and much
faster for the reader. Use that instead.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's not uncommon to have Zephyr running in environments where it
shares a memory bus with a foreign/non-Zephyr system (both the older
Intel Quark and cAVS audio DSP systems share this property). In those
circumstances, it would be nice to have a utility that allows an
arbitrary-sized chunk of that memory to be used as a unidirectional
buffered byte stream without requiring complicated driver support.
sys_winstream is one such abstraction.
This code is lockless, it makes no synchronization demands of the OS
or hardware beyond memory ordering[1]. It implements a simple
file/socket-style read/write API. It produces small code and is high
performance (e.g. a read or write on Xtensa is about 60 cycles plus
one per byte copied). It's bidirectional, with no internal Zephyr
dependencies (allowing it to be easily ported to the foreign system).
And it's quite a bit simpler (especially for the reader) than the
older cAVS trace protocol it's designed to replace.
[1] Which means that right now it won't work reliably on arm64 until
we add a memory barrier framework to Zephyr! See notes in the code;
the locations for the barriers are present, but there's no utility to
call.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
If the advertiser is not running, the host can now set
periodic advertising data in multiple operations.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Provide possibility to have instance specific callbacks
for writing the FW image and executing the update
Signed-off-by: Jarno Lamsa <jarno.lamsa@nordicsemi.no>
Previously the object 5 was only single instance object. Provide
backwards compatibility, so it can be continued to use with single
instance.
Signed-off-by: Jarno Lamsa <jarno.lamsa@nordicsemi.no>
This is a proof-of-concept implementation.
A device might have multiple firmware images which needs to be updated
separately. For example a single device might have
* A bootloader image
* An application image
* External firmware image
Instead of pushing all these updates through the object instance 0 -
/5/0 - here a split to multiple has been made possible.
Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
This PR adds the different handling of temperature sensor for the
STM32L5 soc. In this soc, there are some calibration settings which
need to be applied for temperature conversion.
Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
moving the conversion from adc value to the get function
which will be used for different handling of stm32 temp sensors
Signed-off-by: Wouter Cappelle <wouter.cappelle@crodeon.com>
The dts binding general rules document states that the property
description should explain why the default value was selected
(e.g. "default is the value at power-on").
See comment in #41143
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Ensure that cpu1 only has its image load offset and flash size changed
if BUILD_WITH_TFM is selected, to prevent the flash size being changed
when TFM_BL2=n because TFM dependencies are not met.
Fixes#41127
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
Provides interface, data structures and demuxing capability for ISO RX
PDU allocation and transport from LLL to HCI.
Uses the RXFIFO composite for simplicity and reduced overhead.
Signed-off-by: Morten Priess <mtpr@oticon.com>
This adds the necessary API calls to support the hardware feature of
suspending and resuming active DMA channels. The hardware feature is
supported by at least Synopsys's DesignWare DMA and NXP's eDMA.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
The overall code coverage report of mps2_an385 was blocked by the
tests/net/lib/coap, the error message shows "No Mem available to
continue dump". So we enlarge the gcov heap size to prevent this
situation, try to make the report can be generated at least.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
Just minor styling changes to capitalize the first character
and removing the trailing comma on the brief doc description
on two copy functions.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Doxygen treats "/**" as documentation even if the comment block
is inside the function. So remove the extra asterisk for those
"TESTPOINT" comments.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
