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
