Date   

[ #BluetoothMesh ] Can I use bt_mesh_model_publish() in ./samples/bluetooth/mesh_demo? #bluetoothmesh

Kai Ren
 

Hello,

I'm trying to know the difference between two APIs, they are:

* int bt_mesh_model_publish(struct bt_mesh_model *model)
* int bt_mesh_model_send(struct bt_mesh_model *model,
struct bt_mesh_msg_ctx *ctx,
struct net_buf_simple *msg,
const struct bt_mesh_send_cb *cb, void *cb_data)

All of them are for access message sending, but I'm curious that is it okay that use bt_mesh_model_publish() function in ./samples/bluetooth/mesh_demo? The reason I asked is that mesh_demo is self-provisioning example, so there is no phase for model configuration.

Regards,
Kai


Re: List of Device Names: device_get_binding()

Warren Gay <ve3wwg@...>
 

Thanks Marc. It took a fairly painful process to produce a list
because of how it is spread among several include files. But I was 
finally able to produce a list using:

$ cpp -E -traditional-cpp \
        -I $ZEPHYR_BASE/dts/common \
        -I $ZEPHYR_BASE/dts \
        -I $ZEPHYR_BASE/dts/arm \
        -I $ZEPHYR_BASE/include \
        $ZEPHYR_BASE/dts/arm/st/stm32f407.dtsi | grep label
In file included from /home/wwg/zephyr/dts/arm/st/stm32f4.dtsi:10:0,
                 from /home/wwg/zephyr/dts/arm/st/stm32f401.dtsi:8,
                 from /home/wwg/zephyr/dts/arm/st/stm32f405.dtsi:9,
                 from /home/wwg/zephyr/dts/arm/st/stm32f407.dtsi:8:
/home/wwg/zephyr/dts/arm/st/mem.h:111:2: error: #error "Flash, RAM, and CCM sizes not defined for this chip"
 #error "Flash, RAM, and CCM sizes not defined for this chip"
  ^~~~~
label = "FLASH_CTRL";
label = "FLASH_STM32";
label = "STM32_CLK_RCC";
label = "GPIOA";
label = "GPIOB";
label = "GPIOC";
label = "GPIOD";
label = "GPIOE";
label = "GPIOH";
label = "UART_1";
label = "UART_2";
label = "UART_6";
label= "I2C_1";
label= "I2C_2";
label= "I2C_3";
label = "SPI_1";
label= "OTGFS";
label = "SPI_2";
label = "SPI_3";
label = "GPIOF";
label = "GPIOG";
label = "GPIOH";
label = "GPIOI";
label = "UART_3";
label = "UART_4";
label = "UART_5";

I assume the device name comes from the label. It would be nice if the
API documentation would mention this sort of thing.

Warren


On Sat, May 5, 2018 at 6:41 PM, Marc Reilly <marc.reilly@...> wrote:
Hi Warren,

I'm no expert, but I for the latest master branch at least I think the device names come from the device tree files. 
Look for the .DTS file in your board folder, then follow the .dtsi includes until you see a node for spi. The device name will be the label.

Cheers
Marc

On Sun., 6 May 2018, 08:29 Warren Gay, <ve3wwg@...> wrote:
For the call:

  struct device *device_get_binding(const char *name)

How do I determine the name to provide for SPIx for example, 
for a stm32f407 board?  Is there a file constructed in the zephyr tree that
I can consult?

Warren



Re: List of Device Names: device_get_binding()

Marc Reilly
 

Hi Warren,

I'm no expert, but I for the latest master branch at least I think the device names come from the device tree files. 
Look for the .DTS file in your board folder, then follow the .dtsi includes until you see a node for spi. The device name will be the label.

Cheers
Marc

On Sun., 6 May 2018, 08:29 Warren Gay, <ve3wwg@...> wrote:
For the call:

  struct device *device_get_binding(const char *name)

How do I determine the name to provide for SPIx for example, 
for a stm32f407 board?  Is there a file constructed in the zephyr tree that
I can consult?

Warren


List of Device Names: device_get_binding()

Warren Gay <ve3wwg@...>
 

For the call:

  struct device *device_get_binding(const char *name)

How do I determine the name to provide for SPIx for example, 
for a stm32f407 board?  Is there a file constructed in the zephyr tree that
I can consult?

Warren


Zephyr news, 4 May 2018

Marti Bolivar
 

Hello and happy Friday,

This is the 4 May 2018 newsletter tracking the latest Zephyr
development merged into the mainline tree on GitHub.

An HTML version is available here:

https://opensourcefoundries.com/blog/2018/05/04/zephyr-news-20180504/

Contents are broken down like this:

- Highlights
- Important changes: ABI/API breaks and some features
- New features: non-exhaustive descriptions of new features
- Bug fixes: non-exhaustive list of fixed bugs
- Individual changes
- Architectures
- Kernel
- Drivers
- etc.

Highlights
==========

This newsletter covers changes in Zephyr between these two commits
(inclusive):

- b742b62b ("kconfiglib: Update to get split_expr() in"), 17 April 2018
- dc97fc2a ("kconfiglib: Update to default to UTF-8 for Python 3"), 2 May 2018

Important Changes
-----------------

Retpolines on x86:

x86 CPUs affected by Spectre v2 now support retpolines when invoking
interrupt and exception handlers, during thread entry, and when
invoking syscall handlers.

These changes also saw the removal of the (unused) _far_jump() and
_far_call() routines.

LED and Button Definition Moves:

This continues the long-term project to move device configuration from
Kconfig to Device Tree.

LED and button definitions were removed from all STM32 board.h files,
since the corresponding defines now come from device tree. This is a
breaking change, as the old XXX_GPIO_PORT is now
XXX_GPIO_CONTROLLER. Applications which used the old names will need
updates.

NXP Kinetis SoCs were also converted to generate this information from
Device Tree. This change preserved names, but did not include updates
for the FXOS8700 or FXAS21002 temperature sensors or the MCR20A
802.15.4 radio. Users of those devices on NXP Kinetis boards should be
advised that support is broken in this Zephyr tree.

Deprecated __stack macro removed:

The __stack macro, which was deprecated in favor of K_STACK_DEFINE
before v1.11 was released, has been removed.

mbedTLS update to fix remote execution holes:

The mbedTLS cryptography library was updated from version 2.7.0 to
version 2.8.0, addressing CVEs 2018-0488 and 2018-0487. These are
remote execution vulnerabilities that could occur when TLS or DTLS is
in use.

k_thread_cancel() deprecated:

The k_thread_cancel() API is deprecated. Applications should use
k_thread_abort().

Generic storage partition rename:

The NFFS flash partition available on many boards, which was
previously aliased to nffs_partition, has been renamed to
storage_partition, to reflect its general usefulness for a variety of
storage systems. Its existence is now controlled via a
CONFIG_FS_FLASH_MAP_STORAGE.

Out of tree applications using the old alias or configuration option
to access this partition will need updates.

Features
--------

Architectures:

The ARC architecture now supports CONFIG_STACK_SENTINEL, which can help
diagnose stack overflow issues.

SEGGER RTT support is now enabled on all NXP MCUs.

Support was added for Cadence's proprietary XCC compiler toolchain for
the XTensa architecture, along with support for the intel_s1000 SoC.
Judging from these drivers, the SoC is intended for use in speech and
other audio processing. Zephyr SoC-level support is provided for DMA,
I2S, UART, GPIO, USB, and I2C, with board support via intel_s1000_crb.

Boards:

I2C driver support was enabled for all the official nRF5 boards
provided by Nordic Semiconductor.

The bbc_microbit now supports flash partitions for mcuboot and on-chip
storage.

Build system:

A variety of improvements were merged into the build system.

Notably, the build system now caches information obtained from the
toolchain, optimizing subsequent invocations of cmake using the same
toolchain. Factor of two speedups have been observed when the cache is
used. A few problems have been identified and fixed up since the
initial merge, but hopefully the major issues are resolved.

In another significant addition, the build system now contains an
initial Python-based menuconfig alternative. This can currently be
used by running "ninja pymenuconfig" on all supported targets (though
Windows users will need to install an additional wheel). This is a
significant improvement for Windows users, who previously have not had
a configuration system browser. The pymenuconfig target is
experimental. When it reaches sufficient feature parity with the
existing menuconfig target, it will replace it, and the C-based
Kconfig tools will be removed from Zephyr.

Further improvements include better error feedback when toolchains are
not found, the list of printed boards now respecting BOARD_ROOT, and
silencing of verbose compiler check messages.

Drivers:

There is a new API for LEDs in include/led.h. (Zephyr had an API for
strips of LEDs; this new API is for controlling individual lights.)
The initial API includes support for basic on/off, as well as
brightness and blinking. A driver and sample application for the TI
LP3943 LED controller were also merged.

The ST LSM6DSL inertial module driver saw a cleanup and now supports
sensor hub mode. This allows the LSM6DSL to act as a sensor hub by
connecting additional I2C slave devices through to the driver via the
main communication channel.

STM32L0 and L4 microcontrollers now support the MSI (multi-speed
internal) clock as a system clock source.

The uart_pipe console driver now supports both edge and level
triggering, allowing it to work with CDC ACM.

The MCUX GPIO driver now uses device tree.

A GPIO driver for NXP i.MX SoCs was merged.

Device Tree:

Bindings were added for the DesignWare CAVS multilevel interrupt
controller.

GPIO nodes are now present on all Kinetis SoCs.

Documentation:

The search results pages for the online Zephyr documentation now have
much cleaner output.

Zephyr's documentation describing its Kconfig usage was re-worked and
improved as part of the transition towards a Python-based menuconfig
alternative.

Kernel:

The kernel's scheduler interface was significantly refactored and
cleaned up. The scheduler's system interface was decreased to twelve
functions; notably, usage of _Swap() was removed in various places in
favor of a new _reschedule().

Userspace configurations now support dynamic creation of kernel
objects. Previously, kernel objects (such as mutexes, pipes, and
timers) needed to be declared statically. This is because a special
linker pass is used when building the Zephyr image, which creates a
perfect hash table which was used to validate if a memory address
passed from userspace pointed to a valid kernel object, among other
security checks. In addition to this hash table, Zephyr now supports
maintaining metadata for dynamically created kernel objects using the
new red/black tree implementation that was added in the v1.12
development cycle. Dynamic kernel objects are allocated and freed from
the system heap. The new allocate and free routines are respectively
k_object_alloc() and k_object_free(). They are currently only
callable from supervisor mode.

Libraries:

The singly-linked list implementation in include/misc/slist.h is now
implemented in terms of a new macro metaprogramming header,
include/misc/list_gen.h. This new header allows generation of static
inline routines implementing "list-like" behavior (i.e. defining
operations for getting, removing, inserting, etc.) for any compound
data type that implements a base set of operations. The base
operations from which the others are derived are: initialization;
getting the "next" node; setting the next, head, and tail nodes;
and peeking at the head and tail nodes.

The JSON library's internal descriptor type is more tightly packed,
using bitfields to place information formerly found in four integers
into 32 bits worth of bitfields. This results in a net savings of
read-only data at a slight increase in text size.

Samples:

A sample application demonstrating the BLE broadcaster role by
providing Apple iBeacon functionality was added in
samples/bluetooth/ibeacon.

Samples using LEDs and buttons were updated following the device tree
name change from PORT to CONTROLLER described above.

The LWM2M sample was re-worked to add configuration overlay fragments
for enabling Bluetooth networking and DTLS. The README was updated
with new instructions for building the sample.

Testing:

The effort to prepare Zephyr's tests for inclusion in a test
management system continues.

Various tests were cleaned up with style, tag, and category fixes,
along with numerous tests receiving Doxygen-based documentation.

The sanitycheck script now parses test cases declared by a test suite
from the source code, using regular expressions.

Sanitycheck also now supports a --list-tests flag, which prints
declared test cases. Its output can be further refined by passing the
-T option a relative path to a subdirectory of "tests" (e.g. -T
tests/net/socket).

The test suite core now includes support for skipping tests when they
are not supported.

USB:

There was a fair bit of USB-related activity which spanned areas in
the tree.

The USB DFU class driver was heavily re-worked and moved to
subsys/usb/class. The driver now determines the flash partition layout
for the currently running image and an area to store an update image
via device tree flash partitions, matching Zephyr's MCUboot area
support mechanism. This allows Zephyr applications to add firmware
update support by enabling the USB DFU driver and booting under
MCUboot. Refer to the README and other documentation in
samples/subsys/usb/dfu for more details.

The hci_usb sample application, which allows a Zephyr device which
supports USB and a Bluetooth controller to act as a Bluetooth dongle,
had its core USB operations generalized and migrated into the core USB
subsystem. The sample application is now much smaller; what remains
essentially just enables the driver.

The wpanusb sample, which allows Zephyr applications to expose
802.15.4 radio functionality to a host via USB, saw a major
cleanup. This sample will be more widely useful upon release of
corresponding Linux drivers.

Bug Fixes
---------

There were several networking-related bug fixes: a fragment
double-free, a build error for HTTP clients, a buffer overflow in the
hostname storage area, an ARP null network packet dereference, and a
miscalculation of ICMPv6 packet payload length and checksum fields.

Calling pthread_cond_signal() from a cooperative thread no longer
yields.

The irq_lock() compatibility layer on SMP configurations was fixed,
avoiding potential deadlocks when swapping away from a thread that
holds the lock.

The kernel scheduler's validation of priority levels was fixed.

A bug which allowed user mode code to force the kernel to execute code
at address 0x0 has been fixed by introducing an extra validation step
at every syscall entry point.

A race condition which could potentially allow user space code to
modify memory containing I2C messages before the kernel-level handler
runs was closed.

Issues preventing successful thread context switch during exception
return on ARC were fixed. The fatal error handler on that architecture
also no longer hangs the system after aborting a non-essential thread.

The BusFault Status Register bits on ARMv8-M MCUs are now properly
cleared when that fault occurs.

The Bluetooth Mesh implementation continues to become more robust,
with three bug fixes affecting initialization vectors and node
identity advertising, and two other cleanups.

The boot banner now correctly prints the Zephyr "git describe" output
when the application is outside the Zephyr tree.

A variety of warnings emitted when using dtc version 1.4.6 are now
fixed. These fixes appear to be backwards-compatible.

A variety of USB-related bug fixes went in, including a fix for the
DesignWare driver's excessive generation of zero-length packets, a
missing byte order conversion computation in the common configuration
descriptor, and other fixes and cleanups.

The ST LSM6DSL inertial module driver was converted to use the new SPI
API, following the removal of the old API.

Individual Changes
==================

Patches by area (241 patches total):

- Arches: 31
- Bluetooth: 5
- Boards: 11
- Build: 19
- Continuous Integration: 6
- Device Tree: 9
- Documentation: 12
- Drivers: 36
- External: 4
- Kernel: 17
- Libraries: 6
- Maintainers: 1
- Miscellaneous: 6
- Networking: 8
- Samples: 26
- Scripts: 9
- Storage: 4
- Testing: 31

Arches (31):

- 3d9ba10b arch: arc: bug fixes and optimization in exception handling
- 24acf2a4 arch: arc: bug fixes in irq_load
- 8da51ee3 arch: arc: optimize the _SysFatalErrorHandler
- adf6f48e arch: arc: add the support of STACK_SENTINEL
- b4696bd7 arch: arm: Fix coding style in file irq_relay.S
- 50b69fbb arm: nxp_kinetis: Remove unused defines from soc.h
- 0b7c964f arch: arm: clear BFSR sticky bits in ARMv8-M Mainline MCUs
- 16472caf arch: x86: Use retpolines in core assembly routines
- ae7911cc arch: x86: segmentation: Remove unused _far_call() and _far_jump()
- adf5b36a lpc54114: Remove unused include in soc.c
- 3e3d1a1c x86: minnowboard: Add support for enabling MMU
- 960e9783 x86: linker: Maintain 4K alignment for application memory.
- 246f03c9 x86: minnowboard: Enable the userspace mode
- ae5e11be arm: soc: NXP: Enable SEGGER RTT on all NXP SoCs
- c7d808f9 arch: arm: improve help text for PROGRAMMABLE_FAULT_PRIOS option
- c36e5ac1 arm: Fix title for SoC configuration in Kconfig
- 42a7c573 arm: soc: Elaborate Kconfig strings for MPU selection
- d9cdf7bf arch/arm/soc/st_stm32: Fix typos in soc.h
- de7f40ac kconfig: fix menuconfig
- f14d1be6 intel_s1000: Add intel_s1000 SoC
- 1fcd39b6 intel_s1000: define memctl_default.S and memerror-vector.S files
- c9ace83c xtensa: reset-vector.S hack for booting intel_s1000 [REVERTME]
- 47ff9659 intel_s1000: uart: configure UART for intel_s1000
- 9ed55af2 arch: xtensa: set __start as entry point for Xtensa.
- 63d50e15 intel_s1000: gpio: enable GPIO handling
- 9cc381c0 intel_s1000: i2c: enable I2C for intel_s1000
- dadf9e7a xtensa: intel_s1000: implement interrupt mechanism
- 08172cdf xtensa: provide XCC compiler support for Xtensa
- 2fd277fc arch/arm/soc/st_stm32/stm32f1: Add I2C1 to dts.fixup
- 6c65ac2b arch: arc: fix the typo of label which caused issue #7249
- e3efbd54 POSIX arch: Fix linker -T warning

Bluetooth (5):

- 2a896cc6 Bluetooth: Mesh: Fix IV Update tests when duration is unknown
- c7c5829b Bluetooth: Mesh: Fix missing IVU normal mode timer when provisioning
- aa67a4c5 Bluetooth: Mesh: Remove redundant branch for IV Update
- 92749e7a Bluetooth: Mesh: Remove unnecessary #ifdefs from header file
- 6b111064 Bluetooth: Mesh: Fix enabling Node Identity advertising

Boards (11):

- 678a6e02 boards: stm32 remove led and button definitions from board.h
- c627de1f boards: Move led and button definitions to dts for kinetis boards
- 597517c7 boards: dts: Add i2c to nrf5X_pcaX board dts.
- 513488c9 boards: disco_l475_iot1: define 2 default clock configurations
- f496fd2a boards/arm/stm32_min_dev: Fix APB2 prescaler value
- 992070f1 boards: microbit: Add flash partition definitions to dts
- 034a11b7 boards: arm: 96b_neonkey: Fix I2C_3 for LP3943 LED driver
- 0090fd4d intel_s1000: create xt-sim_intel_s1000_defconfig
- 02736e59 intel_s1000: add intel_s1000_crb board
- cea1c75e boards: intel_s1000_crb: enable DMA
- 46d6ba46 boards: intel_s1000: enable I2S

Build (19):

- f10fddeb cmake: toolchain: Improve error feedback when toolchain is not found
- d9ac1d4b warnings: Disable "unused-local-typedefs" compiler warning
- 6779d3f3 cmake: Fix printed list of supported boards.
- 6c3a94c0 cmake: Add function for checking if a directory is write-able
- 709daa20 cmake: Find a directory that could be used to cache files
- c95c6bef cmake: check_compiler_flag: Support empty-string options
- a7c3f4ed cmake: toolchain: Checksum the toolchain to uniquely identify it
- 84475810 cmake: Introduce zephyr_check_compiler_flag()
- 71b849f1 cmake: Port Zephyr to use zephyr_check_compiler_flag
- 8bcf30e2 cmake: posix: Use absolute paths for toolchain paths
- 33d87efd build: simplify git describe call
- f9b2da37 kconfig: Move CPLUSPLUS from root to "Compiler Options"
- 7db4d569 Revert "warnings: Disable "unused-local-typedefs" compiler warning"
- a4381d9e kconfig.cmake: Consistently use ZEPHYR_BASE
- 9fbdab52 build: fix git describe call on older Git versions
- 632fe1d4 cmake: check_compiler_flag: Fix bug where checks were aliased
- 5f08b106 cmake: Suppress messages about compiler checks
- aa90d721 cmake: Introduce a key version to invalidate corrupted caches
- 878f39c1 makefile: Fix dependencies for privileged stacks

Continuous Integration (6):

- 140daa2f sanitycheck: add min_flash option for 32K devices
- aae71d74 sanitycheck: parse test cases from source files
- c0149cc0 sanitycheck: support listing test cases
- de223cce sanitycheck: Updated helptext to -O/--outdir argument.
- 75e2d901 sanitycheck: refinements to --list-tests
- 770178b7 sanitycheck: Stop on linker warnings also in native_posix

Device Tree (9):

- a43ad6d5 dts: arc: quark_se_c1000_ss: Fix worng interrupt number in i2c 0/1
- 22955b83 dts: Add gpio labels to all kinetis socs
- a27c0ede dts/st: dtc v1.4.6 warnings: #address-cells/#size-cells
without "ranges"
- acc20e24 dts/st: dtc v1.4.6 warnings: Missing property '#clock-cells' in node
- 986f249f dts/st: dtc v1.4.6 warnings: pin-c... node has a reg ... no unit name
- 398a5a4f dts: dtc v1.4.6 warnings: Fix warning for leading 0s
- 97f721d9 dts: xtensa: Add device tree support for xtensa
- 9ee4929d dts: i2c: Add dts support for i2c
- 7be3236c dts: interrupt_controller: Add dts support for DesignWare controller

Documentation (12):

- 3a72cc98 doc: genrest: Simplify select logic with split_expr()
- 28724732 doc: fix mgmt sample path
- 55840693 doc: win: Invoke pip3 instead of pip to be safe
- b57ac8a2 doc: improve Sphinx search results output
- a380dce0 doc: fix links to mailing lists
- e618608f doc: Expand info about troubleshooting ModemManager
- 1ae99f02 doc: Improve Kconfig interface description
- 303484aa doc: Clarify application configuration
- 64eb789f doc: Clarify format for CONF_FILE
- b4d67dcc doc: update doc generation instructions
- 63cb2334 doc: Document Zephyr's Kconfig configuration scheme
- 699759a0 doc: brief description on intel_s1000 usage

Drivers (36):

- 4e8f29f3 gpio: Refactor the mcux gpio driver to use dts
- 8d3b2fa8 usb: usb_dc_dw: Fix incorrect MPS return
- 4f84cf78 usb: Add BOS Descriptors
- 773f3e18 usb: Add sys_cpu_to_le16() conversion for USB field
- 6239341a usb: Add subsys/usb for device descriptor header
- 16532549 usb: mass_storage: Use simpler header include
- 4d703b1e usb: Add Bluetooth USB Device configuration options
- 0322af58 usb: Add Bluetooth device decriptors
- 53410af9 usb: Add Bluetooth device class core functionality
- a09a0b2c sensors/lsm5dsl: Fix SPI API usage
- b7862eb8 hid: core: truncated wLength if it doesn't match report
descriptor size
- 8f7e5bd0 uart_pipe: re-work the RX function to match the API and
work with USB.
- c26fdc1b drivers/spi: Fixed incorrect prompt.
- d8ba007a drivers: clock_control: Add MSI as possible clock source for stm32
- 25fb83c6 drivers: i2c: Fix TOCTOU while transferring I2C messages
- 7e067414 usb: Remove unneeded header include
- c200367b drivers: Perform a runtime check if a driver is capable of
an operation
- 185f2be6 netusb: rndis: Add more debugs
- 222aa600 netusb: rndis: Fix RNDIS always disabled state
- 94bba071 drivers: led: Add public API for LED drivers
- bb394bba drivers: led: Add LED driver support for TI LP3943
- f4ad6988 drivers/spi: Remove DW spi slave test left over
- 180b1397 drivers: sensor: lsm6dsl: Adding sensorhub support
- 580a9b3f drivers: sensor: lsm6dsl: Fix typos
- f7f56ccd drivers: sensor: lsm6dsl: add .attr_set callback
- 46700eaa include: usb: add USB DFU class header
- b2ca5ee5 subsys: usb: rework USB DFU class driver
- 74016bb6 drivers: interrupts: introduce CAVS interrupt logic
- e3f2fa4f drivers: interrupts: introduce Designware interrupt controller
- bd0d5133 drivers: dma: introduce Intel CAVS DMA
- 5b6f0244 drivers: i2s: introduce CAVS I2S
- 5060f4bd driver: usb: enable usb2.0 on intel_s1000
- f618af75 driver: ieee802154: cc1200: fix context handling
- 943ca29d usb: dw: Fix Coverity issue with get_mps()
- c6f2b4cc spi: Fix mcux dspi driver to parse lsb transfer mode correctly
- 67ba7d8a gpio: Add imx gpio driver shim

External (4):

- 2c58de57 ext: lib: crypto: Update mbedTLS to 2.8.0
- 9791597e ext: mcux: Update README to follow template format
- 57e80e53 ext: mcux: Reorganize imported drivers into soc family subfolders
- 4624f132 ext: mcux: Remove clock_config.c/h

Kernel (17):

- 56c2bc96 kernel: add CODE_UNREACHABLE in _StackCheckHandler
- 541c3cb1 kernel: sched: Fix validation of priority levels
- b481d0a0 kernel: Allow pending w/o wait_q for scheduler API cleanup
- 8606fabf kernel: Scheduler refactoring: use _reschedule_*() always
- e0a572be kernel: Refactor, unifying _pend_current_thread() + _Swap() idiom
- 0447a73f kernel: include cleanup
- 15cb5d72 kernel: Further unify _reschedule APIs
- 3f55dafe kernel: Deprecate k_thread_cancel() API
- 5792ee6d kernel/mutex: Clean up k_mutex_unlock()
- 22642cf3 kernel: Clean up _unpend_thread() API
- 8a4b2e8c kernel, posix: Move ready_one_thread() to scheduler
- f5f95ee3 kernel: sem: Ensure that initial count is lesser or equal than limit
- 31bdfc01 userspace: add support for dynamic kernel objects
- e7ded11a kernel: Prune ksched.h of dead code
- 68040c8d kernel: sem: Modify the way BUILD_ASSERT is used
- eb258706 kernel: Move SMP initialization to start of main thread
- 15c40077 kernel: Rework SMP irq_lock() compatibility layer

Libraries (6):

- 2a5fb57e lib: posix: mqueue: Do not dereference mqd pointer before null check
- 3af88642 lib: posix: mqueue: Minor formatting cleanups
- d89249db pthread: Respect cooperative thread schedulign in condition variable
- e7648ba3 lib: posix: pthread_common: Fix potential integer overflow issue
- 9faa42f5 slist: abstract node and list implementation
- 0ec79d68 lib: json: Efficiently pack field name, offset, alignment, type

Maintainers (1):

- 517a08ee CODEOWNERS: Add myself as the Codeowner for LED API and drivers

Miscellaneous (6):

- 81f4b111 include: toolchain: common: Remove deprecated __stack macro
- 666274fa toolchain: gcc: Only use _Static_assert if building with C11
- 05169a02 toolchain: common: Allow multiple uses of BUILD_ASSERT() in
same scope
- 83ac3e24 shell: kernel: Add reboot command
- f8c1cc17 toolchain: update xtools config
- b3153d24 intel_s1000: scripts: debug, debugserver and flash scripts

Networking (8):

- c0d0a61b net: ipv6: Remove irrelevant error log
- 460a6c77 net: tcp: send_syn_segment: Log packet before it's sent
- bf185f58 net: ipv6: Fix crash from double free of fragment
- 8c561994 net: http: Fix client compilation if HTTPS is enabled
- a12138d4 net: hostname: Fix hostname buffer length
- 2002a4e2 net: arp: Do not access NULL network packet
- 3da4d370 net: Implement VLAN priority to packet priority conversion
- d1715685 net: icmpv6: Fix payload length and checksum

Samples (26):

- 162b6e4b samples: Allow use of "CONTROLLER" postfix for LED and GPIO
- d38116cb usb: Use new USB Device interface for Bluetooth over USB sample
- fc5134b0 usb: hci_usb: Fix test name
- d665e128 usb: hci_usb: Correct README
- b35274a4 samples: usb: webusb: Prettify binary object store descriptor
- a9d377e0 usb: wpanusb: Replace char array with structs for descriptor table
- 10ec019a usb: wpanusb: Replace local hexdump() with net_hexdump()
- 9e753f0c usb: wpanusb: Clean up code
- c8e23874 usb: wpanusb: Remove unused headers
- a5e7a8de usb: wpanusb: Remove unused packet handlers
- 74d08efb usb: wpanusb: Correct protocol description
- 7337f4a0 usb: wpanusb: Code cleanup
- acb0f099 samples: echo_server: Update prj_cc2520 configuration
- 2b47d358 usb: wpanusb: Fix regression with putting LQI to wrong place
- 24cc5cc4 usb: wpanusb: Make generic interface to raw 802.15.4 channel
- 190e8d96 usb: wpanusb: Fix setting wrong length
- 30c3461e samples: lwm2m: replace prj_dtls.conf with overlay fragment
- 5df33d67 samples: lwm2m: add overlay conf to support BT networking
- 970b0a99 samples: lwm2m: update README with use of overlay files
- f59a68b6 samples: net: http: Add TLS compilation test
- 6c70aa28 samples: net: Fix CoAP server payload dump function
- 1572594b samples: drivers: Add sample application for LP3943
- b27d9685 samples: bluetooth: Add Apple iBeacon demo application
- 2d1c5241 samples: flash_shell: Use correct flash write block size
- a6eee02c samples: enhance integration sample and document it
- 00c26d24 samples: remove stray config

Scripts (9):

- b742b62b kconfiglib: Update to get split_expr() in
- f3caef8e scripts: extract_dts_inlcudes: look up compatible field in parents
- 69beec87 scripts: extract_dts_includes: generate controller #define's
- 39dc7d03 scripts: gen_kobject_list: Generate enums and case statements
- d3bfbfeb kconfiglib: Update to get choice.direct_dep in
- 73549ad8 scripts: kconfig: Add a Python menuconfig implementation
- cfb3c925 kconfiglib: Update to add warning for malformed .config lines
- 1799cfdb scripts: kconfig: Turn malformed .config lines into errors
- dc97fc2a kconfiglib: Update to default to UTF-8 for Python 3

Storage (4):

- 9fe30535 susbsys: settings: fix coverity issues
- 341b4273 subsys: settings: fix fcb back-end initialization
- 9968cda4 fs: Convert NFFS partition to a generic one
- d67009da subsys: settings: Fix Kconfig dependencies

Testing (31):

- 1931f124 tests: fix arc related codes
- edc048e0 tests: socket: udp: Make sure client sockaddr fully initialized
- e8bcc6f1 tests: socket: Free resources with freeaddrinfo
- 1d1db121 tests: socket: udp: Tighten up error checking
- e564d58b tests: socket: udp: Close test sockets
- 1609f251 tests: kernel: style, tag, and category fixes
- 63f21391 tests: use consistent test function names
- 1f2627a6 tests: net: style, tag, and category fixes
- 9312de00 tests: crypto: style, tag, and category fixes
- 89a50932 tests: posix: style, tag, and category fixes
- fa6cce43 tests: ztest: style, tag and category fixes
- 0f5a88b0 tests: posix: mqueue remove extra printk
- 910a569e tests: stackprot: move to ztest
- 20495e89 ztest: support skipping tests
- 7a5ff137 tests: allow unsupported tests to be skipped
- eb6f2031 tests: fix meta data of peripheral tests
- 7753bc50 tests: kernel: mem_protect: tests for userspace mode.
- b4cb1014 tests: mem_prot: skip unsupported tests
- 9a2b5357 tests: settings: Remove references to non-existent Kconfig variable
- 6f1cff73 ztest: fix result checking
- 3298d60f tests: subsys: settings: Add FCB-beckend initialization test
- ff0857df tests: threads: Add test to verify delayed thread abort
- 2182a53f tests: irq_offload: document test functions
- 25e7b27b tests: critical: document test functions
- 67194a40 tests: errno: document test functions
- 2b62f1ab tests: fixed doxygen comments
- 18cc28a9 tests: Fix malformed CONFIG_TEST=y prj.conf entry
- 567482ff intel_s1000: tests: introduce tests to check features enabled
- a2afa6cf test: board: intel_S1000: Add test application for HID
- e57df9a3 tests: boards: intel_s1000_crb: select application based on config
- b3275d65 tests/samples: add hw dependencies


Re: Support for ARM DS-5 compiler

Peder Møller
 

I was informed that the major step towards ARM DS-5 support, full support of LLVM, is on the schedule for Zephyr rev 1.12.
It seems that we can expect that around June.
 


Re: Using SPI_SLAVE on STM32

Tomasz Bursztyka
 

It has not been rebased against latest SPI API changes, thus why it
can't be merged. But it's a fine PR besides that.

Tomasz

Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/52
00
You probably need the first patch, and the second is an example how
to
do it. Note however the API has changed a bit, you'll have to
check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?





Re: Using SPI_SLAVE on STM32

Armando Visconti
 

Thx Tomasz,

On 05/04/2018 02:08 PM, Tomasz Bursztyka wrote:
Hi,
Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/5200
You probably need the first patch, and the second is an example how to
do it. Note however the API has changed a bit, you'll have to check.
It seems quite old. Why hasn't it been merged yet?
Is there something wrong that prevent it?


Re: Using SPI_SLAVE on STM32

Tomasz Bursztyka
 

Hi,

Check this PR: https://github.com/zephyrproject-rtos/zephyr/pull/5200
You probably need the first patch, and the second is an example how to
do it. Note however the API has changed a bit, you'll have to check.

Br,

Tomasz

Ciao guys,

I'm currently working on ArgonKey, which is a 96 board with a
STM32F412
plus a bunch of motion and environmental sensors.

I'm exploring the possibility to put in place the communication from
HiKey to ArgonKey and I noticed that the stm32 SPI environment
already
implements the SPI_SLAVE communication. Does somebody have already
tried
it out and know what the status is? Is there any example (doesn't
seem
so) where I can get a look from?

Thx,
Arm




Using SPI_SLAVE on STM32

Armando Visconti
 

Ciao guys,

I'm currently working on ArgonKey, which is a 96 board with a STM32F412
plus a bunch of motion and environmental sensors.

I'm exploring the possibility to put in place the communication from
HiKey to ArgonKey and I noticed that the stm32 SPI environment already
implements the SPI_SLAVE communication. Does somebody have already tried
it out and know what the status is? Is there any example (doesn't seem
so) where I can get a look from?

Thx,
Arm


Re: Support for ARM DS-5 compiler

Sebastian Boe
 

Hi,

building Zephyr with an LLVM-based compiler (like DS-5) was prototyped
but not finished in https://github.com/zephyrproject-rtos/zephyr/pull/5901.

Since then there has not been any activity. I'm not sure about the schedule.

Contributions are welcome :)

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Peder Møller <pedermoeller@gmail.com>
Sent: Friday, 4 May 2018 12:57:17 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Support for ARM DS-5 compiler

