digitalRead(2) : When does it Read Pin Signal?

Would appreciate the meaning of digitalRead(2) function. I mean: when does the function read Pin signal (PIND2), and when does it read PD2 signal?

Given below a diagram that describes my conceptual simplified understanding of the internal structure of Bit-2 of Port-D Register of ATmega328P Microcontroller.

|500x285

I have no idea what your diagram is supposed to represent, and your question in general is sort of unclear.

There is only one thing for digitalRead() to look at - it reads the PINx register (in this case PIND), and then masks off all but the appropriate bit.

digitalRead() itself is kinda slow - it has to look up which port, and which pin within the port, that the specified digital pin number refers to. This takes almost 100 clock cycles all told, far longer than it takes for the input to be reflected in the PINx registers.

The value on PINx will reflect the voltages on the pin within 1-1.5 clock cycles - see section 14.2.4 and figures 14-3 and 14-4 in the datasheet.

Would appreciate the meaning of digitalRead(2) function. I mean: when does the function read Pin signal (PIND2), and when does it read PD2 signal?

It will never read the PD2 signal, it always show the PIND2 value. The call is slow because the decoding is not made completely by the compiler but parts are done at run time by using some flash content.

It will never read the PD2 signal, it always show the PIND2 value.

Sometimes they are the same.
In the diagram, the “buffer” you have labeled G2DB that “disconnects” PINx from the actual pin when DDRx is low? That doesn’t actually exist! PINx is always connected to the actual pin, regardless of the state of DDRx.
Here’s the schematic from the actual 328 datasheet, with a bit of highlighting added.
The green path is PINx. It’s always available to the databus (through the synchronizer) (except for in SLEEP mode?)
The purple path is PORTx. Whether or not it is connected to PINx depends on the state of DDRx (which is the yellow path.)
If you read PORTx, you get whatever you last wrote to PORTx. If you read from PINx, you get what’s actually on the pin. If the pin is an output, those should be the same. (There is no Arduino function that ever reads PORTx.)

Screen Shot 2017-11-30 at 6.57.39 PM.jpg

In the diagram, the "buffer" you have labeled G2DB that "disconnects" PINx from the actual pin when DDRx is low? That doesn't actually exist! PINx is always connected to the actual pin, regardless of the state of DDRx.

My understanding appeared from the traditional meaning of pinMode(2, INPUT) function. When pinMode(2, OUTPUT) makes the line output, the pinMode(2, INPUT) must make the line input. In this case, there should be an isolation, and that's why I added the 3-state device - G2DB. Moreover, a pin cannot simultaneously work as input and output. Thanks for re-posting the actual pin structure diagram from the data sheets, which has removed my misconception.

Now, the meaning of pinMode(2, INPUT) appears as: It does not do anything with line direction; it essentially disconnects the output buffer (G2DA) from the input line when DPin-2 is intended to be used as input line. The function also opens the way of enabling the internal pull-up via the PUD-bit. (pinMode(2, INPUT_PULLUP)).

(There is no Arduino function that ever reads PORTx.)

Assume that DPin-2 is configured to work as output, and it is directly connected (experimental setup) to the base of a transistorized load of the following circuit. I wish to toggle the states of LED2. The execution of the instruction digitalWrite(2, !digitalRead(2)) will never toggle the states of LED2 as digitalRead(2) reads the PIND2 and not the PD2. Reading PIND2 will always provide LL (assume Q1 was made ON last time), which after inversion becomes LH; it goes to transistor base; the transistor remains ON; LED2 does not change its states. Am I correct?

|500x300

To toggle the states of the load, I must execute the following instructions (they work!).

void setup() 
{
  pinMode(2, OUTPUT);
}

void loop() 
{
  bool n = bitRead(PORTD, 2);  //it reads PD2
  n = !n;
  bitWrite(PORTD, 2, n);
  delay(1000);
}

Am I correct?

Your LED driver is wrong. It needs a current-limiting resistor in the base circuit. WITH that resistor, the PIND2 level will remain "high" even when the LED is on - that's part of the definition of maximum output current, and part of the difference between "20mA output current" and "40mA absolute max" - the first is how much current can be sourced WHILE MAINTAINING a valid "1" output state. Reading PORTx is safer, of course. It's a "famous problem" on some of the early Microchip PIC microcontrollers: https://download.mikroe.com/documents/compilers/mikroc/pic/help/rmw.htm

The green path is PINx. It's always available to the databus (through the synchronizer) (except for in SLEEP mode?)

You are correct. From Section 18.2.5 Digital Input Enable and Sleep Modes

As shown in the figure of General Digital I/O, the digital input signal can be clamped to ground at the input of the Schmitt Trigger. The signal denoted SLEEP in the figure, is set by the MCU Sleep Controller in Power-down mode and Standby mode to avoid high power consumption if some input signals are left floating, or have an analog signal level close to VCC/2

When sleeping, any GPIO that is not used an an interrupt input has its input buffer disconnected from the pin and in clamped LOW by the MOSFET.

Now, the meaning of pinMode(2, INPUT) appears as: It does not do anything with line direction; it essentially disconnects the output buffer (G2DA) from the input line when DPin-2 is intended to be used as input line. The function also opens the way of enabling the internal pull-up via the PUD-bit. (pinMode(2, INPUT_PULLUP)).

This appears to be the correct understanding. The input buffer is always active (while the controller is not sleeping), the DDR bits just connect/disconnect the output buffer. Reading the PIND register will always reflect the state based on the actual voltage applied to the pin. If the pin is set to OUTPUT and HIGH, but you short it to GND and overload it, reading PIND will report a LOW value.