Now I'm not interested on data packets. I'm just trying to address one slave, so the only thing that I'm doing is to send JUST ONE BYTE on the serial port.
This byte is the address byte. If the slave is addressed, he has to do something(to turn on a led?), otherwise he will resume.
I tried to do this, but he worked only in the 40% of the sent bytes.

So I wrote that code to save in the eeprom what char the pic was receiving. And I saw that the char was right only 40% of times.

For example:
-1st try
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0000 0001 (this is right)

-2nd try
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0110 0111 (????????? whi????)

-3rd try:
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0000 0001 (this is right)

-4th
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0100 1001 (????????? whi????)

-5th
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0011 0101 (????????? whi????)

-6th
PC: %1 0000 0001
PIC: interrupt, read RCREG, received char:%0111 0111 (????????? whi????)


....
and so on...
The idea of sending the data byte with only 8 bits is ok, but, for the moment I'm just testing the address detection..
But if I send 1 byte, and when I read it this is not the byte I sent, even if the ninth bit has generated the interrupt, the slave will not work because it thinks it's not addressed!!

The problem is that I'm expecting a byte in the RCREG and what I find is another one (random?). I don't know if this depends on the registers or what, but testing with an oscilloscope on the USART rx pin, the byte is right, and is just ONE! It's so strange he gives me a completely different value!

Is possible that when the pic saves the registers going in interrupt, he changes the value of the RCREG?