DHCP_CLIENT_OBJECT_NAME is used as a macro so you would have to change the source code in some way in the function
wiced_result_t dhcp_client_init( NX_DHCP* dhcp_handle, NX_PACKET_POOL* packet_pool, NX_IP* ip_handle )
in wiced_network.c to get it to use another value. If it's the dynamic load part you want you could set up a variable and load it from the DCT like you said.
You would also have to change the macro
#define DHCP_CLIENT_INITIALISED(ip) ((ip).nx_dhcp_name == DHCP_CLIENT_OBJECT_NAME)
in wiced_network.c to the variable that has the client name you want to use.
Thank you for your prompt response. Having an open-source SDK is great as it boost the development cycle.
The downside of that is (naturally), that any change to the SDK source code would make it a nightmare-ish when upgrading between SDKs.
Since the DHCP client feature would exist in ( almost ) any IoT device, I would think that we would like to have the device identity reflected there. ( and not the platform using which the device was created )
Could I ask you to consider "exposing" the dhcp client name externally as a future feature ?
( my preference would be a dynamically rather than compile time. The user would be able to set a "device name", and this device name would also be the dhcp client name. )
In the meanwhile, I will modify the SDK locally as you suggested to support dynamic DHCP name.
my proposed solution is:
// in the .h file:
extern char *g_dhcp_client_name;
// in the .c file
static char g_default_dhcp_client_name = "WICED DHCP CLIENT"
char *g_dhcp_client_name = g_default_dhcp_client_name;
The user would be able to update the g_dhcp_client_name pointer during runtime and affect the newly dhcp client name. The default string would still "waste" some space, but that's not *too* much anyway.
1 of 1 people found this helpful
Your solution looks good! Yes it makes sense that some users would want to change the DHCP client name. I'll make a note to our engineers to consider for future development Good luck in your product development!