|
Reminder: advanced compiler novelties are upon us
Hi, Szymon Janc <szymon.janc@...> writes: Adding the warnings, I think, is the best way forward. Keeping the checks after the NULL pointer is accessed gains us little, we are already in undefi
Hi, Szymon Janc <szymon.janc@...> writes: Adding the warnings, I think, is the best way forward. Keeping the checks after the NULL pointer is accessed gains us little, we are already in undefi
|
By
Vinicius Costa Gomes
· #339
·
|
|
samples/net/zoap_server - blockwise transfers?
Hi Wojtek, "Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes: There are still some bugs in the implementation, I am working on solving them, I just noticed it when I was running a CoAP test su
Hi Wojtek, "Bober, Wojciech" <Wojciech.Bober(a)nordicsemi.no> writes: There are still some bugs in the implementation, I am working on solving them, I just noticed it when I was running a CoAP test su
|
By
Vinicius Costa Gomes
· #4573
·
|
|
zoap architecture question...
Hi, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes: I agree that this has a cost in repeated code. Just a little background: when I wrote sol-coap, for the Soletta project, I took the opposite
Hi, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes: I agree that this has a cost in repeated code. Just a little background: when I wrote sol-coap, for the Soletta project, I took the opposite
|
By
Vinicius Costa Gomes
· #3748
·
|
|
zoap architecture question...
Hi, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes: The plan is that the error handling would live in the layer above. So yeah, the zoap-server sample right now is lacking in the invalid messa
Hi, Marcus Shawcroft <marcus.shawcroft(a)gmail.com> writes: The plan is that the error handling would live in the layer above. So yeah, the zoap-server sample right now is lacking in the invalid messa
|
By
Vinicius Costa Gomes
· #3727
·
|
|
Porting to Cortex-M0+
Hi, Euan Mutch <euan.mutch(a)gmail.com> writes: Licensing issues perhaps[1]? "Disclaimer and Credits ... 4. This software may only be redistributed and used in connection with an Atmel microcontroller
Hi, Euan Mutch <euan.mutch(a)gmail.com> writes: Licensing issues perhaps[1]? "Disclaimer and Credits ... 4. This software may only be redistributed and used in connection with an Atmel microcontroller
|
By
Vinicius Costa Gomes
· #3500
·
|
|
[RFC] CoAP for Zephyr
Hi Johan, Johan Hedberg <johan.hedberg(a)intel.com> writes: I had some plans that this could be used in other places, but I am not opposed to make this Zephyr specific, and use net_buf (for example) i
Hi Johan, Johan Hedberg <johan.hedberg(a)intel.com> writes: I had some plans that this could be used in other places, but I am not opposed to make this Zephyr specific, and use net_buf (for example) i
|
By
Vinicius Costa Gomes
· #3085
·
|
|
[RFC] CoAP for Zephyr
Hi, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> writes: The public accessible address is: http://git.infradead.org/users/vcgomes/quapi.git Cheers, -- Vinicius
Hi, Vinicius Costa Gomes <vinicius.gomes(a)intel.com> writes: The public accessible address is: http://git.infradead.org/users/vcgomes/quapi.git Cheers, -- Vinicius
|
By
Vinicius Costa Gomes
· #3084
·
|
|
[RFC] CoAP for Zephyr
Hi, Extracted from: https://gerrit.zephyrproject.org/r/#/c/2487/ --8<---------------cut here---------------start------------->8--- Quapi[1] - Basic CoAP for Zephyr ################################ CoA
Hi, Extracted from: https://gerrit.zephyrproject.org/r/#/c/2487/ --8<---------------cut here---------------start------------->8--- Quapi[1] - Basic CoAP for Zephyr ################################ CoA
|
By
Vinicius Costa Gomes
· #3082
·
|
|
Zephyr Enhancement Proposals
Hi Anas, "Nashif, Anas" <anas.nashif(a)intel.com> writes: +1 Just for reference the Rust[1] project has a similar concept, and it's been working for some time, it may give a few ideas: https://github.
Hi Anas, "Nashif, Anas" <anas.nashif(a)intel.com> writes: +1 Just for reference the Rust[1] project has a similar concept, and it's been working for some time, it may give a few ideas: https://github.
|
By
Vinicius Costa Gomes
· #2900
·
|
|
[RFC] net: New API for applications to send and receive data
Hi Jukka, Jukka Rissanen <jukka.rissanen(a)linux.intel.com> writes: At least from Soletta side, what I feel is lacking from the Zephyr network stack API-wise is this: - net_writeto(struct net_context
Hi Jukka, Jukka Rissanen <jukka.rissanen(a)linux.intel.com> writes: At least from Soletta side, what I feel is lacking from the Zephyr network stack API-wise is this: - net_writeto(struct net_context
|
By
Vinicius Costa Gomes
· #2859
·
|
|
RFC: 2/5 System Device Driver Modifications
Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: Ah, I see. Thanks. Cheers, -- Vinicius
Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: Ah, I see. Thanks. Cheers, -- Vinicius
|
By
Vinicius Costa Gomes
· #2547
·
|
|
RFC: 2/5 System Device Driver Modifications
Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: I am thinking about the case when DEV_BUSY is returned, I am considering this would happen, for example, in the SPI case when there's a transfe
Hi, "Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes: I am thinking about the case when DEV_BUSY is returned, I am considering this would happen, for example, in the SPI case when there's a transfe
|
By
Vinicius Costa Gomes
· #2543
·
|
|
[RFC] GPIO API changes
Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: I am just wondering that in the "old" API '_port_enable_callback()' was a way to have the callback called with the pins expressed in a bit
Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: I am just wondering that in the "old" API '_port_enable_callback()' was a way to have the callback called with the pins expressed in a bit
|
By
Vinicius Costa Gomes
· #2494
·
|
|
[RFC] GPIO API changes
Hi, Sorry if I am a little too late. Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: Another issue of the current API is the confusion caused by 'gpio_port_enable_callback()' and 'gpio_p
Hi, Sorry if I am a little too late. Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: Another issue of the current API is the confusion caused by 'gpio_port_enable_callback()' and 'gpio_p
|
By
Vinicius Costa Gomes
· #2490
·
|
|
Pinmux driver model: per board vs. unified
Hi, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Exactly, from what I can see, it will be only one common function. I see. I wouldn't like that these _priv.{c,h} idiom would become the
Hi, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Exactly, from what I can see, it will be only one common function. I see. I wouldn't like that these _priv.{c,h} idiom would become the
|
By
Vinicius Costa Gomes
· #2339
·
|
|
Pinmux driver model: per board vs. unified
Hi Dmitriy, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Good idea, this is going to be useful to see if what I have in mind is aligned with what other's have. This is a rough sketch of
Hi Dmitriy, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Good idea, this is going to be useful to see if what I have in mind is aligned with what other's have. This is a rough sketch of
|
By
Vinicius Costa Gomes
· #2336
·
|
|
Pinmux driver model: per board vs. unified
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I already started this. Hoping to have something to show later today or tomorrow. Cheers, -- Vinicius
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I already started this. Hoping to have something to show later today or tomorrow. Cheers, -- Vinicius
|
By
Vinicius Costa Gomes
· #2329
·
|
|
Pinmux driver model: per board vs. unified
Hi Dirk, Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I like it. The only thing I am thinking about is polluting the drivers/pinmux/ directory when there are more than a couple of board
Hi Dirk, Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I like it. The only thing I am thinking about is polluting the drivers/pinmux/ directory when there are more than a couple of board
|
By
Vinicius Costa Gomes
· #2322
·
|
|
Pinmux driver model: per board vs. unified
Hi, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes: Thanks for the well thought answer.
Hi, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes: Thanks for the well thought answer.
|
By
Vinicius Costa Gomes
· #2317
·
|
|
Pinmux driver model: per board vs. unified
Hi, (Sorry for the click bait-ish subject) As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to the mailing list. Quoting Dirk: Makes sense. The only thing that may complicate m
Hi, (Sorry for the click bait-ish subject) As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to the mailing list. Quoting Dirk: Makes sense. The only thing that may complicate m
|
By
Vinicius Costa Gomes
· #2307
·
|