Inherit some params from main project in an included static library

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all

 

I haven't found an answer for this question so I created a new topic

 

Please apologize if something related to this was already posted

 

Here is the question:

 

I use Atmel Studio 7 for compiling code for several Arduino boards

 

I have several projects that share the same static libraries for different processors and frequencies

 

Is it possible to inherit some params (like F_CPU or device) from the main project?

 

Each time I start a new project, I include the lib but I have to modify the frequency and the processor for the current project

 

Of course if I try to compile another project with another settings it won't work correctly because these params are local to the lib

 

Can I set the frequency and the processor device according to the main project that include the lib, instead of setting it on the lib?

 

Hope to be clear, my english is far to be perfect ;)

 

Any help will be welcome

 

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sadly this is exactly why static libraries have almost no part to play in AVR development (apart from the obvious ones line libc.a and libm.a). When you use "library" code with an AVR there are almost always some compile time configuration like a UART baud rate or a PORTx choice for an LCD interface or an F_CPU input for calculating timer rates and so on. You have two choices.

 

1) this is horrendous. You have the code pre-built and you actually pass it parameters like "baud", "port", "F_CPU" at run time. It then has some kind of huge switch()/case: structure or some that says something like "if baudrate==9600 and F_CPU==7.3728MHz then UBRR = 47, etc. etc." Or for the LCD.. "if data_port== PORTB ... else if data_port == PORTC ... etc etc"

 

2) you give the client a .c and a .h (and perhaps a config_module.h) and they edit F_CPU and baud and LCD port values into such a file and then they compile the code themselves. This means that the code they build just has code to set UBBR=n and for the LCD PORTx =data and so on

 

So forget trying to build static libs - it has no place in AVR development and frankly Atmel are idiots for even offering the choice on the File-New Project... dialog in Studio 7 (they just inherited that from Visual Studio where the creation of static libs and DLLs does make sense).

 

If you look at any of the well known library code for AVR:

 

http://homepage.hispeed.ch/peter...

http://siwawi.bauing.uni-kl.de/a...

http://www.procyonengineering.co...

 

then you'll see they are all supplied as collections of compilable .c + .h and not .a files. Even the most famous multi-CPU lib for AVR of them all:

 

https://www.arduino.cc/en/Refere...

 

is supplied as .c/.cpp and .h that is built every time. True, once they know which CPU it is targetting they build it all into a libcore.a and then later link against that. But the step is almost completely pointless in this day and age. The -ffunction-sections and -gc-sections options have almost completely done away with the need to segregate code into separate sources and build .a files anyway. (one of the main reason for using .a in the past was to ensure that only the functions called got linked in but with the -gc-sections stuff you can now just build and link everything then the linker finally discards (garbage collects) anything that is not called at the end of the process.

 

If you have some non-hardware specific library code (a JPEG decompressor for example) then like libc.a (printf, strcpy etc) or libm.a (sin, cos, tan etc) you could choose to build that into a .a file I guess. But note that even then you could not use just one .a file. For example some AVRs support MUL, some don't, some have JMP/CALL/RJMP/RCALL and some only have RJMP/RCALL, some have ELPM and some have LPM so there are actually 17 different variants. Like libc.a and libm.a you would therefore need to build 17 versions to be sure of having one that could be used with any of the models of AVR (and then you face matching the right .a to the correct one of the 300+ models of AVR!)

 

Bottom line: forget static libs.

Last Edited: Thu. Sep 29, 2016 - 11:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Clawson for your quick and complete answer

It's sure that without the ability to inherit these parameters, building libs make no sense

At least, your answer, avoided me to spend time and efforts on searching solutions that do not exist

Have a nice day and thanks again

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Sadly this is exactly why static libraries have almost no part to play in AVR development...

 

This is a very frequently-recurring topic - it's just come up again:

 

https://www.avrfreaks.net/comment...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...