NEW JIRA items within last 24 hours: 13
[ZEP-238] Usage of ARCH in application Makefiles is misleading
https://jira.zephyrproject.org/browse/ZEP-238

[ZEP-230] Define I2S driver APIs
https://jira.zephyrproject.org/browse/ZEP-230

[ZEP-237] Support pre-built host tools
https://jira.zephyrproject.org/browse/ZEP-237

[ZEP-232] Support for USB communications device class ACM
https://jira.zephyrproject.org/browse/ZEP-232

[ZEP-231] USB device support
https://jira.zephyrproject.org/browse/ZEP-231

[ZEP-228] File system interface designed after POSIX
https://jira.zephyrproject.org/browse/ZEP-228

[ZEP-234] provide a direct memory access (DMA) interface
https://jira.zephyrproject.org/browse/ZEP-234

[ZEP-233] Support USB mass storage device class
https://jira.zephyrproject.org/browse/ZEP-233

[ZEP-235] Provide an interface for cpu/soc id and version
https://jira.zephyrproject.org/browse/ZEP-235

[ZEP-236] CMSIS core for cortex-M class SoC/MCUs
https://jira.zephyrproject.org/browse/ZEP-236

[ZEP-229] I2S device APIs and Drivers
https://jira.zephyrproject.org/browse/ZEP-229

[ZEP-239] make pristine is almost always needed...
https://jira.zephyrproject.org/browse/ZEP-239

[ZEP-240] printk/printf usage in samples
https://jira.zephyrproject.org/browse/ZEP-240


UPDATED JIRA items within last 24 hours: 3
[ZEP-224] Add save/restore of APIC table in system_apic driver
https://jira.zephyrproject.org/browse/ZEP-224

[ZEP-225] Add kernel API to put SoC to Deep Sleep (DS) State
https://jira.zephyrproject.org/browse/ZEP-225

[ZEP-227] Add kernel API to put SoC to Low Power State (LPS)
https://jira.zephyrproject.org/browse/ZEP-227


CLOSED JIRA items within last 24 hours: 2
[ZEP-220] (Duplicate) We should be able to use Zephyr with original Arduino 101 bootloader
https://jira.zephyrproject.org/browse/ZEP-220

[ZEP-164] (Cannot Reproduce) sanitychecks takes up to 5 hours to run in some cases
https://jira.zephyrproject.org/browse/ZEP-164


RESOLVED JIRA items within last 24 hours: 1
[ZEP-16] (Fixed) Support TI CC2550 SPI based 802.15.4 chip
https://jira.zephyrproject.org/browse/ZEP-16

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1776 : arduino_101: add missing version_header.h file
- https://gerrit.zephyrproject.org/r/1775 : arduino_101: add support for factory configuration
- https://gerrit.zephyrproject.org/r/1774 : doc: add section about 3rd party compilers

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1411 : build: add arc support to issm toolchain

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1773 : include/arch/arc: Fix minor space vs tab issue in indentation
- https://gerrit.zephyrproject.org/r/1711 : sensor: apds9660: remove IP specific GPIO configs
- https://gerrit.zephyrproject.org/r/1743 : gpio: unify kernel configuration for all architectueres
- https://gerrit.zephyrproject.org/r/1746 : samples: pwm: rename local configuration and use printk
- https://gerrit.zephyrproject.org/r/1745 : led_apa102c: rename local configuration and use printk
- https://gerrit.zephyrproject.org/r/1747 : samples: i2c_lsm9ds0: we are using printk only
- https://gerrit.zephyrproject.org/r/1763 : arduino_101: support booting with original bootloader
- https://gerrit.zephyrproject.org/r/1748 : samples: cpp_synchronization: rename local configuration and use one config

My apologies, i am setting up my development system on freescale's ARM based processor, whereas '-m32' is x86 option.

I have a fresh clone from the latest (on 30-April-2016) and i am getting following error while building for BOARD=arduino_due


ubuntu(a)udoobuntu: ~/Projects/zephyr-project/samples/hello_world/nanokernel $ make BOARD=arduino_due
Using /home/ubuntu/Projects/zephyr-project//boards/arduino_due/arduino_due_defconfig as base
Merging /home/ubuntu/Projects/zephyr-project//kernel/configs/nano.config
Merging prj.conf
cc1: error: unrecognized command line option '-m32'
make[3]: *** [scripts/gen_idt/version.o] Error 1
make[2]: *** [scripts_basic] Error 2
make[1]: *** [sub-make] Error 2
make: *** [/home/ubuntu/Projects/zephyr-project/samples/hello_world/nanokernel/outdir/.config] Error 2

Any help would be much appreciated! Thanks.

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1768 : build: Fixes an issue with file permissions on windows
- https://gerrit.zephyrproject.org/r/1770 : arch/arc: improve code-density by using ld_s and st_s with r0-r3
- https://gerrit.zephyrproject.org/r/1767 : doc: Edit arch.rst markup
- https://gerrit.zephyrproject.org/r/1769 : arch/arc: can use small-variant instructions to load/store %r13

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1763 : arduino_101: support booting with original bootloader
- https://gerrit.zephyrproject.org/r/1699 : arch/arc: __start label incorrectly aliased
- https://gerrit.zephyrproject.org/r/1707 : drivers/interrupt_controller: initialize only NUM_IRQS interrupts
- https://gerrit.zephyrproject.org/r/1765 : Bluetooth: L2CAP: Handle incoming connection on signal channel
- https://gerrit.zephyrproject.org/r/1263 : build: support icx llvm compiler
- https://gerrit.zephyrproject.org/r/1740 : build: don't default ARCH to x86
- https://gerrit.zephyrproject.org/r/1411 : build: add arc support to issm toolchain
- https://gerrit.zephyrproject.org/r/1757 : arm/nxp_kinetis/k6x: simplify uart init
- https://gerrit.zephyrproject.org/r/1723 : build: allows CC and CCX override from Makefile source files
- https://gerrit.zephyrproject.org/r/1722 : build: Add MinGW dependencies in makefile
- https://gerrit.zephyrproject.org/r/1656 : doc: Updates the toolchain path format instruction
- https://gerrit.zephyrproject.org/r/1516 : x86: make GDT setup optional
- https://gerrit.zephyrproject.org/r/1764 : Bluetooth: shell: Add BR/EDR PSM server registration
- https://gerrit.zephyrproject.org/r/1756 : arm/nxp_kinetis/k6x: always inline clock init function
- https://gerrit.zephyrproject.org/r/1755 : arm/atmel_sam3: always inline clock init function
- https://gerrit.zephyrproject.org/r/1766 : net: buf: Add net_buf_pull_le32() helper API
- https://gerrit.zephyrproject.org/r/1673 : Bluetooth: L2CAP: Move BREDR tx signalling pool definition to l2cap_br.c
- https://gerrit.zephyrproject.org/r/1674 : Bluetooth: L2CAP: Move BREDR signalling management to l2cap_br.c

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1771 : doc: fixed bullet list for bluetooth
- https://gerrit.zephyrproject.org/r/1762 : quark_se: remove hardcoded reset vector for ARC
- https://gerrit.zephyrproject.org/r/1761 : Revert "samples: philosophers: reduce stack size used"

