Thursday, July 19, 2007

My personal tips about programming

These are some ad-hoc rules of thumb about programming. I'm sure they are not true all of the time. I'd like to hear if your experiences are different - or the same.

In no particular order:
  1. Keep it simple, stupid!
  2. Don't add code hooks for extension unless they are going to be used in this project and there is a definite need.
  3. Often getting something working quickly (call it prototyping if you like) can tell you how you should design something.
  4. When on a deadline, in a large project (longer than a week) doing the unknown stuff first will allow you to re-plan if something goes wrong and it's going to take longer than you think. This can apply even when you are not on a tight deadline if you want to finish the project.
  5. To avoid programmer block or programming avoidance, save something small and easy for the start of a programming session. Ideas are an easy bug fix or a simple class. It should only take a short amount of time and should get you going.
  6. On any project there will be interesting sections and boring sections. If you want to complete the project then you need to do both. Have a strategy to cope.
  7. For other people to use something, the end of the project involves getting a lot of non-design, non-programming stuff done. Everyone can't be a finisher and there will people who find this dull. But the project won't be done unless it's done.
  8. It's difficult (impossible?) to really measure maintainability. Sometimes you need to redesign things though - a good rule is when the module has been tested three times and it still doesn't work. Looking horrid is not unmaintainable.
  9. If it works then it's probably OK no matter how you dislike it. To finish a project you have to put up with a lot of non-ideal solutions. Nearly always there isn't the time to fix things that probably don't need fixing (because they work). In software success is almost always working product not 100% beautiful code.
  10. Hacking up a solution might be horrid and rot your soul but long development times will kill the project. That does more damage to your soul!
  11. Doing things quickly doesn't mean not trying to do things elegantly. Elegance is not complexity.
  12. You learn in design and programming by doing. Books are always good - but without doing you will not know and understand. Don't worry about having a horrid design or having horrid code - you learn from doing that as well.
  13. Learn to read others code. It's hard, perhaps harder than writing code. But you will learn a lot.
  14. Debugging is the art of spotting the symptoms and estimating where the bug might be. Evidence that falsifies that conclusion is better than evidence that collaborates it - even though it causes more work. Don't discard evidence without reason.
  15. Debugging teaches you something about how to design. Don't avoid it.
  16. Single-stepping code can be good at understanding what you have written and learning about how to write. Don't even be shy of it.
  17. There is more to debugging that using a debugger. Both skills are critical - inside the debugger and outside.
  18. Sometimes it's one bug. Sometimes it's more than one.
  19. If the symptoms you have can be explained by more than explanation, what you need to more evidence. Devise tests to find out which it is.
  20. The longer a document is, the less likely it is to be read.
  21. Good design documents are often written for yourself to clarify your thoughts, although they might be read by others who don't know the subject - including yourself at a later time.

LED driver design

This is about Light Emitting Diode (LED) driver function design. I guess this is quite an embedded article, but I think the design questions also are the types you ask in PC programs as well.

You might have the following functions to manipulation the LED:
void ledInit();
void flash_led(int number_of_times);
void led(bool state);

Whilst this is fine, you might instead code this up as a class:
class Led {
Led() { /* code to init direction to out for pin */ }
void on() { /* turn on LED code */ }
void off() { /* turn off LED code */ }
void set(bool state);
void flash();
};

And I guess there are several ways to structure that.

However, I now have more LEDs on different ports ... so what do I do? Seems like the ideal candidate for multiple instances of one class.

One option in procedural design is....

void ledInit(int led_number);
void flash_led(int led_number, int number_of_times);
void led(int led_number, bool state);

But that just looks plain wrong! Mostly because it's procedural I think... but also because those horrid selector parameters. Also how do the different functions know how to select the right led port?


if(led_number==0) { port = 23; }
else if(led_number==1) { port = 24; }
else if(led_number==2) { port = 24; }
else { /* break? */ }

In each one? There is probably a better way of course, even in procedural code.

So what's the best OO way? And I'm guessing there isn't one specific way... just what do you think are the good options?

Here are some ideas for those who don't know where to start...
  • Factory class (for instance production)
  • Template class (pass in port as template parameter? Or specific type?)
  • Write multiple sets of code
  • Use constructor to set up RAM variables that point to specific LED port.
  • static const LEDs objects in ROM/Flash

Saturday, July 14, 2007

Are Computers Fast Enough?

Occasionally this has been a topic of conversation. My answer is I don't think so.

Whilst most people I've talked to say most people just word process or surf the internet as the only things the do on a 'computer' and hence computers are fast enough.

I can think of several things that take too long today:
  • Putting home movies onto DVDs - can take a while,
  • Games - require both more CPU speed and more graphics speed, always. There are always limits on what you can do in terms of how it looks and how it plays.
  • Real world simulations - bit more specialised but a huge field where more processing is good.
  • Compiling computer programs - can take between a few seconds and a few hours (for larger programs) for a complete rebuild. Two seconds is too long! Because of increased program and language complexity we have 'lost' some of our speed gains. Additionally some program optimisations are probably not practical because of speed.
There are also more non-obvious things:
  • Robots (see below).
  • Other applications and programs we don't know about. Things like the web on the internet might not have been possible in the successful form we see today because, amongst other things, the computer speed of most peoples computer would not handle the processing required. The same is true of applications that are not viable today.
Robots. Computers are in things like Robots. The mechanics are not really a problem. Yes, there are scope for advances - but things like cars, digger trucks, robot arms, toys, even washing machines and dish washers, show us that we can move things around.So what's missing? Well, for a start the software. But that's sort of hiding one of the problems. Things like vision processing, without taking short cuts for simple problems, require vast amounts of calculation. Without lots of processing power in small packages this won't happen.

Both PC's and even more so embedded microcontrollers have a very limited amount of processing power - even though they tend to be, in the case of PC's at least, perhaps 1000 times more powerful than 20 years ago...

Simplifing slightly, PC computer speed is made up of:
  • Processing power ... raw CPU clock speed, CPU architecture and how many processors you have plus graphics card processing power - this is obviously a specialised processor for a specific job and there are other types of specialised processor.
  • Speed of memory ... this comes in two parts: main memory (RAM) - primary storage, and hard drive speed (secondary storage). I see quite a few applications that are limited by the second not the first!

Comments? What other current applications or tasks on computer aren't fast enough?
Newer›  ‹Older