问题的来龙去脉:
以前使用nonos v1.30版本的SDK,烧写工具上提示的AP MAC和STA MAC,与程序中获取到的MAC地址是一致的。
后来更换SDK的版本 nonos v1.5.4.发现烧写工具上提示的AP MAC和STA MAC,还是原来的地址,而程序中获取到的mac地址已经改变,后三位没变,前三位,与烧写工具上显示的不一样了。
整个过程中,只改了SDK的版本。烧写工具,开发编译环境没有改变。
mac地址要求
mac地址要有唯一性。担心人为wifi_set_macaddr函数后,mac地址不能唯一。模块使用数量多的时候,不易维护。
问题
1.为什么不同版本的SDK,使用函数wifi_get_macaddr获取的mac地址不同? 效果见附件图片。两模块在测试。
2.
A>由于数量较多,使用函数wifi_set_macaddr去设置每个模块的mac地址,太困难。
B>试问,烧写工具上显示的MAC地址,是怎么个编写形式呢?或者说这个地址是不是出厂默认的MAC地址?模块厂家是怎么给每个模块编默认的mac地址的?是否能保证唯一呢?是不是有默认mac地址的编写工具,可否release?
ESP8266模块的MAC地址,是怎么编写的?
Re: ESP8266模块的MAC地址,是怎么编写的?
Postby YimingLi » Tue Sep 20, 2016 12:28 pm
Hi,
It seems that the issue of different mac prefixes of whether 18-FE-34 or 5C-CF-7F is related to the chipset batches other than the SDK version. The latest batch of ESP8266 chip has provided a new feature to store (burn) the oui info as the MAC prefix in an on-chip register. However the previous old batches store a 0x00000000 in the register.
Experiments tell that, with those old batch of chips(with an ID=0x00F5xxxx e.g.), which I purchased from Espressif years agao, a call to wifi_get_macaddr(STATION_IF, mac_addr) return a prefix of 18-FE-34 in the mac_addr, while with other latest batches of chips(with an ID=0x00CCxxxx e.g.), the call to wifi_get_macaddr(STATION_IF, mac_addr) returns a prefix of 5C-CF-7F for the mac address as examples.
Experiments were performed with SDK version 1.3.0, 1.4.0, and 1.5.0 as well and the same results as above achieved. That is, SDK version make no difference here.
Further more, using the toolkit downloaded from below url:
downloaded from outside China: https://github.com/Anylinkin/ESP8266/tr ... /S8266WIFI
or downloaded from inside China: http://pan.baidu.com/s/1pJy3bUN
has been used to dump out and compare the registers values read out from the two categories of chips, to find that, the new batches of chips use the register value @0x3FF0005C to store the oui prefix other than 0x00000000 as before e.g.
@0x3FF00050 = 0x0DBB0000
@0x3FF00054 = 0x0200CC67
@0x3FF00058 = 0x6400B000
@0x3FF0005C = 0x005CCF7F -> New version of chipset contains the OUI=5C-CF-7F here
@0x3FF00050 = 0xA3BD0000
@0x3FF00054 = 0x0200F56F
@0x3FF00058 = 0x0000A000
@0x3FF0005C = 0x00000000 -> Old version of chipset has 0x00000000 her and using default oui=18-FE-34
This feature has been supported by the lib function wifi_get_macaddr(STATION_IF, mac_addr) since old SDK version 1.3.0 throughto 2.0.0 as I tested. That is, you don't have to change your firmware which calls the wifi_get_macaddr() to get the MAC. However, for those firmwares or applications(such as burning tools) who formulate the mac address from chip by adding a fixed prefix of 18-FE-34 might have to update the firmwares(using wifi_get_macaddr() to get the mac other than from chipid even they are closely related ) or applications(regisiter value at 3FF0005C should be read out as a prefix added to the mac_address).
hope it would be helpful.
Yiming
It seems that the issue of different mac prefixes of whether 18-FE-34 or 5C-CF-7F is related to the chipset batches other than the SDK version. The latest batch of ESP8266 chip has provided a new feature to store (burn) the oui info as the MAC prefix in an on-chip register. However the previous old batches store a 0x00000000 in the register.
Experiments tell that, with those old batch of chips(with an ID=0x00F5xxxx e.g.), which I purchased from Espressif years agao, a call to wifi_get_macaddr(STATION_IF, mac_addr) return a prefix of 18-FE-34 in the mac_addr, while with other latest batches of chips(with an ID=0x00CCxxxx e.g.), the call to wifi_get_macaddr(STATION_IF, mac_addr) returns a prefix of 5C-CF-7F for the mac address as examples.
Experiments were performed with SDK version 1.3.0, 1.4.0, and 1.5.0 as well and the same results as above achieved. That is, SDK version make no difference here.
Further more, using the toolkit downloaded from below url:
downloaded from outside China: https://github.com/Anylinkin/ESP8266/tr ... /S8266WIFI
or downloaded from inside China: http://pan.baidu.com/s/1pJy3bUN
has been used to dump out and compare the registers values read out from the two categories of chips, to find that, the new batches of chips use the register value @0x3FF0005C to store the oui prefix other than 0x00000000 as before e.g.
@0x3FF00050 = 0x0DBB0000
@0x3FF00054 = 0x0200CC67
@0x3FF00058 = 0x6400B000
@0x3FF0005C = 0x005CCF7F -> New version of chipset contains the OUI=5C-CF-7F here
@0x3FF00050 = 0xA3BD0000
@0x3FF00054 = 0x0200F56F
@0x3FF00058 = 0x0000A000
@0x3FF0005C = 0x00000000 -> Old version of chipset has 0x00000000 her and using default oui=18-FE-34
This feature has been supported by the lib function wifi_get_macaddr(STATION_IF, mac_addr) since old SDK version 1.3.0 throughto 2.0.0 as I tested. That is, you don't have to change your firmware which calls the wifi_get_macaddr() to get the MAC. However, for those firmwares or applications(such as burning tools) who formulate the mac address from chip by adding a fixed prefix of 18-FE-34 might have to update the firmwares(using wifi_get_macaddr() to get the mac other than from chipid even they are closely related ) or applications(regisiter value at 3FF0005C should be read out as a prefix added to the mac_address).
hope it would be helpful.
Yiming
Who is online
Users browsing this forum: No registered users and 55 guests
Login
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
Latest SDK
Documentation
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!
- All times are UTC+08:00
- Top
- Delete all board cookies
About Us
Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.