"DSP development" using CCS5.4 to develop DSP6455-based JPEG2000 image decompression process

"DSP development" using CCS5.4 to develop DSP6455-based JPEG2000 image decompression process

Disclaimer: Reference Please specify source http://blog.csdn.net/lg1259156776/

Description: The front-end is the time based on the VS2010 project, the implementation of the openjpeg2000 on Windows, the implementation of the data from memory to extract the work of decompression. As some technical reserves are needed, they are ported to DSP6455 for decompression. This article records the entire migration process.

0. Whimsical: Try to build a good compilation library using VS2010 directly on CCS

This idea is always there, in the debugging VS2010 under the openjpeg2000 and rewrite, because of the cost of Kung fu more, so only to give birth to this once compiled, running around the idea (this is not the Java signboard it). Later also dedicated to this aspect of the content of the understanding and digestion, and finally reached the conclusion that can be achieved at most once written, compiled everywhere, so the source level of cross-platform. In the future, the static link library is considered as the archive of the target file obj, and under Linux, the corresponding obj file can be analyzed using the command ar T xx.lib, or the target file can be solved by ar-v-X xx.lib. So all know that the obj file is pre-compiled, compiled and compiled, has been targeted at the hardware platform on the machine code, it is not possible to be linked on different platforms to execute.

Therefore, only the way is to use the target processor or the development environment on the operating system to build the corresponding library, and then use the development environment to build the library, compile links, this is the only method for this source-level cross-platform language. As a result, the JVM is preferred, although different JVMs need to be installed on different platforms, but they can be run on any platform after they are configured.

1. Porting with CCS3.3

directly to the VS2020 project under the openjpeg of the source files are all copied into the CCS3.3 project directory, and then select the Output static link library (note that the application of DSP is not so-called dynamic link library, because it is not possible, like Windows, in the runtime load DLL, etc.), compile, of course, there will be many errors Miss. The main error is the platform-related section, as Openjpeg is generated by cmake, using cmake directives to generate makefile for cmakelists parsing, or directly corresponding target engineering files, Tested under Windows VS2010 and Linux under the makefile can be successfully compiled through, and generate executable files, the smooth implementation of decompression. But for Windows, the use of cmake to achieve the production of CCS, the Internet did not find the relevant data documents, but also abandoned the use of the simplest method. As a matter of fact, CMake's work on building an embedded development platform might be a little too whimsical, perhaps even later, to be realized. So to get back to the beginning of a pile of errors, I was all commented out, and later proved that I dug a huge hole for myself, took 5 hours to find out the pit, fix it. Finally, a static link library can be generated. Then prepare a method similar to VS2010, and then build a project that uses this generated static link library to decompress.
Also started to compile the source file will have some errors, the same use of the above method, the direct contempt, comments, finally compile can pass, generated the corresponding obj file, but at the time of the link there is a bunch of errors, all kinds of functions are declared, referenced, but there is no definition, Not only is it not found in obj, but those functions in the Lib file are not found.

It should be clear to now, generate static link library, do not need to link, just need to package the corresponding obj file archive. Therefore, this is also in the previous generation of the Lib project did not cause the error, but in this decompression project, because the generated executable file, need to be linked, relocation, etc. before the generation, so all the errors are in this link process.

Note that many of the errors are from some printf,malloc and other functions in these standard libraries have a link error, so it feels that the ccs3.3 may not be advanced, or the relevant parameters are not set "the current guess is that the runtime library is not found, or the link has been wrong", But the solution was not found for a time, so decided to use CCS5.4 to develop, I hope this relatively new development environment can provide a richer runtime library bar.

2. Porting with CCS5.4

Because of the above basis, the test on the CCS5.4 is faster, direct copy, directly generated projects, configuration environment for the DSK6455 target board, the first choice is to generate static link library. debugging by the corresponding static link library, and then the same configuration to extract the project, note the output as an executable file, and then enter the corresponding library.

That's when the problem comes, and at first it's still not noticed, and the error is removed in a commented way, and then the executable is finally generated. This time similar to the CCS3.3 in the link error no longer appear, corresponding to Malloc,alloc,fopen, etc. can be found.

The run-time library in the project configuration is selected as automatic, so this may be the reason that the corresponding function can find the definition. There is no link error, so it is recommended to use a later version of CCS for development, (although it is always possible to develop DSK6455 on CCS5.4, the network will not be able to connect, while the CCS3.3 can connect normally, but the same NDK is used to develop 6678 of the network ports without errors).

At first, there is no rush to download directly to the Board debugging, because in the DSP and other embedded platforms, one of the biggest problem is limited memory, 6455 of the on-chip RAM is only 2M.

