So, I am trying to put together two (rather involved) functions that calculate the DAC. My processing routine for CalcDAC1 and CalcDAC2 are more or less the same, but with different variables. Currently, I'm using global variables that are directly called from the routine. I would like to use the same functionality but send it the variables I want the program to use to process so instead of:
global variables: unsigned int var1a; unsigned int var2a; unsigned int var3a; unsigned int var1b; unsigned int var2b; unsigned int var3b; void main(void) { while(1) { CalcDAC1(); CalcDAC2(); } } void CalcDAC1(void) { //Do stuff with var1a //Do stuff with var2a //Do stuff with var3a } Void CalcDAC2(void) { //Do stuff with var1b //Do stuff with var2b //Do stuff with var3b }
I instead would like to do
void main(void) { while(1) { CalcDAC(var1a, var2a, var3a); CalcDAC(var1b, var2b, var3b); } } void CalcDAC(unsigned char var1, unsigned char var2, unsigned char var3) { //Do stuff with var1 //Do stuff with var2 //Do stuff with var3 }
Unfortunately, my particular function has about 7-10 variables (complicated equation with lots of variables) so it requires me to create a LOT of local variables for each iteration, which I don't have the local space for (if that's the right term). Instead, I would like to send it pointers to local variables (if possible).
I ASSUME it would look something like this:
void main(void) { while(1) { CalcDAC(*var1a, *var2a, *var3a); CalcDAC(*var1b, *var2b, *var3b); } } void CalcDAC(unsigned char *var1, unsigned char *var2, unsigned char *var3) { //Do stuff with var1 //Do stuff with var2 //Do stuff with var3 }
Is this correct or is this even possible in C? Is this something you can only do in C++? Any help with implementation you can give me would be greatly appreciated. Thanks!
Because a vendor of PC tools can sell 100k+ licenses.
How many licenses do you think Keil get to sell of their embedded tools?
How much staff do you think they have to put on cosmetic tasks? How would that affect the already quite significant price?
I honestly have no idea of Keil's yearly license numbers, but if any of you had a ballpark idea of what the numbers were, I'd be interested in finding out.
http://www.keil.com/download/files/8051_market_in_2008.pdf
[ It was 2008. ]
The Development Tools: Problems in long term support of a given architecture usually happen when development tools become stale or are lost entirely. This happens when active support for devices dies away and is no longer kept up to date. Interest is lacking since many of the players have started in newer, more profitable and more exciting ventures. Engineers and tech support have often moved on to new jobs and their skills and knowledge move with them. Some firms rely on residual sales and do very little or no new development and few activities other than maintaining a website and a series of reps who sell other complementing products. But the 8051 market is still interesting and profitable for many players. For one, Keil continues with on-going support and product development. This is not likely to end soon. There are other companies that operate in the same fashion. Certainly, there are enough of them to sustain the 8051 tools industry. It can also be argued that there are more, better and cheaper development tools available today for the 8051 than in the first few years after its birth.
Compilers: Compilers are the key focus of any microcontroller tools chain. Compilers are first on the purchase list once the chip is selected and everything else follows. Nearly everybody has to buy a compiler. A few might purchase only an assembler and it is doubtful anyone hand codes assembly anymore. Other components such as in-circuit emulators and RTOSs are nice options, but not an absolute necessity. A premium compiler is important because of the limited resources of the 8051. Code size in particular is important because of the small amount of ROM available. Atmel has a few parts with only 2Kbytes and this can be a tight fit for any project. Banking schemes to increase memory size need to be fast, easy to implement and robust. A good compiler can help you get the appropriate code size and speed balance in your project. RTOS support is tricky because of the limited stack. Keil C51 excels in these aspects and is why it has become the de facto standard around the world. Many compiler companies see the 8051 as steady or very slowly increasing. Keil’s 8051 business is substantial and active development work is still being done. There are few (maybe no) bugs in the compiler but Keil engineers are kept busy installing new devices in their Device Database®. At the time of this writing, it is estimated to take a Keil engineer 3 to 4 days to enter all the new 8051 devices and companies from the last few months into the database ! Plus there are always a few companies changing 8051 components such as interrupts, data pointers and the way the stack is implemented. These changes must be accommodated for by the compiler. Other compiler companies claim to have great and increasing 8051 business but this is difficult to confirm accurately because of competitive secrecy. It is rather easy to make spurious marketing and sales claims.