Howdy all, Recently I've been working on a Silicon Labs C8051F132 and am trying to implement a simple averaging filter using it. Unfortunately the time the cpu takes making the necessary calculations seems excessive, and enabling the on-chip arithmetic gains me no performance improvement. I was wondering if perhaps something else had to be initialized for the MAC to work. I am using the Keil Compiler, uVision 3, and checking the box under the device settings, and see it add MDU_F120 to the Compiler control string. Unfortunately during the chip's operation from debug mode I can't witness the MAC doing anything. Thank you for any insight you can give me. As I am new to this line of micro, the compiler, and all this stuff in general heh, please let me know if you need some more information. Thanks!
I'll give it a try. I've only had the team's insight to go by, and of course assumptions about the compiler can cause confusion. I'm sorry if anything I've believed to be true has been in err. My main concern was - the design team picked this CPU as a result of it having the capability of fast multiply and register shifting, and made the assumption that Keil would support these routines by default using their compiler. If Keil isn't working properly I hope to let them know, so it can be fixed in a future release. It's only a half hour of coding I suppose, but that one check box could save a lot of people a lot of time! As for Keil support.. This morning I received an email telling me that a solution to my problem is checking the box under the debug options for using the on chip arithmatic accelerator... duh! Thats whats not working lol. Well, hopefully round 2 is better. Thank you again to everyone for the ideas.
If Keil isn't working properly I hope to let them know, so it can be fixed in a future release. It's only a half hour of coding I suppose, but that one check box could save a lot of people a lot of time! Keil IS "working properly". The Keil toolset is a generic '51 toolset and the MAC is unique to the SILabs f12x and f13x series. Keil has some adaptations to some of the unique features in some chips. Lamblasting Keil for not supporting all features in all 5234 derivatives of the '51 is not reasonable. As for Keil support.. This morning I received an email telling me that a solution to my problem is checking the box under the debug options for using the on chip arithmatic accelerator... duh! Thats whats not working lol. Well, hopefully round 2 is better. not surprised. I called about watch of local variables showing up in C, but not in assembler. The answer was "to watch, you must open a watch window" Erik
Keil IS "working properly". The Keil toolset is a generic '51 toolset and the MAC is unique to the SILabs f12x and f13x series. Keil has some adaptations to some of the unique features in some chips. Lamblasting Keil for not supporting all features in all 5234 derivatives of the '51 is not reasonable. Again, I hadn't said there was in fact a true problem with the compiler - I first and foremost acknowledged my own ignorance might be to blame. Secondly I've tried contacting them for help, and have been unable to get any information about what those "some adaptations" might be. The compiler never under any situation I've been able to dream up invokes directives to use the MAC. Therfore it is my opinion that something might be amiss. Maybe an option somewhere, or a syntax in my code, or a true bug,,, who knows. In resolution to the problem, I've gone ahead and written my own routines to invoke the MAC for one of my functions. It reduced the time necessary for a multiple and divide by more than half. With some additional tweaking I can probably get that down even more as I dig into the assembly. The biggest problem will be having to treat the MAC like a peripheral complete with its own module and learning curve, instead of a performance enhancing behind the scenes feature that was hoped for - ie. Click check box, get speed boost :P I greatly appreciate everyone's responses and help!!! It is apparent the problem was a combination of mis-perception and assumption. Some people believe the compiler should do more for the user, some people think it does more than enough. The line has to be drawn somewhere I suppose and that's fair enough. Heh, now to go tackle some other "challenges" ;)
Some people believe the compiler should do more for the user, some people think it does more than enough. The line has to be drawn somewhere I suppose and that's fair enough This is not a question of whether the compiler should "do more for the user", but whether the compiler should adapt to whatever "exotic" feature some derivative might include. I suggest you try the Keil device database http://www.keil.com/dd/parm_search.asp and just enter '51, nothing else and you will see how many derivatives Keil must support with the '51 toolset.. Erik