Are there any plans for including support in Zephyr for the ARM DS-5 compiler?

The getting started guide has some information about how to set up a 3rd party compiler

http://docs.zephyrproject.org/getting_started/getting_started.html#using-custom-and-3rd-party-cross-compilers

However, the example 3rd party compiler is also a GCC compiler.
I have not been successful in setting up the ARM DS-5 compiler for Zephyr using this information, but there was a rumour that the Zephyr project was working on built-in support for ARM DS-5.

Is anyone able to confirm this rumour?

Thanks and best regards,
Peder Møller.


Support for ARM DS-5 compiler

Peder Møller
 

Are there any plans for including support in Zephyr for the ARM DS-5 compiler?

The getting started guide has some information about how to set up a 3rd party compiler


However, the example 3rd party compiler is also a GCC compiler.
I have not been successful in setting up the ARM DS-5 compiler for Zephyr using this information, but there was a rumour that the Zephyr project was working on built-in support for ARM DS-5.

Is anyone able to confirm this rumour?

Thanks and best regards,
Peder Møller.


Re: Usage of generated dts *_GPIO_FLAGS

Erwan Gouriou
 

Hi Diego,


Having direct match between generated FLAGS/INT_CONF aliases and application symbols would be a good idea.
Though not sure which should converge to the other.
INT_CONF (Interrupt configuration I guess) is more restrictive than FLAGS.
Impacted field is used to configure GPIO in general, not interrupt only, so a more generic name might be a better choice.

