Merging changes into the AtmelSTART configuration

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

Is there a proper way to merge changes that I have made to an ASF4 generated file into either:

a) The actual AtmelSTART project, so it will always accept my version in the future, or

b) The current reconfiguration file, so that I can perform a proper merge of two files if both contain changes (let's say I've made changes to a driver, then the driver is updated. I use WinMerge to look at the diff, and I'm looking at how I can actually merge the two files in a way that will be accepted by the AtmelSTART reconfiguration from Atmel Studio 7)

Here is the steps I follow:

1)

Reconfigure AtmelSTART - button

 

2)

Reconfigure AtmelSTART - Interface

3)

View diff

 

At this point I'm not quite sure how to proceed in order to keep the AtmelSTUDIO configuration working in the future, and also keeping my changes.

 

A second question I have is if there is any real possibility to update specific drivers (let's say a driver that I have not altered at all), without going through an AtmelSTART reconfiguration. Recently I had to update the HRI for the Timer/Counter peripheral, because it had introduced a lot of new functions (discovered by accident of course, after starting a new project where these were utilized tor testing - then trying to use the same functions in an older project), but I found no apparent way of only updating the relevant files. I did manage to update, by reconfiguring the AtmelSTART project, and updating the csproj (plus a few other places if I remember correctly), but honestly I only needed to update a single file.

 

Cheers

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

Maybe I don't understand the question, but this seems like a code management problem that a code versioning system, CVS, GIT, SVN would handle, you can think of the auto code generator (START) as just another programmer who is contributing code to the project.  So it needs to go through your software code review, QA, merge/pull process the same as any other programmer assigned to the project.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Yes, that's how I'm seeing it as well, but I am still unsure how to actually handle it. Because if we use your metaphor (that AtmelSTART is a programmer contributing to the project) it is an annoying programmer that keeps reintroducing bugs that have previously been eliminated, reverting merges and generally not caring about anyone but itself. So my question is really more in terms of how to actually make AtmelSTART listen to my complaints, accept merges, or just stop overwriting specific files.

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

simenzhor wrote:
or just stop overwriting specific files.
Isn't that what the dialog in your picture shows? You can look at the diffs and weigh up whether you want to accept the change or not in each file. I guess the issue is that if you only want SOME of the changes in a file you need to apply just some of the diff.

 

But who "owns" these files anyway? You or the "auto-programmer"? I think the point is that you cannot make local amendments as they will stand a chace of being over-written. You have to accept what the auto-programmer delivers or not use her work at all. If you think there are bugs in the auto code then presumably the only way to get that mysterious programmer to fix them is to raise a support ticket on microchip.com. It's a situation similar to C library functions like printf(). If you found a bug in its operation you'd have to contact the lib author and get them to apply a fix - it's not something you could do locally.

 

One approach with HAL/BSP code of course is to take what Start generates - look at the techniques then implement your own local, maintainable copy based on the "example" it gave you.

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

clawson wrote:

simenzhor wrote:
or just stop overwriting specific files.
Isn't that what the dialog in your picture shows?

Yes, but I was trying to describe a "remember my decision" type of solution.

 

clawson wrote:

You can look at the diffs and weigh up whether you want to accept the change or not in each file. I guess the issue is that if you only want SOME of the changes in a file you need to apply just some of the diff.

You are right. That was what I was hoping. That I would be manually able to select diffs to merge, and that AtmelSTART would accept my decision and not try to overwrite again.

 

clawson wrote:

But who "owns" these files anyway? You or the "auto-programmer"?

You are probably hitting the nail on the head here. The auto-programmer owns the files, and they do have a disclaimer not to modify them. However, while an ok solution for smaller projects may be to just duplicate all files used for initialization and pin definitions etc., it doesn't scale very well. I know the proper way to handle this would probably be to go back into AtmelSTART and assign pins in there, but some of the problems I've overwritten has been literal bugs in the AtmelSTART code (specifically in an SPI middleware library. I reported the bug, and it's supposedly fixed, but I don't think the fix has gone live yet).

 

Anyway. I realize this was a long shot. And there are probably problems with the solutions I would "like to find" that make them unfeasible. I figured I should just give it a shot and see if I was missing something obvious.
Thanks

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

Follow up question:
is there a way to decide which line endings AtmelSTART will use? A semi-mature AtmelSTART project was added to a git repo that changed all line endings to UNIX style. Now every single AtmelSTART file shows the entire file as different from last time.

Now, I've configured the diff tool I use to ignore line endings, so when I open the diff it only shows actual changes. But in order to follow the approach we decided on above (unchecking files I have made changes to) I still have to look through hundreds of "modified" files (like in image 3 in the original post) to find the correct ones. I couldn't find a command line option for ignoring line endings for WinMerge: http://manual.winmerge.org/Command_line.html, except maybe the /f option. But I couldn't find an easy way to implement that, and I'm not even sure if it will affect the AtmelSTART output.

Any ideas?
 

Winmerge options

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

There options in Git (git config) to change the way it handles commits and checkout so that it changes the EOLs for your local copy but then pushes "the other thing" back to the repo. Might be worth exploring.

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

clawson wrote:

There options in Git (git config) to change the way it handles commits and checkout so that it changes the EOLs for your local copy but then pushes "the other thing" back to the repo. Might be worth exploring.

Yes, I changed the git config to checkout with CRLF and commit with UNIX (code below if anyone else wants to do this), but the damage was already done, and it doesn't seem to change files that are already committed.

git config --global core.autocrlf true

(the options are "true" "false" and "input")

I guess I could try to delete the local copy of the repo and clone it again. I have not tried that yet.