How to move from a FRDM-K22F demo to a new application

[davepfaltzgraff]

After getting the USB MSD demo to run on the FRDM-K22F, see Trying the throughput test with the host_msd_fatfs_frdmk22f_mqx_frdmk22f, I would like to be able to move that to a new project where I can modify it at will without affecting the original code. My first thought was to archive the project and then un-archive it to a new location. However, due to the heavy use of relative paths (../../../, etc.) I find it almost impossible to find and edit all the places where this was used.

So, for any of the examples in the KSDK_1.0.0 package, what is the best way to extract a particular example to another location where it can be modified and expanded?

Thanks.

[davepfaltzgraff]

I am posting the following in the hope that members of the community may have some ideas. The original idea was to replicate the MQX USB Host example into my own working area. This would allow me to change the files at will and experiment without having to worry about changing any of the original files. My first few attempts were futile attempts to do it the easy way and only lead to frustration and eventually to this post.

Since then, I have worked up the following procedure which seems to work - mostly. The procedure is to:

1. Follow the procedure at How To: Create a New MQX RTOS for KSDK Project in KDS and generate a new, clean, basic MQX project. For example, I put mine at C:\Projects\MQX-HelloWorld

2. Copy the entire folder to a new location and rename that subdirectory. For example, I named mine C:\Projects\MQX-USBHost.

