On Wed, May 17, 2023 at 7:34 PM Brennan Ashton
wrote:
> On Wed, May 17, 2023, 5:13 AM Nathan Hartman
> wrote:
>
> >
> > Let's create a blog section on the nuttx.apache.org site and fill it
> with
> > articles like these!
> >
> > Cheers
> > Nathan
> >
>
> This is supported, just no content added
On Wed, May 17, 2023, 5:13 AM Nathan Hartman
wrote:
>
> Let's create a blog section on the nuttx.apache.org site and fill it with
> articles like these!
>
> Cheers
> Nathan
>
This is supported, just no content added
See https://github.com/apache/nuttx-website/tree/master/_posts
>
On Wed, May 17, 2023 at 2:13 PM Nathan Hartman wrote:
> Let's create a blog section on the nuttx.apache.org site and fill it with
> articles like these!
Maybe Hackster?
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Hi Tim,
Cache flush after dma data copy was a hard nut we had. But it was on read,
you face issues on write, I was to fast.
Maybe this samv7 PR helps also on your arch:
https://github.com/apache/nuttx/pull/5513
Simon
--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone
Tim H
Good suggestion – thanks!
From: Petro Karashchenko
Reply to: "dev@nuttx.apache.org"
Date: Wednesday, 17 May 2023 at 19:28
To: "dev@nuttx.apache.org"
Subject: Re: Odd DMA issue
I think you can try to compare versus SAMv7 SPI+DMA driver that is working
well and see if there are obvious differenc
In what way?
I am concerned by a comment in the sama5 xdmac code which says:
“Calls to sam_dmatxsetup() and sam_dmarxsetup() must not be intermixed on the
same transfer, however.”
They are sort of intermixed as part of the SPI exchange function – which is
near enough identical to most arm proc
I think you can try to compare versus SAMv7 SPI+DMA driver that is working
well and see if there are obvious differences.
BR,
Petro
On Wed, May 17, 2023, 9:18 PM Simon Filgis
wrote:
> D-Cache flush?
>
> --
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278
> --
> sent by mobile phone
>
> Tim Hardi
D-Cache flush?
--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone
Tim Hardisty schrieb am Mi., 17. Mai 2023, 20:05:
> I am working on getting DMA working on the SPI peripheral of the SAMA5D2.
>
> DMA reads now work well, but the writes take absolutely forever…unless I
> have
I am working on getting DMA working on the SPI peripheral of the SAMA5D2.
DMA reads now work well, but the writes take absolutely forever…unless I have
dma debug info enabled, when write transactions (to a GD25Q flash) do then work.
I’m working through it, as it sounds like a race condition or o
Was it working before? If so, are you able to use a git bisect to find
the commit where the bug was introduced? This might minimize the
amount of testing and debugging that needs to be done.
On Wed, May 17, 2023 at 11:12 AM Jukka Laitinen wrote:
>
>
>
> Petro Karashchenko kirjoitti keskiviikko 17
Petro Karashchenko kirjoitti keskiviikko 17. toukokuuta 2023:
> How do you measure the wait period? Are you togging a pin or used MCU free
> running HW timer?
I used RISC-V MTIMER, so it is a free running HW counter at 1us resolution
>
> Best regards,
> Petro
>
> On Wed, May 17, 2023, 5:43 PM
How do you measure the wait period? Are you togging a pin or used MCU free
running HW timer?
Best regards,
Petro
On Wed, May 17, 2023, 5:43 PM Jukka Laitinen wrote:
>
> On 17.5.2023 16.38, Gregory Nutt wrote:
> > On 5/17/2023 7:21 AM, Gregory Nutt wrote:
> >> On 5/17/2023 4:21 AM, Jukka Laitine
On 17.5.2023 16.38, Gregory Nutt wrote:
On 5/17/2023 7:21 AM, Gregory Nutt wrote:
On 5/17/2023 4:21 AM, Jukka Laitinen wrote:
Hi,
I just observed the behaviour mentioned in the subject;
I tried just calling in a loop:
"
sem_t sem =SEM_INITIALIZER(0);
int ret;
ret = nxsem_ti
Hi Sebastien,
one of the projects I am working on requires an EMV 4.3d level 1 compliant
smartcard reader on an STM32U5. So I would be very interested in the work
you are planning to do. I have a lot of background knowledge on EVM
compliant contactless card readers, but unfortunately not so for t
On 5/17/2023 7:21 AM, Gregory Nutt wrote:
On 5/17/2023 4:21 AM, Jukka Laitinen wrote:
Hi,
I just observed the behaviour mentioned in the subject;
I tried just calling in a loop:
"
sem_t sem =SEM_INITIALIZER(0);
int ret;
ret = nxsem_tickwait_uninterruptible(&sem, 1);
"
, and
On 5/17/2023 4:21 AM, Jukka Laitinen wrote:
Hi,
I just observed the behaviour mentioned in the subject;
I tried just calling in a loop:
"
sem_t sem =SEM_INITIALIZER(0);
int ret;
ret = nxsem_tickwait_uninterruptible(&sem, 1);
"
, and never posting the sem from anywhere. The fu
On Wed, May 17, 2023 at 3:12 AM Lee, Lup Yuen wrote:
> When we tilt our Smartphone from Portrait to Landscape... How does it know
> that we're tilting our phone? Watch what happens when we snoop the
> Accelerometer Data from PinePhone's MPU-6050 Accelerometer...
>
>
> https://www.hackster.io/lupy
Hi,
I just observed the behaviour mentioned in the subject;
I tried just calling in a loop:
"
sem_t sem =SEM_INITIALIZER(0);
int ret;
ret = nxsem_tickwait_uninterruptible(&sem, 1);
"
, and never posting the sem from anywhere. The function return
-ETIMEDOUT properly on every
When we tilt our Smartphone from Portrait to Landscape... How does it know
that we're tilting our phone? Watch what happens when we snoop the
Accelerometer Data from PinePhone's MPU-6050 Accelerometer...
https://www.hackster.io/lupyuen/inside-a-smartphone-accelerometer-pinephone-with-nuttx-rtos-b9
19 matches
Mail list logo