How the LED light of a USB card reader works?

[radiolistener]

Even in that case, the driver communicates with the device firmware to change the LED.

This is obvious, because LED is connected to MCU. But the main sense here is which code controls the LED state. When LED state is controlled by driver code from PC side, MCU firmware don't control the LED, it just get state from the driver and put it to GPIO.

For Ethernet (over USB), see Communications Device Class (CDC, PDF v1.2) Ethernet Control Model (ECM) protocol (currently in ECM120.pdf in the previous ZIP archive).  If I recall correctly, it does not have any activity LED controls at all (so those would have to be driver-specific extensions), and the LEDs are fully controlled by the device firmware.

As I remember, for ethernet PHY you can control LED function with configuration and control registers which is available through MDIO bus. It can be configured to disable LED at all, blink automatically or can be controlled directly with register bit states depends on selected mode.

[Nominal Animal]

Even in that case, the driver communicates with the device firmware to change the LED.

This is obvious, because LED is connected to MCU. But the main sense here is which code controls the LED state. When LED state is controlled by driver code from PC side, MCU firmware don't control the LED, it just get state from the driver and put it to GPIO.

No, really.  The "But the main sense here is which code controls the LED state" is wrong approach in the context of this thread.

It is a significant distinction, if we consider the entire model here.  (So, please, let's not start discussing what "control" might actually mean to different people.)

You see, to allow a host device to control the LED, the firmware must offer a way for the host to control the LED state.  The host cannot "take" control over the LED without explicit co-operation from the firmware.  The firmware cannot just hand over the LED state to the host, and instead must implement the interface the host can use to set the LED state.  For every LED state change the host wants, the firmware must actually perform the change.  See?

If we then limit to USB, we can clearly check the standards to see that there are no such interfaces for ordinary USB device activity LEDs; definitely not for USB Mass Storage (which includes both memory sticks and media converters).  There are for keyboard LEDs, but even those are mostly handled by the keyboard itself, with host only in very specific circumstances, like boot, telling the keyboard to set them to a specific state.

For Ethernet (over USB), see Communications Device Class (CDC, PDF v1.2) Ethernet Control Model (ECM) protocol (currently in ECM120.pdf in the previous ZIP archive).  If I recall correctly, it does not have any activity LED controls at all (so those would have to be driver-specific extensions), and the LEDs are fully controlled by the device firmware.

As I remember, for ethernet PHY you can control LED function with configuration and control registers which is available through MDIO bus.

Not for USB devices, which is what this thread is about.  Please do not expand the topic to all ethernet devices or non-USB IC's.  (I, too, probably should not have even mentioned PS/2 either, and kept to USB only.  Apologies.)

The OP is already on a bad track, so it is best to avoid adding to their confusion.  In particular, I'm worried they might now be searching for USB MDIO, arriving at TI USB-2-MDIO, and wondering how they might apply that to solve their problem.  They cannot; it is irrelevant to USB, as USB-2-MDIO is just an application one can use with certain microcontrollers to program TI Ethernet PHYs that will be connected to some microcontroller, without having to implement that programming on the microcontroller the PHY will be used with.

I don't mean you're wrong per se, mind you.  The Teensy 4.1 development boards I have, do have a TI DP83825i 10/100 Ethernet PHY, which does implement the standard LED controls you mentioned (see 7.6.25 on page 62 on the TI DP83825i datasheet).  But all that is via the MDIO bus, connecting the PHY to a microcontroller, and has nothing to do with USB.  Strictly speaking, though, even here the PHY firmware is in control of the LED state, and only exposes an interface –– the 16-bit LEDCR register at offset 0x18 that a host can read and write, via the MDIO bus –– to change the LED behaviour and state.

I understand your idea of focusing on which code decides on the policy of how and when a LED is lit, but it is not appropriate in the context of this thread.  Here, the discussion is about detecting activity and showing activity (or idleness) using a LED.  In practice, this always happens at the firmware level on the device.  Some devices do expose an interface for the host to control the LED state, but it is limited to specific devices, and very uncommon over USB.  Trying to detect activity by examining the USB 2.0 D+ and D- voltages is a crude hack that has a lot of gotchas, including low-speed and full-speed (1 Mbit/s and 12 Mbit/s) having different voltage levels to high-speed (480 Mbit/s).  My entire point in this thread has been to use the information the device firmware gives you, instead of trying to do it at some other level of complexity; and it is also the reason for my pushback here, to try and push OP to the right track.  Definitely no offense or snarkiness or anything like that meant; and in another context, I'd be happy to discuss various systems programming aspects of LED activity controls as implemented in many Linux-based appliances like routers and NASes –– one of my hobbies is to add nontechnical-end-user friendly displays and indicators to such.

[radiolistener]

Here, the discussion is about detecting activity and showing activity (or idleness) using a LED.  In practice, this always happens at the firmware level on the device.

Raspberry Pi 4 has sdcard controller and green activity LED.
The LED is not linked to sdcard controller, it is controlled by software driver on CPU and shows sdcard activity in that way.
So, I would not say that it always happens at the firmware level of device controller.

[Nominal Animal]

Here, the discussion is about detecting activity and showing activity (or idleness) using a LED.  In practice, this always happens at the firmware level on the device.

Raspberry Pi 4 has sdcard controller and green activity LED.
The LED is not linked to sdcard controller, it is controlled by software driver on CPU and shows sdcard activity in that way.
So, I would not say that it always happens at the firmware level of device controller.

1. That controller has no firmware of its own, unless you consider the kernel driver that.  This is common for SDIO devices, including separate chips implementing SD/SDIO/MMC host controllers.
2. The SD/SDIO controller on Pi 4 is an integrated peripheral on the Broadcom BCM2711 SoC, and not an USB device.  It is essentially the same as similar peripherals common on many microcontrollers.

I'm not saying there are no devices that are connected via various buses whose activity LED is controlled by a host; there are, just not USB devices.  I am talking about USB devices, because those are the only ones relevant to this discussion.  With USB devices, the activity LED is always controlled by the device firmware.  That firmware might expose some interface, for example via USB control messages (to endpoint 0), for the host to tell the firmware what state the LED should have, but it is always the USB device firmware that is in control of it: for the LED state to change, the firmware has to perform an action.

I don't understand why you insist on confusing the topic by bringing up unrelated devices, as if they somehow magically refute the above. 

[radiolistener]

I'm not saying there are no devices that are connected via various buses whose activity LED is controlled by a host; there are, just not USB devices.  I am talking about USB devices, because those are the only ones relevant to this discussion.  With USB devices, the activity LED is always controlled by the device firmware.

I remember some USB devices, which LED are controlled by software on PC. They use USB-serial controller inside and as I remember the LED is connected to RTS line which is not used for communication, just to control LED state from PC software side.

I don't understand why you insist on confusing the topic by bringing up unrelated devices, as if they somehow magically refute the above. 

I also don't understand why do you insist that all USB devices have the LED controlled by the controller program and not the host program?

Sometimes there is no controller and no firmware at all on USB device, it can be implemented as hardware design for FPGA and don't know how to control the LED, it just loads the word received from the host into GPIO register and that's it. And actual control is performed by software on the host.

For example: USB PHY => FPGA => LED on GPIO

Where is firmware and controller here? And who controls the LED state on FPGA GPIO?

To be clear: I don't deny that the LED can be controlled by a controller itself, I just saying that this is not the single way how LED can be controlled.

[Nominal Animal]

I'm not saying there are no devices that are connected via various buses whose activity LED is controlled by a host; there are, just not USB devices.  I am talking about USB devices, because those are the only ones relevant to this discussion.  With USB devices, the activity LED is always controlled by the device firmware.

I remember some USB devices, which LED are controlled by software on PC. They use USB-serial controller inside and as I remember the LED is connected to RTS line which is not used for communication, just to control LED state from PC software side.

Again, that is still controlled by the USB device firmware.  The RTS line is not controlled by the host, but by the USB serial device firmware, which allows the host to set that pin state via an USB CDC control message; specifically SetControlLineState (SET_CONTROL_LINE_STATE) message, whose 16-bit value contains the DTR state in the least significant bit, and RTS state in the next bit.

The driver does not control the LED state directly.  It is the standard USB CDC firmware on the device that responds to the standard SetControlLineState requests by the driver, to set the output signals DTR and RTS to the states the host desires.

This is not quibbling.  Yes, you can argue that it is the driver that decides what state the LED (or RTS pin state) should have, and that is true.  That is just not relevant here.  For every state change, it is the USB device firmware that responds to the SetControlLineState request from the host driver, to actually change the state.  If the firmware was buggy, there is nothing the host could do to force the LED or RTS pin state to change.

There are many microcontrollers with native USB interfaces that can implement that exact same USB CDC interface, including old AVRs like ATmega32u4 and AT90USB1286.  Their firmware can implement an activity LED that flickers whenever there is data flowing, but otherwise follows the RTS state, for compatibility with the device you mention.  This is at the root of why I claim such activity indicators are controlled by the USB device firmware, and never by the host: the host cannot "grab" control of the LED state or anything else, it can only send control commands/requests that the device firmware acts upon.

To draw a direct line from this to the question posed in the thread title: the activity LED is controlled by the firmware on the USB card reader device. Neither USB card readers nor USB mass storage devices have a standard interface for the host to control an activity LED.  While the host computer (filesystem driver, specifically) certainly knows when it is communicating with an USB device, we have no standardized interfaces to connect that information to an activity indicator, not even in Linux.  So, to add such an indicator to an existing device or a device being designed, the sensible point is at the device firmware or USB interface chip; and lacking that, adding an USB hub with the activity indicator to show when data is flowing between the device and the host through the hub.

Imagining ways of having some kind of an activity LED on an USB device that is not controlled by the USB device but by the host is just wrong.  They all boil down to control messages from host to device, so cannot solve the problem at hand.  At best, discussing such muddles the topic.  At worst, it is trolling, just to confuse anyone reading this thread and wanting to find out how such indicator LEDs are implemented in practice.  (For USB devices, if you want the host to be able to control a LED, you have to provide an USB control message interface for it.  Using USB CDC or HID, there are suitable ones that could be useful, depending on exactly what you need.  It is even possible for a single USB device to provide more than one logical device, for example a keyboard device, a mouse device, a touchpad device, and an USB serial (CDC ACM) device.  For USB gamepads using native USB HID interface, I like using the USB serial for controlling what keys each gamepad button produces, so that at runtime, I can reconfigure the gamepad for whatever games I want to play.)

[radiolistener]

Again, that is still controlled by the USB device firmware.  The RTS line is not controlled by the host, but by the USB serial device firmware, which allows the host to set that pin state via an USB CDC control message; specifically SetControlLineState (SET_CONTROL_LINE_STATE) message, whose 16-bit value contains the DTR state in the least significant bit, and RTS state in the next bit.

I suspect there is no firmware in USB-serial converter, it can be implemented as hardware logic circuit.

For example, you can send packet to USB end point and the first bit of each packet will be loaded to GPIO register on FPGA. There is no firmware and no controller, just dumb digital logic circuit with state machine. It just get data from USB packet and put it to GPIO. USB PHY don't know about the LED and FPGA don't know about the LED. Only software on PC side know that specific GPIO of FPGA is connected to the LED and can change its state. So where is firmware controlled LED in this case?

The driver does not control the LED state directly.

The driver can control LED state directly through USB interface. Why not? I done it many times.

If you control the LED with button, it don't means that the LED is controlled by wire. Just because wire is dumb and can't control LED state without external command from the button, it just transfers the command. The same USB bus just transfers the command from software driver on the host. USB is just a channel to transfer some data.

[Nominal Animal]

I suspect there is no firmware in USB-serial converter, it can be implemented as hardware logic circuit.

No, it cannot.  The simple reason is the complexity of device enumeration, a required step before any data can be transferred between USB standards compliant devices and host.

No, USB devices cannot be passive like the example you described, because they have to respond to queries from the host before the host can send any data.  USB essentially requires a rather complex state machine to work; much more so if you support USB 2.0 High Speed or USB 3 or later SuperSpeed modes.

I think you really, really need to go look at the USB standards to understand exactly how USB communications work, before you start claiming idiotic things that if you knew the basics of the standard you'd immediately know would not work in practice at all.

This has become too ridiculous of a "discussion" to participate any further; it is as if you simply refuse to listen, and spout garbage because you don't want to admit you know nothing of USB.

[magic]

LOL

[magic]

I suspect there is no firmware in USB-serial converter, it can be implemented as hardware logic circuit.

No, it cannot.  The simple reason is the complexity of device enumeration, a required step before any data can be transferred between USB standards compliant devices and host.

Technically, it should be possible. There is nothing magical about finite state machines or sending canned responses to a dozen predefined descriptor requests. I doubt anyone is doing it this way when an off the shelf MCU core with ROM is just as good and very cheap.

edit
Project idea: build a working USB device out of 74 logic

[radiolistener]

No, USB devices cannot be passive like the example you described, because they have to respond to queries from the host before the host can send any data.  USB essentially requires a rather complex state machine to work; much more so if you support USB 2.0 High Speed or USB 3 or later SuperSpeed modes.

I'm using FPGA device which processes all USB and Ethernet requests and sends responses with state machine in verilog. It processing requests and keep continuous realtime stream transfer to PC (and it allows to request second realtime stream through another USB endpoint). There is no firmware and no controller. All is done in state machine on verilog, it's not very simple, but at the same time not so hard.

For Ethernet it even doing much more, because it implements full UDP stack, include ARP, DHCP and even ICMP protocol handling. All this is done in state machine. No firmware, no controller. And relatively simple.

So, I surprised why you think that this is impossible? 

On the contrary I would say that it will be hard to implement with MCU, because it needs to handle data at very high speed. Simple MCU is unable to send realtime continuous 1 Gbps stream and at the same time handle all requests and send responses.

I doubt anyone is doing it this way when an off the shelf MCU core with ROM is just as good and very cheap.

yes, it is more simple to do slow protocols handlilng on MCU, for example ARP, DHCP, ICMP is ideal for MCU implementation. But if you need to send high speed stream, it requires very fast MCU with communication interfaces which allows to transfer data from FPGA to MCU and back. It add delays, bottlenecks and eats FPGA resources. So, it's more easy to implement it on FPGA with state machine. Yes it will be equals to a large circuit on 74 logic, but since FPGA has enough elements you can use it and there is nothing complicated.

You can fit full state machine for UDP stack with ARP, DHCP, ICMP handnling into 2-4 kLE and even less with optimizations. So you can use chip with just 5-10 kLE for this. For example 10CL025 with 25 kLE can fit into a small USB stick, I have devboard with it and it's size is the same as STM32 bluepill...

I don't think that using 4 of 25 kLE is a stopper to implement all this in state machine... This is just 16% of chip resources.

There is better way than connecting FPGA to MCU, you can implement your own MCU core in verilog with instruction set optimized for your tasks. But from my point of view, it makes project more complicated and eats more resources than implementing it as state machine.

[amyk]

I suspect there is no firmware in USB-serial converter, it can be implemented as hardware logic circuit.

No, it cannot.  The simple reason is the complexity of device enumeration, a required step before any data can be transferred between USB standards compliant devices and host.

Never heard of the infamous FTDI USB-serial converters? The real ones are indeed hard-wired state machines, and many fakes and compatibles use a mask-programmed MCU instead:

https://zeptobars.com/en/read/FTDI-FT232RL-real-vs-fake-supereal%20this%20deep-down

I think you really, really need to go look at the USB standards to understand exactly how USB communications work, before you start claiming idiotic things that if you knew the basics of the standard you'd immediately know would not work in practice at all.

Maybe you should listen to your own advice.

[SiliconWizard]

This last part of the discussion becomes ridiculous as it's clearly just about playing with words. From his replies, which are usually detailed enough not to leave much to interpretation, Nominal was merely pointing out that implementing USB was involved enough that it would require more than just simple logic, which some seem to believe.

Now obviously everything can be implemented with FSMs, and FSMs do not need a complete CPU to be implemented. Or general-purpose CPU, I would say. Define what you mean by CPU otherwise, if you remove the "general-purpose" qualifier.

Possibly the slightly unfortunate word in Nominal's post(s) was to mention the need for "firmware", which, again, define what "firmware" is - circles back to the above. But probably still a bit unfortunate as it would elicit in most people's mind the idea that it runs on a full-blown CPU.

And yes, many USB device interface chips implement what's needed of the USB protocol purely in "hardware" (so from some RTL) and not with a CPU core in the chip. And yes that's just a bunch of FSMs.

Not surprised if some vendors of such chips would OTOH implement it using a CPU core of some kind, although I personally don't have evidence for that nor a particular vendor in mind. But if they do this, and place the firmware in some small embedded Flash area (or more likely, OTP, cheaper), that would allow fixing bugs/adding features without having to respin new silicon, which also has its benefits.

[magic]

Never heard of the infamous FTDI USB-serial converters? The real ones are indeed hard-wired state machines, and many fakes and compatibles use a mask-programmed MCU instead:

https://zeptobars.com/en/read/FTDI-FT232RL-real-vs-fake-supereal%20this%20deep-down

Hmm, looks like you are right.

Note, however, that the EEPROM appears to be about 1.5Kbits rather than 1K. What are they hiding?
(Maybe it isn't enough space for firmware implementing USB state machines on any reasonably general-purpose core.)

Project idea: build a working USB device out of 74 logic

I thought about feasibility of that for a few minutes and concluded that USB would be a little annoying. Just at the lowest layers, the whole bit stuffing and two different CRCs would consume a bunch of chips to merely send/receive the raw bitstream on the wire.