MSP430F5438A supports communication scheme verification based on COAP protocol
[Copy link]
The overall goal of the demo is to support the verification of communication solutions based on the COAP protocol;
After multiple comparisons and consideration of existing resources, the following solutions were finally selected. All of them have open source code, and they should be able to be debugged on the board after simple adaptation.
Hardware solution: MSP430F5438A + operating system: ucos + IoT kit: Alibaba IoT-SDK_V2.0 + IDE: IAR
Since Alibaba IoT-SDK_V2.0 is programmed based on the Linux system (other platforms are not yet supported) and the compiler is GCC, many problems were encountered during the porting process:
1. Configure the header file directory: Makefile is not used in the IAR environment, so the header file directory needs to be configured separately in IAR. The specific configuration method is as follows:
a) Right-click the project name, select Options...
b) Find C/C++ compiler -> Preprocessor; in Additional include directories: (one per line), $PROJ_DIR$ is the root directory of the project, and you can configure the relevant content directories based on the root directory; you
can compile each file separately first, and after solving the compilation problem, make to link the symbol table;
2. Keyword conflict: IAR's compiler is not as rich as GCC. Here are some problems I encountered in the compilation process:
a) typeof: Although I have done embedded development in C for several years, this is the first time I have come across the typeof keyword. Since Alibaba's Iot SDK uses the Linux list library to support linked list operations
/**
* list_for_each_entry_safe - iterate over list of given type safe against removal of list entry
* @pos: the type * to use as a loop cursor.
* @n: another type * to use as temporary storage
* @head: the head for your list.
* @member: the name of the list_struct within the struct.
*/
#define list_for_each_entry_safe(pos, n , head, member) \
for (pos = list_entry((head)->next, typeof(*pos), member), \
n = list_entry(pos->member.next, typeof(*pos), member); \
&pos->member != (head); \
pos = n, n = list_entry(n->member.next, typeof(*n), member))
_once ("cur" is used before its value is set D:\SVN\
02 智能解决方案\软件工程\ucos-msp430\ucos-msp430\ali-IoT\src\packages\iot-coap-c\CoAPExport.c 219 Warning[Pe549]:
variable "cur" is used before its value is set D:\SVN\02 智能解决方案\软件工程\ucos-msp430\ucos-msp430\ali-IoT\src\packages\iot-coap-c\CoAPExport.c 219
Error[Pe029]: expected an expression D:\SVN\02 Intelligent Solutions\Software Engineering\ucos-msp430\ucos-msp430\ali-IoT\src\packages\iot-coap-c\CoAPExport.c 219
Error[Pe059]: function call is not allowed in a constant expression D:\SVN\02 Intelligent Solutions\Software Engineering\ucos-msp430\ucos-msp430\ali-IoT\src\packages\iot-coap-c\CoAPExport.c 219
After reading the list library carefully, I found that the list library contains two types of implementation schemes:
the first one. The above-mentioned implementation scheme similar to the iterate template has a more flexible structure setting and can support various types of structures. Therefore, the typeof keyword is indispensable;
the second one is more traditional, which is an implementation scheme based on the linked list structure. It directly operates the linked list, so there is no need to use the typeof keyword, which is implemented as follows:
/**
* list_for_each_safe - iterate over a list safe against removal of list entry
* @pos: the &struct list_head to use as a loop cursor.
* @n: another &struct list_head to use as temporary storage
* @head: the head for your list.
*/
#define list_for_each_safe(pos, n, head) \
for (pos = (head)->next, n = pos->next; pos != (head); \
pos = n, n = pos->next)
After analysis, the interface list_for_each_safe can be used instead of list_for_each_entry_safe; the highlighted part is the core of solving the problem, and the definition of list_entry can be found on Baidu
/* before solving the problem*/
void LITE_json_keys_release(list_head_t *keylist)
{
json_key_t *pos, *tmp;
list_for_each_entry_safe(pos, tmp, keylist,list)
{
if (pos->key) {
LITE_free(pos->key);
}
list_del(&pos->list);
LITE_free(pos);
}
}
/*After solving*/
void LITE_json_keys_release(list_head_t *keylist)
{
json_key_t *pos, *tmp;
list_head_t *list_pos, *list_tmp;
list_for_each_safe(list_pos, list_tmp, keylist)
{
pos = list_entry(pos, json_key_t, list);
if ( pos->key) {
LITE_free(pos->key);
}
list_del(&pos->list);
LITE_free(pos);
}
}
b) __restrict__: The restricted pointer is introduced in the C99 standard to alleviate the problem of pointer ambiguity in the C language. Alleviating the problem of pointer ambiguity can be used for compiler code optimization.
LITE_sprintf((char *__restrict__)ascii + i % 16, "%c", ((buf[i] >= ' ' && buf[i] <= '~') ? buf[i] : '.'));
The following compilation error occurs in IAR. This solution is relatively simple. Directly remove the __restrict__ keyword, but it will sacrifice some performance. We will consider optimizing this part in the future.
Error[Pe018]: expected a ")" D:\SVN\02 Intelligent Solutions\Software Engineering\ucos-msp430\ucos-msp430\ali-IoT\src\packages\LITE-log\lite-log.c 60
I will write here first, and then add more if I encounter new problems later;
|