Erwan


On 4 May 2018 at 07:33, Diego Sueiro <diego.sueiro@...> wrote:
Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/



Re: Core407V STM32F407VET6 Board Definition

Yannis Damigos
 

Hi Waren,

CONFIG_GPIO_STM32=n in your core407v_stm32f407_defconfig disables the STM32
gpio driver.

Yannis


On Fri, May 4, 2018 at 5:53 AM Warren Gay <ve3wwg@gmail.com> wrote:

This is in reference to the MCU board
https://www.waveshare.com/wiki/Core407V

I have been able to build & flash the project in zsrc.tar.gz (below)
using the
board BOARD olimex_stm32_e407. The LEDs flash as expected.
However, when I try to use my own board definition (BOARD
core407v_stm32f407),
it builds but does not execute correctly (no LED flashing). Perhaps
someone
can point out something obviously wrong with my board definition.
Thanks, Warren
https://drive.google.com/open?id=10MFd3qMrX5062BkAz-mm3KdWUtUbcsLJ
(core407.tar.gz board defn)

https://drive.google.com/open?id=1p0TX3f30R2Rf6qKyBbci1xjRpApzz7he
(zsrc.tar.gz has blinky)


Usage of generated dts *_GPIO_FLAGS

Diego Sueiro
 

Hello,

