Re: Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Nathan Hartman]

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
>
> See https://github.com/apache/nuttx-website/tree/master/_posts
>


Woohoo! Thanks, Brennan!

Nathan

Re: Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Brennan Ashton]

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

>

Re: Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Tomek CEDRO]

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

Re: Odd DMA issue

[Simon Filgis]

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 Hardisty  schrieb am Mi., 17. Mai 2023, 20:31:

> 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 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 Hardisty mailto:t...@hardisty.co.uk>> 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 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 other
> > timing/sequence problem but if anyone by any chance has encountered
> > anything similar, clues or suggestions would be most welcome!
> >
> > Thx,
> >
> > Tim
> >
>
>
>

Re: Odd DMA issue

[Tim Hardisty]

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 differences.

BR,
Petro

On Wed, May 17, 2023, 9:18 PM Simon Filgis 
mailto:si...@ingenieurbuero-filgis.de>>
wrote:

D-Cache flush?

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tim Hardisty mailto:t...@hardisty.co.uk>> 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 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 other
> timing/sequence problem but if anyone by any chance has encountered
> anything similar, clues or suggestions would be most welcome!
>
> Thx,
>
> Tim
>

Re: Odd DMA issue

[Tim Hardisty]

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 processors, though.

From: Simon Filgis 

D-Cache flush?

--
Ingenieurbüro-Filgis
USt-IdNr.: DE305343278
--
sent by mobile phone

Tim Hardisty mailto:t...@hardisty.co.uk>> 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 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 other
timing/sequence problem but if anyone by any chance has encountered
anything similar, clues or suggestions would be most welcome!

Thx,

Tim

Re: Odd DMA issue

[Petro Karashchenko]

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 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 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 other
> > timing/sequence problem but if anyone by any chance has encountered
> > anything similar, clues or suggestions would be most welcome!
> >
> > Thx,
> >
> > Tim
> >
>

Re: Odd DMA issue

[Simon Filgis]

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 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 other
> timing/sequence problem but if anyone by any chance has encountered
> anything similar, clues or suggestions would be most welcome!
>
> Thx,
>
> Tim
>

Odd DMA issue

[Tim Hardisty]

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 other 
timing/sequence problem but if anyone by any chance has encountered anything 
similar, clues or suggestions would be most welcome!

Thx,

