search

xcore / sc_ethernet

10/100 MII Ethernet MAC for XMOS microcontrollers
http://xcore.github.com/sc_ethernet/index.html
Other
37 stars 29 forks source link

Is there a reason for so many MAC formats? #20

Closed interactive-matter closed 12 years ago

interactive-matter commented 12 years ago

While browsing through the source and the demo source I have encountere three different formats for MAC addresses in the source code: 6 characters 6 int 2 int

Is it useful? It always puzzles me which format to use and how to reformat the mac address. Or am I missing something completely.

DavidNorman commented 12 years ago

The 2 int version is the internal storage which is done so that we can be sure of the alignment of the address. The 6 char is the external representation which sort of is how you would think of a mac address as a general user, i think.

i'm not sure what the 6 int is about - maybe an error

ajwlucas commented 12 years ago

There's probably a few reasons for the disparities between formats. One format might be suitable for reading from OTP, another might be more suitable for sending down a channel end (it's more efficient to send 2 ints than 6 chars or ints). Another might need to be endian reversed in a char buffer for sending over the network.

I agree it can be confusing and we should probably try to provide some sort of wrapper that uses a common format that maps to the function-specific format.

interactive-matter commented 12 years ago

Yes,

I am with ajwlucas theory. It seems the same to me. for passing the MAC in function references often 6 ints are used. It is often packed into 2 ints. In reality it is 6 chars.

I suggest for future version to simlpy stick to the 2 (unsigned) int and streamline all function calls to this.

It is short, easy to store and simple. Perhaps in a format that it can be easily transformed into a 6 (theoretically 8) byte array.

Just a feature request to make the source more easily accessible

interactive-matter commented 12 years ago

Suggestion: Is it possible to convert all external references to the MAC address to 8 unsigned chars? This format is most commonly used and is easily mappable to 2 integers. In theory only 6 bytes need to be stored, but that would bring some alignemnt problems (At least as far as I understand it - if I am wrong I am happy to be corrected). All functions give and take those 8 unsigned chars. If the send it over a channel or store it internally the functions can internally map it to two integers. This would massivley reduce the complexity of mac handling.

And while we are at it I managed to confuse how the server handles the mac address. It expects a two integer array, build by mapping the 6 chars into it. And it even provides a function to retrieve the mac via it's communication channel. I think those aspects could be better documented since I assumed that I have to read the mac adress from the OTP several times or copy it into different arrays - even though it can be easily obtined from the ethernet server, which seems to be the proper way.

DavidNorman commented 12 years ago

You are correct. The way to get at the MAC address post initialization is to use the tx_server channel and the get function. It only needs to be retreived from the OTP once at initialization time.

I think that having an 8 byte MAC address would be confusing, since it is really only 6 bytes long, and it wouldn't be immediately clear what the endianness or alignment is.

interactive-matter commented 12 years ago

Yes, but having several different formats depending on the function is not helping either ;) perhaps some struct with padding could help, like

typedef struct { unsigned char mac_address[6]; unsigned char padding[2]; } s_mac_address

or something similar. I think one of the biggest issues of the ethernet stack is taht it's API is really hard to understand. Hence I think it should be simplified. (To help, I am trying to extract a more or less generic handler from the demo code which can be the starting point of a very simple API)