I'd like to know what is the usage of the *_GPIO_FLAGS macro.

For example in "dts/bindings/gpio/nxp,kinetis-gpio.yaml" file:

cell_string: GPIO
"#cells":
  - pin
  - flags

And "boards/arm/frdm_k64f/frdm_k64f.dts" file we have
gpios = <&gpioa 4 GPIO_INT_ACTIVE_LOW>;

This will generate in "zephyr/include/generated/generated_dts_board.h":
#define GPIO_KEYS_1_GPIO_CONTROLLER "GPIO_0"
#define GPIO_KEYS_1_GPIO_FLAGS_0    0
#define GPIO_KEYS_1_GPIO_PIN_0      4
#define GPIO_KEYS_1_LABEL       "User SW3"
#define GPIO_KEYS_1_GPIO_FLAGS      GPIO_KEYS_1_GPIO_FLAGS_0
#define GPIO_KEYS_1_GPIO_PIN        GPIO_KEYS_1_GPIO_PIN_0
#define SW0_GPIO_CONTROLLER     GPIO_KEYS_1_GPIO_CONTROLLER
#define SW0_GPIO_FLAGS          GPIO_KEYS_1_GPIO_FLAGS
#define SW0_GPIO_PIN            GPIO_KEYS_1_GPIO_PIN
#define SW0_LABEL           GPIO_KEYS_1_LABEL

