Comments (6)
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
from sc_ethernet.
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.
from sc_ethernet.
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
from sc_ethernet.
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.
from sc_ethernet.
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.
from sc_ethernet.
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)
from sc_ethernet.
Related Issues (18)
- README.rst summary table HOT 1
- getmac.h/xc oddities HOT 14
- Is it possible that XC-3 with two channels does not work? HOT 8
- Cannot call xtcp_connect twice in a row without waiting for new connection event
- app_ethernet_demo may contain usefull code HOT 1
- Only "app_ethernet_tests" builds of the app HOT 2
- The pakage format is puzzling HOT 2
- app_demo_code does not like my ping HOT 8
- What does NUM_MII_RX_BUF/NUM_MII_TX_BUF do & why is it important? HOT 3
- Use of MAC_PROMISCUOUS HOT 1
- UDP connections from Windows XP HOT 4
- Multiple ethernet slice cards on a slice core board? HOT 1
- no XC-3 support HOT 8
- Xmos Daisy Chain topology HOT 3
- Function call parameter mismatch in two port MAC
- mii.xc build issue HOT 1
- smi_config in module_ethernet/src/server/smi.h is superfluous? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sc_ethernet.