scompo

I don't know if you already saw this but here this guy used CMSIS dsp library to build an audio analyzer. The code it's available here. Maybe you'll find this useful.

If I can recall correctly I think he's using the toolchain available here: https://launchpad.net/gcc-arm-embedded, I switched to that too, but I haven't tried building that. I've forked the work of mrnuke on the libopencm3 library, we're both implementing basic LM4F120xl support in it. It's still very basic. It looks promising, but still under development.

I've downloaded that and take a look at it and I've never used that before. It looks like in the cmsis/Device/ARM/ARMCM4/Source/GCC there are a linker script and a startup assembly file that should be ok to link in it I guess. the ld script uses ARM.edix and extab sections, other than libc specific sections. On github there's a test-newlib branch where mark roy has done a lot of work on integrating that into it, I'm still testing that out, but it's working somehow. You can find it here (the branch) and here (mroy's fork).

The issue wasn't really that, the linker script allocated memory correctly both in ram and flash, the problem was related to the alignment to a 1024 boundary but basically it was copying the .data initialized values from the end of text, with an aligned variable (vtable) the data was shifted because of that in memory so when it copied the values it just copied random stuff to the variables and the ram vector table (vtable). The solution I found was changing the order of the *(vtable) and *(.data.*) putting the .data before before the aligned ram vector. I don't know if this would solve your p

Quick update: I've noticed that when the startup file start copying the value of the initialized variables to ram there's a problem, I guess that's what's causing the program size to be smaller too. What I suppose it's happening it's that the linker script doesn't allocate enough space in flash to store the variables declared with the __attribute__ ((aligned(1024)) attribute in FLASH (the load address) for it but it does in RAM (reallocation address). I'm still not sure if that's the reason (more likely to be) or vice-versa but I'll check it as soon as I can. This causes the low level star

Thanks for the clarifications. I understand, so there isn't a workaround as it is, sorry to hear that, it shouldn't behave as it is, it gives unexpected results. I had no idea on how to write linker script too before writing this, I looked at the LD program manual and the sites mentioned here. I'll dig more into this!

Yes, I agree the problem should probably be in the LD script.. The strange thing it's that with the TimerIntRegister function the variable don't get initialized correctly. Instead using an interrupt assigned in the NVIC vector and just enabling it afterwards doesn't create any problem. A quick&easy fix would be just declaring the global variable and initialize it inside the main or whenever it's needed instead of declaring and assigning at the same time (it would just get set to 0 in the .bss segment), so it would probably work fine. The difference in the code size it's pretty strange t

Thanks for the catch. Yes, I've tried initializing a long before the main and it's not working. I'll look further into that and search for a solution.

Got it working. Really nice to use, great job and really useful! I've made a tutorial on how to build openocd and debug a simple code in gdb, if anyone it's interested it's here.

Wow, thanks, a lot! I cleaned up the makefile a little bit, fixed some warnings with the startup file and linker script and added support for stellarisware, just making the target in the directory tree. https://github.com/s...ad-template-gcc A lot of thanks to Wollw for his makefile wich is much cleaner than mine and helped me a lot. And I forgot to say that to load a bin file to the stellaris launchpad I used lm4tools so thanks a lot to them too! Also figured out a lot of changes to make it work better.

I don't know if I am an early adopter, I hope I am. I've got something here and here

Hi, I've never noticed that the license for the examples of the stellaris launchpad were closed, they say explicitly that: # Texas Instruments (TI) is supplying this software for use solely and # exclusively on TI’s microcontroller products. The software is owned by # TI and/or its suppliers, and is protected under applicable copyright # laws. You may not combine this software with “viral” open-source # software in order to form a larger program. I wasn't very comfortable with this and I finally decided to write the needed linker script, startup file and the useful Makefile from sc

Wow, this is really nice!

Very nice stuff! The Makefile of the first program didn't work on my system as it was, I just had to replace the "//" comments with "#" and got it building fine! The second had a problem with the makefile too but this issue tells how to solve it! Great work btw! It's really nice to program the stellaris launchpad on linux!

Thank you! Hope someone would find that useful. I haven't read that post before, good news! It will be nice and easy when he'll get the stellaris launchpad working!

Hi, I don't know if this is the right place to put this, if it isn't please let me know.. I've managed to get a working complier with the arm-none-eabi lite toolchain from codesourcery. Stellarisware examples are compiling just fine on linux. The right toolchain it's chosen automatically by the makedefs definitions. I've managed to get a simple project compiling on gcc and verified it runs correctly in a windows pc with the LMLoader program. Basically I created another folder in the boards directory, copied an existing example from the lm4f120x folder, edited the file names and chan