EETimes

Embedded Systems October 2000 Vol13_11

Issue link: http://dc.ee.ubm-us.com/i/71842

Contents of this Issue

Navigation

Page 178 of 181

• BREAK POINTS You'd be surprised how many embed- ded systems, those that are "done" and shipping, access memory in bizarre ways. Writing to ROM. Reading from unused memory. Though perhaps harmless, these odd behaviors indicate lurking software problems. Consider setting up unused/ extra chip selects to nigger on any errant memory access, or expand your PLD decode logic to signal such problems by means of an extra output. Code that behaves unexpectedly is flawed, even when the symptoms seem benign. Clean yoltr room. Bugs thrive in messy places. Performance and size Sometimes engineering costs lnoTe than f aster hardware. If you ' re build ing a mil- lion of something, production costs overwhelm development costs. That's much less true for small p.-oduction runs. Never forget that one of the "pro- duction " costs is that of the amor tized engineering. If a design decision adds a month to the proj ect, at perhaps a cost of $20,000, tllen tlle product' price must include this additional cost: $20,000 divided by the number of units made. Does an 8051 really make sense for your low-run application? Would a bigge r CPU d ramatically reduce development costs? Will shoe- horning bytes into an undersized code space eat weeks of expensive develop- ers' time? A tiny CPU is, without question, the perfect choice for a huge range of appl ications. You just can 't beat them for minimizing PCB real estate, recur- ring costs, and power consumption. And I've long been a proponent of dis- tributing small CPUs around a board to handle small chores li ke lIO pro- cessing. But do understand the very rea. 1 costs of working in a confined address space with perhaps under- powered tools and languages. Make CPU tradeoffs that minimize total sys- tem cost, from engi neering tllrough prod uction. Overload a CPU at your IJeril. A 90% loaded processor doubles deve lop- ment time. At 95%, figure on tripling tlle effort. This is hardly surprising to our intuitive understanding of pro- gramming. At one point or another, we've all battled a performance-bound system by tuning every bit of code it contains, instead of We 20% that is typically responsible for most of tlle real-time problems. Margins minimize engineering costs by allowing us to be a little sloppy. They let us deliver a product which is not quite tuned to perfec tion, avoiding the extreme costs that entails. Can CMX Really Put TCP/IP On My Little Ole . • ERTFS - EMBEDDED REAL TIME FILE SYSTEM Since 1987 in Hundreds of Applications Worldwide Selected as the File System for Several Major Embedded Operating Systems DOS/Win95/FAT32 Compatible Simple OS and CPU Porting Layer Contiguous File Support Realtime Extensions Includes Support for IDE, Floppy, ROM/RAM Disk, PCMClA, Compact Flash CDROM Support Available 100% 'C' Source Code· Royalty Free 'Oa 4.; $ J'oftwa~ TOLL FREE www.ertfs.com I 800 428-9340 Outside U.S. Call 9784489340 email: sales@ertfs.com 680 Worcester Road Framingham MA 01702 Ph: (508) 872-7675 Fax: (508) 620-6828 email: cmx@cmx.com WWW: www.cmx.com Embedded Systems Programming oaOBER 2000 175 Chip? Yes, Ma'am, CMX has been doing amazing th ings with . RTOSes and TCP/IP stacks for many years now. If you haven 't visited us in a while, you are missing a lot of cool, new technology that is economical, royalty free, and comes with

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11