Author Topic: How the LED light of a USB card reader works?  (Read 5520 times)

0 Members and 4 Guests are viewing this topic.

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #25 on: August 21, 2024, 06:37:01 am »
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.
« Last Edit: August 21, 2024, 06:49:50 am by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #26 on: August 21, 2024, 07:30:58 am »
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.
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #27 on: August 24, 2024, 11:45:41 am »
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.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #28 on: August 24, 2024, 12:30:08 pm »
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.  :-//
 
The following users thanked this post: tooki

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #29 on: August 24, 2024, 03:44:04 pm »
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.
« Last Edit: August 24, 2024, 04:24:07 pm by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #30 on: August 24, 2024, 04:30:44 pm »
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.)
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #31 on: August 24, 2024, 04:44:58 pm »
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.
« Last Edit: August 24, 2024, 05:01:43 pm by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #32 on: August 24, 2024, 05:26:31 pm »
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.
« Last Edit: August 24, 2024, 05:28:12 pm by Nominal Animal »
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 7236
  • Country: pl
Re: How the LED light of a USB card reader works?
« Reply #33 on: August 24, 2024, 05:50:49 pm »
LOL :horse:
 

Offline magic

  • Super Contributor
  • ***
  • Posts: 7236
  • Country: pl
Re: How the LED light of a USB card reader works?
« Reply #34 on: August 24, 2024, 05:55:28 pm »
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 :scared:
« Last Edit: August 24, 2024, 06:01:04 pm by magic »
 
The following users thanked this post: Someone

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #35 on: August 24, 2024, 06:34:22 pm »
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.
« Last Edit: August 24, 2024, 07:20:09 pm by radiolistener »
 

Offline amyk

  • Super Contributor
  • ***
  • Posts: 8415
Re: How the LED light of a USB card reader works?
« Reply #36 on: August 25, 2024, 08:14:06 pm »
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.
 
The following users thanked this post: radiolistener, magic

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15413
  • Country: fr
Re: How the LED light of a USB card reader works?
« Reply #37 on: August 26, 2024, 01:37:44 am »
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.
 
The following users thanked this post: PlainName

Offline magic

  • Super Contributor
  • ***
  • Posts: 7236
  • Country: pl
Re: How the LED light of a USB card reader works?
« Reply #38 on: August 26, 2024, 05:27:42 am »
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 :scared:
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.
« Last Edit: August 26, 2024, 05:34:19 am by magic »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #39 on: August 26, 2024, 09:19:03 am »
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,
Hard-wired state machine ≠ hardware logic circuit.

Define those terms any way you like, but in the context of this discussion, the former requires an IC with the complexity of a microcontroller or an FPGA, and the latter refers to a circuit a hobbyist could put together from standard jelly-bean logic, inferring from the suggested solution related to that post.

Fact is, the USB state machine is complex.  Just look at the image of the genuine FT232RL after etching at Zeptobars: there are thousands of logic gates in it.  No matter how you put it, it is not reasonable to call it "hardware logic circuit"; it is integrated logic implementing a rather complex state machine.

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.
Perhaps you should re-read this thread, and consider whether your "post" is useful to anyone, or are just continuing a play on words because you don't like the facts I'm offering.

Technically, it should be possible.
Technically, it should be possible to create an USB controller out of bacteria.  However, when you go ask an EE if they're willing to design one for you, they'll laugh you out of the room, or quote a price in the tens of millions.  I wonder why is that?  :o  I guess they don't know their field, right?

We all know the reason is feasibility.  There are no USB to serial converters made out of discrete parts, because it is not feasible: you'd need a crapton of chips, while a single integrated chip in the USD 0.10 - 10.00 range will do the job, depending on the exact type of USB interface you need.

The EEPROM/Flash in FTDI USB to Serial chips is to store the configuration information used by the state machine to enumerate the device, plus to configure the endpoints and pin functionality on some of the converters.  That alone should tell you the complexity of the state machine; it is just not something you create out of discrete logic, a "hard-wired logic circuit", as is implied by the context of reply #31.

If you, magic and amyk, want to interpret terms differently than the context they were used in implies, feel free: but I consider that language wankery, and an utterly stupid pastime.
 
The following users thanked this post: tooki

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #40 on: August 26, 2024, 11:21:51 am »
Note, however, that the EEPROM appears to be about 1.5Kbits rather than 1K. What are they hiding?

