Alright, here is the thing.
I needed a little bit more than setting the text and the rgb color of the lcd device, - so as per usual - I checked everybody's source codes. (hehh, almost literally).
There are two main ways to deal with wiring/i2c:
Lowlevel - The low level way where each ping is paired to a boolean (or a boolean returning function). So they do the protocol kinda bit by bit. Here is a good and related example:
//monitor the busy flag of LCD on its DB7
unsigned char busy=1;
//unsigned char cnt=0;
PORTC=0xff; //Set all data pins to 1 initially
DDRC=0x00; //configure all bits as inputs
EN=0; //Start LCD command
RS=0; //It's a command
RW=1; //It's a read command
busy=BF; //read the busy flag
} while(busy==1);// && cnt<255);
EN=0; //Finish the command
RW=0; //Turn off RW for future commands
Highlevel - Using a library like the fivdi's i2c-bus. In these cases the usual atomic unit is a byte, and the physical wiring is paired with bits of the particular byte.
let chc = line[i].charCodeAt(0);
i2cBus.writeByteSync(TEXT_I2C_ADDR, 0x40, chc);
Both approaches have their role, it's not about that.
I use the highlevel approach since I'm developing in nodejs for node-RED and other than these conditions the lib I'm referring to is a very nice one, covers all the I2C householding for me. (setting the write bit, receiving nacks, acks, etc.) Also it's fully async and sync, so I have that flexibility as well. Well, having mentioned the advantages of the lib: it has writeQuick and readQuick which are commands to send a single bit. (never had to use that)
I read the HD44780 datasheet and every second page they warn us to check the busy bit. Being a good geek I thought I'll implement that thing, and it also gives back address values other than the busy bit.
Also understood, that we are - other than the initialization - talking about microseconds, and with software level delays they are going to work fine keeping the code device agnostic. In fact you don't even have to deal with the busy flag at all. I went for this solution obviously.
What do I want to achieve? Well, it's more like I'm kinda frustrated not being able to work out the solution from the datasheet. It's more like learning how to translate a datasheet to code. Having a 0x80 and 0x40 in the code works, but you know... wouldn't it be nicer with constants?
mehh, it was long.