|
RFC: API change - make all device instance constant
Hello, The PR was merged. Now ALL device instances are constant. Along with this change: all isr handlers take a const void pointer. To all relevant stakeholders that this may affect: !!! PLEASE REBAS
Hello, The PR was merged. Now ALL device instances are constant. Along with this change: all isr handlers take a const void pointer. To all relevant stakeholders that this may affect: !!! PLEASE REBAS
|
By
Tomasz Bursztyka
· #7308
·
|
|
RFC: API change - make all device instance constant
Hello, As part of https://github.com/zephyrproject-rtos/zephyr/issues/22941 I am proposing to switch all device instances to constant, see: https://github.com/zephyrproject-rtos/zephyr/issues/27399 An
Hello, As part of https://github.com/zephyrproject-rtos/zephyr/issues/22941 I am proposing to switch all device instances to constant, see: https://github.com/zephyrproject-rtos/zephyr/issues/27399 An
|
By
Tomasz Bursztyka
· #7241
·
|
|
RFC: API change - Device structure attribute renaming
Hello, I am proposing to rename 3 attributes of struct device. These attributes names have legacy roots which do not make sense anymore. See: https://github.com/zephyrproject-rtos/zephyr/issues/27397
Hello, I am proposing to rename 3 attributes of struct device. These attributes names have legacy roots which do not make sense anymore. See: https://github.com/zephyrproject-rtos/zephyr/issues/27397
|
By
Tomasz Bursztyka
· #7240
·
|
|
[RFC] API change - Normalize DMA, IPM and UART callbacks signatures including the caller's device pointer.
Hello, You will find the github issue here https://github.com/zephyrproject-rtos/zephyr/issues/26923 Which describes the changes. PRs are already done and linked there as well. Tomasz
Hello, You will find the github issue here https://github.com/zephyrproject-rtos/zephyr/issues/26923 Which describes the changes. PRs are already done and linked there as well. Tomasz
|
By
Tomasz Bursztyka
· #7183
·
|
|
DMA: driver API's thread safety
Hi Raveendra, Yes it should be up to the driver to manage this. However, this is not the case in many drivers (across all domain, not only DMA). This is also one of the thing which is being solved thr
Hi Raveendra, Yes it should be up to the driver to manage this. However, this is not the case in many drivers (across all domain, not only DMA). This is also one of the thing which is being solved thr
|
By
Tomasz Bursztyka
· #6975
·
|
|
To bring back RPL to Zephyr project
Hi, Former RPL was a port of contiki's RPL implementation, if I am not mistaken. But it slipped a lot compared to its original code, which one got a lot more features implemented. Also, the issue with
Hi, Former RPL was a port of contiki's RPL implementation, if I am not mistaken. But it slipped a lot compared to its original code, which one got a lot more features implemented. Also, the issue with
|
By
Tomasz Bursztyka
· #6807
·
|
|
[EXT] [Zephyr-devel] about Dual Mac application for zephyr
Hi, Indeed the driver requires another instance to be added. Hopefully it's trivial, basically a copy-paste of the existing one minor tiny modifications. The annoying part will be modifying Kconfig as
Hi, Indeed the driver requires another instance to be added. Hopefully it's trivial, basically a copy-paste of the existing one minor tiny modifications. The annoying part will be modifying Kconfig as
|
By
Tomasz Bursztyka
· #6482
·
|
|
Proper way to handle GPIO IRQ enablement
Hi Lincoln, Can you try https://github.com/zephyrproject-rtos/zephyr/pull/11396 (1st commit) That should solve your issue. Instead of returning -EALREADY if already installed, I just return 0. Tomasz
Hi Lincoln, Can you try https://github.com/zephyrproject-rtos/zephyr/pull/11396 (1st commit) That should solve your issue. Instead of returning -EALREADY if already installed, I just return 0. Tomasz
|
By
Tomasz Bursztyka
· #5416
·
|
|
Proper way to handle GPIO IRQ enablement
Hi, Actually you found a bug. It's not up to the user to know that the cb is already installed (even though, logically it does not make sense to add the same cb many times), in other words: gpio shoul
Hi, Actually you found a bug. It's not up to the user to know that the cb is already installed (even though, logically it does not make sense to add the same cb many times), in other words: gpio shoul
|
By
Tomasz Bursztyka
· #5415
·
|
|
SPI driver development
Hi Jiri, One thing is common over all drivers is how it iterates through the r/w buffers (drivers/spi/spi_context.h) but rest depends on hardware and whether or not you use a HAL to access it (nrfx, s
Hi Jiri, One thing is common over all drivers is how it iterates through the r/w buffers (drivers/spi/spi_context.h) but rest depends on hardware and whether or not you use a HAL to access it (nrfx, s
|
By
Tomasz Bursztyka
· #5068
·
|
|
Multiple Instances of Drivers
Hi, There is already an on-going work on how devices (aka driver instance) are generated. See issue: https://github.com/zephyrproject-rtos/zephyr/issues/6293 Especially, check for b0661 and erwango PR
Hi, There is already an on-going work on how devices (aka driver instance) are generated. See issue: https://github.com/zephyrproject-rtos/zephyr/issues/6293 Especially, check for b0661 and erwango PR
|
By
Tomasz Bursztyka
· #2219
·
|
|
Using SPI_SLAVE on STM32
Hi Armando, I am not maintaining stm32 driver, I won't much of any help about it. Get in touch with PR 5200 owner or one of the guys that created the driver (git blame). Br, Tomasz
Hi Armando, I am not maintaining stm32 driver, I won't much of any help about it. Get in touch with PR 5200 owner or one of the guys that created the driver (git blame). Br, Tomasz
|
By
Tomasz Bursztyka
· #2186
·
|
|
Using SPI_SLAVE on STM32
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
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
|
By
Tomasz Bursztyka
· #2132
·
|
|
Using SPI_SLAVE on STM32
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 h
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 h
|
By
Tomasz Bursztyka
· #2130
·
|
|
dhcpv4 with the enc28j60 module
Hi Clemence, Could you try sniffing the ipv4 traffic? And could you paste your .config somewhere? Btw, a tiny detail: You don't need CONFIG_ETH_ENC28J60_0_GPIO_SPI_CS on stm32 board, unless you ant to
Hi Clemence, Could you try sniffing the ipv4 traffic? And could you paste your .config somewhere? Btw, a tiny detail: You don't need CONFIG_ETH_ENC28J60_0_GPIO_SPI_CS on stm32 board, unless you ant to
|
By
Tomasz Bursztyka
· #2027
·
|
|
Implement SPI on a STM32f7
Hi Clemence, SPI is supported on stm32f4 SoCs, the doc is probably not up to date. Maybe it's just not enabled on the board's dts file. But on SoC level it is, see dts/arm/st/stm32f407.dtsi which incl
Hi Clemence, SPI is supported on stm32f4 SoCs, the doc is probably not up to date. Maybe it's just not enabled on the board's dts file. But on SoC level it is, see dts/arm/st/stm32f407.dtsi which incl
|
By
Tomasz Bursztyka
· #2002
·
|
|
i2c device driver
Hi Marcio, Is it an i2c controller you are trying to support or a device that uses the i2c bus? If it's the first option: What you want is looking at include/i2c.h There you'll find the i2c API your d
Hi Marcio, Is it an i2c controller you are trying to support or a device that uses the i2c bus? If it's the first option: What you want is looking at include/i2c.h There you'll find the i2c API your d
|
By
Tomasz Bursztyka
· #1880
·
|
|
network module
Hi Ismael, Ah, then you are a bit more in trouble, design wise. I.e., the current LoRaMAC port would need to be finished, and exposing an API which - in turn - your offload device could support as wel
Hi Ismael, Ah, then you are a bit more in trouble, design wise. I.e., the current LoRaMAC port would need to be finished, and exposing an API which - in turn - your offload device could support as wel
|
By
Tomasz Bursztyka
· #1801
·
|
|
network module
Hi guys, About LoRa, there is already a PR for the LoRaMAC port here: https://github.com/zephyrproject-rtos/zephyr/pull/5764 Get in touch with Ding Tao about it, there a tiny changes required but that
Hi guys, About LoRa, there is already a PR for the LoRaMAC port here: https://github.com/zephyrproject-rtos/zephyr/pull/5764 Get in touch with Ding Tao about it, there a tiny changes required but that
|
By
Tomasz Bursztyka
· #1799
·
|
|
Zephyr issue tracking system moved to Github
Hi Paul, Fine by me. Tomasz
Hi Paul, Fine by me. Tomasz
|
By
Tomasz Bursztyka
· #1388
·
|