In this example SW0_GPIO_FLAGS is not "consumed" by any source code, but  "samples/basic/button/src/main.c" application is using SW0_GPIO_CONTROLLER, SW0_GPIO_PIN and SW0_GPIO_INT_CONF.

I think we should name this gpio dts cell as "int_conf" instead of "flags", this way the dts configuration will be used in the button application, for example.



Regards,

--
*dS
Diego Sueiro

CEO do Embarcados
www.embarcados.com.br

/*long live rock 'n roll*/


Re: What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

HI Aaron,

This PDF may help developers who want to go with Zephyr #BluetoothMesh.

https://www.zephyrproject.org/wp-content/uploads/sites/38/2018/03/openiot_zephyr_lts_what_and_why.pdf

But following links are Silent about #BluetoothMesh
As per attached image, #LTS is going to release in June 2018.

So currently, I'm clueless & unfortunately have to go with stack provided by Silicon manufactures
which are Black Box & inherently complicated.  😥

 

On Fri, May 4, 2018 at 8:27 AM, Aaron Xu <overheat1984@...> wrote:
Hi,

We all look forward that the zephyr project bluetooth mesh can be used on a real project.
Before that, we want to know those question's answer.

Thanks.

vikrant8051 <vikrant8051@...> 于2018年5月3日周四 下午9:53写道:
Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!








