Makefile migration

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

I just picked up a project that was shelved for a while that was written using AVRStudio 4.18. It used a makefile (thanks for the help Stu!) and linker_script.x file to modify the .hex file. I would like to migrate to AVRStudio 5 but notice the makefile structure may be different.

Does anyone have experience in migrating Makefile/linker_script files from Version 4 to Version 5, and since Version 6 beta is now released, that one as well?

Is Version 5 generally well accepted or are people still sticking with Version 4?

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

Quote:

but notice the makefile structure may be different.

It isn't - it's GNU make as always.

Presumably in 4.18 you had the "use external makefile" box ticked and then pointed to this hand crafted makefile? Just do the same in Studio 6.

(most use 4 unless you need some device supported that it did not have).

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

clawson-
Thanks for the reply. I tried checking the 'use external makefile' but AVRStudio 5 is not happy with the makefile presumably because the makefile references WinAVR:

## General Flags
PROJECT = BOOGER
MCU = atmega2560
TARGET = BOOGER.elf
CC = avr-gcc.exe                              <---

## Other flags
WINAVR = C:\Program Files\Atmel\WinAVR        <---
OBJCOPY = $(WINAVR)/bin/avr-objcopy           <---
FORMAT = ihex

Since AVRS5 isn't using WinAVR, any suggestions on what to replace these entries with?

-Thanks-

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

Quote:

any suggestions on what to replace these entries with?

Yes. It's just a matter of Atmel having placed the executables in other directories than WinAVR. Locate those executables and use the paths that Atmel chose.

For C:\Program Files\Atmel\WinAVR, locate the directory that contains avr-gcc.exe. Use that path in your makefile.

If that does not solve the problem with the last makefile variable also, i.e. if Atmel has chosen to place their objcopy in another relative path, you need to locate avr-objcopy.exe too, and use the path to that.

If you are ambitious you perhaps change the name of the makefile variable from WINAVR to TOOLCHAIN, but it has to be done throughout the makefile so perhaps not..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Johan
Apparently it is not that simple. I tried your suggestions and AVRS5 would not compile. The makefile modified some srecord attributes in the .hex file. I had to go back through some of my old notes and I see the srecord documentation pertained to WinAVR. With AVRS5 are there still srecord utilities? More specifically, I am referring to the tutorial:

https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=80723

Stu had given me a big hand two years ago with this. Unfortunately I don't know how this would port over to AVRS5.

Has anyone done this or something similar with the newer flavors of AVR Studio?

Thanks!

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

Quote:

' but AVRStudio 5 is not happy with the makefile presumably because the makefile references WinAVR

Tell us more about "not happy". As long as WinAVR is still installed on the PC in the place referenced by the Makefile I can see no reason why AS5 should have a problem with it. When "use external" is used it does little more than if you start a command prompt and type "make" in that directory. Actually what DOES happen if you try exactly that? (assuming you have make and avr-gcc in your PATH)

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

So now we've seen both "not happy" and "won't compile" in posts from you. In both cases my crystal ball failed to display the actual messages you got. I can see no other option than you actually doing that classich finger-dance-on-the-keyboard: mark, copy, switch-to-AVRfreaks-posting-dilaogue, paste.

Quote:
The makefile modified some srecord attributes

Again: We do not like guesswork, we need the details - what "srecord attributes"?

Or, how about actually attaching the current version of the makefile in a post here?

Remember that it is you that is looking for help - think about what other people might want in order to give that as fast and correct as possible..

-----

Quote:
As long as WinAVR is still installed on the PC

Cliff! As I understand attigeek he does not have WinAVR installed on the machine, but wants to utilize AVT Toolchain with a custom external makefile that was written for WinAVR.

So it might be that Atmel has built binutils so that objcopy and/or srec does not wortk with he same options as it did in WinAVR. We'll know if we test both toolchains in this respect(I won't) or the OP comes back with good verbatim error messages.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

So it might be that Atmel has built binutils so that objcopy and/or srec does not wortk with he same options as it did in WinAVR. We'll know if we test both toolchains in this respect(I won't) or the OP comes back with good verbatim error messages.

More likely the Makefile may be invoking GNUwin32 tools that are only shipped with WinAVR. (on the whole things like objcopy are generally backwards compatible).

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

WinAVR is not installed as the machine was a recent build. I was thinking of copying the srec_cat.exe executable from the older machine running 4.18 w/WinAVR.

I only have the mornings to work on the Atmel project as the afternoons I have a lab shift on some time-shared equipment. If the executable does not solve the problem, I will post what AVRS5 is not happy about tomorrow.

Thanks again

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

Well for sure AS5 does NOT contain a copy of srec_cat.exe so that's going to be at least one of the problems.

To be honest the simplest solution may well be to install WinAVR2010110 on the new machine. (Atmel go out of their way to ignore it these days though I suppose it might be an issue if its PATH entry were listed before anything provided by Atmel of the same name).

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

The question anbout why the OP wants to migrate to AS5 (or even AS6) now arises. Is AS5 is wanted just for an arguably better IDE solution or is the reason actually that AVR Toolchain is wanted for new device support?

Atmels descision tnot to include "everything in WinAVR" in their Toolchain build seems more and more to be a void in a head somewhere in Trondheim. (In fact, not using the work put down in WinAVR in the first place is strange (to be very diplomatic). A case of NIH/prestige methinks..)

If Atmel really wants people to migrate form WinAVR to tToolchain, then they shoud support all that WinAVR supported.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

LOL

for somebody like me (who uses Linux) this discussion is really funny.
Which tool comes with what Win??!
If I need a tool, I install it!
If I need a newer version, I install it!

At the end it was just a good decision to force our Windows users to use Cygwin -
and I'm just happy that I don't need this ... at all ;-)

-sb

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

Excellent, Sam. That helped. Not.

For e.g. installing avr-gcc, in the meaning "building and installing it" this is far from trivial even for peopel who are generally "technically fluent". I've tried to read through discussions about this several times, and e.g. the knowledge of what patches to apply etc is close to black art. And no, last time it was up for discussion the repos for the well known distis was not up to par re this.

I'm somewhere in the middle land - I don't like to be fenced in like Windows does to me. Sometimes I need the freedom to wreak havoc on a command line, etc.. OTOH, I don't want to be forced to that when I actually wqant to do something that ought to be a well established procedure, the desired result being the same as many other thousands of users desire. If I want a "standard" piece of software I want a simple command/installation/whatever.

And Cygwin is just laughable. The persons behind that got so excited with being in Windoze-land that they even adopted the DLL Hell principle. (For e.g. WinAVR this became a non-problem the minute they move out of the dependency of Cygwin and stood on MinGW instead. I can't assess the quality of MinGW, but I sure never have had two different softwares that depended on it, and that came with their oen different versions (as in different APIs) of a DLL named MinGW.dll, overwriting each other so that the last one installed wins and the previous ones are now non-functioning.

Now, I suggest a mod breaks off Sams post and my last one. They do not in any way contribute to the OPs problem. Suggested subject: "Windoze/Linux pissing contest".

Or just delete both posts. I would be fine with that too..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

[post deleted on the basis that it does nothing to actually help the OP's actual question]

PS: continued here: https://www.avrfreaks.net/index.p...