Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed MAC reverse byte order issue within the ESP32SPI library as it … #66

Open
wants to merge 5 commits into
base: master
from

Conversation

@mytechnotalent
Copy link

mytechnotalent commented Aug 21, 2019

…was originally echoing the MAC address in reverse byte order. Added portable MAC function call within WSGISERVER.PY example to properly echo MAC address when running example.

…was originally echoing the MAC address in reverse byte order. Added portable MAC function call within WSGISERVER.PY example to properly echo MAC address when running example.
@mytechnotalent

This comment has been minimized.

Copy link
Author

mytechnotalent commented Aug 21, 2019

@ladyada ganbatte done it :)

@ladyada

This comment has been minimized.

Copy link
Member

ladyada commented Aug 21, 2019

@brentru wanna try this and use an external tool to verify the MAC of the esp32

@anecdata

This comment has been minimized.

Copy link
Contributor

anecdata commented Aug 22, 2019

Minor point, but can we mark this as a breaking change in the release notes? Some people (like me) may have code that uses the old order.

@ladyada

This comment has been minimized.

Copy link
Member

ladyada commented Aug 22, 2019

why would it be a breaking change? usually you display the MAC, but code doesnt stop working because of the new order

@anecdata

This comment has been minimized.

Copy link
Contributor

anecdata commented Aug 22, 2019

I suppose it's not breaking within CP (and perhaps dumb on my part), but for example, I use an ID based on old order to ID the ESP unit to my server.

@ladyada

This comment has been minimized.

Copy link
Member

ladyada commented Aug 22, 2019

whatever y'all want to do. they're just numbers

@mytechnotalent

This comment has been minimized.

Copy link
Author

mytechnotalent commented Aug 22, 2019

I don't want to break anyone's code. What I will do is add a new function to the adafruit_esp32spi.py library called MAC_address_actual to which you as the community can have a review on.

…ibrary calling the actual MAC address and providing a usage of the function in the webserver code within WSGISERVER.
…ibrary calling the actual MAC address and providing a usage of the function in the webserver code within WSGISERVER. This time with line breaks at end to not break Travis.
@mscosti

This comment has been minimized.

Copy link
Contributor

mscosti commented Aug 23, 2019

For what its worth, it appears that the nina-fw is purposely sending the order this way, and the arduino WiFiNina library doesn't do anything to adjust it. In the example usage you can see they're reversing the output of the call when printing it, but the byte array the .macAddress() function returns is left untouched.

I'm not sure why this is the way it is. Does it make sense to simply document this behavior, and perhaps implement a helper method that reverses it for use when printing?

@ladyada

This comment has been minimized.

Copy link
Member

ladyada commented Aug 25, 2019

i think reversing it in the example is also fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.