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!
That code is in assembly though, while using Keil I am programming in C. The benefit of using Keil is supposed to be its ability to implement those routine calls to the Mac without me having to find a way to add assembly code by hand. At no time does the Keil compiler output directly in assembly that I have seen so far. It goes directly from C to a file I burn on the chip. I even spoke with our production group about somehow adding the correct assembly code in post-compilation, and they shook their heads and said there will be a better way, we can't do that. :shrug: Seeing as how Keil has the checkbox for implementing the Arithmetic unit, and has libraries that are designed to access the MAC listed on their site that would do assembly routines like the one posted - I'd think everything would be taken care of for me. Perhaps Keil has a bug or erroneous declaration of MAC support on SiLabs F13x line of chips. Perhaps it would be possible to write my own assembly routine that Keil calls from a C function. I'm still pretty new to the ins and outs of Keil, so if you could tell me how to modify the compiled code to manually add in those assembly routines I'd appreciate it.
"so if you could tell me how to modify the compiled code to manually add in those assembly routines I'd appreciate it" There's a whole section in the manual devoted to interfacing C and assembler. I do agree, though, that if Keil support use of the MAC direct from 'C' it would be worth persevering until you find out how to do it. In general the technical support is very good, don't give up!
the easy way would be to make a separate c module with just one non-optimized function: unsigned short MACmul (U16 val1, U16 val2) { return (val1 * val2) ) Then use the generated assembler ("At no time does the Keil compiler output directly in assembly" is incorrect) as a base for the assembly routine, just replace "the guts") Erik
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
"At no time does the Keil compiler output directly in assembly that I have seen so far." See it now: http://www.keil.com/support/man/docs/c51/c51_src.htm You could also enable the assembler listing in the Listing Options. "I even spoke with our production group about somehow adding the correct assembly code in post-compilation, and they shook their heads and said there will be a better way" Yes, they're definitely right on that one! "Perhaps it would be possible to write my own assembly routine that Keil calls from a C function." Easy - see: http://www.keil.com/support/man/docs/c51/c51_ap_ctoasm.htm
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
The MOD_F120 directive only applies to MUL and shift. See: http://www.keil.com/support/man/docs/c51/c51_mdu_f120.htm. Reason: the MAC is just a Multiply Accumulate Unit and does not support division. Reinhard
Well, the divison was happening as a necessity of the average filter. All the numbers were multiplied by a gain coefficient of 4096, and I was able to get divison via the shift function. A divide by 4096 is the same as left shifting the result until the significant bits filled the rounding registers. I don't have the code in front of me at the moment to explain it in much more detail, but that definately helped shave 20us or more off the overall filter operation. Aside from the division, the accumulates for the average filter is where I had hoped the MAC would improve performance the most. I had a loop that was something like: for(i=0;i<31;i++) { dm += buffer[i]; } result = dm/4096; So I was able to plug that (and a bunch of calibration code above and below it) into the MAC and decreased the processing time from 40us for calibration and filtering, down to about 10us running a 96mhz sysclk. I think some of the confusion was a result of the MAC unit not having a true 32 bit output, it only supports 16 bit output which prevents WORD * WORD operations - UNLESS you pull the data out of the Accumulate registers (and that doesn't seem to be a standard operation). So in the end I suppose its difficult to have a compiler optimize code for a MAC. That being said, what does "supporting the MAC" really mean? I still wasn't able to get any examples of when the compiler would utilize the MAC. The project has really taken off now and I can't find time to look into the situation further. The filter works, its now quick enough and I'm moving on :P Just had to code the MAC as a peripheral and not rely on the compiler so much. Again I appreciate all the help. Much of the problem has been my inexperience in the matter and trying to find the simplest solution.