Re: STM32 SmartCard mode happening right now!

[Michael Jung]

Hi Sebastien,

Thanks for your reply!

You wrote:
> For the moment I am focused on uart smartcard support only.

Once you have something that I could start to port to the STM32U5, please
let me know.

Bye,
Michael

Sebastien Lorquet  schrieb am Mo., 22. Mai 2023,
10:07:

> Hi,
>
> First of all I need reliable communication with a particular brand of
> card I cant disclose, and I dont think any certification is on the scope :)
>
> But EMV certification is probably possible with a bit more dedication.
> Usually the complexities are around timeouts, error behaviour, and a lot
> of idiosyncrasies.
>
> You could help by porting to your platform, and testing the code that
> will be common to all platforms.
>
> I believe implementing the pcsclite de-facto standard would benefit a
> wider community, since it would allow interoperability with linux
> programs that use smartcards?
>
> For the moment I am focused on uart smartcard support only.
>
> Thanks for your interest,
>
> Sebastien
>
>
> Le 17/05/2023 à 16:17, Michael Jung a écrit :
> > 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 

RE: Touchscreen scaling/LVGL

[TimH]

There is nuttx/drivers/input of course - only just remembered; I'll see if 
anything "generic" fits there for this.

>-Original Message-
>From: TimH 
>Sent: Wednesday, May 24, 2023 12:04 PM
>To: dev@nuttx.apache.org
>Subject: RE: Touchscreen scaling/LVGL
>
>I'm thinking:
>
>1) that the LVGL Gregory linked to is a contender for the graphical
>interface, only for LVGL of course, to do the calibration
>2) The existing calibration routines in nuttx-apps (e.g. ccalibration for
>NXWM as suggested by Alan C. Assis) is a great alternative for non-LVGL
>implementations
>3) Developers can write their own front end if preferred.
>
>All produce the necessary offsets and scale factors etc.
>
>In my case, the screen is only used by pudgy, often gloved, fingers so
>absolute accuracy is not required; any variations between displays are
>not an issue as there are large touch button areas that are difficult to
>miss!
>
>That just leaves the question of where/how to calculate compensated x/y
>co-ordinates that take the offsets into account.
>
>I see there is CONFIG_TSCALIBRATION used by platform_setconfig, currently
>only used by mikroe boards that I can see, along with some structs (i.e.
>sCalibrationData) but there is no "generic" TSD driver in nuttx/drivers.
>
>Perhaps that is something that one day might be a useful enhancement, as
>it could then standardise the struct(s) etc. and provide "methods" along
>the lines of efuse, power/supply, and so on.
>
>Ultimately, the offsets/scaling do need to be applied somewhere though,
>and to me, IOCTL to the ADC driver feels right. In the case of the SAMA5
>a read via the character driver is what actually initiates a TSD sample,
>so the overhead of calculating offsets seems acceptable, but other
>processors/implementations could do this on a timer etc so it's not a
>definitive approach.
>
>I will implement IOCTLs, using the sCalibrationData struct as the
>argument and see how I get on.
>
>>From: Gregory Nutt 
>>Sent: Tuesday, May 23, 2023 7:51 PM
>>
>>
>>On 5/23/2023 12:11 PM, Tim Hardisty wrote:
>>> Hi,
>>>
>>>
>>> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y
>>coordinates scaled 0-4095.
>>>
>>> LVGL wants them scaled to the actual size of the display (800x480 in
>>> my
>>case).
>>>
>>> 2) Enhance the chip's TSD driver after all, using a Kconfig setting
>>> to
>>enable X/Y scaling to the display's size (set in board-specific files
>>already).
>>>
>>
>>Many touchscreens require calibration by the application via a
>>calibration screen.  Hence, only the application knows the scale
>>factors to use and so scaling is done by the application.
>>
>>Scaling could also be done by the driver using calibration information
>>provided via an IOCTL.  All resistive touchscreens require calibration.
>>If your touchscreen does not require calibration, then I suppose it
>>could even be provided by a configuration setting.
>>
>>Raw, unscaled input is also needed by the application, however (in
>>order to do calibration, for one).
>>
>>Scaling in the driver could also be inefficient since the driver does
>>not know if the sample will be used or not.  It might be better to to
>>scale in the application even if calibration is not necessary.
>>
>>A quick Google provides some references for touchscreen calibration
>>with
>>LVGL:
>>
>>  * https://forum.lvgl.io/t/calibrate-a-touchscreen-with-tpcal-h/244
>>  * https://github.com/jakpaul/lvgl_touch_calibration
>>
>>The are other calibration displays under nutts-apps/ (not for LVGL)
>