NEW JIRA items within last 24 hours: 3
[ZEP-216] Zephyr should support LWM2M for device management
https://jira.zephyrproject.org/browse/ZEP-216

[ZEP-215] Zephyr should provide MQTT client capability
https://jira.zephyrproject.org/browse/ZEP-215

[ZEP-217] Galileo ADC/SPI initialization error
https://jira.zephyrproject.org/browse/ZEP-217


UPDATED JIRA items within last 24 hours: 2
[ZEP-163] AIO doesn't work on QUARK_D2000_CRB
https://jira.zephyrproject.org/browse/ZEP-163

[ZEP-208] Zephyr's net stack does not handle fragmentation of packets properly
https://jira.zephyrproject.org/browse/ZEP-208


CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1765 : Bluetooth: L2CAP: Handle incoming connection on signal channel
- https://gerrit.zephyrproject.org/r/1764 : Bluetooth: shell: Add BR/EDR PSM server registration
- https://gerrit.zephyrproject.org/r/1766 : net: buf: Add net_buf_pull_le32() helper API
- https://gerrit.zephyrproject.org/r/1763 : arduino_101: support booting with original bootloader
- https://gerrit.zephyrproject.org/r/1760 : Bluetooth: Add support for using SYS_LOG
- https://gerrit.zephyrproject.org/r/1761 : Revert "samples: philosophers: reduce stack size used"
- https://gerrit.zephyrproject.org/r/1762 : quark_se: remove hardcoded reset vector for ARC
- https://gerrit.zephyrproject.org/r/1757 : arm/nxp_kinetis/k6x: simplify uart init
- https://gerrit.zephyrproject.org/r/1755 : arm/atmel_sam3: always inline clock init function
- https://gerrit.zephyrproject.org/r/1756 : arm/nxp_kinetis/k6x: always inline clock init function
- https://gerrit.zephyrproject.org/r/1752 : arch/arc: add ICCM_BASE_ADDRESS and ICCM_SIZE
- https://gerrit.zephyrproject.org/r/1754 : tests: timestamp_serialize for arc can be no-op
- https://gerrit.zephyrproject.org/r/1745 : led_apa102c: rename local configuration and use printk
- https://gerrit.zephyrproject.org/r/1747 : samples: i2c_lsm9ds0: we are using printk only
- https://gerrit.zephyrproject.org/r/1746 : samples: pwm: rename local configuration and use printk
- https://gerrit.zephyrproject.org/r/1743 : gpio: unify kernel configuration for all architectueres
- https://gerrit.zephyrproject.org/r/1744 : philosophers: no local config changes needed
- https://gerrit.zephyrproject.org/r/1748 : samples: cpp_synchronization: rename local configuration and use one config
- https://gerrit.zephyrproject.org/r/1742 : qemu_x86: Make the FPU available if it's not building for IAMCU
- https://gerrit.zephyrproject.org/r/1741 : quark_x1000: The Quark X1000 does have an FPU
- https://gerrit.zephyrproject.org/r/1740 : build: don't default ARCH to x86

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1673 : Bluetooth: L2CAP: Move BREDR tx signalling pool definition to l2cap_br.c
- https://gerrit.zephyrproject.org/r/1674 : Bluetooth: L2CAP: Move BREDR signalling management to l2cap_br.c
- https://gerrit.zephyrproject.org/r/1713 : Bluetooth: BR/EDR: Reset pairing context when needed
- https://gerrit.zephyrproject.org/r/1711 : sensor: apds9660: remove IP specific GPIO configs
- https://gerrit.zephyrproject.org/r/1516 : x86: make GDT setup optional
- https://gerrit.zephyrproject.org/r/1077 : sanitycheck: allow for more expressive filtering in testcase.ini
- https://gerrit.zephyrproject.org/r/1076 : expr_parser.py: simple expression language
- https://gerrit.zephyrproject.org/r/1078 : test_tickless: improve testcase.ini filter
- https://gerrit.zephyrproject.org/r/1735 : arch/arc/include: start_task_arch.h needed so ARC can build microkernel apps
- https://gerrit.zephyrproject.org/r/1557 : doc: update installation to add PLY library to Python3
- https://gerrit.zephyrproject.org/r/1708 : include/arch/arc: fix memory permissions
- https://gerrit.zephyrproject.org/r/1707 : drivers/interrupt_controller: initialize only NUM_IRQS interrupts
- https://gerrit.zephyrproject.org/r/1699 : arch/arc: __start label incorrectly aliased
- https://gerrit.zephyrproject.org/r/1666 : nios2: basic build, non-functional
- https://gerrit.zephyrproject.org/r/1584 : Added profiler application and scripts

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1759 : Bluetooth: Fix not being able to set CONF_FILE for init test
- https://gerrit.zephyrproject.org/r/1758 : Bluetooth: Fix using invalid responder address as peripheral
- https://gerrit.zephyrproject.org/r/1444 : Bluetooth: drivers/nble: Fix calling cmd from discov callback
- https://gerrit.zephyrproject.org/r/1202 : Bluetooth: tester: Return pre defined db offset on start server
- https://gerrit.zephyrproject.org/r/1736 : drivers/nble: Fix passing NULL pointer instead of conn to write() cb
- https://gerrit.zephyrproject.org/r/1737 : drivers/nble: Fix missing write flush() callback
- https://gerrit.zephyrproject.org/r/1739 : drivers/nble: Fix status returned from on_nble_gatts_write_evt