Tim

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Nathan Hartman]

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. 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 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 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 function return
> > > >>> -ETIMEDOUT properly on every call.
> > > >>>
> > > >>> But when measuring the time spent in the wait, I see randomly that
> > > >>> sometimes the sleep time was less than one systick.
> > > >>>
> > > >>> If I set systick to 10ms, I see typical (correct) sleep time between
> > > >>> 1 - 2us. But sometimes (very randomly) between 0 - 1us.
> > > >>> Also in these error cases the return value is correct (-110,
> > > >>> -ETIMEDOUT).
> > > >>>
> > > >>> When sleeping for 2 ticks, I see randomly sleep times between
> > > >>> 1-2us, for 3 ticks 2-3us. So, randomly it is exactly
> > > >>> one systick too small.
> > > >>>
> > > >>> I looked through the implementation of the
> > > >>> "nxsem_tickwait_uninterruptible" itself, and didn't saw problem
> > > >>> there. (Actually, I think there is a bug if -EINTR occurs; in that
> > > >>> case it should always sleep at least one tick more - now it doesn't.
> > > >>> But it is not related to this, in my test there was no -EINTR).
> > > >>>
> > > >>> I believe the problem might be somewhere in sched/wdog/ , but so far
> > > >>> couldn't track down what causes it.
> > > >>>
> > > >>> Has anyone else seen the same issue?
> > > >>>
> > > >>> Br,
> > > >>>
> > > >>> Jukka
> > > >>
> > > >>
> > > >> If I understand what you are seeing properly, then it is normal and
> > > >> correct behavior for a arbitrary  (asynchonous) timer.  See
> > > >> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> > > >> for an explanation.
> > > >>
> > > >> NuttX timers have always worked that way and has confused people that
> > > >> use the timers near the limits of their resolution.  A solution is to
> > > >> use a very high resolution timer in tickless mode.
> > > >>
> > > >>
> > > > Oops.  You are seeing a timer that is 1 tick too short.  That is an
> > > > error and should never happen.  Sorry for reading incorrectly. It was
> > > > still early in the morning here.
> > > >
> > > > The timer logic adds +1 tick to the requested to assure that that
> > > > error never occurs.  If +1 were not added, the bad result would be
> > > > exactly as you describe (and as explained in the confluence reference).
> > > >
> > > >
> > > Hi, yes, exactly. Seeing timeout 1 tick too short. Sorry for not
> > > explaining it clearly enough :)
> > >
> > > I fear that there is now some bug. It was rather easy to re-produce,
> > > just a loop with few thousand iterations, and it occurs (infinite loop,
> > > 10 ms tick, less than a minute to catch). Most of the time it works ok;
> > > the sleep time is longer than the requested ticks. But when it triggers,
> > > the sleep is exactly one tick too short (and shorter than the requested
> > > timeout in ticks).
> > >
> > > I was just asking, if others have seen this as well; I'd like to know if
> > > it is really a bug in current nuttx main. It is always possible that
> > > there is something funny in our local build - although I can't see what
> > > it could be.
> > >
> > > -Jukka
> > >
> > >
> > >
> > >
> >

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Jukka Laitinen]

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 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 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 function return
> > >>> -ETIMEDOUT properly on every call.
> > >>>
> > >>> But when measuring the time spent in the wait, I see randomly that
> > >>> sometimes the sleep time was less than one systick.
> > >>>
> > >>> If I set systick to 10ms, I see typical (correct) sleep time between
> > >>> 1 - 2us. But sometimes (very randomly) between 0 - 1us.
> > >>> Also in these error cases the return value is correct (-110,
> > >>> -ETIMEDOUT).
> > >>>
> > >>> When sleeping for 2 ticks, I see randomly sleep times between
> > >>> 1-2us, for 3 ticks 2-3us. So, randomly it is exactly
> > >>> one systick too small.
> > >>>
> > >>> I looked through the implementation of the
> > >>> "nxsem_tickwait_uninterruptible" itself, and didn't saw problem
> > >>> there. (Actually, I think there is a bug if -EINTR occurs; in that
> > >>> case it should always sleep at least one tick more - now it doesn't.
> > >>> But it is not related to this, in my test there was no -EINTR).
> > >>>
> > >>> I believe the problem might be somewhere in sched/wdog/ , but so far
> > >>> couldn't track down what causes it.
> > >>>
> > >>> Has anyone else seen the same issue?
> > >>>
> > >>> Br,
> > >>>
> > >>> Jukka
> > >>
> > >>
> > >> If I understand what you are seeing properly, then it is normal and
> > >> correct behavior for a arbitrary  (asynchonous) timer.  See
> > >> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> > >> for an explanation.
> > >>
> > >> NuttX timers have always worked that way and has confused people that
> > >> use the timers near the limits of their resolution.  A solution is to
> > >> use a very high resolution timer in tickless mode.
> > >>
> > >>
> > > Oops.  You are seeing a timer that is 1 tick too short.  That is an
> > > error and should never happen.  Sorry for reading incorrectly. It was
> > > still early in the morning here.
> > >
> > > The timer logic adds +1 tick to the requested to assure that that
> > > error never occurs.  If +1 were not added, the bad result would be
> > > exactly as you describe (and as explained in the confluence reference).
> > >
> > >
> > Hi, yes, exactly. Seeing timeout 1 tick too short. Sorry for not
> > explaining it clearly enough :)
> >
> > I fear that there is now some bug. It was rather easy to re-produce,
> > just a loop with few thousand iterations, and it occurs (infinite loop,
> > 10 ms tick, less than a minute to catch). Most of the time it works ok;
> > the sleep time is longer than the requested ticks. But when it triggers,
> > the sleep is exactly one tick too short (and shorter than the requested
> > timeout in ticks).
> >
> > I was just asking, if others have seen this as well; I'd like to know if
> > it is really a bug in current nuttx main. It is always possible that
> > there is something funny in our local build - although I can't see what
> > it could be.
> >
> > -Jukka
> >
> >
> >
> >
>

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Petro Karashchenko]

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 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 function return
> >>> -ETIMEDOUT properly on every call.
> >>>
> >>> But when measuring the time spent in the wait, I see randomly that
> >>> sometimes the sleep time was less than one systick.
> >>>
> >>> If I set systick to 10ms, I see typical (correct) sleep time between
> >>> 1 - 2us. But sometimes (very randomly) between 0 - 1us.
> >>> Also in these error cases the return value is correct (-110,
> >>> -ETIMEDOUT).
> >>>
> >>> When sleeping for 2 ticks, I see randomly sleep times between
> >>> 1-2us, for 3 ticks 2-3us. So, randomly it is exactly
> >>> one systick too small.
> >>>
> >>> I looked through the implementation of the
> >>> "nxsem_tickwait_uninterruptible" itself, and didn't saw problem
> >>> there. (Actually, I think there is a bug if -EINTR occurs; in that
> >>> case it should always sleep at least one tick more - now it doesn't.
> >>> But it is not related to this, in my test there was no -EINTR).
> >>>
> >>> I believe the problem might be somewhere in sched/wdog/ , but so far
> >>> couldn't track down what causes it.
> >>>
> >>> Has anyone else seen the same issue?
> >>>
> >>> Br,
> >>>
> >>> Jukka
> >>
> >>
> >> If I understand what you are seeing properly, then it is normal and
> >> correct behavior for a arbitrary  (asynchonous) timer.  See
> >> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> >> for an explanation.
> >>
> >> NuttX timers have always worked that way and has confused people that
> >> use the timers near the limits of their resolution.  A solution is to
> >> use a very high resolution timer in tickless mode.
> >>
> >>
> > Oops.  You are seeing a timer that is 1 tick too short.  That is an
> > error and should never happen.  Sorry for reading incorrectly. It was
> > still early in the morning here.
> >
> > The timer logic adds +1 tick to the requested to assure that that
> > error never occurs.  If +1 were not added, the bad result would be
> > exactly as you describe (and as explained in the confluence reference).
> >
> >
> Hi, yes, exactly. Seeing timeout 1 tick too short. Sorry for not
> explaining it clearly enough :)
>
> I fear that there is now some bug. It was rather easy to re-produce,
> just a loop with few thousand iterations, and it occurs (infinite loop,
> 10 ms tick, less than a minute to catch). Most of the time it works ok;
> the sleep time is longer than the requested ticks. But when it triggers,
> the sleep is exactly one tick too short (and shorter than the requested
> timeout in ticks).
>
> I was just asking, if others have seen this as well; I'd like to know if
> it is really a bug in current nuttx main. It is always possible that
> there is something funny in our local build - although I can't see what
> it could be.
>
> -Jukka
>
>
>
>

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Jukka Laitinen]

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_tickwait_uninterruptible(&sem, 1);

