Re: IP Clearance

HI, > "something like this" you mean because of the license or because of the small > number of files? Because of the license and it’s a small amount of code, it's regarded at Category A [1]. However do take care not to fork existing projects if possible. > If the latter, my question is always

Re: IP Clearance

> But for something like this under the BSD license you don't have to relicense > it, you just need to mention this in the LICENSE file. "something like this" you mean because of the license or because of the small number of files? If the latter, my question is always "what is big enough?". So

Re: IP Clearance

Hi, > Well, I suppose any new contribution should always be in ALv2, so yes. If you want it to be ALv2 then it is best to: a) Ask the author to relicense it to ALv2 b) Ask them to sign an ICLA (assuming they are the copyright owner not their employer. In most cases it will be their employer.) c)

Re: IP Clearance

On Tue, Oct 27, 2020, at 22:44, Justin Mclean wrote: > Hi, > > > I was about to edit a file and saw it was BSD licensed with Copyright to > > company and author which does not to appear to be an active commiter. What > > is the procedure to start asking for ICLAs/SGAs? Should I just email the >

Re: IP Clearance

Hi, > I was about to edit a file and saw it was BSD licensed with Copyright to > company and author which does not to appear to be an active commiter. What is > the procedure to start asking for ICLAs/SGAs? Should I just email the author? Depends on a few things: - Do you want to relicense as A

Re: IP Clearance

Hi, I was about to edit a file and saw it was BSD licensed with Copyright to company and author which does not to appear to be an active commiter. What is the procedure to start asking for ICLAs/SGAs? Should I just email the author? Relative to this is something I was thinking recently: shouldn'

Re: BLE602 and NuttX

For sure, I kind of recall a similar situation with the ESP modules, but then it looked better in practice. I kind of miss working on the Dialog parts for this, they are so low power. --Brennan On Tue, Oct 27, 2020, 9:14 AM Matias N. wrote: > If you can measure current consumption on sleep an

Re: BLE602 and NuttX

If you can measure current consumption on sleep and idle, it would be great. The datasheet lists very high values. On Tue, Oct 27, 2020, at 12:37, Brennan Ashton wrote: > They are sending me some hardware in a couple weeks, so we shall see what > comes of it. > > --Brennan > > On Tue, Oct 27, 2

Re: BLE602 and NuttX

They are sending me some hardware in a couple weeks, so we shall see what comes of it. --Brennan On Tue, Oct 27, 2020, 8:04 AM Matias N. wrote: > In case you missed it, there's a new RISC-V chip with BLE+WIFI support, > clearly competing with ESP8266/ESP32. > The documentation and code is just

Re: BLE602 and NuttX

Hi Matias, Bouffalo Lab is following Espressif path, this is a good news!!! Let's see if they will really open-source everything! BR, Alan On 10/27/20, Matias N. wrote: > In case you missed it, there's a new RISC-V chip with BLE+WIFI support, > clearly competing with ESP8266/ESP32. > The docu

BLE602 and NuttX

In case you missed it, there's a new RISC-V chip with BLE+WIFI support, clearly competing with ESP8266/ESP32. The documentation and code is just starting to appear and the company has given a good first step by asking users about comments. You can find the issue here: https://github.com/bouffalo

Re: interrupt priorities on nRF52

Hi Nathan, I totally agree! Zero Jitter Interrupt is a better name. We don't have zero latency, we have zero jitter. BR, Alan On 10/27/20, Nathan Hartman wrote: > On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote: > >> Hi Nathan, >> as I mentioned in my previous email, this isn't about overhe

Re: interrupt priorities on nRF52

And I just wrote this questions while you were writing the answers =) Thanks, I understand a bit better that this indeed interrupts other ISRs. On Tue, Oct 27, 2020, at 11:12, Nathan Hartman wrote: > On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote: > > > Hi Nathan, > > as I mentioned in my pre

Re: interrupt priorities on nRF52

Are you suggesting that these "zero latency interrupts" (which I simply understand as "write my own ISR handler instead of using NuttX's dispatch system") do actually interrupt other handlers? Is it because you wouldn't be disabling other interrupts as NuttX internally does in its own handler? I

Re: interrupt priorities on nRF52

On Tue, Oct 27, 2020 at 10:03 AM Matias N. wrote: > Hi Nathan, > as I mentioned in my previous email, this isn't about overhead, is about > other ISRs delaying mine. I didn't see your reply until after, but Zero Latency Interrupts should more aptly be called Zero Jitter Interrupt, because jitte

Re: interrupt priorities on nRF52

Hi Matias, The High-perf Zero Latency Interrupts is a misleading name. In fact it works like something external to the NuttX: https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts You can use it with a timer with highest priority that will interrupt the N

Re: interrupt priorities on nRF52

Hi Nathan, as I mentioned in my previous email, this isn't about overhead, is about other ISRs delaying mine. This happens only so often if I'm unlucky, so it isn't like it breaks the communication completely. But I would like to trust the communication more and know that if I start processing I

Re: interrupt priorities on nRF52

On Tue, Oct 27, 2020 at 4:09 AM Xiang Xiao wrote: > On Tue, Oct 27, 2020 at 7:43 AM Matias N. wrote: > > > As Greg mentioned in the corresponding open issue, TizenRT took Greg's > > snippets from the Wiki page and mostly implemented that. Couldn't really > > find more changes than that, so I'm n

Re: interrupt priorities on nRF52

Zero Latency Interrupts, AFAIK, are to reduce ISR overhead. My problem is other ISRs being run delay the execution of time-critical ISRs. On Tue, Oct 27, 2020, at 05:09, Xiang Xiao wrote: > On Tue, Oct 27, 2020 at 7:43 AM Matias N. wrote: > > > As Greg mentioned in the corresponding open issue,

Re: Running ifconfig on BeagleboneBlack

Just submitted a pull request for issue # 1883. Though it builds fine, I couldn't test it on real hardware as Beaglebone Black doesn't currently have necessary networking support built in. I'd really appreciate it if someone could test it on

Re: interrupt priorities on nRF52

On Tue, Oct 27, 2020 at 7:43 AM Matias N. wrote: > As Greg mentioned in the corresponding open issue, TizenRT took Greg's > snippets from the Wiki page and mostly implemented that. Couldn't really > find more changes than that, so I'm not sure if it is actually used on > TizenRT or they managed t