Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


doragasu last won the day on January 31 2013

doragasu had the most liked content!

About doragasu

  • Rank
    Level 1

Contact Methods

  • Website URL

Profile Information

  • Gender
  1. Thanks for info. So VADD/VMUL take 1 cycle, but you have to load/store the operands... So unless these instructions can read operands and write results into SRAM without needing extra cycles, each operation will take more than 1 cycle (maybe 3 or 4, right?). In the past I have worked with some TI DSPs (like C55XX ones) that had a MAC instruction that could read two operands from RAM, multiply-accumulate them (and shift result, and do stuff with operand pointers) and write back the result to internal RAM in 1 cycle(*). I suppose this is not the case here _________ (*): Not reall
  2. I think the topic title is clear enough. Does anybody have info about the FPU performance of these Cortex-M4 chips? I have been googling for a while and can't find anything. It would be great to know the total MFLOPS achievable with these chips, or even better the MFLOPS/MHz.
  3. Great work! Too printf is this difficult to get to properly work :-P
  4. Great work! I suppose I should update my Linux tutorial for Tiva family, but I'm extremely busy ATM.
  5. Damn! I saw it today at HaD, too late! I hope I catch next
  6. I had a look to TI-RTOS and it looks really nice. A lot of useful stuff, (SYS/BIOS, FatFs, USB stack, TCP/IP stack) and everything using FOSS licenses. Really cool. Anyone using it in here? The problem I have with it, is that it is supposed to be used with Code Composer Studio. TI-RTOS package comes with all the components mentioned above, and also with a set of tools called XDCtools. XDCtools contain a lot of binaries and Eclipse plugins that are automatically integrated with CCS. These tools are mainly used to configure SYS/BIOS components and browse the status of objects (semaphores, ta
  7. I thought I solved the problem when I changed the toolchain to gcc-arm-embedded. The problem was minimized but it's not completely gone. Anyway, I have switched to sprintf + custom function for sending text through the UART...
  8. I assumed snprintf() would have the same memory corruption problem, but I have just tested it and it's working! Why would printf() corrupt the memory and snprintf() work? EDIT: debugged a bit more, and I have noticed sprintf() does not call _sbrk(), but printf() does. So there must be a problem with _sbrk()...
  9. Thanks for the tips. I have checked them, but unfortunately still found no solution to my problem
  10. I'm trying to get printf() to work in my newlib-based setup. I followed the instrutions here. I'm using the same code for syscalls, and almost the same linker script. Just added a ALIGN(8) directive before the heap label, and changed the way the stack is defined to a (at least for me) cleaner one. I have checked with both the debugger, and browsing the .map file that linker script works as expected, and if I build the test program in the tutorial, it behaves exactly the same, giving me exactly the same memory addresses and usage. But when I try to integrate it in a project I'm developing,
  11. The problem I had was not in the compilation steps, it was in the linking stage. What flags are you calling the linker with? Also are you linking with gcc or with ld?
  12. I'm using GNU tools for Stellaris development, but I don't use Windows. Anyway, it's really nice you took the effort to write a Windows+Cygwin tutorial. I'm sure some devvers will find it useful! Thanks!
  13. I don't know how to help, but maybe the sources of this mod player can be useful.
  14. Surprisingly enough, I have found the answer in Stellarisware documentation. This is written in chapter 28.1: Mistery solved!
  15. I think I'll use trial and error method. I'll post the results when I reach a conclusion.
  • Create New...