NEW JIRA items within last 24 hours: 1
[ZEP-214] CC2520 Rx not working with QMSI drivers
https://jira.zephyrproject.org/browse/ZEP-214


UPDATED JIRA items within last 24 hours: 0

CLOSED JIRA items within last 24 hours: 0

RESOLVED JIRA items within last 24 hours: 0

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1739 : drivers/nble: Fix status returned from on_nble_gatts_write_evt
- https://gerrit.zephyrproject.org/r/1737 : drivers/nble: Fix missing write flush() callback
- https://gerrit.zephyrproject.org/r/1736 : drivers/nble: Fix passing NULL pointer instead of conn to write() cb
- https://gerrit.zephyrproject.org/r/1735 : arch/arc/include: start_task_arch.h needed so ARC can build microkernel apps
- https://gerrit.zephyrproject.org/r/1733 : ISR: set vector base very early
- https://gerrit.zephyrproject.org/r/1723 : build: allows CC and CCX override from Makefile source files
- https://gerrit.zephyrproject.org/r/1722 : build: Add MinGW dependencies in makefile

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1584 : Added profiler application and scripts
- https://gerrit.zephyrproject.org/r/1720 : sensor: add support for BMG160 gyroscope
- https://gerrit.zephyrproject.org/r/1721 : sensor: bmg160: add sample application
- https://gerrit.zephyrproject.org/r/1666 : nios2: basic build, non-functional
- https://gerrit.zephyrproject.org/r/1656 : doc: Updates the toolchain path format instruction
- https://gerrit.zephyrproject.org/r/1263 : build: support icx llvm compiler
- https://gerrit.zephyrproject.org/r/1411 : build: add arc support to issm toolchain

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1738 : samples: magn_polling: include stdio.h and remove redundant configs
- https://gerrit.zephyrproject.org/r/1732 : boards/arduino_due: remove redundant I2C default kconfigs
- https://gerrit.zephyrproject.org/r/1725 : adc/qmsi: use new DEVICE_AND_API_INIT()
- https://gerrit.zephyrproject.org/r/1727 : counter/qmsi: use new DEVICE_AND_API_INIT()
- https://gerrit.zephyrproject.org/r/1726 : aio_comparator/qmsi: use new DEVICE_AND_API_INIT()
- https://gerrit.zephyrproject.org/r/1728 : pwm/qmsi: use new DEVICE_AND_API_INIT()
- https://gerrit.zephyrproject.org/r/1729 : rtc/qmsi: use new DEVICE_AND_API_INIT()
- https://gerrit.zephyrproject.org/r/1730 : watchdog/qmsi: use new DEVICE_AND_API_INIT()
- https://gerrit.zephyrproject.org/r/1731 : spi/qmsi: don't assign driver_api if init fails
- https://gerrit.zephyrproject.org/r/1734 : Zephyr 1.3.0-rc2
- https://gerrit.zephyrproject.org/r/1724 : Bluetooth: monitor: Update to new protocol format
- https://gerrit.zephyrproject.org/r/1710 : samples: gpio: sanitize test and remove obsolete options
- https://gerrit.zephyrproject.org/r/1691 : misc: Add sys_slist_insert
- https://gerrit.zephyrproject.org/r/1692 : tests: test_slist: Add test for sys_slist_insert
- https://gerrit.zephyrproject.org/r/1387 : Bluetooth: gatt: include service api definition proposal
- https://gerrit.zephyrproject.org/r/1702 : linker-tool-gcc: improve readability
- https://gerrit.zephyrproject.org/r/1705 : test_timer: nanokernel: use empty config for all arches
- https://gerrit.zephyrproject.org/r/1704 : test_xip: nanokernel: use common proj.conf
- https://gerrit.zephyrproject.org/r/1703 : test_obj_tracing: nanokernel: use common config
- https://gerrit.zephyrproject.org/r/1706 : philosophers: nanokernel: use empty config
- https://gerrit.zephyrproject.org/r/1701 : test_errno: remove unnecessary use of nanokernel API
- https://gerrit.zephyrproject.org/r/1668 : arch/Makefile: simplify
- https://gerrit.zephyrproject.org/r/1700 : nanokernel: move C atomic operations to centralized code
- https://gerrit.zephyrproject.org/r/1667 : Makefile.toolchain.zephyr: add nios2 arch
- https://gerrit.zephyrproject.org/r/1709 : sensors: sample: this testcase is for arduino_101

As many are probably aware by now CI services for FD.io and
ZephyrProject.org have returned to a functioning state.

For those interested in the cause our vendor has informed us that one of
their other customers came under a heavy DDoS and their automated
mitigation tools were unable to effectively block the attack. As of
about 00:30 PDT (07:30 UTC) services should have started to clear and
come back to a functioning state.

Our administrative team verified and poked systems that ended up in an
error state due to repeated connectivity bouncing of our site-to-site
VPN links.

-Andy-

--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation

Hi Vinicius,

On Wed, 2016-04-27 at 12:10 -0300, Vinicius Costa Gomes wrote:

Hi Jukka,

Jukka Rissanen <jukka.rissanen(a)linux.intel.com> writes:

Signed-off-by: Jukka Rissanen <jukka.rissanen(a)linux.intel.com>
---
Hi,

current network application APIs in Zephyr are synchronous and a
bit of awkward to use in TCP. Because of these things, I propose
couple of new functions that are asynchronous and easier to use
by the application. These APIs require net_buf fragmentation
support
that I sent earlier.

At least from Soletta side, what I feel is lacking from the Zephyr
network stack API-wise is this:

