Can you explain how to copy and move an example project and get it to compile?
I've been working with the eval board and a project in the examples directory. The SDK 2.4.0 installer puts the examples folder here:
For any given example folder, say, SPItoFTDI, inside that SPItoFTDI folder there will be some files and a subdirectory called iar. Each iar directory has project files (i.e. files with extensions such as .dep, .ewd, .ewp, .ewt and .eww). When I run IAR Embedded Workbench and open that .eww workspace file, I'll see that the SPItoFTDI project has a number of driver source files associated with it (e.g. dma.c, gpio.c, spi.c, uart.c, wdt.c, etc.) Also, in that IAR workspace, if I look at the Project Options -> C/C++ Compiler preprocessor tab, I see that this project lists additional include directories:
Now, I'd like to move my copy of this directory out of that example folder and work on it in another location (where I can set up a repository for version control, not have to worry about my folder with my extensions to your example getting overwritten when I install the next SDK, etc.)
Can you explain what I need to change in the project so that when I move it out of the examples directory, I can still get it to compile? For instance, the build process can't find dma.c, nor the other Driver Source files that are in the project.
I haven't looked specifically at those examples yet so the following are general recommendations.
In general, anything with $PROJ_DIR$ in it is good, as it will be updated (by IAR) based on the current location of the project. The location is relative to the project directory, and will be found.
Anything with an absolute path defined is not optimum, as this will not be updated when the project is moved.
Having battled the same problem as yourself, I came to the conclusion that this structure is the best for revision controlling.
With this structure, when you add the driver files to the project in IAR, they will be added with a path relative to the project directory and be portable.
Ah, I see. That's a good suggestion. I will give it a try. I do have a couple more questions ...
Q1. What do you put in your .gitignore file (i.e. which IAR files do you ignore)? I saw somewhere that we should probably also version-control the project's .ewd files:
IAR Which files should be version controlled?
Q2. This second question is specifically about version tracking for the SDK v.2.4.0's SPItoFTDI example. In the SPItoFTDI example, the ADuCM350 acts as an SPI master, and assumes you've purchased FTDI's module which contains its SPI-to-USB chip, the FT4222H. (The module is called the UMFT4222EV, and it acts as an SPI slave, before forwarding the data up the USB bus to a Windows computer). The SPItoFTDI example sends "123" over the ADuCM350's SPIH bus to the UMFT4222EV which in turn, sends the info up to a Win32 console program. The console program prints out that it got "123" and the UMFT4222EV sends an ACK back to the ADuCM350. The ADuCM350 then sends "ABC" and the console program prints out that it got "ABC". Great.
The Win32 console program is a C++ program which you get from FTDI. That is, you download FTDI's D2XX low-level Windows USB driver for the FT4222H, and then you download FTDI's library for the FT422H's SPI functionality (the library is called LibFT4222). In that library are some example programs, and the SPItoFTDI example expects you to run FTDI's example named spi_slave_test_slave_side.cpp. This is in a Microsoft Visual Studio C++ project.
So when I go to extend this SPItoFTDI comms example for my own needs, I really need to keep code from two completely different IDEs (IAR's Embedded Workbench and Microsoft's Visual Studio) in sync.
What approach would you recommend for doing that?
I was thinking of having a series of repositories, where I stop each one after I get to a finished state of new communication functionality ... where each of these repositories is its own .git directory and then has one subdirectory of ADuCM350 IAR code and one subdirectory for UMFT4222EV Visual Studio C++ code. And then I guess for this repository you'd have one single .gitignore file at the .git top level that contains the file types to ignore for both Visual Studio and for IAR. Does that sound like how something like this is typically version controlled?
I've done a lot of development and added a number of new features to this SPItoFTDI communication protocol, but I've been keeping track of stuff manually. And now I have custom boards and various hardware test setups (i.e. one UMFT4222EV sending SPI data to another, an streaming version of the ADuCM350 sending continuous buffers to the UMFT4222EV, etc. etc.). It's all getting to be quite unwieldy ...
Thanks for any pointers or suggestions.
The IELFTool is a modified version of the tool in the IAR installation directory. It has been modified for the specific CRC and parity information of the ADUCM350. It is therefore different to the version in the IAR installation directory.
Personally, to ease deployment, I would create a tools directory in my repository, and revision control the EXE (and ignore the source of it).
Note as well, for someone to make use of the sources the specific version tools needed (the compilers for IAR, and Visual Studio etc) will need to be archived and instructions provided for whoever will consume the source. You could bundle the tool with that approach.
However, given that the project you create is dependent on where this tool will be installed (and it is small), I would probably take the first approach. Purists may disagree.
Regarding your structure of repositories, I am not sure if I got your specific question but I would comment as follows.
The two projects (IAR and Visual Studio) are bound together and could reside in a single .git repository. Using GIT branching, or using build configurations within the IDE could allow you to manage the different boards. It would depend on your implementation and needs as to what would work best for you.
Actually, here's a 3rd question (attached)...