Hello Yannis, Yannis Damigos <giannis.damigos@...> wrote: [] Thanks for confirming this. I by now also submitted a Github report, it borders on a bug that a review author can't dismiss their

<paul.sokolovsky@...> wrote: Hello, https://help.github.com/articles/dismissing-a-pull-request-review mentions "repository administrators or people with write access can dismiss a

Hello, I spotted a following issue: if I gave negative ("change requested") review (or just the same, positive review), I don't seem to be able to change it back to "no review". For example, if I

Hello, quick correction. I am doing support for NUCLEO-F030R8 specifically (which includes the F0 family anyway). Sorry for misleading information in the previous message. Yours faithfully, Maciej

Hello, I am going to work on the STM32F0 support for Zephyr for the next 2-3 weeks. If there is already such a project in development, let me know! If you would like to help me or give some advices,

Hello, "Boie, Andrew P" <andrew.p.boie@...> wrote: To follow up, this indeed highlighted various issues in the code, e.g. with networking subsystem, for

Hi all, I have prepared a proposal for the I2S (Inter-IC Sound) driver API. https://github.com/zephyrproject-rtos/zephyr/pull/745 The list of the most important design decision I've made

This does make sense. Having the get API makes the code very simple for the majority of devices where the sector sizes are uniform in size. The only thing is that if code needs to know if the

Hi David. Thanks for your answer. Bellow I responds to your comments: I totally agree. Agree on that - driver shouldn’t break hardware specification If hw doesn't allow rewrites then driver

We enabled the MMU with an identity page table for the qemu_x86 and qemu_x86_iamcu board targets. Branching off to bad memory addresses, dereferencing NULL pointers, etc should now trigger page faults

There does have to be some knowledge of what the flash device is doing in order for an application to be able to use the flash robustly. However, at least all of the drivers that I've used will write

Hi, Since it seems this issue is flying under the radar lets have it first discussed here since there might be implemented for the general design of many kernel

Hello All, I was looking into the STM32 CRYPT, HASH and CRC32 units and how they fit in Zephyr and could not really figure it out. There is a drivers/crypto/ with some "real" drivers for doing

Hello Andrzej, "Puzdrowski, Andrzej" <Andrzej.Puzdrowski@...> wrote: I can't say much about Flash API, but the above paragraph reminds me well about my own thoughts/wording about following

You need to prefix the name with CONFIG_ and drop the quotes. Try this instead: #define GPIO_DRV_NAME CONFIG_GPIO_MCUX_PORTB_NAME If you take a peek at

Okay Thank you, but when I tried following Code #include <zephyr.h> #include <misc/printk.h> #include <device.h> #include <gpio.h> #define GPIO_DRV_NAME "GPIO_MCUX_PORTB_NAME" .... gipo_dev =

The gpio driver names are defined in drivers/gpio/Kconfig.mcux From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...]On Behalf Of Kevin Stöckl Sent: Friday, July 07, 2017 8:41 AM To:

Hello, where did i get the GPIO_DRV_NAME for the FRDM-K64F Board? Virenfrei. www.avast.com

In my opinion Flash driver API hasn’t well-defined common behavior. It could cause additional complexity in component added on top of flash driver because the incompatibility must be deferred at

Don't you think this article is just a both overstated? Companies do discontinue boards from time to time. It's normal. There remain plenty of zephyr-supported boards to choose from: