Thread: Goodbye IFI?
View Single Post
  #34   Spotlight this post!  
Unread 25-06-2007, 14:39
steveg's Avatar
steveg steveg is offline
Livin' the Dream
AKA: Stephen Guerrera
no team
Team Role: Mentor
 
Join Date: Jan 2003
Rookie Year: 2003
Location: Boston, MA
Posts: 70
steveg is a splendid one to beholdsteveg is a splendid one to beholdsteveg is a splendid one to beholdsteveg is a splendid one to beholdsteveg is a splendid one to beholdsteveg is a splendid one to beholdsteveg is a splendid one to beholdsteveg is a splendid one to behold
Send a message via AIM to steveg
Re: Goodbye IFI?

Quote:
Originally Posted by Adam Y. View Post
The problem is that what you describe is a limitation of almost all of the embedded devices that compete with the PICs. Typically, programing techniques that won't cause problems on a computer will typically cause enormous problems in a microprocessor.
While that's true to some extent, I will say that you don't necessarily need an object-oriented language to implement an object-oriented design. C++ and Java do include many features that encourage this style of design, but using MPLab and C (less so in assembly for obvious reasons), it's certainly do-able to have a clear object-oriented style to you code.

The main features of object-oriented design are encapsulation and data abstraction. This means that all of your functions that deal with a common set of data are grouped together and that some variables and functions are meant to be accessed from the outside in order to provide an interface, while others are to remain hidden behind the scenes.

In C++ and Java, classes make it very simple to perform encapsulation, and likewise public, protected, and private keywords make it very easy to abstract your variables and functions.

With an embedded controller, you don't have the overhead for these niceties. Your data encapsulation is done by using "typedef structs" and just by breaking you program up into multiple files. Instead of accessing variables directly, you create functions which access them. You will need pointers. You also need to keep track which functions are part of your interface, and which are lower level.

Here's a decent code example illustrating some of the concepts I'm talking about, in case i'm not making much sense.

Also, just to throw this out there, from a complexity point of view, it's generally considered better to find an iterative solution to a problem rather than a recursive solution.
Reply With Quote