Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won

  1. scompo

    Anyone building CMSIS under Linux?

    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.
  2. 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.
  3. 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).
  4. 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 problem, but I think your issue could be a similar alignment issue on the DSPLib you mentioned, do you have any code available for me to take a look at doragasu?
  5. 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 startup file to copy the data from FLASH to RAM with random values until the RAM_end_data address it's reached. I could (probably I am) be wrong but I hope this is the case..
  6. 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!
  7. 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 too, as you said it should be pretty much the same. The only difference it's that I don't use any optimization and the TI makefile uses O2 (If I can recall correctly), maybe it depends on that, it's just really strange mine it's smaller. I'll try building the same program with the TI files and see what's different. Btw I'm still investigating on the reason why the .data code doesn't get initialized right in some circumstances, any suggestion it's totally welcome
  8. 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.
  9. scompo

    ICDI support in OpenOCD

    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.
  10. 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.
  11. I don't know if I am an early adopter, I hope I am. I've got something here and here
  12. 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 scratch and license them with a BSD license. You can find my impressions here and the code in this github repository. Right now it doesn't support Stellarisware (It's basically the first working version) but I'm planning to add support for libraries in the Makefile as soon as I have time! I don't think it would be so difficult! Of course the sofware it's opened, so: every help, suggestion, bug issue it's welcome! I hope this would be useful in any way!
  13. scompo

    Very Basic HD44780 driver for Stellaris LaunchPad

    Wow, this is really nice!
  14. scompo

    ICDI support in OpenOCD

    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!
  15. scompo

    Stellaris gcc compile 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!