3. Start KDS, and import the [project from the new directory. Note: Make sure there are no other projects in KDS. (Keep it simple and clean!)

4. In KDS, rename the project. Go to Project=>Properties=>C/C++ Build=>Settings : Build Artifact tab and rename the Artifactname. (Usually the same as the project. You can also use the ${ProjName} construct if you're comfortable with that.)

5. Delete the project from KDS and re-import. After doing the import, do a refresh. This may not be necessary, but it just makes sure that internal references are up to date.

6. Compile the project as a sanity check. It should be the same as the original project. If not, resolve any differences.

7. Open the original Freescale MQX example project as a second project. If you examine the modules and structure, you'll see that there are many commonalities - same debug console, etc.

8. Where there are differences, copy the files from the example into the new project. Be sure you copy the files and do not use links or virtual folders. (I used the Import from File system method.) If you are prompted to add include paths along the way, go ahead and accept them.

9. Be sure to replace the main.c of the original project with the appropriate module(s) from the example project. Again make sure it is an actual file copy into the final project.

11. At this point everything should be in place. Compile. I am sure that various header files will not be found. Go to the Project=>Properties=>C/C++ Build=>Settings=>Cross ARM C Compiler=>Includes and add the appropriate path to the "Include paths (-I)" section. This is an iterative process and may take many cycles to find all the files. I do NOT encourage just copying the include paths from the original example project as this tends to carry over a lot of "cruft". The current effort is to come up with a clean project that is more easily understood.

After all that, I got a clean compile and tried to debugit. It ran - partially. Just a portion of the initial message got printed and then it would hang. The symptom was almost identical to the problem I reported in _usb_khci_task_create() does not return. Which is also an attempt to use the USB host mode.

After a lot of stepping through the code, I thought that I must have copied something wrong, so I went through the entire project comparing the various files. All files were identical. This left the various project related files. In all cases except the two .cproject files, I could account for the differences. Although many of the differences are reasonably clear, there are a lot of little changes that make no sense.

So, here's where I'm looking for ideas. Is there some way to compare the two .cproject files to determine which differences are significant? They are XML files and a lot of the differences seem to be a numeric reference meaningful only to Ecplise, but which ones are safely ignored?

Any suggestions? I feel so close and yet so far!

Thanks

[ivadorazinova]

Hi David,

I recommend you create a copy of the demo using the script.

I send you the tutorial which describes this procedure which make whole copy with paths and settings.

How to create copy of KSDK example in KDS

I hope it helps you,

Iva

[davepfaltzgraff]

I have several problems with this approach.

The first is that there is heavy use of relative paths. For example, the include directive of:

  ${ProjDirPath}/../../../../../../config/mcu/mk22f120m

more or less restrains me to staying within the directory structure defined by Freescale and the KSDK. I want to move the project into my own area such as C:\Projects\xxx.Using this directive as an example, the system would try to search for a header file at C:\config\mcu\mk22f120m\ which does not exist.

The second is the use of virtual folders. As I understand it, this is a link to the original file. A change in that file for this project would make the same change in another project which may have undesirable side effects.

Don't get me wrong. I think the concept of the virtual folder is good in that it saves space and time in addition to enabling code reuse. However, in my case, I would like to be able to extract the project in its entirety from the Freescale KSDK directory structure and put it where I can work with it, put it in version control, etc. (Note that the header files and libraries should remain where they are. I am speaking of the code unique to this specific project.)

In looking at some of the newer work, for example code generated by PE in the most recent version of KSDK, instead of using relative paths the ${KSDK_PATH} construct is used so that a project is more portable. For example, I can export the entire project through an archive file and then import it to an entirely different location and have it work. There is no need to clean up a lot of paths which is prone to errors.

I think a good example that shows what I mean is the tutorial found at How To: Create a New MQX RTOS for KSDK Project in KDS. The few cases where the ..\ construct is used is entirely within the project and even those could be replaced with the ${ProjDirPath} and thus be avoided completely.

[ivadorazinova]

Hi David,

yes, you are right. If you create a copy of the example, you must observe certain rules.

If you need to work with specific files, please just put them into your project.

So, e.g. if you want to modify board.h, etc in boards folder,

please go to folder boards, C:\Freescale\KSDK_1.1.0\boards and copy frdmk22f to your project folder.

After that don´t forget to delete these files in KDS and put there new ones.

and rewrite paths in KDS for Compiler.

You can rewrite the files by this way.

Best Regards

Iva

[davepfaltzgraff · Accepted solution]

The procedure that Iva describes is basically correct, but it does not carry it far enough. I need to be able to move the project to any file structure on any computer that I want. This totally removed it from any dependencies of the KSDK structure. The following finally worked for me.

1. Use the script that Iva provided to generate a parallel project. As mentioned this is still dependent on the KSDK structure. So...

2. For each of the source folders (those containing .c and .h files), create a new folder by a different name. For example, for the "Sources" folder, create the new one as "Sources2".

3. Now for each file within the original folder, look at the "properties" pane to find the true path to the file and then going to the new folder, use the Import=>File System option to go to the true path and select the corresponding files. When selecting the files, go to the "Advanced" panel and make sure that "Create Links in Workspace" is NOT selected. Once all of the files have been copied into the new folders, delete the original folders a\nd rename the new folders to the original names.

4. AT this time do a build. It should be OK, but if not go back and copy in the correct files. This is an iterative process and once you have a clean compile, export this intermediate result to an archive file. (Just in case you need to come back to this point.)

5. Now go into the project properties and edit the C/C++ Build=>Settings=>Cross ARM C Compiler=>Includes to eliminate the relative (../) references. This takes a little work, but it is best to replace the strings of "../../../../../..." with ${KSDK_PATH}. Again this is an iterative process and may take some figuring out to get it right. Check it out by doing a build. Once you have it right, again make an archive for sanity.

6. Now go into the project properties and edit the C/C++ Build=>Settings=>Cross ARM C Linker=>Libraries (and Miscellaneous) to edit out the relative paths in the same manner. Check it out by doing builds. Once you have this right, generate the archive file as before.

7. Now, if you've done it right, take the archive file and unzip it to a new location. If you've done it right, all relative links outside of the project have been removed and the project should compile and run. If not, dig down and find the spots you've missed and go back to the appropriate step. (Remember those archive files we made along the way?).

Although it is tedious, this has worked for me and now I am free to change anything within the project without worrying about changing any of the original code.

Note: I'm OK with KSDK header files remaining in the KSDK area as I should not be changing those. This is also true of any driver files that I should not be changing, but I do know that some of them may get copied over in the process. If this is a concern, it is now a minimal effort to clean up.

I hope this lengthy process helps others in getting their projects going as well.

[yorknh]

I don't really have much of a solution for you, but I ran into the exact same thing for the exact same reasons. I ultimately ended up creating a couple of path variables that pointed to where I copied the project and then rather trying to modify the paths in eclipse, which is brutal, I shut it down. I then edited the project files with and editor and then reopened KDS. It did work, but it was was more painful than it should be.

Again, I can't recommend what I did unless you really need to, but I did want to let you know you aren't the only one struggling with the same issue.