Code simplification

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello.

I have completed my project. Things is running smoothly (with a few hickups).

Ok, before I get all sorts of we not going to do your degree, we have our own etc........this is NOT a subject that has something to do with microcontrollers or programming.Out of the whole class I am the only one that used the AVR that was willing to learn something on my own and move away from the HUGE(physical size not capabilities) 100x100mm 80C31 training board they gave us at Varsity(peace of junk in my opinion).

So, what I was going to say is; I would like to know if there is someone that has some free time, or someone that wants to help me expand my AVR, C knowledge that I can mail my Project to and that will have a look at it and see were I can better the code or if I could have done something else. Time is not critical as I am going to hand in my project tomorrow with the code I have generated.

This is only so that I can continue to learn more about the AVR when I tackle some other things I want to build for myself.

So, the project does the following:

It is an audiometer, consisting of an LCD, keypad via ADC, and PWM output with different frequencies(11 of them). I know the higher frequencies are very unstable due to the amount of values in the lookup table and sampling rate etc.

Also, I am controlling two relay outputs, indicator LEDs etc.

Also a "power saving mode" that isn't really a power saving mode, more a standby than power saving.Basically clearing the LCD, switching of the backlight and stopping the PWM.

So, if you are interested, pm me or post it here. I would like to eventually post the project under the project section if it will be able to help someone new to AVR one day.

Last Edited: Wed. Jun 11, 2008 - 11:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mtlost wrote:
100x100mm 80C51 training board they gave us at Varsity(peace of junk in my opinion).

8051 is much much cheaper than an AVR with the same no. of pins and some of the same facility. (UART + Watch Dog + SPI etc). I do not know of power saving modes of 8051 (i guess that there are none.) But for project sthat do not utilize 70% of AVR I would say go for 8051.

http://www.national.com/mpf/LM/L... is a single IC that can do a part of what you want to do.

Bharath Bhushan Lohray
M.Sc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry,I always do that, write 51 when I mean 31. AVR arn't expensive, well not on my scale of doing things. But its a single chip, the 80C31 has WAY to many extras and I don't like that at all.

I;m not sure what you mean the LM3914 is something I can use, its a bar graph display?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A LM3914 is very expensive, you can buy a mega88 for that. I think lord.loh thinks you made a simple VU meter :) (for which you need a LM3915).

You cannot use the UART and have SPI with a 8031. SPI is a UART mode.

What if you need the speed of an AVR?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sorry ... I did not know what an audiometer actually was. I thought it measured ambient sound. I now realise that it measures hearing loss. Forget the LM 3914.

8031 is not at all recommended. but the AT89S51 or AT89S52 might be used where an AVR is not justifiable. 8051/52 are the cheapest one that I can get. (Indian Rs 40) ATmega32 costs ~Rs 300 while ATmega88 can cost about ~Rs80 (1US$~ Indian Rs 42) AT Tiny is not available.

Bharath Bhushan Lohray
M.Sc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are a great number of 8051 single-chip variants. You just have to choose whichever suits your needs.

It is a little unfair to compare an 80C31 that require external memory. Your training board probably could execute from RAM, and have a fairly large user XRAM. This would have been very convenient some twenty years ago when it was designed.

I am sure that all AVR and mcs51 prices are negotiable if your quantities are large.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MTLost,

Congrats on getting your project done!

Sorry I can't help on optimizing your code, I don't know C...

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, if you show us the c code, you'll get lots of style comments.... there are about 3 popular indenting styles and everyone prefers the one they use. You can optimize the program for readablility, or modularity and reuseability. I'm of the opinion that most small programs can live in one c file. I know that once upon a time the 'software engineers' decided everything should be in a module, and a modula should be in a file, and a file should be 200 lines or less. That was then. This is now. I rescind this opinion when the program gets 2 other programmers, and grows to dozens of modules and gets to about 64k.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"POP!" - the sound of a can of worms being opened...

Learn assembly if you want tight code. You are at the mercy of the compiler then using Basic and C, and there are times when the "translation" is not so good.

Be one with the hardware!

Brad

No Fate But What We Make!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Learn assembly if you want tight code. You are at the mercy of the compiler then using Basic and C, and there are times when the "translation" is not so good.

Untrue. There are many things that can be done to improve optimization in C.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree - bad code in assembler can be slower and more bloated than good compiled C code. Garbage in - garbage out!

Brad

Koshchi wrote:
Quote:
Learn assembly if you want tight code. You are at the mercy of the compiler then using Basic and C, and there are times when the "translation" is not so good.

Untrue. There are many things that can be done to improve optimization in C.