It uses EEPROM to store USB device descriptors and configuration bits which can be customized by user.

Fact is, the USB state machine is complex.

AM signal modulation also complex. But it doesn't means that it cannot be done without MCU and firmware...
It was processed in pure analog circuits for many years even before first CPU/MCU was invented.

The same with USB, you can implement it in firmware code for MCU or you can implement it in hardware circuit which don't have CPU/MCU at all and don't have firmware. So, its just incorrect to say that USB logic is always implemented in MCU firmware.

But with this terminology we have deviated from the essence. And the essence is who issues the commands to turn on or off the LED. It can be done on any side - from host software, from MCU firmware or from hardware circuit.

So, the statement that the LED is always controlled by MCU firmware is broken and incorrect at least in two planes: 1) USB device may not have MCU firmware at all; and 2) The LED may be controlled by host software and USB device may even don't know about the LED, for example it may just map some bit in the packet to corresponding GPIO and that's it.
« Last Edit: August 26, 2024, 11:49:11 am by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #41 on: August 26, 2024, 12:51:59 pm »
So, its just incorrect to say that USB logic is always implemented in MCU firmware.
Fortunately, that's not what I said, nor what I meant.  I never even implied that a "MCU" is required for USB.

To me, "firmware" refers to the complex programmable logic and behaviour implemented in an FPGA, ASIC, microcontroller, or other processor, that is fundamental to its operation.  I consider the FTDI FT232H and others ASICs.  (For example, AMD64 aka x86-64 processors themselves have firmware, in the form of updateable microcode, that can change the behaviour of these processors.)

This is because they are designed using programming languages, typically Verilog/VHDL or some variant of C, and not as logic circuits.
That is, humans do not care exactly what logic circuits are implemented; the designers only specify the behaviour, using an abstract programming language.

If you disagree with the term, that's fine; English is a wonky language, and not everybody agrees.  I base my use of "firmware" on the first use case of the definition at wikipedia, the firmware wikipedia article, and the definitions of software and programming language.  To me, an ASIC is the compiled result of a programming language (Verilog or VHDL, typically), and thus clearly "firmware".

And the essence is who issues the commands to turn on or off the LED.
Not in this thread.  "Who issues the commands" is irrelevant, because it cannot be tapped into using simple logic or simple circuits.

What matters is "Who drives the LED and why".  Because that is something we can then use, something we can apply to solve the problem at hand: how to implement an activity LED.

If we all were to follow your definition of the essence, the answer would be along the lines of "we need to listen to that which issues the commands", which is neither useful nor feasible in practice.

If we follow my definition of the essence, we find that we need to either tap into the USB device IC, or we need to add an USB single-port hub between the host and the device, which provides us the activity information.

All through this thread, I've been emphasizing that we need to focus on the limited problem set at hand.  You've constantly tried to expand it into non-USB devices and generalities.  While that in itself is fine, discussing such in this thread will lead OP and others unfamiliar with USB as a bus and interfacing with it, utterly astray.  That is the reason I object to that.

My purpose here is to help those who read this thread with the intent of understanding of how to implement USB activity LEDs, or monitoring USB bus activity; not to quibble about what is theoretically possible (but utterly infeasible in practice), or what happens with other buses.
« Last Edit: August 26, 2024, 12:53:47 pm by Nominal Animal »
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #42 on: August 26, 2024, 01:17:16 pm »
To me, "firmware" refers to the complex programmable logic and behaviour implemented in an FPGA, ASIC, microcontroller, or other processor, that is fundamental to its operation.

No. Programmable logic and behaviour implemented in an FPGA is named gateware.
The firmware term is used for MCU code.

And I don't think that USB IC uses gateware. The gateware may be used at early stage of design for debugging on FPGA, then its converted to specific technology node. But I'm not familiar with die design process, so not sure how this transform is done.

To me, an ASIC is the compiled result of a programming language (Verilog or VHDL, typically), and thus clearly "firmware".

No, there is fundamental difference between firmware and gateware.

Firmware is machine code for MCU which is usual for programmers who is familiar with classic programming.

While gateware is a logic implemented with configurable digital logic gates.

