Do I need to handle endianess over an 8 bits bit-fields struct on a 32 bit architecture?

I am doing some embedded software on a 32 bits architecture (precisely AVR32).
On this software I am retrieving a flag, coded on one byte, from an external peripheral connected via I2C.

Each bits of this byte are a boolean variable.
The struct is the following:

typedef union __attribute__((packed)){
  struct __attribute__((packed)) {
    uint8_t flag_a : 1;
    uint8_t flag_b : 1;
    uint8_t flag_c : 1;
    uint8_t flag_d : 1;
    uint8_t flag_e : 1;
    uint8_t __unused : 3;
  }
  uint8_t raw;
}Flag_t;

My question is, if I want to make this code portable, do I need to redefine the struct inside the union in the reverse order for the other endianness ?

Or, is the endianness issues not present in this situation ?

Endianness is only an issue for multi-byte variables, so it is not an issue in your case.

However, the use of bit-fields is potentially an issue for portability. The C Standard leaves it up to the compiler implementation to decide how they are implemented. Thus they cannot be expected to behave identically across different environments.

A better option is simply to use a single byte and define the meaning of the different bits. E.g.:

   typedef uint8_t Flag_t;
   typedef enum
   {
      flag_a = 1u << 0,
      flag_b = 1u << 1,
      flag_c = 1u << 2,
      flag d = 1u << 3,
      flag e = 1u << 4,
   } Flag_Bits_t;

> if I want to make this code portable

Then do not use bit-fields. Use bit operations.

> in the reverse order for the other endianness ?

Yes, but this is compiler specific, i.e. not portable. On gcc you can use https://stackoverflow.com/questions/47600584/bitfield-endianness-in-gcc .

> is the endianness issues not present in this situation ?

Yes, but not only - compiler may insert any padding between structure members, uint8_t may not be supported for a bitfield, and it is "endianness" of bits within a byte that compiler chooses to make.