Combat UC-TCPIP

After more than 10 days of efforts, finally on the board to the Uc-tcpip run up. While still remember, hurry to record the process, share experience. Also took a lot of detours in the future to learn lessons.

This more than 10-day work can be divided into three parts: data collection, code migration, test debugging.

Due to the needs of the project, we want to add a network port to the existing ARM7 platform to run TCP applications, but our existing project does not implement the TCP/IP protocol stack. After preliminary investigation, began to collect on the internet about some uc-tcpip information, mainly "official Micrium" UC-TCPIP source code, plus two or three different hardware platform use example (thank csdn, Google svn and share, etc.). It also searches for posts or blogs with several UC-TCPIP experience.

The official source code is divided into several directories, of which the source under the Uc-tcpip directory is the most core source. Simply put, source is directly used, other parts such as NIC, OS, CPU and other directories are based on specific development environment specific analysis and modification. In addition, Uc-lib is a general function library that handles memory allocations and string conversions, and can also be used directly.

Our project has been using UCOS-II, but carefully read the UC-TCPIP configuration instructions, ucos-ii minimum version requirements are v2.8x, and we are currently using Ucos-ii v2.52, so the first step must first upgrade ucos-ii.

After one or two days of efforts, I put the original DSP and arm platform above the project Ucos-ii are upgraded to v2.86, the middle because the configuration of the wrong idle task stack size caused overflow, took some time to debug.

Transplant Uc-tcpip is a little more than a bit of effort. First of all, I'm trying on the ARM7 platform. Add Uc-tcpip/source to the project first, set the search directory path, compile through but the link failed, because there are still many function references are not implemented. The solution is to search uc-tcpip/if, Uc-tcpip/os, Uc-lib and other modules, select the appropriate implementation file and add to the project. Because there is no physical network chip on the platform at present, it is necessary to add some empty interfaces related to the operation of the network chip. It also rewrites CPU-related cpu_critical_enter and cpu_critical_exit macros, disabling some debugging and assembly optimization-related configurations such as net_dbg_cfg_* (@net_cfg. h), uc_cfg_optimize _asm_en (@app_cfg. h) and so on. Finally, the execution file is generated, downloaded to the target platform "run" up, of course, this time only the task began to run, the substance did not do.

With previous experience, it is much smoother to transplant uc-tcpip into a DSP platform. I have a piece of DSP board with network Chip cs8900a, and found on the internet for UC-TCPIP driver net_nic for cs8900a, just can replace the NIC module. This is not the "bottom-up" driver, however, because the NIC module only knows how to operate the cs8900a registers, but where the physical address of those registers is unknown, it depends on the specific platform. In the UC-TCPIP structure of the BSP module to the matter, which shows that the implementation of net_bsp need us to do it ourselves. In fact, we do not need to add a lot of things, mainly read, write register operation interface, as well as interrupt service program. By the way, it is UC-TCPIP hierarchy division, although I now for if, NIC, BSP and so on the concept is still relatively vague, but probably know the BSP equivalent to the bottom, and hardware closely related, NIC is an abstraction of the network interface, the two corresponding to the physical layer, as to if I do not understand, may be related to the data link layer. Anyway change the board may have to change BSP, network chip may have to change NIC. This design is very convenient and flexible when porting. Before encountered a certain drive, which involves from the physical layer to the application layer, with the cry ah ... The cost is to introduce a lot of layers, and space and time efficiency will have an impact. But I think this is definitely worth the money compared to the difficulty of development and maintenance.

Build and then it's down to the board to debug. Set up a simple task of sending UDP packets at regular intervals. But there was no bag to hear. Breakpoint single-step tracking, check the network cable, with the old program driver comparison, replacement, tossing for one weeks, finally found that the BSP is wrong, I have a misunderstanding of the operation of the Register ... At this point I can not help but sigh, if there is a partner or something a little bit code review, this problem should be resolved early. When I caught the first UDP packet, excited for less than a minute, found that the content has a byte reversed, it seems that the problem of the size end is not good. In the various header files and endian related to the countless macro definitions in a long time, it is concluded that the "fetch" NIC definition is wrong?, change, finally send and receive packets are normal. Finally, I opened a socket, which has simply tested UDP and TCP transceiver. Here, my project can be said to have only taken the first step ...

Summary of lessons learned during the transplant:

1. When I first contacted Uc-tcpip, I felt that the directory structure was a bit complicated and I didn't know where to start. The quick way to get started is to read the instruction manual, look at the example project, find someone else to write the experience of using ...

2.os_cfg.h, Cpu.h, Net_cfg.h and App_cfg.h and other head files to be carefully configured according to the actual situation, you can refer to other projects, but can not blindly copy.

3. The embedded program runs mainly due to array overflow, stack overflow, and wild pointers, which are not possible after the upgrade ucos-ii because the stack settings are small.

4. Hardware or protocol-related code to pay attention to the problem of byte permutation and size end, this project has CPU endian,cs8900a endian, and TCPIP protocol endian, our project CPU is Little_endian, and cs8900a, Tcpip opposite. If the configuration is wrong, if the data is not good for the reason, if there is no data out that may have to look for half a day.

5. Often add a new library compile link when there will be a lot of strange warning and error, dazzling, patience, and even will scare back the weak will abandon the use of the new library. Some of the common reasons are summarized briefly:

First, the header file is not found, usually need to add a search path (-i "path");

Second, there is no definition or duplicate definition, some header files do not have anti-duplication included, the inclusion of the wrong order will appear similar problems;

Three is unable to find the symbol, link missing external function or global variable, it is retrace add module, sometimes may have to achieve their own, in addition ucos like define OS_MASTER_FILE,UC-TCPIP like define Net_xxx_module, You may wish to take care of such a macro when you cannot find a global variable;

Four is a naming conflict, which is also expressed as a duplicate definition, but the related macro, variable or function in different modules is not the same thing, this wood has namespace had to sacrifice one side, renamed, this time let me meet BSD Socket Close conflicts with the API's close and DSP runtime rts6700.lib ... ；

In fact, compared to debugging the compilation error is not scary, after all, there is no class, template these things, or not difficult to deal with.

Attached project Source: http://download.csdn.net/source/3270822

Uc-tcpip and cs8900a Drive source code (online): http://download.csdn.net/source/3274016