Re: What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

Aaron Xu
 

Hi,

We all look forward that the zephyr project bluetooth mesh can be used on a real project.
Before that, we want to know those question's answer.

Thanks.

vikrant8051 <vikrant8051@...> 于2018年5月3日周四 下午9:53写道:

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







Core407V STM32F407VET6 Board Definition

Warren Gay <ve3wwg@...>
 

This is in reference to the MCU board https://www.waveshare.com/wiki/Core407V

I have been able to build & flash the project in zsrc.tar.gz (below) using the 
board BOARD olimex_stm32_e407. The LEDs flash as expected.

However, when I try to use my own board definition (BOARD core407v_stm32f407), 
it builds but does not execute correctly (no LED flashing). Perhaps someone
can point out something obviously wrong with my board definition.


What will be status of #BluetoothMesh in #LTS release ? #lts #bluetoothmesh

vikrant8051 <vikrant8051@...>
 

Hi,

What will be status of #BluetoothMesh in #LTS v.1.12.0 release ?

Will it be released as #Qualified stack ?

As of now, we can't save Provisioning, Configuration & other real time data (eg. message sequence Nos, states of Models etc. etc) on SoC flash. Will it be possible in #LTS release ?

( For that we need something like " https://github.com/zephyrproject-rtos/zephyr/pull/6391 " to get merge.

I tried to save above mentioned data using NFFS, but it consumes lots of RAM & I don't know exactly what & when to save on SoC flash.

Plus NFFS is not recommended for SoC which has limited write/erase cycles for its flash.)

