The SAM4L have a unique I2C driver. It shares simultaneously pins for
both master and slave controllers. Each controller have their own
instance. This introduces the TWIM controller that handles only the
master part.
The TWIM controller uses no copy and the driver was prepared to work
with both 7 and 10 bits address. The controller can handler up to 256
bytes for a single transfer allowing long data communication with
almost no CPU intervention.
The driver was wrote specifically to Zephyr. It receives a transfer
list of from upper layers to a specific device on the bus. It programs
the first and second transfer, if it exists, before start. At end of
full read/write interrupt, will program the next data block. This
process repeats until all transfers be executed. The driver uses
interrupt from TWIM to check for erros or program next tranfer.
Future work can enable low power mode on the driver allowing long
transfers with low power consumption.
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
This change adds support for DNS Service Discovery (DNS-SD)
as described in RFC 6763.
Fixes#29099
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
Introduce TagoIO IoT Cloud HTTP post client example. This explorer
Zephyr network resources to demonstrate an end to end application.
The TagoIO allows that any user can test on a easy way Ethernet, WIFI
and Modem (PPP) with BSD sockets. The example provides overlays to
configure WIFI and Modem.
The application consists an a pseudo temperature sensor that sends
periodically data to TagoIO IoT Cloud platform. The data can be
visualized on a web browser dashboard, cellphone or tablet. The
steps to configure TagoIO are described on the example documentation.
Special Variables:
- CONFIG_TAGOIO_DEVICE_TOKEN DEVID token generated by TagoIO
- CONFIG_TAGOIO_HTTP_WIFI_SSID SSID when using WIFI
- CONFIG_TAGOIO_HTTP_WIFI_PSK PASSWD when using WIFI
- CONFIG_MODEM_GSM_UART_NAME UART label when using MODEM
- CONFIG_MODEM_GSM_APN APN when using MODEM
Signed-off-by: Gerson Fernando Budke <nandojve@gmail.com>
Add Inventek es-WIFI modules shield. This shield exposes es-WIFI driver
using Arduino Uno R3 header by UART or SPI interfaces. It shows how
user can create their own overlay and expose es-WIFI driver.
The current Inventek's EVB doesn't have all pins necessary to control
the module by Arduino hearder. This shows how to wire to get ISM43xx
EVB working.
Signed-off-by: Gerson Fernando Budke <gerson.budke@atl-electronics.com>
Add uart bus interface to extended esWIFI driver. This enables all
Inventek modules with IWIN AT Commands firmware.
Signed-off-by: Gerson Fernando Budke <gerson.budke@atl-electronics.com>
This change reworks the cc13xx_cc26xx IEEE 802.15.4 driver to use
the TI RF driver API that is available in modules/hal/ti.
There are a number of benefits to using TI's API including
- a stable multi-OS vendor library and API
- API compatibility with the rest of the SimpleLink SDK and SoC family
- potential multi-protocol & multi-client radio operation
(e.g. both 15.4 and BLE)
- coexistence support with other chipsets via gpio
- vetted TI RF driver resources, such as
- the radio command queue
- highly tuned / coupled RTC & RAT (RAdio Timer) API
Fixes#26312
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
This provides structure for the regulator device hierarchy and a
driver for GPIO-controlled regulators along with its binding.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
In npcx7 series, there're 8 Pulse Width Modulator (PWM) modules and each
one support generating a single 16-bit PWM output. A 16-bit clock
prescaler (PRSCn) and a 16-bit counter (CTRn) determine the cycle time,
the minimal possible pulse width, and the duty-cycle steps.
Beside introducing pwm driver for Nuvoton NPCX series, this CL also
includes:
1. Add PWM device tree declarations.
2. Zephyr PWM api implementation.
3. Add aliases in npcx7m6fb_evb board device tree file for supporting
samples/basic/blinky_pwm application and pwm test suites
Signed-off-by: Mulin Chao <MLChao@nuvoton.com>
In npcx7 series, all of them support the Intel Enhanced Serial
Peripheral Interface (eSPI) Revision 1.0. This specification provides a
path for migrating host sub-devices via LPC to a lower pin count, higher
bandwidth bus. In addition to Host communication via the peripheral
channel, it provides virtual wires support, out-of-band communication,
and device mastering option over the Chipset SPI flash.
Becisdes introducing eSPI device in npcx7, this CL also includes:
1. Add eSPI device tree declarations.
2. Add npcx7-espi-vws-map.dtsi to present the relationship between eSPI
Virtual-Wire signals, eSPI registers, and wake-up input sources.
3. Zephyr eSPI api implementation.
4, Add OOB (Out of Band tunneled SMBus) support.
5. Add configuration files for eSPI test suites.
Signed-off-by: Mulin Chao <MLChao@nuvoton.com>
Adding myself @jenmwms and @aasthagr as codeowners for
/arch/x86/, /soc/x86/, /boards/x86/, and
/drivers/serial/*ns16550* for x86 development.
Signed-off-by: Jennifer Williams <jennifer.m.williams@intel.com>
Move the devicetree bindings for Analog-to-Digital Converters (ADCs)
from dts/bindings/iio/adc to dts/bindings/adc as Zephyr does not have
an IIO layer.
Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
In early Zephyr days, STM32 code base greatly benefited from the care
of a handful of people.
These days are gone and so did these few people that haven't been
contributing for at least a year now.
CODEOWNERS file is updated to reflect current status of contribution,
for the areas where the is an active contributor.
Let them be thank for these initial contributions.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
Add timing functions and APIs. This is now used with some of the tests
we have for performance and metrics and will be used whereever timing
informations are needed, for example for tracing, profiling and other
operations where timing info is critical.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Add a generic host command handler framework that allows users to
declare new host command handlers with the HOST_COMMAND_HANDLER macro
at build time. The framework will handle incoming messages from the
host command peripheral device and forwards the incoming data to the
appropriate host command handler, which is looked up by id.
The framework will also send the response from the handler back to the
host command peripheral device. The device handles sending the data on
the physical bus.
This type of host command communication is typically done on an embedded
controller for a notebook or computer. The host would be the main
application processor (aka AP, CPU, SoC).
Signed-off-by: Jett Rink <jettrink@google.com>
The host command peripheral device API abstracts how an embedded
controller sends and receives data from a host on a bus. Each bus like
eSPI, SPI, or I2C would implement their own host command peripheral
device. Each hardware device would then handle the necessary hardware
access to send and receive data over that bus.
The chosen host command peripheral device will be used by the host
command handler framework to send and receive host data correctly.
Signed-off-by: Jett Rink <jettrink@google.com>
