Replies: 3 comments 3 replies
-
It should be kind of ok? IIRC not strictly according to the rules though... FYI for the Wiznet drivers I have added a setting for MAC address, so one can get a "legal" one from a scrapped device and use that. Perhaps add it to the F7/H7 drivers and populate it with a default value from your algorithm making it overridable? |
Beta Was this translation helpful? Give feedback.
-
I think setting the LAA bit is the key point, as then only has to be locally unique (like auto-generated VM MAC addresses etc). But yes, agree it's a fudge for not having a legitimate hardware address.
That sounds ideal, will do that.. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Is there a reason the MAC address is printed in reverse here? |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @terjeio, updating the H7 code in line with yours. One thing, I don't see https://github.com/grblHAL/core/blob/d4c9d21ab2fe056bfaecef9471d77cb23a319590/plugins.h#L95 |
Beta Was this translation helpful? Give feedback.
-
Not yet, to be defined in a .pio file or build configuration if needed? |
Beta Was this translation helpful? Give feedback.
-
The current ST code always sets the same MAC address, which causes issues when multiple boards are present.
I've just committed a branch to the H7 driver, that I think takes a better approach (I borrowed the idea from the Zephyr codebase).
First three bytes are the ST OUI prefix, but with the LAA bit set.
Last three bytes from a CRC32 hash of the 96 bit chip UID.
I think this is a reasonable approach to generating persistently unique IDs, what do you think? If you are in favour, I could create a PR for the F7 repo also..
Beta Was this translation helpful? Give feedback.
All reactions