How many Models (for eg. Generic, Lighting) will show case under #LTS ?

What will be status of Friend & Low Power Nodes implementation ?

When I tried SMP_Server example along with #MCUboot, to do #DFU_OTA, I found that it depends upon NFFS.
Is that means we have to depends upon #NVS (PR6391) & NFFS both?
Please throw some light about overall implementation for developers if he/she want to add #DFU_OTA feature along with #BluetoothMesh.

How to do #DFU_OTA using Android/iOS smartphones App? (as suggestion)
 
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

If something has very little chance to get introduced with #LTS release, then till when it get expected to be part of implementation ?

Thank You in advance !!







Re: Networking API example code

Paul Sokolovsky
 

Hello Patrik,

As we were requested at the TSC meeting to keep the discussion public
at the devel mailing list, please let me re-route this conversation
there.

I also apologize for delayed response - there were public holidays
here. Please see responses below.

On Fri, 27 Apr 2018 15:10:18 +0300
Patrik Flykt <patrik.flykt@linux.intel.com> wrote:

Here is a fairly simple piece of C code that we can use to demonstrate
different networking APIs in Zephyr. It's simple, as the request was
to present the APIs in the Networking Forum next week. Of course a
more realistic example would be much more elegant, but then time
would be spent on deducing the internal flow of the program, which
will not create any more clarity on the matter.
As I mentioned in my previous mail (dated Apr 26,
https://lists.zephyrproject.org/g/devel/topic/examples_for_zstream/18100280),
Zephyr tree includes 5 ready socket examples which demonstrate socket
API from various angles and are known to work. I proposed to use one of
them to demonstrate TLS API approaches.

Your going forward with an adhoc example may leave an impression that
your API can't work with existing examples, and require an artificial
one - which is definitely not true.

But your going with a single-source-file example also hides what the
existing Zephyr socket samples are. They are fully self-contained
(albeit small and "toy") applications with build files included, and
these build files demonstrate thess apps working on both Zephyr and a
reference POSIX system (tested with Linux).

Samples for my Zstream API preserve this continuity. And that's where
your API would have problems. And I hope it's not just me who's keen to
see how you'd resolve that.

So, I hope you had time over the last week also convert one of the
samples at
https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/net/sockets
to your API and test it with both Zephyr and a POSIX system.

Oh, and btw, your sample code had a mistake, so couldn't work as is, I
had to fix it.


I was thinking that the code that is changed/added could be indicated
for example by color, so that the modifications needed by each API and
proposal would be easy to spot. As the code is quite short, it might
even be possible to squeeze the samples on two slide pages each. With
that we then can present the original example socket code below, the
Net App version, Zstream and socket option version in a reasonably
short time in an understandable way.
Fairly speaking, Zstream was at that stage - discussing individual
calls in a presentation-like manner circa beginning of February (and
that was done on github). The way I understood TSC's request is to
prepare 2 more or less real-world samples to compare 2 APIs. I didn't
try to squeeze mine into the presentation slides. I also let Github diff
viewer do the coloring:

https://github.com/pfalcon/zephyr/pull/2/commits/735ba51e56a191e45e9afb7f1a5e221976451e67

This is your sample, as-is from the mail.

https://github.com/pfalcon/zephyr/pull/2/commits/bc1dbb75c5f76739681f9d44eb755f50bb45bc2b

This adds missing connect() call, and build files for Zephyr and POSIX.
This represents a working, testable sample.

https://github.com/pfalcon/zephyr/pull/2/commits/8d2cf8da1fddf946ea8912a327e76d28e05fcaba

This shows the changes required to convert socket-based sample to
Zstream-based sample, still preserving buildability and functioning on
both Zephyr and POSIX.

(Links are valid until git rebase.)


Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

3321 - 3340 of 7832