"

, and never posting the sem from anywhere. The function return 
-ETIMEDOUT properly on every call.


But when measuring the time spent in the wait, I see randomly that 
sometimes the sleep time was less than one systick.


If I set systick to 10ms, I see typical (correct) sleep time between 
1 - 2us. But sometimes (very randomly) between 0 - 1us. 
Also in these error cases the return value is correct (-110, 
-ETIMEDOUT).


When sleeping for 2 ticks, I see randomly sleep times between 
1-2us, for 3 ticks 2-3us. So, randomly it is exactly 
one systick too small.


I looked through the implementation of the 
"nxsem_tickwait_uninterruptible" itself, and didn't saw problem 
there. (Actually, I think there is a bug if -EINTR occurs; in that 
case it should always sleep at least one tick more - now it doesn't. 
But it is not related to this, in my test there was no -EINTR).


I believe the problem might be somewhere in sched/wdog/ , but so far 
couldn't track down what causes it.


Has anyone else seen the same issue?

Br,

Jukka



If I understand what you are seeing properly, then it is normal and 
correct behavior for a arbitrary  (asynchonous) timer.  See 
https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays 
for an explanation.


NuttX timers have always worked that way and has confused people that 
use the timers near the limits of their resolution.  A solution is to 
use a very high resolution timer in tickless mode.



Oops.  You are seeing a timer that is 1 tick too short.  That is an 
error and should never happen.  Sorry for reading incorrectly. It was 
still early in the morning here.


The timer logic adds +1 tick to the requested to assure that that 
error never occurs.  If +1 were not added, the bad result would be 
exactly as you describe (and as explained in the confluence reference).



Hi, yes, exactly. Seeing timeout 1 tick too short. Sorry for not 
explaining it clearly enough :)