- net_writeto(struct net_context *context, struct net_buf *buf,
       struct net_addr *to, uint16_t port)

- net_readfrom(struct net_context *context, struct net_buf *buf,
       struct net_addr *from, uint16_t *port);

- net_context_add_addr(struct net_context *context,
       struct net_addr *local_addr, uint16_t port);

Sure, if the API's make sense then just send the patches.

See what Ivan needed to do here:

https://github.com/solettaproject/soletta/blob/master/src/lib/comms/s
ol-socket-impl-zephyr.c#L260

Cheers,
Jukka

Hi
I have similar kind of requirement except instead of BLE we are using BT
Expecting some answers from experts for your query

Hi Johan,

On Wed, 2016-04-27 at 21:56 +0300, Johan Hedberg wrote:

Hi Jukka,

On Wed, Apr 27, 2016, Jukka Rissanen wrote:
 +/**

+ * @brief Callback that is called when there is something received
from
+ * the network.
+ *
+ * @details It is callback responsibility to release the net_buf
when the
+ * data is no longer needed. The callback is called in fiber
context.
+ *
+ * @param context Network context
+ * @param status 0 if ok, <0 if there is an error
+ * @param iov List of net_buf that contain data
+ * @param user_data User supplied data
+ */
+typedef void (*net_readv_cb_t)(struct net_context *context,
+        int status,
+        struct net_buf *iov,
+        void *user_data);

A couple of things: I think "recv" is more intuitive than "read" when
it
comes to network operations (as opposed to e.g. file access). Same
goes
for "send" vs "write".

We have a net_send() API already that is why I used net_read() and
net_write() here. I will drop the v from the function name in next
version.

I don't think the fact that the net_buf parameter might have extra
fragments after it is enough justification for having it named "iov"
instead of simply "buf". Once fragmentation support is there it
should
be the default assumption that any buffer might have a list of
trailing
fragments. So at most I'd just mention this in the function
documentation.

Sure, the parameter name can be changed.

+/**
+ * @brief Register a receiver to get data from network.
+ *
+ * @details Application uses this to get data from network
connection.
+ * Caller needs to specify a callback function that is called when
data
+ * is received by the socket. When the IP stack has received data,
it then
+ * calls user specified callback and it is callback responsibility
to
+ * release the net_buf when the data is no longer needed.
+ * This function will return immediately as it only sets a
callback to be
+ * called when new data is received. Application can remove the
registered
+ * callback by calling the function with same context and setting
cb to NULL.
+ *
+ * @param context Network context
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_readv(struct net_context *context,
+       net_readv_cb_t cb,
+       void *user_data);

To make the purpose of the function clearer I'd rename this to
net_set_recv_cb() or similar.

Sure, np.

+/**
+ * @brief Callback that is called when user can send
+ * data to the network.
+ *
+ * @details The first call to this function will set *status to 0
and
+ * bytes_sent to 0. Application can then prepare the data to be
sent
+ * in net_buf fragment list. The data to be sent is returned to
the
+ * caller of the function. If application does not wish to send
anything
+ * it can just return NULL. In this case the caller will
deallocate the
+ * iov list. Application should set the *status to <0 to indicate
more
+ * detailed reason for the error if NULL is returned.
+ *
+ * For successfully sent UDP data, the IP stack will call this
+ * callback again with status set to 0 and bytes_sent telling how
many bytes
+ * were sent. If the UDP data was not sent for some reason, then
*status
+ * will have value < 0 and bytes_sent is set to 0.
+ *
+ * For TCP, the callback is called when the network connection has
been
+ * established. In this case the *status is 0 and bytes_sent is 0.
+ * If there is a connection timeout, the status code will be
-ETIMEDOUT
+ * and bytes_sent is set to 0. Other error codes are also possible
in
+ * which case the *status < 0 and bytes_sent will tell how many
bytes were
+ * successfully sent. If the *status is set to 0 then bytes_sent
will tell
+ * how many bytes were sent to the peer.
+ *
+ * The iov fragment list does not contain data that has been
successfully
+ * sent. Also the iov->frags->data of the first data fragment will
point to
+ * first byte that has not yet been sent.

If you want to maintain the same buffer list even after sending all
data
in some of them (something I don't think is a good idea since you
want
to unref and get the bufs back to the pool asap) I'd just set buf-

Hmm, the idea was that already sent buffers would be returned to the
pool immediately and removed from the fragment list. The fragment list
would only contain buffers that need to re-sent. This is needed in TCP,
for UDP we can always send the packets.

len

of all completed buffers to 0, i.e. the start of remaining data would
be
the first buffer in the chain with buf->len > 0. If the idea is to
keep
rotating the return parameter back to the next calls input parameter
I'd
just go forward in the chain and give a pointer to the first buffer
with
data left while having unrefed all the previous ones.

    If all the data was sent
+ * successfully, then the first item of iov list will have its
frags pointer
+ * set to NULL. Application can send more data if it wishes by
returning
+ * a new list of data fragments.
+ *
+ * The callback is called in fiber context.
+ *
+ * @param context Network context
+ * @param status 0 if ok, <0 if there is an error in stack side
+ * Application can return error code if needed via this pointer.
+ * @param bytes_sent How many bytes were sent.
+ * @param iov List of net_buf that contain data. If this is NULL,
then
+ * allocate the buf and fill it with data. If non-NULL, then the
protocol
+ * headers are already there and you can append the data.
+ * @param user_data User supplied data
+ *
+ * @return A valid net_buf that needs to be sent,
+ * NULL if user is not able to send anything.
+ */
+typedef struct net_buf *(*net_writev_cb_t)(struct net_context
*context,
+    int *status,
+    int bytes_sent,
+    struct net_buf *iov,
+    void *user_data);

I'm not really following what exactly the relationship is of the
input
net_buf parameter and the return value of this function. Sounds
unnecessarily complicated to me (the little bit that I did
understand).
Why does this function need an input net_buf parameter to start with?

If the data could not be sent, the stack calls this API again to allow
the app to do something about the situation. This is used in TCP so
that the application can know what data has been transferred
successfully to the peer.

