1190 views|0 replies

1663

Posts

0

Resources
The OP
 

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;

This post is from Microcontroller MCU
 

Guess Your Favourite
Just looking around
Find a datasheet?

EEWorld Datasheet Technical Support

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews

Room 1530, Zhongguancun MOOC Times Building, Block B, 18 Zhongguancun Street, Haidian District, Beijing 100190, China Tel:(010)82350740 Postcode:100190

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京B2-20211791 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号
快速回复 返回顶部 Return list