Merging two projects with unresolved errors.

Bump...

To make it clear I had one project [project1] which reads acceleration readings using SPI which works.

I then started a new project [project2] which transmits empty packets using the CC2520 example code which also works.

Now I have tried to merge the two together, both ways i.e. move the files from project1 into project2 and vice versa with no luck. I know it must be some weird settings problems as they both work on their own. I made sure all the header files are linked in the project's settings, but still nothing works. Why is it so hard to do something so simple?

Daniel Tomicek said:

I'm not a SW person, I mainly work in hardware so bear that in mind in your replies

In hardware terms, an "unresolved symbol error" is an unconnected net.

You have some dangling wires; they are nicely labelled - but not actually connected to what the labels suggest.

You have used something (or things) which you have not defined.

So your merge is incomplete; you have missed some stuff - specifically, the stuff which resolves those symbol references.

Some cars have the driver's seat at the left, some have that at the right. Can you merge the two so that we can have two drivers? (This is pure "hardware".)

Daniel Tomicek said:

but what do I need to do to merge them?

Just basic knowledge of C programming. You can't make one program out of two just by merging source code. What you shall do is - do actual programming. Take one project as basis and augment it using code parts (functions and so on) from another.

Though I am hardware based, I do know some C coding and I think I need to go into more detail.

So this following project has a main.c file which includes Acceleration.h in the header which is shown here:

I obtained the code needed for wireless transmission from the CC2520 page which I have included in my main.c:

and I have also linked the files in the project settings:

When I try compiling, I get errors and warnings such as this, which say the function is declared implicitly. 

And in the console, this warning shows for all the files I have "included". 

"D:/Yek/components/common/hal_defs.h", line 19: warning #11-D: unrecognized preprocessing directive
"D:/Yek/components/common/hal_defs.h", line 27: warning #11-D: unrecognized preprocessing directive
"D:/Yek/components/common/hal_defs.h", line 35: warning #11-D: unrecognized preprocessing directive
"D:/Yek/components/common/hal_defs.h", line 42: warning #11-D: unrecognized preprocessing directive
"D:/Yek/components/common/hal_defs.h", line 51: warning #11-D: unrecognized preprocessing directive

I hope this helps. 

Daniel Tomicek said:

I do know some C coding and I think I need to go into more detail

Yes, you do.

Here are some suggested resources for learning 'C': http://blog.antronics.co.uk/2010/12/12/

Why is there this opinion abroad that software is "easy" and anyone can "just do it"  ?

Presumably, as a hardware designer, you value the study & experience that goes into your job?

If a programmer were to try to leap into designing hardware without properly understanding voltages, currents, Ohm's law, etc would you be sympathetic when they say, "Why is it so hard to do something so simple?"...?

Software isn't especially difficult - but neither is it trivial. You do have to spend the time learning the languages & the tools.

[end of rant]

Andy Neil said:

I do know some C coding and I think I need to go into more detail

Yes, you do.

Here are some suggested resources for learning 'C': http://blog.antronics.co.uk/2010/12/12/

Why is there this opinion abroad that software is "easy" and anyone can "just do it"  ?

Presumably, as a hardware designer, you value the study & experience that goes into your job?

If a programmer were to try to leap into designing hardware without properly understanding voltages, currents, Ohm's law, etc would you be sympathetic when they say, "Why is it so hard to do something so simple?"...?

Software isn't especially difficult - but neither is it trivial. You do have to spend the time learning the languages & the tools.

[end of rant]

[/quote]

The point of my frustration Andy is that the two projects I have created, work independently. I have done the steps which I needed to in the two separate projects in order to get them working, in the merge. I had several people look at my problem whom have had plenty of microcontroller programming and they can't figure it out either. To me this doesn't seem like a code problem but rather somewhere in the project settings.

You shouldn't assume I haven't tried other options, looked at other posts on the forums online and asked other people before posting here...

Daniel Tomicek said:

I get errors and warnings such as this, which say the function is declared implicitly

In other words, you code does not contain any declarations of those things, so the compiler has assumed default - or "implicit" - declarations.

This is standard 'C' compiler behaviour.

Daniel Tomicek said:

D:/Yek/components/common/hal_defs.h", line 19: warning #11-D: unrecognized preprocessing directive

So what, exactly, does appear at line 19 of your D:/Yek/components/common/hal_defs.h file ?

As you say you're getting these warnings for all your included files, don't you think this may be the reason why the afore-mentioned declarations are not being found...?

Andy Neil said:

I get errors and warnings such as this, which say the function is declared implicitly

In other words, you code does not contain any declarations of those things, so the compiler has assumed default - or "implicit" - declarations.

This is standard 'C' compiler behaviour.

[/quote]

Yes it is defined in the "hal_mcu.h" file. These files are all the ones downloaded from TI, and as I have mentioned before works in another project without these errors.

Andy Neil said:

D:/Yek/components/common/hal_defs.h", line 19: warning #11-D: unrecognized preprocessing directive

So what, exactly, does appear at line 19 of your D:/Yek/components/common/hal_defs.h file ?

As you say you're getting these warnings for all your included files, don't you think this may be the reason why the afore-mentioned declarations are not being found...?

[/quote]

Yes I do believe this is one of the reasons but I am really unsure as to how it would be fixed. 

Daniel Tomicek said:

Yes I do believe this is one of the reasons but I am really unsure as to how it would be fixed. 

Well, there's some fairly basic conditional-compilation stuff there - and there's a clue in the symbol name containing "IAR"...

Looks like somewhere somehow you defined __IAR_SYSTEMS_ICC__.To the tool chain, this means you intended to use IAR instead of CCS. Are you using IAR? I bet you are not and should not have defined __IAR_SYSTEMS_ICC__.

I see. Well, these are the files supplied by TI so I have not modified them in any way, since it worked for me in my other project.

I've got to the point now where there are no "problems", so it compiles (still with the warnings). HOWEVER the code does absolutely nothing. I can't even get it to print to console (which I could do previously before the merge). 

Daniel Tomicek said:

these are the files supplied by TI so I have not modified them in any way, since it worked for me in my other project

So the other Project obviously provided the correct  configuration!