I fear that there is now some bug. It was rather easy to re-produce, 
just a loop with few thousand iterations, and it occurs (infinite loop, 
10 ms tick, less than a minute to catch). Most of the time it works ok; 
the sleep time is longer than the requested ticks. But when it triggers, 
the sleep is exactly one tick too short (and shorter than the requested 
timeout in ticks).


I was just asking, if others have seen this as well; I'd like to know if 
it is really a bug in current nuttx main. It is always possible that 
there is something funny in our local build - although I can't see what 
it could be.


-Jukka

Re: STM32 SmartCard mode happening right now!

[Michael Jung]

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 the
contact cards.  We do have people in the team that do have this knowledge,
though.

Do you think your approach would allow to get EMV 4.3d certification?
Would it be possible to get early access to your code?  Could I help you in
developing this?

Thanks!
Michael


On Tue, May 9, 2023 at 7:13 PM Sebastien Lorquet 
wrote:

> Hi,
>
> it is time!
>
>
> I am, right now, starting to implement the smart card mode for STM32
> USART, starting with STM32H7, this will be portable to other STM32 chips
> I guess.
>
> The UART mode will just configure the uart for smartcard shenanigans,
> eg, put it in working order for this mode.
>
> Smart card contact protocols (T=0, T=1) will go into a user space app
> that manages readers, similar to pcsclite daemon in linux.
>
>
> So the smart card mode of the stm32 usarts is just an activation of the
> proper registers, that will :
>
> -wire the hardware as expected: enable the clock output, define one
> single full duplex IO line
>
> -reconfigure the uart character framing, including parity generation and
> detection, which is a fundamental mechanism, required for protocol
> compliance testing.
>
>
> The exchanges will still be made with the read() and write() primitives
> (protocol is a kind of IPC), so I am expecting to add just a few IOCTLs:
>
> -ENABLE smart card mode with a bool parameter to enable or disable,
> default disabled
>
> -START or STOP the clock signal (if possible, I did not dive in the RM yet)
>
> -Define the communication speed in terms of ETU (clock pulses per bit,
> which is different from the baud rate and the industry standard way to
> define smart card comm speeds). This need to be modifiable, the speed is
> negotiated dynamically at card insertion.
>
> This will return a ENOTTY error if a particular uart does not support
> Smart Card mode.
>
>
>
> However, to be future proof, another way is possible.
>
> USB CCID smart card readers are also a thing. In pcsclite (linux), these
> are managed via libusb from userspace.
>
> But we can do something special in NuttX, like defining a smart card
> "lower half" that can be implemented by both the stm32 uart in smart
> card mode, or by the future usb ccid driver. I do not plan to *port* the
> full pcsclite, but I will do something that tend to be compatible, while
> being much smaller.
>
> The great question is then how to manage the "upper half" of such drivers.
>
> If it was just me, it would be a character device, that would have
> IOCTLs to enumerate lower halves (eg card readers) so a user space app
> can dispatch commands to multiple readers. But I know NuttX despise
> character devices. So, I am going to need some inspiration here. Sockets
> do not seem appropriate to how things work in the smart card world, I
> can tell that from 13 years of professional experience :)
>
> If NuttX has a libusb-like protocol now or later, then we dont need to
> be concerned by this lower half and char dev, this can all happen in the
> management daemon.
>
> There are also modular card readers that use plain old serial protocols,
> these would also be handled from the user space daemon via specific
> drivers.
>
>
>
> So, this is the correct time to define this in a way that please
> everyone and will be useful for a long time. We need compromises between
> imperative needs of this mode and the NuttX way of doing things.
>
> The goal is to facilitate the upstreaming of this feature.
>
> I know smart cards are unusual and quite niche, you can ask me as many
> questions as needed to understand smart card context, behaviour, and
> habits.
>
>
> Thank you for your reading and comments
>
> Sebastien
>
>

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Gregory Nutt]

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 never posting the sem from anywhere. The function return 
-ETIMEDOUT properly on every call.


But when measuring the time spent in the wait, I see randomly that 
sometimes the sleep time was less than one systick.


If I set systick to 10ms, I see typical (correct) sleep time between 
1 - 2us. But sometimes (very randomly) between 0 - 1us. 
Also in these error cases the return value is correct (-110, 
-ETIMEDOUT).


When sleeping for 2 ticks, I see randomly sleep times between 
1-2us, for 3 ticks 2-3us. So, randomly it is exactly 
one systick too small.


