Jump to content

doragasu

Members
  • Content Count

    56
  • Joined

  • Last visited

  • Days Won

    1

doragasu last won the day on January 31 2013

doragasu had the most liked content!

About doragasu

  • Rank
    Level 1

Contact Methods

  • Website URL
    http://kernelhacks.blogspot.com

Profile Information

  • Gender
    Male
  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 really one cycle, it would take 5 cycles, but because of the pipeline you can count it as a 1 cycle instruction unless you are calculating latencies.
  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, tasks, etc). I could try building the libraries using GNU toolchain, but I don't know if they will be really useful if we are not able to use XDCtools. Could XDCtools be integrated Eclipse, the same way they are in CCS? Any Eclipse gurus here? And if XDCtools cannot be integrated in Eclipse, is it possible to use TI-RTOS without using XDCtools? (even if we lose the graphical configuration tools and the debugging tools).
  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, calling printf() somehow works: the text is written to the UART. But as a side effect, memory gets corrupted . I have tested _sbrk(), and it works perfect. This function is called twice, and each time it grows the heap the requested amount and returns the right pointer to allocated memory. I have even tried replacing the _write() stub with an empty one (just a "return len;" sentence), and it behaves the same: when I call printf(), memory gets corrupted. If I remove the printf() calls from my code, no memory corruption occurs. I have also tried increasing the stack up to 16 KiB without luck. I have been the last 3 days trying to debug this. I just can't make it work. Any suggestions? Could it be a bug in newlib?
  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...