RE: Touchscreen scaling/LVGL

[TimH]

I'm thinking:

1) that the LVGL Gregory linked to is a contender for the graphical interface, 
only for LVGL of course, to do the calibration
2) The existing calibration routines in nuttx-apps (e.g. ccalibration for NXWM 
as suggested by Alan C. Assis) is a great alternative for non-LVGL 
implementations
3) Developers can write their own front end if preferred.

All produce the necessary offsets and scale factors etc.

In my case, the screen is only used by pudgy, often gloved, fingers so absolute 
accuracy is not required; any variations between displays are not an issue as 
there are large touch button areas that are difficult to miss!

That just leaves the question of where/how to calculate compensated x/y 
co-ordinates that take the offsets into account. 

I see there is CONFIG_TSCALIBRATION used by platform_setconfig, currently only 
used by mikroe boards that I can see, along with some structs (i.e. 
sCalibrationData) but there is no "generic" TSD driver in nuttx/drivers.

Perhaps that is something that one day might be a useful enhancement, as it 
could then standardise the struct(s) etc. and provide "methods" along the lines 
of efuse, power/supply, and so on.

Ultimately, the offsets/scaling do need to be applied somewhere though, and to 
me, IOCTL to the ADC driver feels right. In the case of the SAMA5 a read via 
the character driver is what actually initiates a TSD sample, so the overhead 
of calculating offsets seems acceptable, but other processors/implementations 
could do this on a timer etc so it's not a definitive approach.

I will implement IOCTLs, using the sCalibrationData struct as the argument and 
see how I get on.

>From: Gregory Nutt 
>Sent: Tuesday, May 23, 2023 7:51 PM
>
>
>On 5/23/2023 12:11 PM, Tim Hardisty wrote:
>> Hi,
>>
>>
>> A touchscreen peripheral (SAMA5D2 as it happens) delivers X and Y
>coordinates scaled 0-4095.
>>
>> LVGL wants them scaled to the actual size of the display (800x480 in my
>case).
>>
>> 2) Enhance the chip's TSD driver after all, using a Kconfig setting to
>enable X/Y scaling to the display's size (set in board-specific files
>already).
>>
>
>Many touchscreens require calibration by the application via a
>calibration screen.  Hence, only the application knows the scale factors
>to use and so scaling is done by the application.
>
>Scaling could also be done by the driver using calibration information
>provided via an IOCTL.  All resistive touchscreens require calibration.
>If your touchscreen does not require calibration, then I suppose it could
>even be provided by a configuration setting.
>
>Raw, unscaled input is also needed by the application, however (in order
>to do calibration, for one).
>
>Scaling in the driver could also be inefficient since the driver does not
>know if the sample will be used or not.  It might be better to to scale
>in the application even if calibration is not necessary.
>
>A quick Google provides some references for touchscreen calibration with
>LVGL:
>
>  * https://forum.lvgl.io/t/calibrate-a-touchscreen-with-tpcal-h/244
>  * https://github.com/jakpaul/lvgl_touch_calibration
>
>The are other calibration displays under nutts-apps/ (not for LVGL)
 

Fwd: [Announcement] An admin posted important news for Sony

[Tomek CEDRO]

:-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

-- Forwarded message -
From: Hackster.io 
Date: Wed, May 24, 2023, 07:41
Subject: [Announcement] An admin posted important news for Sony
To: 





Jinger Zeng

admin
Announcements

Hi Sony community, NuttX just launched their community hub on Hackster, if
your tech stack consists of NuttX, you can now tag it on your project BOM.

Simply add https://www.hackster.io/nuttx/products

to your "things", and your project will show up under NuttX's platform hub.

Cheers!
View post


Cheers,
The Hackster.io team
--





Trending now: Ultra-lightweight Solar-Powered Messenger Bag


Don't want to receive this type of email?.