Also, what's the reason this needs to be asynchronous this way? If
the
app is responsible for allocating the net_buf can't it just give it
straight to the stack with net_send() or similar, with an optional
callback to notify completion (or failure) of sending the data over
the
network?

The data to be sent could be given as a parameter when calling
net_write() but there would still be need to call the callback. I did
it like this in first version of API but after some experimenting it
felt more natural that all the data sending would be done from one
place (from cb), and the initial net_write() call would only do
connection establishment when needed.

+ * @brief Reply data to sender.
+ *
+ * @details This is a helper that will help user to reply data to
the
+ * sender. Application can use this function to reply data it
received
+ * via net_readv().
+ *
+ * @param context Network context
+ * @param timeout How long to wait until user can send data. This
is only
+ * used in TCP.
+ * @param iov Data to be sent
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_replyv(struct net_context *context,
+        int32_t timeout,
+        struct net_buf *iov,
+        net_writev_cb_t cb,
+        void *user_data);

This is basically something like the net_send() I mentioned earlier.

Yes, it is almost the same. As I mentioned to Ivan in another mail,
that in order to avoid to allocate extra context for reply data, the
net_reply() was created. It just swaps the IP addresses of the network
packet. It is not really mandatory but acts as a helper.


Cheers,
Jukka

Hi Ivan,

On Wed, 2016-04-27 at 11:59 -0300, Iván Briano wrote:

On Wed, 27 Apr 2016 11:59:50 +0300, Jukka Rissanen wrote:

Signed-off-by: Jukka Rissanen <jukka.rissanen(a)linux.intel.com>
---
Hi,

current network application APIs in Zephyr are synchronous and a
bit of awkward to use in TCP. Because of these things, I propose
couple of new functions that are asynchronous and easier to use
by the application. These APIs require net_buf fragmentation
support
that I sent earlier.

Cheers,
Jukka


include/net/net_socket.h | 141
+++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)

diff --git a/include/net/net_socket.h b/include/net/net_socket.h
index 88073b1..2451de3 100644
--- a/include/net/net_socket.h
+++ b/include/net/net_socket.h
@@ -143,6 +143,147 @@ int net_reply(struct net_context *context,
struct net_buf *buf);
 struct simple_udp_connection *
  net_context_get_udp_connection(struct net_context
*context);
 
+/**
+ * @brief Callback that is called when there is something received
from
+ * the network.
+ *
+ * @details It is callback responsibility to release the net_buf
when the
+ * data is no longer needed. The callback is called in fiber
context.
+ *
+ * @param context Network context
+ * @param status 0 if ok, <0 if there is an error
+ * @param iov List of net_buf that contain data
+ * @param user_data User supplied data
+ */
+typedef void (*net_readv_cb_t)(struct net_context *context,
+        int status,
+        struct net_buf *iov,
+        void *user_data);

I receive a list of net_buf, based on what criteria? A list of
packets
or a single packet split in several buffers? If the latter, then you

The latter, the app would receive list of buffers. This complicates the
application a bit but some API could be used to retrieve the data so
that app would not need to know much about the individual fragments.

are
relegating to the application developer the job of putting it all
together, which in many cases will be required. Unless we expect that
every single higher level protocol will work with non-continuous
chunks
of memory.

+
+/**
+ * @brief Register a receiver to get data from network.
+ *
+ * @details Application uses this to get data from network
connection.
+ * Caller needs to specify a callback function that is called when
data
+ * is received by the socket. When the IP stack has received data,
it then
+ * calls user specified callback and it is callback responsibility
to
+ * release the net_buf when the data is no longer needed.
+ * This function will return immediately as it only sets a
callback to be
+ * called when new data is received. Application can remove the
registered
+ * callback by calling the function with same context and setting
cb to NULL.
+ *
+ * @param context Network context
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_readv(struct net_context *context,
+       net_readv_cb_t cb,
+       void *user_data);
+
+/**
+ * @brief Callback that is called when user can send
+ * data to the network.
+ *
+ * @details The first call to this function will set *status to 0
and
+ * bytes_sent to 0. Application can then prepare the data to be
sent
+ * in net_buf fragment list. The data to be sent is returned to
the
+ * caller of the function. If application does not wish to send
anything
+ * it can just return NULL. In this case the caller will
deallocate the
+ * iov list. Application should set the *status to <0 to indicate
more
+ * detailed reason for the error if NULL is returned.
+ *
+ * For successfully sent UDP data, the IP stack will call this
+ * callback again with status set to 0 and bytes_sent telling how
many bytes
+ * were sent. If the UDP data was not sent for some reason, then
*status
+ * will have value < 0 and bytes_sent is set to 0.
+ *
+ * For TCP, the callback is called when the network connection has
been
+ * established. In this case the *status is 0 and bytes_sent is 0.
+ * If there is a connection timeout, the status code will be
-ETIMEDOUT
+ * and bytes_sent is set to 0. Other error codes are also possible
in
+ * which case the *status < 0 and bytes_sent will tell how many
bytes were
+ * successfully sent. If the *status is set to 0 then bytes_sent
will tell
+ * how many bytes were sent to the peer.
+ *
+ * The iov fragment list does not contain data that has been
successfully
+ * sent. Also the iov->frags->data of the first data fragment will
point to
+ * first byte that has not yet been sent. If all the data was sent
+ * successfully, then the first item of iov list will have its
frags pointer
+ * set to NULL. Application can send more data if it wishes by
returning
+ * a new list of data fragments.
+ *
+ * The callback is called in fiber context.
+ *
+ * @param context Network context
+ * @param status 0 if ok, <0 if there is an error in stack side
+ * Application can return error code if needed via this pointer.
+ * @param bytes_sent How many bytes were sent.
+ * @param iov List of net_buf that contain data. If this is NULL,
then
+ * allocate the buf and fill it with data. If non-NULL, then the
protocol
+ * headers are already there and you can append the data.
+ * @param user_data User supplied data
+ *
+ * @return A valid net_buf that needs to be sent,
+ * NULL if user is not able to send anything.
+ */
+typedef struct net_buf *(*net_writev_cb_t)(struct net_context
*context,
+    int *status,
+    int bytes_sent,
+    struct net_buf *iov,
+    void *user_data);

