Embedded Systems November 2000 Vol13_12

Issue link:

Contents of this Issue


Page 97 of 189

ili ;:;: a' 0 0 LlmNG 1 I• File name: _vcr.h •I I• Private attributes •I typedef struct { tMode mode; tButton play_button; tButton stop_button; } _cVCR I• Private methods •I boolean _cVC~et_tape_present(void>; I• returns true if tape is in the VCR •I I• File name: vcr.h •I #include _vcr.h I• Public methods •I void cVCR_constructor(void); void cVCR_play(void); void cVCR_stop(void); void cVCR_set_time(void); void cVCR_eject_tape(void); I• define TAPE_pRESENT register #define TAPE_PRESENT Ox04 I• File name: vcr.c •I #include vcr.h I* Declare object •I _VCR _oVCR; I• Private method implementations (a couple of examples) •I static boolean c_VCR_get_tape_present(void); { if(TAPE_PRESENT) { return true; } else { return false; } } void cVCR_play(void) { _VCR.mode = playing; } 96 NOVEMBER 2000 Embedded Systems Programming I• Check tape present register •I I• Playing or Stopped *' tainly ways of getting around thi s (for example, passing a pointer to th e object to be manipulated ) . But again, this involves a lot of pointers. After a lengthy discussion, the team decided that thi s situation would be acce ptabl e for th e Gruntmas te r 's impleme ntation. Lessons learned Overall , using an object-oriented approach worked well. It provided an excellent framework for the design to be created, but the proj ect certainly wasn 't flawless. Performing an object- oriented analysis and design can be a complex process. Implementing that design in C adds even more complexi- ty. That, combined with the team's inexperience with 00, yielded several "lessons learn ed" (including what worked and what didn' t) . These lessons are shared here to hopefully prevent fumre teams from repeating them: • Be careful that the object-oriented design doesn 't turn into a struc- mred design. This can happen i f the team does not have a strong background in object technology • Write the coding standard before design begins. This will help poin t out limi tations in the implementa- tion that may affect the design, such as not having inhe1itan ce. It also ensures that a consistent nam- ing style exists between UML dia- grams and code • Write a UML diagramming stan- dard . At first this may not seem nec- essary when using the Unified Modeling Language, but it is. UML does not address all of the issues facing embedded developers. The most frequent example of this that the Zeppelin team ran into was how to model ROM-only tabl es. Tables are a common construct in embedded systems, but UML does- n't readily support their modeling. It would have saved the Zeppelin team time to have decided how to model tabl es, and capture that in a

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12