Languages for gateware define digital circuits instead of machine code like it happens in language for firmware. And this is fundamental difference. This is why programmers who know how to program in classic programming language but don't familiar with verilog, usually unable to understand how verilog code works, just because they are used how the classic code linked with machine code (firmware) and have no idea what is digital circuit (gateware).

Metastability issues which is usual for gateware, but just doesn't exists in firmware is example of such fundamental difference.
« Last Edit: August 26, 2024, 01:52:12 pm by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #43 on: August 26, 2024, 02:39:59 pm »
No. Programmable logic and behaviour implemented in an FPGA is named gateware.
That's the first time I've heard the term.

There are exactly 27 posts here at EEVBlog forums that mention the term; and 44% of those are your posts (or the match is in text quoted from your post).  A couple are just in snippets of code or logs, as part of a filename path.

So, forgive me if I don't use the terms you do, those being rather rarely used here, and me not familiar with FPGA development anyway.  (I actually don't like jargon much anyway, even in software development or computational materials physics, my "strongest" fields).  I see even wiktionary has a definition, so I guess it is widely used in some circles.  If I had known the term, then I would have used "firmware or gateware", and not "firmware".  Maybe I was careless, sorry.  :'(

Like I said, I'm not interested in playing with or arguing about the word definitions.  I've explained the context and meaning I've used them.  It is your problem if you choose to ignore that and apply your own internal definitions instead, and then wonder why others argue with you.  Useful and worthwhile communication is an interaction, not a power game or force feeding operation.  Language is complex and muddy; it is much more useful to try and concentrate on the ideas and concepts being conveyed, than on words being used ignoring the context.  (It's still better than concentrating on who says instead of what is being said, though; that being way too common in Western countries today.)

As an example, talk about volume with a DJ, in a hair salon, with a visual artist, or with a scientist.  They all define the term in completely different, usually incompatible ways.  I do not mind.  I prefer to use it in the context, and define the term (even temporarily, for the duration of a single discussion) whenever necessary.  I've even discussed the difference between the visual art definition and physical definition with both scientists and artists, simultaneously, because conveying the message and the idea is more important to me than quibbling about the exact definition of a term.
« Last Edit: August 26, 2024, 02:41:50 pm by Nominal Animal »
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #44 on: August 26, 2024, 03:08:15 pm »
There are exactly 27 posts here at EEVBlog forums that mention the term; and 44% of those are your posts (or the match is in text quoted from your post).  A couple are just in snippets of code or logs, as part of a filename path.

This is not my term. I'm sure almost anyone who familiar with FPGA development know it very well.
But it appears that FPGA development is not popular subject on this forum, so it's not surprise that there is not so much information about it here.

This is not surprising, because gateware development is not as popular as software development and there is much less information on this topic, as well as specialists.

if you don't believe me, just look for example on CERN site:
https://indico.cern.ch/event/1337180/contributions/5629282/attachments/2882918/5051661/ISOTDAQ2024_Advanced_FPGA_Design.pdf
Quote
Key concepts about FPGA design
FPGA gateware design is NOT programming

See page 13 for difference between software/firmware (programming) and gateware design. You are not the first to be surprised by this difference, almost any programmer who has encountered FPGA discovers that there is another world...

When you are familiar with classic software/firmware programming it is very difficult to understand the essence of gateware design. That's why there are few programmers who is able to understand Verilog/VHDL.
 
« Last Edit: August 26, 2024, 03:22:42 pm by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #45 on: August 26, 2024, 04:03:15 pm »
[Gateware] is not my term. I'm sure almost anyone who familiar with FPGA development know it very well.
Sure –– I did show that it is already defined at e.g. Wiktionary, so it is definitely a known term ––, but outside FPGA developers, it is not a well-known term.  Be assured, I do know it now, and won't confuse you or others familiar with FPGA development by mixing the terms.

