Gotcha regarding the DEBUGASSERT. I can open up a GitHub issue to document
this discussion so it can be fixed?
Yeah regarding the critical section for sched_lock() I agree that atomicity
is needed too for the RMW. What are your thoughts on the existing mutex and
semaphore functions without barrie
On 8/28/2024 7:15 PM, Daniel Appiagyei wrote:
Hi Gregory, thank you for the quick response!
RE: 'lockcount' needing to be in a critical section:
That's good information to know, I wasn't aware before. I'm searching nuttx
for exact matches of the string 'sched_lock();' to find occurrences and
s
Actually, let me correct my previous statement that mutexs and semaphores
need critical sections, I think they just need memory barriers. We can look
at how the Linux kernel does it to double check our knowledge. Here’s s
quick stack overflow link, for what it’s worth.
https://stackoverflow.com/que
Hi Gregory, thank you for the quick response!
RE: 'lockcount' needing to be in a critical section:
That's good information to know, I wasn't aware before. I'm searching nuttx
for exact matches of the string 'sched_lock();' to find occurrences and
seeing this is not always done. Yeah a critical sec
On 8/28/2024 6:14 PM, Daniel Appiagyei wrote:
Hi all,
Looking at sched_lock.c (
https://github.com/apache/nuttx/blob/master/sched/sched/sched_lock.c#L187),
, specifically at the non-SMP sched_lock() implementation, how do we ensure
that:
1. There's no data-race when incrementing the lock count:
Hi all,
Looking at sched_lock.c (
https://github.com/apache/nuttx/blob/master/sched/sched/sched_lock.c#L187),
, specifically at the non-SMP sched_lock() implementation, how do we ensure
that:
1. There's no data-race when incrementing the lock count:
'rtcb->lockcount++;', (given that no mutex or cri
On 2024-08-28 15:48:10, Felipe Moura Oliveira wrote:
> Hello All,
>
> Following Gustavo instructions I was able to see it working several commits
> before master.
> I will open a github issue, maybe more people can look it and help us to
> solve.
If you have working hash, then please do "git bisec
Hello All,
Following Gustavo instructions I was able to see it working several commits
before master.
I will open a github issue, maybe more people can look it and help us to
solve.
Em qua., 28 de ago. de 2024 às 13:11, Felipe Moura Oliveira <
moura@gmail.com> escreveu:
> Yes Alan.
>
> I st
On 8/28/2024 9:43 AM, raiden00pl wrote:
I don't know what was the initial intention about `drivers/`, only Greg can
answer this question.
All directories except for arch/ and board/ should have only generic
code that can be built with all all compilers and for any target. That
is true for almos
arch/drivers looks like a better idea than just drivers/
but arch/ contains one directory per architecture: arm x68 risc-v. and
drivers is not an arch.
drivers/arch/ could also be used.
Sebastien
On 28/08/2024 18:03, Lwazi Dube wrote:
On Wed, 28 Aug 2024 at 11:43, raiden00pl wrote:
I don
Yes Alan.
I started testing with 1 MHz and dropped the speed to check.
*are you sure that clock rising/falling edges are configured correctly for
mosi/miso read/write requirements? *Yes I check it properly.
Em qua., 28 de ago. de 2024 às 12:48, Alan C. Assis
escreveu:
> Hi Tomek,
>
> As you c
On Wed, 28 Aug 2024 at 11:43, raiden00pl wrote:
> I don't know what was the initial intention about `drivers/`, only Greg can
> answer this question.
> But what I see now is that `drivers/` implement `upper-half` drivers, and
> arch specific drivers implement "lower-half" drivers (there are proba
Hi Tomek,
As you can see in the signal wave screenshots, he is using 100Hz, which is
already too slow for SPI.
BR,
Alan
On Wed, Aug 28, 2024 at 12:15 PM Tomek CEDRO wrote:
> are you sure that clock rising/falling edges are configured correctly for
> mosi/miso read/write requirements?
>
> have
I don't know what was the initial intention about `drivers/`, only Greg can
answer this question.
But what I see now is that `drivers/` implement `upper-half` drivers, and
arch specific drivers implement "lower-half" drivers (there are probably a
few exceptions
to this rule).
For this reason, pollu
On Wed, 28 Aug 2024 at 09:21, raiden00pl wrote:
> As Alan said `drivers/` should remain independent from `arch`.
> The clean separation of arch from the rest of the code is one of the nicest
> things about NuttX and it should stay that way.
>
I won't argue against clean separation, but why does
As Alan said `drivers/` should remain independent from `arch`.
The clean separation of arch from the rest of the code is one of the nicest
things about NuttX and it should stay that way.
But the problem of reusing the same low-level driver code across different
arch implementations is an unsolved
16 matches
Mail list logo
