What does the running transcript hash in RFC-8446: TLS 1.3 do? From RFC8446:
In general, implementations can implement the transcript by keeping a
running transcript hash value based on the negotiated hash.  Note,
however, that subsequent post-handshake authentications do not
include each other, just the messages through the end of the main
handshake.
Could someone explain what it means by by keeping a
running transcript hash value ?
I want to implement TLS1.3 on a microcontroller where RAM is limited. For example if I have to calculate HMAC of a message 1000 bytes long, is it possible to calculate first a HMAC of first half of the message, delete the fist half of the message and calculate the final HMAC from the first HMAC and the remaining half of the message ?
What's keeping a running transcript hash value ?

It means keeping the internal state of the hash in-between processing pieces of the message hashed. Virtually all hashes are designed to make this easy, for the benefit of devices with limited RAM. They can hash large messages piece by piece, with a three-function interface Start/Hash/Finalize allowing to repeat the Hash step as needed, passing a piece of the message at each call.
Such implementations of SHA-256 keep a state that comprises:

the hash so far (32 bytes)
the input buffer (64 bytes) holding 0 to 511 bits of input data not hashed yet
the length so far (8 bytes), which also encodes how much data was hashed (multiple of 512 bit) plus how much data is in the input buffer.


is it possible to calculate first a HMAC of first half of the message, delete the fist half of the message and calculate the final HMAC from the first HMAC and the remaining half of the message ?

Essentially yes, except that what's calculated first is not &quot;a HMAC of first half of the message&quot;. Computing $\operatorname{HMAC}(K,(M_0\mathbin\|M_1),\ell)$ with $\operatorname{SHA-256}$ when $M_0$ and $M_1$ are available sequentially can go:

Check $0\le\ell\le64$ (the output length, here assumed in bytes)
if $K$ is more than 64 bytes, then $B\gets\operatorname{SHA-256}(K)$, else $B\gets K$
expand $B$ to 64 bytes by appending zeroes
$B\gets B\oplus\mathsf{3636\ldots3636_h}$ (the ipad constant, over 64 bytes)
Perform the first hash

Start
Hash $B$
Hash $M_0$
Hash $M_1$
Finalize the hash, yielding $H_1$


$B\gets B\oplus\mathsf{6A6A\ldots6A6A_h}$ (the XOR of the ipad and opad constants, over 64 bytes)
Perform the second hash

Start
Hash $B$
Hash $H_1$
Finalize the hash, yielding $H_2$


Truncate $H_2$ to length $\ell$ as needed to obtain the final result.

Between steps 3 and 4 of the first hash, it is needed a state of only about 168 bytes of data, including 104 bytes for the the hash state, and 64 bytes for $B$.
For SHA-512, we need to change the 64 to 128, and the RAM needed doubles.