AVR Freaks

First of all, thank you all very much for the help.

Would you say that 5.4 is OK to use in production level code? I suppose since Atmel Studio 7 uses it, it ought to be fine since that is what we're using to build the project right now.

Yes indeed, I did find the Makefile in there, however, it contains a bunch of windows paths. That is what led me to suspect that there was some kind of bloating going on, surely this little application can't need all that stuff? But maybe it does. I'm by not means an expert on embedded development (yet  ).

So the way that the project directory looks right now in Windows is a folder called "LCD_init", a subfolder in there is called "Debug" and that's where I found the Makefile. I would like to replicate this folder system and compilation process on my Linux machine.

So for an example, if we just look at a random include like  -I"../src/ASF/sam0/utils/cmsis/saml21/source" . I assume that I can either take these files and move them to a different folder and then change the path, or do I need to create some kind of folder system that makes Linux find these applications where they are supposed to be? Suppose that I want them in a generic place so that they aren't tied just to this code, but that they can be used generally as in Atmel Studio 7 for any future code. Does the .tar.gz file automatically put things where they need to go? Where do I unzip it, in ~, in root? Or do I have to manually place each file where it needs to go?

It can't really be as easy as unzipping the tar file in my home directory, can it? (please Lord let it be that simple!)

I looked at the IDE and it seems exactly like the kind of annoying bloatware that I am trying to get rid of. I don't want to be negative Nancy over here but I really dislike it and would much rather figure out a workaround that allows me the control that I have through just working in a Linux terminal. Again, I don't want to be negative nor do I want to seem like I am dismissing your advice, but I am ready to go through some headache to get this working without an IDE. I love how clean it is to work in the terminal and how much in control I feel over the whole process. I also feel like it makes me a better programmer as I get a much better understanding of what I am doing instead of black-box engineering by pressing some magic button on an IDE.

Thank you!

Ah I see, I see. So theoretically I could compile and run everything without any of that stuff. Suppose, however, that I want to have access to it all, I assume that it is included in the toolchains for Linux?

I have a working knowledge of programming but I'm fairly new to embedded systems. I've only ever dabbled in it before :). Thanks for the vote of confidence though, haha.

Yes, sorry about that. However after a titanic amount of googling I kept ending up on these forums. Granted, the questions where about porting avr-gcc to Linux but my assumption is that it shouldn't be much different from porting arm-gcc as really the only thing that is different is the compiler. The "process" of porting to Linux ought to be similar, or am I wrong? My logic is that really what it comes down to is moving a makefile, making sure that it works and then making sure that a bunch of dependencies that are used in the compilation process exist on the system.

Ah I see, now I get it. Thank you! 

Well right now my job IS to set up a custom build system - I was handed this project by my boss. We already compile everything else through makefiles. This is a small booting application that is needed to start our LCD screen - we would like to be able to compile it through the terminal like we do with everything else. The goal is then to add it to the shell script that compiles the entire system so that we won't need to do two different manual compilations. 

At any rate, I went ahead and installed the bloatware for now. I can use it and lift the makefile straight out of the IDE and get it working that way, I suppose. However, when I built my HEX file and flashed it to memory it actually killed the device. I had to hardware-reset everything back to zero. Opening up the hex files I noticed some immediate differences:

Correct

:10610000A8250020D97B0000D57B0000D57B0000AE :10611000000000000000000000000000000000007F

Incorrect

:10000000A8250020D1180000CD180000CD18000050 :1000100000000000000000000000000000000000E0

I suppose maybe I should compile the assembly file and see what the heck is going on, but I'm not sure how to do that in Atmel Studio 7 or MPLABX - yet another reason for why I hate IDEs :(. 

Nevermind, I was able to solve the issue. Now I will extract the Makefile and see about compiling manually.

Compiled in Atmel Studio 7:

Disassembly of section .text:

