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
-
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
-
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.
-
Great work! Too printf is this difficult to get to properly work :-P
-
Damn! I saw it today at HaD, too late! I hope I catch next
-
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
-
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...
-
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()...
-
Thanks for the tips. I have checked them, but unfortunately still found no solution to my problem
-
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,
-
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?
-
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!
-
I don't know how to help, but maybe the sources of this mod player can be useful.