I looked through the implementation of the 
"nxsem_tickwait_uninterruptible" itself, and didn't saw problem 
there. (Actually, I think there is a bug if -EINTR occurs; in that 
case it should always sleep at least one tick more - now it doesn't. 
But it is not related to this, in my test there was no -EINTR).


I believe the problem might be somewhere in sched/wdog/ , but so far 
couldn't track down what causes it.


Has anyone else seen the same issue?

Br,

Jukka



If I understand what you are seeing properly, then it is normal and 
correct behavior for a arbitrary  (asynchonous) timer.  See 
https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays 
for an explanation.


NuttX timers have always worked that way and has confused people that 
use the timers near the limits of their resolution.  A solution is to 
use a very high resolution timer in tickless mode.



Oops.  You are seeing a timer that is 1 tick too short.  That is an 
error and should never happen.  Sorry for reading incorrectly. It was 
still early in the morning here.


The timer logic adds +1 tick to the requested to assure that that error 
never occurs.  If +1 were not added, the bad result would be exactly as 
you describe (and as explained in the confluence reference).

Re: nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Gregory Nutt]

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 function return 
-ETIMEDOUT properly on every call.


But when measuring the time spent in the wait, I see randomly that 
sometimes the sleep time was less than one systick.


If I set systick to 10ms, I see typical (correct) sleep time between 
1 - 2us. But sometimes (very randomly) between 0 - 1us. 
Also in these error cases the return value is correct (-110, -ETIMEDOUT).


When sleeping for 2 ticks, I see randomly sleep times between 
1-2us, for 3 ticks 2-3us. So, randomly it is exactly 
one systick too small.


I looked through the implementation of the 
"nxsem_tickwait_uninterruptible" itself, and didn't saw problem there. 
(Actually, I think there is a bug if -EINTR occurs; in that case it 
should always sleep at least one tick more - now it doesn't. But it is 
not related to this, in my test there was no -EINTR).


I believe the problem might be somewhere in sched/wdog/ , but so far 
couldn't track down what causes it.


Has anyone else seen the same issue?

Br,

Jukka



If I understand what you are seeing properly, then it is normal and 
correct behavior for a arbitrary  (asynchonous) timer.  See 
https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays for 
an explanation.


NuttX timers have always worked that way and has confused people that 
use the timers near the limits of their resolution.  A solution is to 
use a very high resolution timer in tickless mode.

Re: Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Nathan Hartman]

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/lupyuen/inside-a-smartphone-accelerometer-pinephone-with-nuttx-rtos-b92b58
>
> Thanks to Filipe Cavalcanti for inspiring this tutorial! :-)



Kudos!!


BTW Hackster.io has problems for me, it got stuck at "Saving..." and lost
> my edits a few times. Remember to copy and paste your Article Text into
> another Backup Project at Hackster.io! :-)



Let's create a blog section on the nuttx.apache.org site and fill it with
articles like these!

Cheers
Nathan

nxsem_tickwait_uninterruptible randomly timeouts one tick too soon?

[Jukka Laitinen]

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 call.


But when measuring the time spent in the wait, I see randomly that 
sometimes the sleep time was less than one systick.


If I set systick to 10ms, I see typical (correct) sleep time between 
1 - 2us. But sometimes (very randomly) between 0 - 1us. Also 
in these error cases the return value is correct (-110, -ETIMEDOUT).


When sleeping for 2 ticks, I see randomly sleep times between 
1-2us, for 3 ticks 2-3us. So, randomly it is exactly one 
systick too small.


I looked through the implementation of the 
"nxsem_tickwait_uninterruptible" itself, and didn't saw problem there. 
(Actually, I think there is a bug if -EINTR occurs; in that case it 
should always sleep at least one tick more - now it doesn't. But it is 
not related to this, in my test there was no -EINTR).


I believe the problem might be somewhere in sched/wdog/ , but so far 
couldn't track down what causes it.


Has anyone else seen the same issue?

Br,

Jukka

Article: PinePhone Accelerometer with NuttX (InvenSense MPU-6050)

[Lee, Lup Yuen]

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-b92b58

Thanks to Filipe Cavalcanti for inspiring this tutorial! :-)

BTW Hackster.io has problems for me, it got stuck at "Saving..." and lost
my edits a few times. Remember to copy and paste your Article Text into
another Backup Project at Hackster.io! :-)

Lup