At the time of decompression, the work flow of the project is as follows: Read the JPEG2000 compressed source file in J2C format from the computer F disk, save in memory, then feed the memory into the function of the modified LIB to extract the data from memory, and finally output the image of BMP file on the F disk.

This process seems very simple, the implementation of DSP, but the memory of the function and variable data in the Lib library is managed by the Lib library itself, which means that most of the memory management in the Lib library is through malloc or alloc dynamic application, so, Need to have a large stack in the DSP operating environment, so you need to set the size of the stack in the linker basic options of the project cmd file or the project configuration, for the sake of insurance, it is better to set a larger, here directly set to 0x2000000, too large, in the on-chip RAM can not be applied at all. Considering such a large memory consumption, and the DSK6455 tablet plug-in 512MB DDR2, consider all the program and data are put into DDR2 to perform, This requires that the. Text segment in the configuration cmd, the. Stack segment, the. BSS segment, and so on, be mapped to the address space of the DDR2, which solves the problem of insufficient memory, but understand that the DDR2 clock rate is only about 600MHZ, plus a certain access delay, so do not expect a higher rate of execution, but in the debugging phase Accepted.

Subsequent if the debugging through, but also in turn to the use of Lib memory optimization, in the middle certainly a lot of memory is not needed, because there is a place in the Lib as if to apply for the maximum image memory, which is a certain amount of memory waste, follow-up optimization should pay attention to this point.

After completing the above memory configuration, began to download to the board of the test, started running at full speed, found that the output of the information decode error, can only decode the previous header, and then slightly debugged, the image can be properly sized. However, because the input is the library file, debugging can not enter the library file function definition, and then re-establish a project, this time not to use the library, but directly all the generated Library de project source files are added to the project to facilitate the trial. After debugging, after the modified files are copied to the library project, compile the build library, and then enter the project to use the library to test whether the library is available.

So, the back of the debugging can be said to be dark, various add breakpoints, a variety of problems to find the cause, estimated to spend three hours, finally let me after 10 consecutive functions of the call found a return value of false, it is caused by some parameters after reading and then determine the problem, and output error debugging information. And then into this function, I was pleasantly surprised to find out that this is actually the line of code that I have previously commented out in order to exclude compilation errors. is actually a function of the variable memory request, because there are corresponding macro definitions under Win32, so the precompiled instruction control compiles the code snippet of the Win32 platform, but under CCS, there is no such macro definition, and the related function does not. What I commented out was really a function that was called when no platform was found, and it was remembered that the compiler error of the output was that the corresponding function was undefined. Damn it. The result is a 3-hour search for the cause of the error.

Then fix this error, and also check whether there are errors caused by this cause, but also notice in the specific test Win32 macro definition to compile the code snippet, to see if the corresponding code snippet on CCS is missing, and so on. In short, and a series of troubleshooting, and finally really can not find the problem, only after the debugging, and really output the corresponding BMP file, but really a burst of joy, originally in the last issue has been grinding without patience, if uncertain, estimated to give up. Fortunately, fortunately!

But the problem again, found that the output of the picture can not be opened, and then use UltraEdit to open the image data extracted under the VS2010, found that the same as the head, corresponding to the BM, and then the hexadecimal editor, found also on the same head (at that time also really fainted, actually no serious than the right, Because later found that the difference is only the CCS output file is missing 00, the others are roughly the same. Mainly UltraEdit sub-screen to see, the back of the 8 numbers can not be seen, is obscured, resulting in a dislocation than the "careless will always Be bad"). Then actually returned to suspect is not the decompression problem, it is very worrying whether the algorithm has a problem, because if it is the problem of the algorithm, it is difficult to do. It was hard to convince myself that the data was correct, but still think about the mistake of saving the data, which seems to take 1 hours. Finally, through the comparison of the output of the two, found that the original CCS is actually using fprintf ("%c", 0) output ASCII code of 0 characters, simply cannot be lost. "Damn it."

When the data is found to decode the right time, my heart just put down, for the fprintf output problem, is a better solution, directly replaced by fwrite, then of course, the first through a new Ccsfiletest simulation project to test is not really lose 0, after the verification, Decide to use fwrite directly to output. Later things are relatively simple, not the table.

In fact, I have found that the output file size is different, and even the previous fixed format of the file header is different, but should be suspected, but did not drill down, resulting in a one-hour later to solve the problem. It's a waste of a statement.

2015-10-23 Debug Record Zhang Bongyi

Copyright NOTICE: This article for Bo Master original article, reprint please indicate source http://blog.csdn.net/lg1259156776/.

"DSP development" using CCS5.4 to develop DSP6455-based JPEG2000 image decompression process