cfriedt / greybus-for-zephyr Goto Github PK
View Code? Open in Web Editor NEWGreybus Module for the Zephyr Real-Time Operating System
License: BSD 3-Clause "New" or "Revised" License
Greybus Module for the Zephyr Real-Time Operating System
License: BSD 3-Clause "New" or "Revised" License
Once zephyrproject-rtos/zephyr#29029 is merged, we can remove zephyr-dynamic-pthread-stacks.patch
from the build process. This ticket is here to track the upstream ticket and ensure it gets merged eventually.
The README.rst
file should be updated to reflect the patches that must be applied.
Currently, Greybus for Zephyr does not support the Greybus HID protocol.
This change should include platform-specific changes to enable Greybus HID protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr HID APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
This patch is required to include Zephyr's sys/byteorder.h
when the target platform is posix_native
, posix_native_64
, or nrf52_bsim
.
There is not yet an issue upstream in Zephyr to apply this fix, but that should be a part of completing this ticket.
The README.rst
file should be updated to reflect the patches that must be applied.
depends on
should be preferred to select
prj.conf
of tests and samples instead of in subsys/greybus
I am trying to add support for UART transport, and ran into some issues
arm-zephyr-eabi/arm-zephyr-eabi"/lib/thumb/v7e-m+fp/hard -specs=nano.specs && :
/home/anuj/zephyr-sdk-0.12.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/../../../../arm-zephyr-eabi/bin/ld: modules/greybus/subsys/greybus/lib..__greybus__subsys__greybus.a(transport-uart.c.obj): in function `uart_work_fn':
/home/anuj/zephyrproject/greybus/subsys/greybus/platform/transport-uart.c:57: undefined reference to `ring_buf_get'
/home/anuj/zephyr-sdk-0.12.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/../../../../arm-zephyr-eabi/bin/ld: /home/anuj/zephyrproject/greybus/subsys/greybus/platform/transport-uart.c:82: undefined reference to `ring_buf_get'
/home/anuj/zephyr-sdk-0.12.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/../../../../arm-zephyr-eabi/bin/ld: modules/greybus/subsys/greybus/lib..__greybus__subsys__greybus.a(transport-uart.c.obj): in function `gb_xport_uart_isr':
/home/anuj/zephyrproject/greybus/subsys/greybus/platform/transport-uart.c:195: undefined reference to `ring_buf_get'
/home/anuj/zephyr-sdk-0.12.3/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/../../../../arm-zephyr-eabi/bin/ld: /home/anuj/zephyrproject/greybus/subsys/greybus/platform/transport-uart.c:204: undefined reference to `ring_buf_put'
I saw this with both stm32f3_disco
and lpcxpresso55s69_cpu0
. This was after I added the requisite board conf and overlay files.
I am trying to understand what these chipsets need to support in order for UART to work. One thing I did realize that both these chips have usart and not uart in their device trees under Zephyr. Could that be a problem when adding support for them?
Once zephyrproject-rtos/zephyr#30363 is merged, we can remove zephyr-aligned-allocators.patch
from the build process. This ticket is here to track the upstream ticket and ensure it gets merged eventually.
The README.rst
file should be updated to reflect the patches that must be applied.
Probably both the net
and uart
demos could have their gb_transport_backend_init()
functions move to gb_xport_init()
.
It seems like the logical place for that and then we remove the gb_transport_backend_init()
symbol altogether.
Currently, Greybus for Zephyr does not support the Greybus Firmware Management protocol.
This change should include platform-specific changes to enable Greybus Firmware Management protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr Firmware Mangement APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
To comply with Zephyr's Module Guidelines, all code should be checked for being appropriately licensed.
Zephyr's license_check might be able to help with that.
The main BLE platform has so far been nrf52840dk_nrf52840
. We should create an overlay and conf for that board.
Additionally, although the uart sample has recently been updated, it is not a main focus of this project, it might be good to add board-specific overlays and conf files there too.
Hey @cfriedt
I am trying to wire up my Linux machine to a CC1352 Launch board. I start gbridge with sudo ./gbridge -p /dev/ttyS0 -b 115200
where S0 is the port that I have connected to the DIO12/DIO13 pins of CC1352 launch board. Along with GND. Are there any other pins that I am supposed to wire up? Running the UART example
It was originally unclear how to generate code (from say, a binary file) and include it as a C array before.
The correct cmake function to use is here and is called generate_inc_file
.
We will also need to create a function (along with a python script) to convert the flattened .dts
to a .mnfs
file.
Once that is done, we can convert the .mnfs
to a .mnfb
, and call generate_inc_file
to include the binary .mnfb
directly in C.
Previously, the spi tests were developed using spi_sim, but the spi emulator that eventually made it into zephyr is called spi_emul.
It isn't clear if spi_emul has an API that is similar to spi_sim, but the existing tests must be converted to use the API that is upstream.
Are there plans to add ADC support? I see in the Greybus spec, in Chapter 11 Bridged PHY Connection Protocols
that there is no mention of ADC. Is this something that would first be added to Greybus on the host, before considering that here?
Friedt Professional Engineering Services copyright should be on a number of files.
Some sources are missing copyright.
New files should also be checked for copyright.
This should be checked in CI as well (relates to #4).
Additionally, I think it would be appropriate to be consistent and use the BSD license everywhere in this project, as that is what was originally used in the NuttX code, and BSD is a permissible license that is acceptable to the Zephyr Project.
Greybus for Zephyr currently configures hardware and peripherals at compile-time The Zephyr Way using DeviceTree.
However, it might be desirable to automatically generate a DT overlay file based on an existing .mnfb
(Manifest Binary) file (a .mnfb
file is a binary equivalent representation of an .mnfs
file and the process is reversible).
That would require some intimate knowledge of the platform and its peripherals, so likely it would need to be done in python, and each supported board would require some file specializing some peripheral mapping.
Ideally, this boils down to making a reversible, extensible, .dts to .mnfs translator. It should probably be added to gbutil.py.
Doing so might be more of a convenience than anything and it should not be a requirement for any milestone. More of an eventual "nice to have".
Also, this does nothing to solve the problem of dynamically configuring peripherals at boot time based on the manifest loaded (from an SD card or EEPROM). Probably the only approach that will work there is to have a "catch all" DT overlay that activates each peripheral that any possible manifest would require. Then at least device instances will not be stripped out of the Zephyr binary.
It might not be ultimately the best to use only 1 level, but currently log levels are hard coded inside of several files.
For now, join them to a single Kconfig variable.
Maybe at a later date, log levels can be adjusted per-component.
While there was some original work that targeted authentication and encryption, it was primarily a proof of concept. The PoC used two SSH keys and some python code to emulate a device. The authentication and encryption messages themselves were assigned greybus message types out of the "reserved" numerical range.
The PoC code was more or less identical to what standard TLS does, with the absence of verifying a certificate against a trusted 3rd party Certificate Authority.
Due to the nature of how CPorts are implemented in TCP/IP, and that each CPort is independent of the others, each service is required to perform authentication and encryption independently.
It would be ideal to support industry standard TLS rather than using some custom method. Zephyr provides support for mbedTLS as well as special BSD socket options for TLS security.
The approach that will likely be taken with the initial TLS implementation will be that certificates will likely be self-signed and they will be distributed at build time.
Also, it is unclear whether TLS supports some kind of "NULL" security equivalent to plain-text that can be automatically used during the negotiation phase. If something like that does not exist, then it will be necessary to fix security at build-time both on the Linux side and on the microcontroller side.
The original NuttX implementation only supported one device (CPort) per Bundle. However, the natural direction of Greybus is to support multiple devices (CPorts) per Bundle.
It's likely that some refactorization will be required to achieve this.
The only remaining warning that existed when building Greybus for Zephyr (in #34) was fixed by cfriedt/manifesto#2.
manifesto:453: DeprecationWarning: This method will be removed in future versions. Use 'parser.read_file()' instead.
cfg_parser.readfp(f)
There are still some Kconfig warnings when building for native_posix_64
but that is ok, I think.
Currently, whitespace is a bit of chaos. Zephyr has fairly strict requirements for coding style and we want to adhere to those.
This change will include a bulk whitespace fixup (which everyone loves, of course).
Additionally, we should run the checkpatch.pl to ensure that coding style conventions are preserved for any new PRs
Currently, Greybus for Zephyr does not support the Greybus PWM protocol.
This change should include platform-specific changes to enable Greybus PWM protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr PWM APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
CI should generate HTML documentation and automatically deploy site updates.
We should pull in the Zephyr logo as well.
Currently tests and samples build with a number of warnings.
We should compile with zero warnings.
A frequent warning has to do with const
-ness of things at the device init stage.
Currently, Greybus for Zephyr does not support the Greybus USB protocol.
This change should include platform-specific changes to enable Greybus USB protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr USB APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
If following the instructions in the README and using BOARD=cc1352r_sensortag
with the following build options, then the sample application fails to compile due to devicetree issues.
$ west build -b cc1352r_sensortag -t flash ../greybus/samples/subsys/greybus/net -- -DOVERLAY_CONFIG=overlay-802154.conf -DCONFIG_NET_CONFIG_IEEE802154_DEV_NAME=\"IEEE802154_0\" -DCONFIG_IEEE802154_CC13XX_CC26XX=y -DCONFIG_IEEE802154_CC13XX_CC26XX_SUB_GHZ=n
Error:
In file included from /home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_macro.h:34,
from /home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util.h:17,
from /home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/list_gen.h:12,
from /home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/slist.h:22,
from /home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/drivers/gpio.h:19,
from /home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/greybus/subsys/greybus/platform/gpio.c:1:
zephyr/include/generated/devicetree_unfixed.h:1149:52: error: 'DT_N_S_greybus0_S_gbbundle1_S_gbgpio0_P_label' undeclared here (not in a function); did you mean 'DT_N_S_greybus0_S_gbbundle3_S_gbspi0_P_label'?
1149 | #define DT_N_INST_0_zephyr_greybus_gpio_controller DT_N_S_greybus0_S_gbbundle1_S_gbgpio0
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_internal.h:65:26: note: in definition of macro '__DEBRACKET'
65 | #define __DEBRACKET(...) __VA_ARGS__
| ^~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_internal.h:57:2: note: in expansion of macro '__GET_ARG2_DEBRACKET'
57 | __GET_ARG2_DEBRACKET(one_or_two_args _if_code, _else_code)
| ^~~~~~~~~~~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_internal.h:52:2: note: in expansion of macro '__COND_CODE'
52 | __COND_CODE(_XXXX##_flag, _if_1_code, _else_code)
| ^~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_macro.h:117:2: note: in expansion of macro 'Z_COND_CODE_1'
117 | Z_COND_CODE_1(_flag, _if_1_code, _else_code)
| ^~~~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/devicetree.h:1986:2: note: in expansion of macro 'COND_CODE_1'
1986 | COND_CODE_1(DT_HAS_COMPAT_STATUS_OKAY(DT_DRV_COMPAT), \
| ^~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/device.h:171:2: note: in expansion of macro 'Z_DEVICE_DEFINE'
171 | Z_DEVICE_DEFINE(node_id, node_id, DT_LABEL(node_id), init_fn, \
| ^~~~~~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/devicetree.h:393:32: note: in expansion of macro 'DT_CAT'
393 | #define DT_PROP(node_id, prop) DT_CAT(node_id, _P_##prop)
| ^~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/devicetree.h:496:27: note: in expansion of macro 'DT_PROP'
496 | #define DT_LABEL(node_id) DT_PROP(node_id, label)
| ^~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/device.h:171:36: note: in expansion of macro 'DT_LABEL'
171 | Z_DEVICE_DEFINE(node_id, node_id, DT_LABEL(node_id), init_fn, \
| ^~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/device.h:186:2: note: in expansion of macro 'DEVICE_DT_DEFINE'
186 | DEVICE_DT_DEFINE(DT_DRV_INST(inst), __VA_ARGS__)
| ^~~~~~~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_internal.h:106:36: note: in expansion of macro 'DT_N_INST_0_zephyr_greybus_gpio_controller'
106 | #define UTIL_PRIMITIVE_CAT(a, ...) a##__VA_ARGS__
| ^
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_internal.h:105:26: note: in expansion of macro 'UTIL_PRIMITIVE_CAT'
105 | #define UTIL_CAT(a, ...) UTIL_PRIMITIVE_CAT(a, __VA_ARGS__)
| ^~~~~~~~~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/devicetree.h:297:31: note: in expansion of macro 'UTIL_CAT'
297 | #define DT_INST(inst, compat) UTIL_CAT(DT_N_INST, DT_DASH(inst, compat))
| ^~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/devicetree.h:1589:27: note: in expansion of macro 'DT_INST'
1589 | #define DT_DRV_INST(inst) DT_INST(inst, DT_DRV_COMPAT)
| ^~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/device.h:186:19: note: in expansion of macro 'DT_DRV_INST'
186 | DEVICE_DT_DEFINE(DT_DRV_INST(inst), __VA_ARGS__)
| ^~~~~~~~~~~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/greybus/subsys/greybus/platform/gpio.c:154:9: note: in expansion of macro 'DEVICE_DT_INST_DEFINE'
154 | DEVICE_DT_INST_DEFINE(_num, \
| ^~~~~~~~~~~~~~~~~~~~~
zephyr/include/generated/devicetree_unfixed.h:2776:65: note: in expansion of macro 'DEFINE_GREYBUS_GPIO_CONTROL'
2776 | #define DT_FOREACH_OKAY_INST_zephyr_greybus_gpio_controller(fn) fn(0)
| ^~
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/zephyr/include/sys/util_internal.h:106:36: note: in expansion of macro 'DT_FOREACH_OKAY_INST_zephyr_greybus_gpio_controller'
106 | #define UTIL_PRIMITIVE_CAT(a, ...) a##__VA_ARGS__
| ^
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/greybus/subsys/greybus/platform/gpio.c:160:1: note: in expansion of macro 'DT_INST_FOREACH_STATUS_OKAY'
160 | DT_INST_FOREACH_STATUS_OKAY(DEFINE_GREYBUS_GPIO_CONTROL);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
[185/248] Building C object modules/greybus/subsys/greybus/CMakeFiles/..__greybus__subsys__greybus.dir/platform/i2c.c.obj
/home/cfriedt/Desktop/greybus-for-zephyr-build/zephyrproject/greybus/subsys/greybus/platform/i2c.c:97:13: warning: Macro is deprecated
97 | DT_INST_FOREACH_STATUS_OKAY(DEFINE_GREYBUS_I2C_CONTROL);
| ^~~~~~~~~~~~~~~~~~~~~
[187/248] Building C object modules/greybus/subsys/greybus/CMakeFiles/..__greybus__subsys__greybus.dir/spi.c.obj
ninja: build stopped: subcommand failed.
Currently, Greybus for Zephyr has a deferred init mechanism that is used to insure all devices are probed before the bus is finally initialized.
The fundamental issue here is that devices in Zephyr are probed in a somewhat random order and not in an order that is consistent with Device Tree (i.e. parent devices should be automatically probed before child devices).
It should be possible to remove the deferred init mechanism by specifying different init priorities for the bus itself, string descriptors, bundles, interfaces, and cports.
Currently, Greybus for Zephyr does not support the Greybus UART protocol.
This change should include platform-specific changes to enable Greybus UART protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr UART APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
The Greybus Manifest Source file (.mnfs) and the Greybus Manifest Binary file (.mnfb) are both generated automatically from a board's DeviceTree overlay file (.dts).
Users might want to extract those build artefacts, so there should be some information in the README
about where to find them (namely, at build/zephyr/greybus.mnfs and build/zephyr/greybus.mnfb, respectively).
It's kind of messy mixing west with git submodules. Oh well.
git -C greybus submodule init
git -C greybus submodule update
It would also be nice to have an SVG logo specifically for the Greybus for Zephyr project.
The logo should be added to documentation and should be available for usage under the Creative Commons license, or similar.
This issue is related to #16
Once zephyrproject-rtos/zephyr#26484 is merged, we can remove zephyr-gpio-emul.patch
from the build process. This ticket is here to track the upstream ticket and ensure it gets merged eventually.
The README.rst
file should be updated to reflect the patches that must be applied.
Currently, Greybus for Zephyr does not support the Greybus Camera protocol.
This change should include platform-specific changes to enable Greybus Camera protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr Camera APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
Currently, Greybus for Zephyr does not support the Greybus Firmware Download protocol.
This change should include platform-specific changes to enable Greybus Firmware Download protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr Firmware Download APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
Currently, Greybus for Zephyr does not support the Greybus Audio protocol.
This change should include platform-specific changes to enable Greybus Audio protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr Audio APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
It would be great to have a shell available to query Greybus statistics, capabilities, settings, and resources.
This would just tie the into the regular Zephyr shell in the usual way.
Previously, the i2c tests were developed using i2c_sim, but the i2c emulator that eventually made it into zephyr is called i2c_emul.
It isn't clear if i2c_emul has an API that is similar to i2c_sim, but the existing tests must be converted to use the API that is upstream.
There is not yet a PR in Zephyr to support querying any kind of state from GPIO devices.
It has previously been stated that the application should keep track of any such state.
However, as a generalization, the hardware itself keeps track of GPIO state. Whether or not it's possible to query those values from hardware is another issue. Also synchronization of those values is yet another issue.
The existing patch simply keeps track of GPIO state in software, but the eventual API should be flexible enough to allow specific drivers to implement it with hardware-specific register accesses or alternatively using the basic software approach.
The README.rst file should be updated to reflect the patches that must be applied.
Currently CI builds and runs GPIO
and GPIO (TLS)
tests for native_posix_64
as well as qemu_cortex_m3
.
Additionally, it builds sample applications for a number of different boards.
It would be ideal to use a build matrix to reduce the number of lines in the GitHub Actions workflow (module.yml).
Create a doc/tls.rst
file that describes the options that should be selected for TLS.
It would be nice to display a badge with test coverage metrics.
Some macros were deprecated in zephyrproject-rtos/zephyr#30766
DEVICE_AND_API_INIT -> DEVICE_DT_INST_DEFINE
DEVICE_GET -> DEVICE_DT_INST_GET
DEVICE_DECLARE -> DEVICE_DT_INST_DECLARE
Currently there are warnings from the toolchain and we would have liked to get rid of all warnings in #1
The Zephyr example application is the authority for how Zephyr modules should be organized.
Additionally, with the release of v2.7.0 (LTS2), we should change which rev we point to.
It would also make sense to adopt a similar tagging convention for tagged releases.
E.g. update west.yml to point at v2.7.0
, tag v2.7.0, and and then update west.yml to point at main
When v2.7.1 is tagged, similarly, we should update.
The TLS transport works. However, TLS is incredibly memory intensive. The problem is multiplied several times over with each active TLS service and connection.
As a space optimization (in terms of dynamic memory requirements) a good solution would be to "concentrate" all Greybus connections through a single TCP/IP port by stuffing the CPort ID inside of one of the reserved portions of the Greybus Message Header, much like the UART transport already does.
It's is likely to be a win-win, as all communications need to go through a single physical connection regardless of the transport used.
The original gbridge author probably thought it might be better to map CPorts to TCP/IP ports for performance purposes, but since every greybus handler is threaded anyway, things will be handled async anyway.
We'll be optimistic in assuming that higher-bandwidth Greybus protocols do not start the lower bandwidth ones.
This feature is mirrored in cfriedt/gbridge#8.
For details, see cport_pack() / cport_unpack().
Currently, Greybus for Zephyr does not support the Greybus SDIO protocol.
This change should include platform-specific changes to enable Greybus SDIO protocol support in Zephyr. The change should add code that enables the original NuttX code to interface with any required Zephyr SDIO APIs.
Tests and sample applications should be included as well to demonstrate functionality in CI and on hardware
Zephyr has some scripts that check various compliance items (the compliance items are selectable). This will catch things like missing copyright notices but it can be configured to catch virtually every issue.
It might be worth it to skip subsys/greybus/*.c
but to check subsys/greybus/platform/
because much of the original NuttX code will likely not adhere to the same styles that Zephyr uses. A not necessarily obvious goal is to also leave much of the original NuttX / Greybus code intact as-is with as little change as possible.
https://github.com/zephyrproject-rtos/zephyr/blob/master/.github/workflows/compliance.yml
Qemu already has a GPIO device that Zephyr uses but it lacks proper emulation support.
We need to use Qemu for #25 because native_posix
targets the Linux socket API which does not support the TLS extensions.
Also, it's better to get Qemu working without TLS support first, as that is a separable problem.
qsort(3) became part of that standard C library with C99. Should probably be added to Zephyr's minimal libc implementation. I can't recall if Zephyr's newlib includes qsort()
atm.
This ticket is here to track cfriedt/gbridge#6
Currently, some greybus components use CONFIG_GREYBUS_LOG_LEVEL
but others just have their log levels hard-coded.
It might not be best to use a single log level for all Greybus components (i.e. eventually they could each have their own independent Kconfig setting) but for now it's better to tie them all into a single Kconfig variable than to hard-code them.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.