So the way to use this is:
 - I have data to send, I call net_writev() and set my callback.
 - When data can be sent, callback is called, *status and bytes_sent
= 0
 - I allocate a net_buf, put my data in it, and return it.
   * What's the iov received here? Only for error cases or the
callback
     can be called multiple times to send the remaining data? In that
     case, the idea is that I receive a list of unsent data that I
need
     to return and that's it?

The latter. So the callback would be called again to send the remaining
data.

 - When all data was sent, the callback is called again with *status
0
   and bytes_sent sent to the total of bytes sent... since the last
time
   the function was called? Since the first?

Since the last time the function was called.

The thing with the fragment list, I'm understanding is meant to work
as
an iovec, so let's say I have a CoAP server that wants to notify
three
different clients of a change in a resource, it would make sense to
have
a single buffer with the payload and change the one with the header.
If
I understand this correctly, when data was sent successfully, I will
not
have access to the net_buf with the payload anymore, so I would need
to
recreate it, correct? In this case, there's no gain (and maybe even a
little loss) in doing a list of fragments, when I can just use a
single
buffer and copy both header and payload to it.

The net_buf's have a refcount so the same buffer can be used to send
same data to multiple clients.

+
+/**
+ * @brief Send data to network.
+ *
+ * @details Application uses this to send data to a network
connection.
+ * Caller needs to specify a callback function that is called when
data
+ * is ready to be sent. The function will return immediately, the
timeout
+ * is only used when calling the user callback. For UDP, the
timeout is
+ * ignored. For TCP the callback is called after the TCP
connection is
+ * established and user is able to send data, or if there is an
error
+ * creating a connection or if the connection timeouts.
+ *

This means that every time I call net_writev(), the TCP connection is
established? Or is that only the first time? If it's only the first,
why
not add a connect() function? And if it's established every time,
what's
the point of that?

The connection would be created only once. Adding the connect() is one
option but it is not really necessary.

+ * @param context Network context
+ * @param timeout How long to wait until user can send data. This
is only
+ * used in TCP.
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_writev(struct net_context *context,
+        int32_t timeout,
+        net_writev_cb_t cb,
+        void *user_data);
+
+/**
+ * @brief Reply data to sender.
+ *
+ * @details This is a helper that will help user to reply data to
the
+ * sender. Application can use this function to reply data it
received
+ * via net_readv().
+ *
+ * @param context Network context
+ * @param timeout How long to wait until user can send data. This
is only
+ * used in TCP.
+ * @param iov Data to be sent
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_replyv(struct net_context *context,
+        int32_t timeout,
+        struct net_buf *iov,
+        net_writev_cb_t cb,
+        void *user_data);
+

Is there really no way to get rid of this? Why can't we just have a
'send' function that works for all cases? If the problem is getting
the
address to send to, just add a helper function to put this in the
net_buf before sending.

If we are able to put some intelligence to plain send then why not. The
reason for the reply() was that we could have only one context for the
connection (to save some memory). For example in BSD sockets, the
listening socket is accepted by the app in which case when sending one
uses the accepted socket to send data and the addresses in the packet
are set then correctly.
But if the send can figure out itself that it should reverse the
addresses in the sending IP packet, then we can get rid of reply.

 #ifdef __cplusplus
 }
 #endif

Cheers,
Jukka

We are currently aware of accessibility issues to the CI infrastructure
for FD.io and ZephyrProject.org. We have been tracking the issue since
it started at 21:36 PDT (04:36 UTC).

At the present moment we cannot offer an ETA on a resolution to the
problems.

-Andy-

--
Andrew J Grimberg
Systems Administrator
Release Engineering Team Lead
The Linux Foundation

Hi Jukka,

Guys !! Good day !!
Iam currently Evaluating the zephyr rtos for my project

Appreciate your ideas on the below

I have two radio's ( BLE and Wifi) on my board
My application is to Switch ON radio and do the tx/rx in the available
radio ( BLE or wifi at a single point of time )
Is that a good idea to follow as

For device driver initialization (nanokernel)
================================

1. Do a device init for BLE in nanokernel and write a fiber for rx and
tx in the BLE driver
2. Do a device init for WiFi in nanokernel and write a fiber for rx and
tx in the WiFi driver

For application (microkernel)
=======================

1. Create task for BLE in microkernel
2. Create task for wifi in microkernel
3. Write a main file to call these tasks

Appreciate your ideas for my requirement

Thanks
Walker

NEW JIRA items within last 24 hours: 0

UPDATED JIRA items within last 24 hours: 1
[ZEP-107] Need a consistent way for selecting boards and SOCs in menuconfig
https://jira.zephyrproject.org/browse/ZEP-107


CLOSED JIRA items within last 24 hours: 1
[ZEP-100] (Fixed) Test bug for Gerrit
https://jira.zephyrproject.org/browse/ZEP-100


RESOLVED JIRA items within last 24 hours: 2
[ZEP-204] (Cannot Reproduce) GPIO sample refuses to compile
https://jira.zephyrproject.org/browse/ZEP-204

[ZEP-148] (Fixed) Online documentation for kconfig repeats itself
https://jira.zephyrproject.org/browse/ZEP-148

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/1720 : sensor: add support for BMG160 gyroscope
- https://gerrit.zephyrproject.org/r/1719 : nanokernel: Fix nanokernel object timeout recalculation
- https://gerrit.zephyrproject.org/r/1721 : sensor: bmg160: add sample application
- https://gerrit.zephyrproject.org/r/1707 : drivers/interrupt_controller: initialize only NUM_IRQS interrupts
- https://gerrit.zephyrproject.org/r/1713 : Bluetooth: BR/EDR: Fix legacy pairing
- https://gerrit.zephyrproject.org/r/1700 : nanokernel: move C atomic operations to centralized code
- https://gerrit.zephyrproject.org/r/1706 : philosophers: nanokernel: use empty config
- https://gerrit.zephyrproject.org/r/1705 : test_timer: nanokernel: use empty config for all arches
- https://gerrit.zephyrproject.org/r/1704 : test_xip: nanokernel: use common proj.conf
- https://gerrit.zephyrproject.org/r/1703 : test_obj_tracing: nanokernel: use common config
- https://gerrit.zephyrproject.org/r/1702 : linker-tool-gcc: improve readability
- https://gerrit.zephyrproject.org/r/1701 : test_errno: remove unnecessary use of nanokernel private API
- https://gerrit.zephyrproject.org/r/1717 : drivers/nble: Refactor CCC changed logic
- https://gerrit.zephyrproject.org/r/1716 : drivers/nble: Save peer address with CCC write
- https://gerrit.zephyrproject.org/r/1692 : tests: test_slist: Add test for sys_slist_insert
- https://gerrit.zephyrproject.org/r/1691 : misc: Add sys_slist_insert
- https://gerrit.zephyrproject.org/r/1711 : sensor: apds9660: remove explicit GPIO configs
- https://gerrit.zephyrproject.org/r/1710 : samples: gpio: sanitize test and remove obsolete options
- https://gerrit.zephyrproject.org/r/1708 : include/arch/arc: fix memory permissions
- https://gerrit.zephyrproject.org/r/1699 : arch/arc: __start label incorrectly aliased
- https://gerrit.zephyrproject.org/r/1695 : openocd: Upgrade to 0.9

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1584 : Added profiler application and scripts
- https://gerrit.zephyrproject.org/r/1580 : Add support of event logger put/get without sync
- https://gerrit.zephyrproject.org/r/1387 : Bluetooth: gatt: include service api definition proposal
- https://gerrit.zephyrproject.org/r/1648 : net: buf: Add fragmentation API support
- https://gerrit.zephyrproject.org/r/1666 : nios2: basic build, non-functional
- https://gerrit.zephyrproject.org/r/1593 : nanokernel: Add callout API
- https://gerrit.zephyrproject.org/r/1649 : net: buf: Add fragmentation API tests
- https://gerrit.zephyrproject.org/r/1661 : tests: Add unit test for sys_callout API
- https://gerrit.zephyrproject.org/r/1594 : Bluetooth: SMP: Make use of sys_callout API
- https://gerrit.zephyrproject.org/r/1613 : i2c: add device config helpers
- https://gerrit.zephyrproject.org/r/1667 : Makefile.toolchain.zephyr: add nios2 arch
- https://gerrit.zephyrproject.org/r/1616 : samples: mcp9808: support two devices
- https://gerrit.zephyrproject.org/r/1668 : arch/Makefile: simplify
- https://gerrit.zephyrproject.org/r/1379 : microkernel: [un]block tasks on nanokernel objects infrastructure

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/1709 : sensors: sample: this testcase is for arduino_101
- https://gerrit.zephyrproject.org/r/1712 : samples: cleanup environmental sensing README file
- https://gerrit.zephyrproject.org/r/1718 : ieee802154: cc2520: Invalid argument should return -EINVAL
- https://gerrit.zephyrproject.org/r/1715 : drivers/nble: Improve debug
- https://gerrit.zephyrproject.org/r/1714 : drivers/nble: Remove unneeded type cast
- https://gerrit.zephyrproject.org/r/1694 : doc: Bluetooth: Create separate development file
- https://gerrit.zephyrproject.org/r/1693 : doc: Bluetooth: General language fixes to the current documentation
- https://gerrit.zephyrproject.org/r/1696 : drivers: stm32: Include errno.h
- https://gerrit.zephyrproject.org/r/1697 : arch: st_stm32: Include errno.h
- https://gerrit.zephyrproject.org/r/1698 : device: Include errno.h
- https://gerrit.zephyrproject.org/r/1684 : sensor: fix bmc150_magn compile error
- https://gerrit.zephyrproject.org/r/1690 : jira: prevent email with 0 changes
- https://gerrit.zephyrproject.org/r/1513 : Bluetooth: Add temporary workaround for MyNewt HCI_LE_Random reliability
- https://gerrit.zephyrproject.org/r/1029 : device: Remove DEV_* codes
- https://gerrit.zephyrproject.org/r/1601 : doc: power_mgmt: Added Power Management documentation
- https://gerrit.zephyrproject.org/r/1681 : ieee802154: Fix returning codes
- https://gerrit.zephyrproject.org/r/1682 : gpio: Fix returning codes
- https://gerrit.zephyrproject.org/r/1655 : newlib: Change location of libraries
- https://gerrit.zephyrproject.org/r/1596 : sensor: migrate all drivers to new SYS_LOG
- https://gerrit.zephyrproject.org/r/1251 : sensor: make runtime configurable attrs continuous
- https://gerrit.zephyrproject.org/r/1575 : sensor: split lsm9ds0_gyro driver
- https://gerrit.zephyrproject.org/r/1341 : sensor: add driver for LSM9DS0 accel and magn
- https://gerrit.zephyrproject.org/r/1574 : sensor: split bmc150_magn driver
- https://gerrit.zephyrproject.org/r/1340 : sensor: add the posibility to fetch one data type
- https://gerrit.zephyrproject.org/r/1278 : sensor: refactor bmc150 and lsm9ds0
- https://gerrit.zephyrproject.org/r/1573 : sensor: rename SENSOR_TYPE_* to SENSOR_VALUE_TYPE_*
- https://gerrit.zephyrproject.org/r/1360 : sensor: fix init driver_api
- https://gerrit.zephyrproject.org/r/1678 : quark_se_devboard: use QMSI drivers
- https://gerrit.zephyrproject.org/r/1683 : doc: Remove references to Bluetooth from Networking
- https://gerrit.zephyrproject.org/r/1679 : arduino 101: use QMSI spi driver

Hi Jukka,

Jukka Rissanen <jukka.rissanen(a)linux.intel.com> writes:

Signed-off-by: Jukka Rissanen <jukka.rissanen(a)linux.intel.com>
---
Hi,

current network application APIs in Zephyr are synchronous and a
bit of awkward to use in TCP. Because of these things, I propose
couple of new functions that are asynchronous and easier to use
by the application. These APIs require net_buf fragmentation support
that I sent earlier.

At least from Soletta side, what I feel is lacking from the Zephyr
network stack API-wise is this:

- net_writeto(struct net_context *context, struct net_buf *buf,
struct net_addr *to, uint16_t port)

- net_readfrom(struct net_context *context, struct net_buf *buf,
struct net_addr *from, uint16_t *port);

- net_context_add_addr(struct net_context *context,
struct net_addr *local_addr, uint16_t port);

See what Ivan needed to do here:

https://github.com/solettaproject/soletta/blob/master/src/lib/comms/sol-socket-impl-zephyr.c#L260

Cheers,
Jukka


include/net/net_socket.h | 141 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 141 insertions(+)

diff --git a/include/net/net_socket.h b/include/net/net_socket.h
index 88073b1..2451de3 100644
--- a/include/net/net_socket.h
+++ b/include/net/net_socket.h
@@ -143,6 +143,147 @@ int net_reply(struct net_context *context, struct net_buf *buf);
struct simple_udp_connection *
net_context_get_udp_connection(struct net_context *context);

+/**
+ * @brief Callback that is called when there is something received from
+ * the network.
+ *
+ * @details It is callback responsibility to release the net_buf when the
+ * data is no longer needed. The callback is called in fiber context.
+ *
+ * @param context Network context
+ * @param status 0 if ok, <0 if there is an error
+ * @param iov List of net_buf that contain data
+ * @param user_data User supplied data
+ */
+typedef void (*net_readv_cb_t)(struct net_context *context,
+ int status,
+ struct net_buf *iov,
+ void *user_data);
+
+/**
+ * @brief Register a receiver to get data from network.
+ *
+ * @details Application uses this to get data from network connection.
+ * Caller needs to specify a callback function that is called when data
+ * is received by the socket. When the IP stack has received data, it then
+ * calls user specified callback and it is callback responsibility to
+ * release the net_buf when the data is no longer needed.
+ * This function will return immediately as it only sets a callback to be
+ * called when new data is received. Application can remove the registered
+ * callback by calling the function with same context and setting cb to NULL.
+ *
+ * @param context Network context
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_readv(struct net_context *context,
+ net_readv_cb_t cb,
+ void *user_data);
+
+/**
+ * @brief Callback that is called when user can send
+ * data to the network.
+ *
+ * @details The first call to this function will set *status to 0 and
+ * bytes_sent to 0. Application can then prepare the data to be sent
+ * in net_buf fragment list. The data to be sent is returned to the
+ * caller of the function. If application does not wish to send anything
+ * it can just return NULL. In this case the caller will deallocate the
+ * iov list. Application should set the *status to <0 to indicate more
+ * detailed reason for the error if NULL is returned.
+ *
+ * For successfully sent UDP data, the IP stack will call this
+ * callback again with status set to 0 and bytes_sent telling how many bytes
+ * were sent. If the UDP data was not sent for some reason, then *status
+ * will have value < 0 and bytes_sent is set to 0.
+ *
+ * For TCP, the callback is called when the network connection has been
+ * established. In this case the *status is 0 and bytes_sent is 0.
+ * If there is a connection timeout, the status code will be -ETIMEDOUT
+ * and bytes_sent is set to 0. Other error codes are also possible in
+ * which case the *status < 0 and bytes_sent will tell how many bytes were
+ * successfully sent. If the *status is set to 0 then bytes_sent will tell
+ * how many bytes were sent to the peer.
+ *
+ * The iov fragment list does not contain data that has been successfully
+ * sent. Also the iov->frags->data of the first data fragment will point to
+ * first byte that has not yet been sent. If all the data was sent
+ * successfully, then the first item of iov list will have its frags pointer
+ * set to NULL. Application can send more data if it wishes by returning
+ * a new list of data fragments.
+ *
+ * The callback is called in fiber context.
+ *
+ * @param context Network context
+ * @param status 0 if ok, <0 if there is an error in stack side
+ * Application can return error code if needed via this pointer.
+ * @param bytes_sent How many bytes were sent.
+ * @param iov List of net_buf that contain data. If this is NULL, then
+ * allocate the buf and fill it with data. If non-NULL, then the protocol
+ * headers are already there and you can append the data.
+ * @param user_data User supplied data
+ *
+ * @return A valid net_buf that needs to be sent,
+ * NULL if user is not able to send anything.
+ */
+typedef struct net_buf *(*net_writev_cb_t)(struct net_context *context,
+ int *status,
+ int bytes_sent,
+ struct net_buf *iov,
+ void *user_data);
+
+/**
+ * @brief Send data to network.
+ *
+ * @details Application uses this to send data to a network connection.
+ * Caller needs to specify a callback function that is called when data
+ * is ready to be sent. The function will return immediately, the timeout
+ * is only used when calling the user callback. For UDP, the timeout is
+ * ignored. For TCP the callback is called after the TCP connection is
+ * established and user is able to send data, or if there is an error
+ * creating a connection or if the connection timeouts.
+ *
+ * @param context Network context
+ * @param timeout How long to wait until user can send data. This is only
+ * used in TCP.
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_writev(struct net_context *context,
+ int32_t timeout,
+ net_writev_cb_t cb,
+ void *user_data);
+
+/**
+ * @brief Reply data to sender.
+ *
+ * @details This is a helper that will help user to reply data to the
+ * sender. Application can use this function to reply data it received
+ * via net_readv().
+ *
+ * @param context Network context
+ * @param timeout How long to wait until user can send data. This is only
+ * used in TCP.
+ * @param iov Data to be sent
+ * @param cb User supplied callback function
+ * @param user_data User supplied data
+ *
+ * @return 0 if cb registration was ok, <0 otherwise
+ */
+int net_replyv(struct net_context *context,
+ int32_t timeout,
+ struct net_buf *iov,
+ net_writev_cb_t cb,
+ void *user_data);
+
#ifdef __cplusplus
}
#endif
--
2.5.5

Cheers,
--
Vinicius