if you don't believe me, just look for example on CERN site:
https://indico.cern.ch/event/1337180/contributions/5629282/attachments/2882918/5051661/ISOTDAQ2024_Advanced_FPGA_Design.pdf
Quote
Key concepts about FPGA design
FPGA gateware design is NOT programming
That is a rather simplistic/problematic/exaggerated view of programming by Manoel Barros Marin of International School of Trigger and Data Acquisition.  (BTW, I've worked for a couple of CERN research partner organizations for a bit, having had a CERN user account and email address for a few years, if that sort of stuff matters to you.)
That definition of "programming" does not match reality, you see.

It would be more accurate and useful to distinguish between imperative programming and say declarative programming.  Mind you, even the Wikipedia article on computer programming makes a similar error (without any references), by talking about "step by step instructions".  Such instructions are specific to imperative programming.

An example of purely declarative programming is the OpenSCAD declarative programming language for describing 3D constructive solid geometry, often used to describe parametrized objects like gears and such for 3D printing.  In particular, it is not executed step by step, but all at once.  (To implement animation, the same program is evaluated for each frame, but with different values of built-in variables related to "time".)

A third, very useful category of programming is functional programming, which evolved from lambda calculus.  It is neither imperative or declarative, exactly; but it is closer to declarative, as it essentially describes the mapping of inputs to outputs using functions (using the mathematics definition of a function).  With functional programming, even the actual order of operations a computer will perform is utterly unknown to the programmer.  It is definitely nothing "step by step".

You are not the first to be surprised by this difference, almost any programmer who has encountered FPGA discovers that there is another world...
There are many worlds beyond imperative programming, which is often the only world most programmers know.

I am well aware of the approaches behind Verilog and VHDL, and I can somewhat read Verilog already (although I don't think I've written a line of Verilog yet).   (For example, I fully understand the difference between <= and = assignment operators.  In Verilog, their effects are quite different from each other.)

I just do not consider it different from other forms of "programming"; only different from "imperative programming".  To me, it is a fourth class, similar to functional programming in that it is not imperative, is not exactly declarative but close ("declarative style", like functional programming); but instead of mapping inputs to outputs using functions, Verilog and VHDL use a more verbose human-readable (non-mathematician readable) form, and terms from electronics (like wire for example).

Considering it completely separate is just tribalist self-aggrandizement; like those who use jargon to bolster their self-image, instead of explaining the terms they use so everybody understands the message.  It is concentrating on the appearances and separation, instead of focusing on the useful bits.

Separating Verilog and VHDL from imperative programming is very useful and informative, but there are other forms of programming like functional and declarative programming that are similarly different from imperative programming too, and yet are still considered as part of "programming" nonetheless.
« Last Edit: August 26, 2024, 04:05:49 pm by Nominal Animal »
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #46 on: August 26, 2024, 04:41:01 pm »
It would be more accurate and useful to distinguish between imperative programming and say declarative programming.

No. I know many declarative programming languages (like Prolog, Lisp, SQL, XSLT, etc.) and many imperative programming languages (like C#, C/C++, JS, ASM, etc). And understand the difference between them. But I'm talking about different thing.

There is a fundamental difference between a programming language for computers (CPU/MCU) and a hardware description language (HDL). The first one is used to write code that is compiled or interpreted into machine code, which is executed by a CPU or MCU. The second one is used to describe digital circuits, including logic gates and their connections. It is incorrect to categorize both as the same type of language just because they both use the word 'language'. Programming languages and hardware description languages serve different purposes and define fundamentally different concepts.

To be clear, it's like compare programming language with chemical formula language. These are fundamentally different concepts.

I am well aware of the approaches behind Verilog and VHDL, and I can somewhat read Verilog already (although I don't think I've written a line of Verilog yet).   (For example, I fully understand the difference between <= and = assignment operators.  In Verilog, their effects are quite different from each other.)

Perhaps you only think that you can read verilog code. Even if you understand what means logic operation and what is the difference between <= and =, it still not enough to well understand how verilog code works... Its more easy to understand if you familiar with designing digital circuit schematics, because this is exactly what verilog describes...

For comparison any programming language (imperative or declarative, procedural, object oriented, functional, lambda, closures, etc) describes machine code. And here is fundamental difference with HDL, because it describes digital circuit, but NOT machine code...
« Last Edit: August 26, 2024, 05:16:11 pm by radiolistener »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6950
  • Country: fi
    • My home page and email address
Re: How the LED light of a USB card reader works?
« Reply #47 on: August 26, 2024, 05:20:12 pm »
There is a fundamental difference between a programming language for computers (CPU/MCU) and a hardware description language (HDL). The first one is used to write code that is compiled or interpreted into machine code, which is executed by a CPU or MCU. The second one is used to describe digital circuits, including logic gates and their connections. It is incorrect to categorize both as the same type of language just because they both use the word 'language'. Programming languages and hardware description languages serve different purposes and define fundamentally different concepts.
So, what do you call OpenSCAD or functional programming, then?  Not programming?

At its very core, how much does it actually matter if the programming language leads to machine code executed by a processor, to a description used to configure an FPGA, or to a description of manufacturing an ASIC?

Outside the epoxy-encapsulated circuitry, the observable inputs and outputs behave the exact same way, regardless of the physical implementation (MCU, FPGA, ASIC).

You claim it is incorrect to categorize such programming under the same term, because the physical implementation differs.  I disagree, because the physical implementation is just not relevant to most use cases.  We already agreed that "step by step" is incorrect by definition, because it would exclude functional programming.

We do not actually care whether a USB-to-serial converter is an ASIC, an FPGA, or an MCU; we care that it performs according to the programmed rules. For USB controllers in particular, that is a rather complex state machine.  (Complex as in having many parts.  Those parts are individually straightforward, so it is not problematic, just a lot of serious but not-too-difficult work to implement.)

I wonder how you'd describe Nadav Rotem's graduate research project, which transpiled C to Verilog for synthesis using LLVM.  (See Rotem-CToVerilog.pdf.)  Rememver, Verilog and VHDL are just one approach to logic synthesis.  There is absolutely nothing that says that HDLs are the best or the only way to do logic synthesis.  There is no technological reason why you could not synthesize C source code (that limits itself to binary inputs and outputs instead of streams) into logic for an FPGA or ASIC.  The only reason it is not done in practice, is that it requires a compiler/transpiler that is more work to create than its worth.  (Even Nadav Rotem omitted recursion and some imperative control flow constructs.)

Thus, because of the above, and especially because transpilers exist between Verilog/VHDL and other programming languages, I claim your (and Manuel Barros Marin's) definition of "programming" and "programming language" as excluding logic synthesis is in fundamental error.

If we cannot even agree to definitions of terms for the sake of discussion, how can we interact in a mutually beneficial manner?  I suspect it is neither possible, nor useful to try any further, sorry.
« Last Edit: August 26, 2024, 05:22:25 pm by Nominal Animal »
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 4055
  • Country: ua
Re: How the LED light of a USB card reader works?
« Reply #48 on: August 26, 2024, 05:39:16 pm »
I wonder how you'd describe Nadav Rotem's graduate research project, which transpiled C to Verilog for synthesis using LLVM.  (See Rotem-CToVerilog.pdf.) 

I would say this is a kind of software to generate emulators for C code in verilog. Because there is no equivalence between machine code and digital circuit. But you can emulate C code with circuit and vice versa - emulate digital circuit with C code...

That tool may be helpful if you don't know verilog and want to generate verilog code which will emulate some C code. But this code will not be effective, it's like running Linux inside virtual machine on Windows... It will works, but not the same effective as Linux running on hardware. :)
« Last Edit: August 26, 2024, 05:43:55 pm by radiolistener »
 

Offline xvr

  • Frequent Contributor
  • **
  • Posts: 429
  • Country: ie
    • LinkedIn
Re: How the LED light of a USB card reader works?
« Reply #49 on: August 27, 2024, 11:23:37 pm »
"Hardware Description Language" and "General purpose programming language" are not question of languages themself, but type of its usage. When you writes computer program you describe it in terms of algorithms and sequential execution of them. HDL 'program' describes hardware structure. There is no sequence execution - all performed absolutely in parallel manner.

But languages themself could be arbitrary. You can write general purpose program in Verilog or VHDL. Moreover, you will write it when you run your schematic in simulator. You use sequential program to describe test suite. Both Verilog and VHDL has a big part of language that can't be used for RTL description, and it sole purpose in writing sequential tests as in general purpose language. Moreover, when you run such test all your RTL code will be run as general purpose program - it will not be converted into RTL.

Another example of HDL - SystemC. This is a HDL language used to create hardware, but internally this is just library and set of macros for generic C++. And any SystemC RTL definition is a valid C++ program. You can synthesize RTL from it or compile and run as C++ program.

And the last one - HLS synthesizer in Vivado suite (Xilinx/AMD development system for its FPGA) takes C (or even C++) function and synthesize RTL from it. So arbitrary C/C++ syntheses is not just an academical research, but production grade technology for now.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf