Giter Site home page Giter Site logo

greybus-for-zephyr's People

Contributors

anujdeshpande avatar cfriedt avatar vaishnavachath avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

greybus-for-zephyr's Issues

subsys: greybus: hid protocol

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

build: remove sys-byteorder patch

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.

Issue linking ring buffers for new board support

Hi @cfriedt @Vaishnav98

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?

subsys: greybus: firmware management protocol

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

samples: greybus: additional board support

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.

Connection diagram

image
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

build: generate mnfb at build time rather than runtime

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.

tests: greybus: spi: convert to spi_emul

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.

subsys: greybus: can adc be supported?

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?

update copyright and license

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.

subsys: greybus: generate devicetree using mnfb

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.

subsys: greybus: use a common log level

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.

subsys: greybus: authentication and encryption

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.

subsys: greybus: multiple devices per bundle

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.

manifesto: version bump to eliminate configparser warning

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.

build: run checkpatch and other style checkers

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

subsys: greybus: pwm protocol

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

build: eliminate warnings

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.

subys: greybus: usb protocol

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

build: broken build for cc1352r_sensortag

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.

subsys: greybus: remove deferred init

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.

subsys: greybus: uart protocol

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

doc: readme section for generated greybus manifest

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).

documentation: create a logo

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

build: remove gpio-emul patch

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.

subsys: greybus: camera protocol support

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

subsys: greybus: firmware download protocol

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

subsys: greybus: audio protocol

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

subsys: greybus: create a greybus shell

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.

tests: greybus: i2c: convert to i2c_emul

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.

build: remove gpio-get-direction patch

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.

build: create a build matrix

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).

greybus: tcpip + tls: use a single socket

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().

subsys: greybus: sdio protocol

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

build: run compliance checks

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

test: greybus: gpio: fix gpio on qemu

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.

subsys: greybus: tie log levels into kconfig

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.