No Fate But What We Make!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
"POP!" - the sound of a can of worms being opened...

Quote:

The worms crawl in, the worms crawl out,
The worms play pinochle on your snout.
...
The worms that crawl in are lean and thin
The worms that crawl out are fat and stout.

edited to remove some of the more graphic lines

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Well, if you show us the c code, you'll get lots of style comments.... there are about 3 popular indenting styles and everyone prefers the one they use. You can optimize the program for readablility, or modularity and reuseability. I'm of the opinion that most small programs can live in one c file. I know that once upon a time the 'software engineers' decided everything should be in a module, and a modula should be in a file, and a file should be 200 lines or less. That was then. This is now. I rescind this opinion when the program gets 2 other programmers, and grows to dozens of modules and gets to about 64k.

Whichever of the indenting styles you prefer, I would urge that you never use hardcoded tabs. One presumably indents, makes vertical columns & tables, ASCII art, and so on. as part of an effort to improve code readability. It's important, then, for what shows up in a reader's editor to match (as close as possible) the way YOUR editor presents it, and the ONLY way to ensure that (given the variety of editors/viewers) is to use nothing but single space characters as spaces (well, that and fixed-width fonts).

And there are other qualities that one can optimize for: size and/or speed, for example. You can also optimize for debuggability. This last criterion is seldom spoken of, but particularly when one is in a "learning" mode, I think it's useful to enhance your debugging tools' ability to show you, step-by-step, what your program does. Here's an example of a perfectly valid C expression that (IMHO) scores poorly on the "debuggability meter":

  if(  oneFunction(arg1, anotherFunction(arg2))
     > yetAnother(arg3)                         ) doSomething();

Caching the various return values in variables will very likely cost you nothing (the compiler does it anyway, and given that a lot of us use GCC here, may even help discourage GCC from generating extra 16-bit nonsense), but you'll have more opportunities, when debugging, to separate the actions of the routines concerned:

  aType firstTemp = anotherFunction(arg2);
  bType secondTmp = oneFunction(arg1, firstTemp);
  bType thirdTemp = yetAnother(arg3);

  if( secondTmp > thirdTemp ) {
     doSomething();
  }

Better still if you pick meaningful names for things. This is a contrived example, of course, but if you were to use a debugger (AStudio, say) on the second example code, you can chose to "step over" or "step into" the computation of the intermediate values that the "if" statement will deal with. You can see what those values are before you "step through" the "if". And, because the "doSomething()" is on a separate line, you've got a solid chance of putting a breakpoint on it that will be hit only when the "if" evaluates to "true".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

bobgardner wrote:
Well, if you show us the c code, you'll get lots of style comments....

Quote:

Whichever of the indenting styles you prefer, I would urge that you never use hardcoded tabs.

LOL. I'd vote the other way. 99+% of code is only read by the coder, in my experience. (I guess I could temper that a bit in a group environment, to agree to use a "style" acceptable to all.)

My big vote >>for<< tabs is based on the less keystrokes when editing. YMMV. I also like to keep my tab width small 1-4-7 so that C nesting doesn't get too far to the right and force a lot of screen-shifting and/or wrapping.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
99+% of code is only read by the coder, in my experience

Boy - how I wish that was MY experience too!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm--yeah, you've got the big projects/teams.

Maybe I'm just clouded by being a "team of one" for ~10 years. Looking back to past lives, much of that dev was "mine" as well. While there may be code reviews and the like no-one else would typically do much editing of the sources especially VAX & PC engineering and production "tools"--cross-compilers, simulators, and the like.

Even in big (for us) firmwares with a "large" team of up to half a dozen, the sections were pretty much divided. There were some common file templates and structure "rules" but each programmer would still have their own "style".

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

bobgardner wrote:
Well, if you show us the c code, you'll get lots of style comments....

Quote:

Whichever of the indenting styles you prefer, I would urge that you never use hardcoded tabs.

LOL. I'd vote the other way. 99+% of code is only read by the coder, in my experience. (I guess I could temper that a bit in a group environment, to agree to use a "style" acceptable to all.)

My big vote >>for<< tabs is based on the less keystrokes when editing. YMMV. I also like to keep my tab width small 1-4-7 so that C nesting doesn't get too far to the right and force a lot of screen-shifting and/or wrapping.

Lee


We're way down on the slippery slope here already, but most of the code editors I've used lately, and certainly the venerable "vi" ( my editor of choice ) have some sort of "new lines start at current indent level" feature. Even AStudio's editor does. This, coupled with the "increase indent/decrease indent" controls, pretty much eliminates the "too many keystrokes" objection. How much to indent is another matter of choice, and usually adjustable via some separate control.