00006100 <exception_table>:
    6100:	a8 25 00 20 d9 7b 00 00 d5 7b 00 00 d5 7b 00 00     .%. .{...{...{..
	...
    612c:	d5 7b 00 00 00 00 00 00 00 00 00 00 d5 7b 00 00     .{...........{..
    613c:	25 81 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     %....{...{...{..
    614c:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     .{...{...{...{..
    615c:	d5 7b 00 00 65 78 00 00 75 78 00 00 85 78 00 00     .{..ex..ux...x..
    616c:	95 78 00 00 a5 78 00 00 b5 78 00 00 d5 7b 00 00     .x...x...x...{..
    617c:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     .{...{...{...{..
	...
    6194:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 d5 7b 00 00     .{...{...{...{..
    61a4:	d5 7b 00 00 d5 7b 00 00 d5 7b 00 00 00 00 00 00     .{...{...{......

Compiled in MPLABX:

Disassembly of section .text:

00006100 <_sfixed>:
    6100:	200025a8 	.word	0x200025a8
    6104:	00007c25 	.word	0x00007c25
    6108:	00007c21 	.word	0x00007c21
    610c:	00007c21 	.word	0x00007c21
	...
    612c:	00007c21 	.word	0x00007c21
	...
    6138:	00007c21 	.word	0x00007c21
    613c:	00008179 	.word	0x00008179
    6140:	00007c21 	.word	0x00007c21
    6144:	00007c21 	.word	0x00007c21
    6148:	00007c21 	.word	0x00007c21
    614c:	00007c21 	.word	0x00007c21
    6150:	00007c21 	.word	0x00007c21
    6154:	00007c21 	.word	0x00007c21
    6158:	00007c21 	.word	0x00007c21
    615c:	00007c21 	.word	0x00007c21
    6160:	00007921 	.word	0x00007921
    6164:	00007931 	.word	0x00007931
    6168:	00007941 	.word	0x00007941
    616c:	00007951 	.word	0x00007951
    6170:	00007961 	.word	0x00007961
    6174:	00007971 	.word	0x00007971
    6178:	00007c21 	.word	0x00007c21
    617c:	00007c21 	.word	0x00007c21
    6180:	00007c21 	.word	0x00007c21
    6184:	00007c21 	.word	0x00007c21
    6188:	00007c21 	.word	0x00007c21
	...
    6194:	00007c21 	.word	0x00007c21
    6198:	00007c21 	.word	0x00007c21
    619c:	00007c21 	.word	0x00007c21
    61a0:	00007c21 	.word	0x00007c21
    61a4:	00007c21 	.word	0x00007c21
    61a8:	00007c21 	.word	0x00007c21
    61ac:	00007c21 	.word	0x00007c21
    61b0:	00000000 	.word	0x00000000

Why are they different?! I've checked all the options they are the same, the compiler versions are identical. What the heck is going on!? The MPLABX code does NOT work.

The functions seem to be doing the same thing but mapped to different points in memory, the MPLABX file is about 1kB larger than the Atmel Studio file for some mysterious reason.

Atmel Studio:

void cpu_irq_enter_critical(void)
{
	if (cpu_irq_critical_section_counter == 0) {
    78c4:	4b0c      	ldr	r3, [pc, #48]	; (78f8 <cpu_irq_enter_critical+0x34>)
    78c6:	681b      	ldr	r3, [r3, #0]
    78c8:	2b00      	cmp	r3, #0
    78ca:	d106      	bne.n	78da <cpu_irq_enter_critical+0x16>
 */

MPLABX:

void cpu_irq_enter_critical(void)
{
	if (cpu_irq_critical_section_counter == 0) {
    6268:	4b0c      	ldr	r3, [pc, #48]	; (629c <cpu_irq_enter_critical+0x34>)
    626a:	681b      	ldr	r3, [r3, #0]
    626c:	2b00      	cmp	r3, #0
    626e:	d106      	bne.n	627e <cpu_irq_enter_critical+0x16>
 */