Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 118 of 181

JOSEPH LEMIEUX Abstracting System Hardware for Maximum Reuse Abstracting hardware is difficult at times, but necessary. If you do it right, the resulting software will be much easier to rellse. here are many reasons to adopt hardware abstraction. The fo remost is to enable code reuse. The tenn code reuse has been defined in many cIilfe l~ ent ways throughout industry, from code that i bon-owed and slightly modi.tied for each project, to Libraries of features that are released as object code and linked togetller during development For the purpose or t11is article, code reuse will be defined as any code, eitller at a source level or in library foml, that is reused completely, witll only changes in the definition of con- stants in a header. Abstrdction that requires ['unctions to be written or macros to be defined that change executable code is considered "borrowed" and not "reused." Another justification fo r hardware abstraction is maintainabili ty of the appli- cation code. If a standard method of accessing hardware exists, all software engi- neers in a department can maintain the code. When hardware changes, the abstraction changes in one locatio n, not in eve ry source code module. For exam- pl e, changing the port fo r a digiuLi input from Port 1 to Port 2 would require a change in the constant fed to the I/O layer, and each module will then benefi t from thi s change afte r linking. Finally, quali ty of the end product increases. By reusing code and absu~acting hardware, ule number of new or modified lines of code is reduced for each pro- j ect. Since the probability of creating a defect increases with ule number of lines of code written, by reducing this number, the number of defects will also decrease. This article describes ulree methods of abstracting hardware from software applications. The first method, which I call the f unction name method, is a direct I/O access method using a different fun ction for each input and output. This Embedded Systems Programming OCTOBER 2000 117

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11