From jwbruce at ece.msstate.edu Thu Oct 2 13:03:57 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Thu Oct 2 13:04:07 2008 Subject: [ece4723] pic24 tools on linux vs. windows In-Reply-To: <24958342.49361222970495090.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <4224118.49381222970637349.JavaMail.root@zimbra.ece.msstate.edu> Embedded Systems dudes -- FYI: I have been building linux versions of the Microchip tools for the PIC24 from open-source code tree that Microchip released. I have not gone to linux exclusively because the linux tools crash. 6-8 weeks ago, I discovered that the linux toolchain would seg-fault on several, but not all, of the code examples from the new PIC24 textbook. These examples are far simpler than ESOS. However, the exact same version of the tools would compile successfully on windows using the exact same code, headers, and optimizations. So, I propositioned to the open-source microchip forum that something was amiss. I conjectured that there are two options: #1) the code tree released to the open-source community by Microchip was not the same tree they are using to build their proprietary product, and/or #2) Microsoft's compiler (used to build the windows pic24 tools) behaves differently than gcc, which I used to compile the linux version of the pic24 tools. Well, an adventurous forum member has investigated. See his email below. We still don't know which of the two options above is true. But, it makes you wonder: * did Microchip release different code, or * does the Microsoft libraries over-malloc() memory for strings compared to gcc? If the latter, then this is crash waiting to happen in the windows tools? Have a good Fall break. JWB ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298 ----- Forwarded Message ----- From: "Joseph Julicher" To: gnupic@linuxhacker.org Sent: Monday, September 29, 2008 2:23:25 AM GMT -06:00 US/Canada Central Subject: RE: [gnupic] Debian Template/Patches for C30 v3.10 i386 I have passed this on to the C30 team. Joseph Julicher Applications Manager Microchip Technology, Inc. -----Original Message----- From: Hiep DOAN [mailto:mail@falleaf.net] Sent: Sunday, September 28, 2008 11:55 PM To: Xiaofan Chen Cc: gnupic@linuxhacker.org Subject: Re: [gnupic] Debian Template/Patches for C30 v3.10 i386 There are an seg-fault in strcpy(). There are 6 places in the sourcecode they use this function without checking the string length of the source and destination. We can correct it, but we should notice Microchip officially before announce to the community. Thanks. 2008/8/1 Xiaofan Chen > On Thu, Jun 19, 2008 at 4:17 PM, dennis_amonics > wrote: > > > > Hi Xiaofan and Hiep, > > Sorry for the late reply. I only tested this today. > > > I am trying to make the .deb files using your modified patches. However, > > I've found the following problems: > > > > 1) When I build the package pic30-binutils_3.10-1_i386.deb, using the > > download source mplabalc30_v3_10.tar.gz, an unpacking error was > generated. > > It turns out there is a missing underscore in the "rule" file: > > binutils=mplabalc30v3_10. After changing the filename as > mplabalc30_v3_10, > > the problem is solved. > > > > Same here. And the resultant debian package did not work. It caused > seg-fault. > > > 2) Then I continue to build the package pic30-gcc_3.10-1_i386.deb, using > the > > download source mplabc30_v3_10.tar.gz, an unpacking error was generated. > > This time, I cannot determine where the problem is. The error message is > as > > follows: > > Same error here under Ubuntu 6.06. > > I've also received debian package from Hiep Doan. Both caused seg-fault > under Ubuntu 8.04. > > Xiaofan > -- DOAN Hiep Vice Director R&P Trading and Forwarding Co. Ltd. 58/48 Nguyen Minh Hoang - Ward 12 - District Tan Binh Hochiminh city - 70000 - VIETNAM Office VN: +84 8 8119870 - Mobile KR: +82 10 2079 1635 - Mobile VN: +84 936 316 326 www.rpc.vn - www.falleaf.net --------------------------------------------------------------------- To unsubscribe, e-mail: gnupic-unsubscribe@linuxhacker.org For additional commands, e-mail: gnupic-help@linuxhacker.org From pmw36 at msstate.edu Fri Oct 3 14:55:40 2008 From: pmw36 at msstate.edu (Michael Weir) Date: Fri Oct 3 14:55:53 2008 Subject: [ece4723] Lab 5- Testing Message-ID: I currently have one (and only one) board that generate the signals for testing Lab 5. I would advise that you make an appointment before my lab hours on Friday to test and demo your code. I will be available during normal lab hours Monday and Tuesday, Wednesday Night, Thursday Afternoon and Friday during my lab hours. A few groups will probably wait till my lab hours on Friday. This everyone's code is perfect and there is everyone gets the checkoff or a couple groups do not get enough time to thoroughly debug and miss it. Michael Weir From pmw36 at msstate.edu Sun Oct 5 19:11:06 2008 From: pmw36 at msstate.edu (Michael Weir) Date: Sun Oct 5 19:11:22 2008 Subject: [ece4723] PVM Message-ID: In answer to the question below, you are required to have python/pc code for both the checkoff and submission for lab 5. Ideally this would have meant supplementing your python code from lab 4. However since you did not do lab 4, I would look ahead and create a solid code base for the requirements of the future labs. The python code is responsible for parsing user input (key commands), communicating with the MCU via the serial port, and converting the values returned from the MCU to correct weather data. Also, an unrelated question: Thomas and I have been reading and parsing the language in the Task 5 spec, and can't seem to agree: are we required to have any python/pc code? Or do we just need MCU code to take the readings, and respond to key-presses in RealTerm? (That question goes for both checkoff and submission). Thanks! -Jeff From jwbruce at ece.msstate.edu Tue Oct 7 11:30:56 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Oct 7 11:31:09 2008 Subject: [ece4723] Fwd: The Embedded Muse 166 In-Reply-To: Message-ID: <28981622.62071223397056131.JavaMail.root@zimbra.ece.msstate.edu> The latest newsletter from Jack. ----- Forwarded Message ----- From: jack@ganssle.com To: jwbruce@ece.msstate.edu Sent: Monday, October 6, 2008 11:05:39 PM GMT -05:00 US/Canada Eastern Subject: The Embedded Muse 166 -------------------------------------------------------------- Embedded Muse 166 Copyright 2008 TGG October 6, 2008 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. Subscribe and unsubscribe info is at the end of this email. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Editor's Notes - Comm Monitors - Book Review - Coders Vs Programmers - Jobs! - Joke for the Week - About The Embedded Muse **************************************************************** This issue of The Embedded Muse is sponsored by Netrino. Calling all embedded C programmers! Test your skills in the online Embedded C Quiz. In less than ten minutes, see how you measure up. No matter your score, you'll be automatically registered to win one of three colorful new iPod Nanos to be given away this month. Start at http://www.netrino.com/Embedded-Systems/Embedded-C-Quiz-Muse **************************************************************** Editor's Notes -------------- Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it's not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/classes.htm . switch(city){ case San Jose: case Phoenix: case Austin: Are you in the San Jose, Phoenix or Austin areas? I'll present a public version of the Better Firmware Faster class in San Jose on December 8, Phoenix on December 10 and Austin on December 12. Registration and other info here: http://www.ganssle.com/classes.htm . You'll earn 0.7 Continuing Education Units, learn a lot, and have more than a little fun. Sign up before November 8 and receive a $50.00 discount. } Emmett Kyle sent a link to this page: http://klabs.org/history/build_agc/ . If you've ever wanted to build your own Block I Apollo Guidance Computer, you've GOT to check this out! Comm Monitors ------------- Dale Botkin contributed yet another approach to monitoring comm links: "There's a much simpler and far less expensive solution. I have yet to find a PC that actually requires EIA-232 voltage levels to operate; in fact, if you review the data sheets for line receivers back as far as the venerable 1489, you will find that none of the ones in general use require a negative voltage. For reasonable cable lengths and environments, a simple inverter will do the job quite nicely. http://www.botkin.org/dale/rs232_interface.htm This is a circuit I've used in production for several years now with no issues talking to a wide range of PCs, laptops and other serial devices." Book Review ----------- This week I had the pleasure of reading John Davies' new book "MSP430 Microcontroller Basics." It's a 668 page course in embedded systems, using the MSP430 as an example platform. It's also a great reference to the MSP430, whether you're a novice or a gray-beard who needs to know more about that part. The MSP430 from TI is a 16 bit RISC-like microcontroller that sports extremely low-power modes and a nice mix of on-board memory and peripherals. TI offers some cool low-cost development platforms. Once a stealth part, it has garnered great market share. Unlike some books that jump all around, or others that dive right into deep technical discussions, this book starts with a high level view of the MSP430 itself. From there it moves into an introduction to embedded systems, one that's aimed at college CS or EE majors just getting exposed to the whacky world of embedded. That does not mean it's a textbook; far from it as the material is very accessible and the writing lively and engaging. Just the sort of thing I wish textbooks were, and I could see this being used in a hands-on college course. An intro to embedded? Yawn, right? No, stay with me. John shows aspiring developers how to write a simple C program to turn an LED on, first in C and then in assembly. These are complete tiny apps that will compile/assemble. He describes the intent of each line, and couples that description to the hardware design. He then reframes the assembly into relocatable code and shows what that is all about. An intro to embedded C and assembly? Double yawn. Nope - hang in there. Using the same careful explanations he grows the discussion to use buttons, timers instead of delay loops, and much more. The lessons are complete, detailed, and clear. Then the good stuff starts for working MSP430 engineers. He describes in clear detail with code and hardware designs the use of the MSP430 and its peripherals. Need to run the SPI in a particular mode? The code is there. Want to get interrupts up? Just copy the listings (there's no CD but he does provide a web link to the code). He keeps drilling deeper, giving more complex examples that are all directly useable by any MSP430 developer. Oscilloscope traces, where applicable, ground the discussion into the physical effects we engineers need. The MSP430 does have analog I/O, and John doesn't neglect that. He talks about aliasing, signal/noise ratio issues, and handling the A/Ds. Yep - the math is there, too, not complicated at all, but essential to working with analog. A CS person or novice EE would learn a lot about electronic circuits from this material. Unusually, this book is both a great introduction to embedded systems for the novice, as well as an incredibly-useful reference for experienced developers. Highly recommended. The folks at Newnes Press have offered Muse readers a 20% discount good till the end of the year - go to www.newnespress.com and use discount code 93682. Coders Vs Programmers --------------------- I get ticked off whenever a manager uses the word "coder". Unless, of course, he or she is referring to a peon who does nothing but crank code. Historically "coder" means someone who translates a very detailed design to C, C++ or whatever language is used. In the old IBM "chief programmer" days coders were an important part of the development team, but were at the bottom of the pyramid. It was assumed these folks were trainees or had little expertise, so they slaved at more or less rote translation activities. Coders were analogous to draftsmen, those skilled technicians who render engineering concepts into the important but dull drawings needed to actually build something. Let's face it: it's not hard to write code. Even teenaged hackers manage to build simple systems. UML advocates often demonstrate that the machine itself can write the code from a sufficiently-detailed design. The challenge we engineers face is designing a solution to a particular problem. I believe the real fun is in inventing the solutions, not in the dreary coding process. For me the most exciting and creative part of a project is doing the rough system design, figuring out what should be done in hardware and what in the firmware, and then blocking out the overall approach. But the only complete design spec tends to be the code. There are a hundred little decisions we make as we type in C statements, from oddball exception handling to what happens if some really weird combination of inputs happens. What happens if the user presses all three buttons, belches and kicks the machine? In my experience virtually no design document captures every essence of what the program will really do. In the embedded world there are few true coders. We're highly trained engineers who code and design together, or who create the structure and then implement it in firmware. Perhaps we'd be more efficient if we did separate designers and coders, but this seems unlikely to happen. It's certainly valuable to keep ones hands in the dirty business of actually making the system and getting it to work. The crucible of making things work always teaches us a lot about the limits of what we can actually build. The "coders" word is usually used by managers who view software as a necessary evil, rather than a critical part of the value delivered to the customer. That attitude dooms projects and frustrates the staff. Desktop developers embrace "programmer" as a job description. Perhaps that adequately captures the limited range of skills needed to crank out a Windows app. Me, I prefer "engineer", a moniker that better describes the breath of experience needed for embedded systems, where hardware and software seamlessly blend together to yield a product. Jobs! ----- Let me know if you're hiring firmware or embedded designers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words. Netrino has multiple open positions for embedded software developers and FPGA and board-level electronics designers, in Maryland and California. Join the Embedded Systems Experts(tm) in a fun work environment that offers challenge and variety. Learn more at http://www.netrino.com/Embedded-Systems/Jobs-Muse . St. Jude Medical: Atrial Fibrillation Division Epicor Product. We're looking for a Lead Software Engineer to develop embedded firmware for new and existing commercial medical devices. We offer a small, flexible engineering environment with an exciting opportunity to architect and design new code from the ground up on a next generation platform. The ideal candidate would have expertise in developing embedded C/C++ code (requirements development, design, coding, hardware integration and test) in a regulated environment. Desired Skills/Experience: * B.S. degree or equivalent experience * 5+ years work related experience * Experience with embedded C/C++ software development * Real Time Embedded operating systems concepts and low level programming * Experience developing in regulated environments (medical, aerospace, etc.) * Knowledge of embedded digital hardware architectures Please contact tciciarelli@sjm.com. Terumo Cardiovascular Systems is hiring a Senior Embedded Hardware Engineer. This position is responsible for the development of a blood parameter monitoring system used in cardiovascular surgery. This is a lead designer position for a custom analog/digital design on a team of experienced engineers from multiple disciplines included Mechanical, Software and Systems Engineering. It typically requires a four-year degree, PhD strongly preferred (not required), coupled with at least 8 years experience in an engineering environment developing, designing and specifying products. Terumo Cardiovascular Systems is a medical device manufacturer specializing in the design, production, marketing and service of life-sustaining cardiovascular equipment and disposables. www.terumo-cvs.com Joke for the Week ----------------- Brian Souter sent this: I don't know if you follow the scientific journals and news or not. But lately there has been talk about how they are generating light pulses who's length is measured in 'attoseconds'. So how long is an attosecond? It is 1/1000 of a femtosecond. How long is a femtosecond? A femtosecond is one millionth of one billioth of a second. Or in scientific notation, a femtosecond is 1*10^-15 (1E-15), and thus, an attosecond is 1*10^-18 (1E-18). Or for short (pardon the pun), an attosecond is an insignificant amount of time. Does this mean when your boss gives you an attoboy, they are giving you an insignificant amount of praise? About The Embedded Muse ----------------------- The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. -- If you do not want to receive any more newsletters, http://www.jackganssle.com/lists/?p=unsubscribe&uid=e054cf7788a17a7ea25d9054032f2c06 To update your preferences and to unsubscribe visit http://www.jackganssle.com/lists/?p=preferences&uid=e054cf7788a17a7ea25d9054032f2c06 Forward a Message to Someone http://www.jackganssle.com/lists/?p=forward&uid=e054cf7788a17a7ea25d9054032f2c06&mid=36 -- Powered by PHPlist, www.phplist.com -- From jwbruce at ece.msstate.edu Tue Oct 7 11:32:59 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Oct 7 11:33:08 2008 Subject: [ece4723] Fwd: Christopher Lakey - M.S. Thesis Defense - 10/13/2008 - 3:00 PM - HPC room A250 - HIERARCHICAL GEOGRAPHICAL IDENTIFIERS AS AN INDEXING TECHNIQUE FOR GEOGRAPHIC INFORMATION RETRIEVAL In-Reply-To: <10cd4e640810061412w799c8e80g42966001788448a2@mail.gmail.com> Message-ID: <22918365.62101223397179868.JavaMail.root@zimbra.ece.msstate.edu> FYI. ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298 ----- Forwarded Message ----- From: "Christopher Lakey" To: faculty@ece.msstate.edu, grads@ece.msstate.edu Sent: Monday, October 6, 2008 5:12:24 PM GMT -05:00 US/Canada Eastern Subject: Christopher Lakey - M.S. Thesis Defense - 10/13/2008 - 3:00 PM - HPC room A250 - HIERARCHICAL GEOGRAPHICAL IDENTIFIERS AS AN INDEXING TECHNIQUE FOR GEOGRAPHIC INFORMATION RETRIEVAL TITLE:?HIERARCHICAL GEOGRAPHICAL IDENTIFIERS AS AN INDEXING TECHNIQUE FOR GEOGRAPHIC INFORMATION RETRIEVAL WHO: Christopher Lakey ?? ? Candidate, Master of Science, Computer Engineering WHAT: M.S. Thesis Defense WHERE: HPC room A250 WHEN: 3PM, Monday, 13 October 2008 ABSTRACT: Location plays an ever increasing role in modern web-based applications. Many of these applications leverage off-the-shelf search engine technology to provide interactive access to large collections of data. Unfortunately, these commodity search engines do not provide special support for location-based indexing and retrieval. Many applications overcome this constraint by applying geographic bounding boxes in conjunction with range queries. We propose an alternative technique based on geographic identifiers and suggest it will yield faster query evaluation and provide higher search accuracy. Our experiment compared the two approaches by executing thousands of unique queries on a dataset with 1.8 million records. Based on the quantitative results obtained, our technique yielded drastic performance improvements in both query execution time and accuracy. _______________________________________________ Faculty mailing list Faculty@ece.msstate.edu http://www.ece.msstate.edu/mailman/listinfo/faculty From pmw36 at msstate.edu Fri Oct 10 14:11:47 2008 From: pmw36 at msstate.edu (Michael Weir) Date: Fri Oct 10 14:11:55 2008 Subject: [ece4723] Lab Checkoff Message-ID: The lab 3 checkoff is due next week during lab. Currently I still only have one weather board for the checkoff. Ideally the code should be done and during this time groups just demonstrate its functionality. However, only a couple of groups have begun testing their board against the weather board. Therefore, the one weather board will limit the amount of time groups have to debug their device against the simulated weather conditions. The checkoff and deliverables will be due at the end of lab. I am willing to come on Monday from 12 - 3. Email me by Sunday to let me know if I should come. I would highly recommend that any group that has not done at least initial testing against the weather board take advantage of this opportunity. Michael Weir From jwbruce at ece.msstate.edu Tue Oct 14 08:24:44 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Oct 14 08:24:48 2008 Subject: [ece4723] new ESOS snapshot Message-ID: <3200034.107951223990684884.JavaMail.root@zimbra.ece.msstate.edu> The ECE3724 .zip archive contains a new snapshot of the ESOS tree. The new version contains a couple of bugfixes, redefined semaphores that are "extern"-friendly, and a more compact I2C library. You should start using this rev of ESOS as soon as possible. Your user code should not change at all. Just recompile with the new tree. These changes were identified and requested by y'all. Thanks for making ESOS better. jwb ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298 From pmw36 at msstate.edu Thu Oct 23 06:51:29 2008 From: pmw36 at msstate.edu (Michael Weir) Date: Thu Oct 23 06:51:37 2008 Subject: [ece4723] Lab7 Bonus Message-ID: The bare minimuim bonus will be 15 out of the 200 points for lab 7. However, there is no maximum number of points. Efforts that go beyond the minimuim will be rewarded. Michael Weir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ece.msstate.edu/pipermail/ece4723/attachments/20081023/536d6ddd/attachment.html From jwbruce at ece.msstate.edu Thu Oct 23 12:27:38 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Thu Oct 23 12:27:43 2008 Subject: [ece4723] task7 py file In-Reply-To: <3598658.155061224782526102.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <544619.155081224782858345.JavaMail.root@zimbra.ece.msstate.edu> I have uploaded a starting point file for your wxSensorSerial.py to the lab website. Some methods have already been coded and you are free to use them. The included code may not work with your team's implementation without mods. Hopefully this file will help you jumpstart your task#7. jwb ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298 From jwbruce at ece.msstate.edu Fri Oct 24 16:51:17 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Fri Oct 24 16:51:21 2008 Subject: [ece4723] new ESOS tree published In-Reply-To: <3694540.161931224885045469.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <29450921.161951224885077085.JavaMail.root@zimbra.ece.msstate.edu> Embedded System dudes: There is a new revision of ESOS in the .zip file on the ECE3724 lab website. This latest version of ESOS contains a SPI service similar to the I2C service. There is an example file showing SPI mastering in the chap14 folder. Enjoy! jwb ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298 From jwbruce at ece.msstate.edu Tue Oct 28 12:51:26 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Oct 28 12:51:45 2008 Subject: [ece4723] Fwd: The Embedded Muse 167 In-Reply-To: Message-ID: <18335381.179821225216286019.JavaMail.root@zimbra.ece.msstate.edu> Here is Jack's latest newsletter. You should probably read it, there may be an exam question on Thursday taken from his discussions. (HINT. HINT.) See you at 11AM on Thursday. jwb ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298 ----- Forwarded Message ----- From: jack@ganssle.com To: jwbruce@ece.msstate.edu Sent: Thursday, October 23, 2008 9:18:16 PM GMT -06:00 US/Canada Central Subject: The Embedded Muse 167 -------------------------------------------------------------- Embedded Muse 167 Copyright 2008 TGG October 23, 2008 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. Subscribe and unsubscribe info is at the end of this email. EDITOR: Jack Ganssle, jack@ganssle.com CONTENTS: - Editor's Notes - Book Review - The Failure of Reuse - Jobs! - Joke for the Week - About The Embedded Muse **************************************************************** This issue of The Embedded Muse is sponsored by Netrino. Are you an embedded C expert? Know the difference between volatile * const and const * volatile? See how your skills measure up in a fun, quick, online quiz. Challenge your peers for bragging rights. All takers are automatically registered to win one of three iPod Nanos. Start at http://www.netrino.com/Embedded-Systems/Embedded-C-Quiz-Muse **************************************************************** Editor's Notes -------------- Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it's not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/classes.htm . switch(city){ case San Jose: case Phoenix: case Austin: Are you in the San Jose, Phoenix or Austin areas? I'll present a public version of the Better Firmware Faster class in San Jose on December 8, Phoenix on December 10 and Austin on December 12. Registration and other info here: http://www.ganssle.com/classes.htm . You'll earn 0.7 Continuing Education Units, learn a lot, and have more than a little fun. Sign up before November 8 and receive a $50.00 discount. } Harold Teague has an interesting question for Muse readers: We're in the process of establishing job roles along the lines of firmware architect, firmware design engineer, and firmware integration/systems engineer. Does anyone have these or similar descriptions already defined? Let me know what you think and I'll publish the results here. In the seemingly never-ending quest for the perfect communications monitor, Bill Eubank sent info about an RS-232 monitor that runs on a Game Boy! See http://www.databoy.netfirms.com/. He writes: I have had one of these for may years and I still use it regularly. It monitors both sides of the communications, receive and transmit. It can also capture this information and transfer it to a PC for storage and/or printing. I met Yosuf Taraki, the designer, several years ago. He's a very nice guy. Book Review ----------- After the last Great Book Giveaway, J. Silva submitted a review of "Practical Software Estimation": Function point estimation methods are usually glossed over in a small section in program management books. "Practical Software Estimation" by M. A. Parthasarathy provides an in-depth discussion of function point-based methodologies for program management. The author gives a thorough explanation of the process with a few examples for each definition and case studies throughout. The first few chapters of the book are dedicated to introducing the process and basic concepts. The main meat of the material is another four chapters. The last half touches broadly on how to use the process for various types of projects (new development, migration or maintenance), as well as addressing metrics and estimation methods. It has some useful information for outsourcing project, which can shortcut lack of experience. Unfortunately, with all these helpful examples, it was difficult to synthesize much of the information into something useful in real life for a number of reasons. First, the process seems so complicated that it is difficult to apply it to some projects. From the high level, the process is simple but the devil is in the details. Second, it seems time consuming. I do not think this method would work for small, fast projects. Third, it requires the project manager to not only have a strong understanding of the requirements, but also how the design would breakdown. It is difficult to discern if this is a fault with the actual method or the author's presentation. I would recommend this book to a program manager on a large-scale, complex government contract with a long time horizon and a need for accurate schedule and costs. I would not recommend this for startup organizations, smaller project developers, or novice program managers. The Failure of Reuse -------------------- Reuse is the holy grail of software engineering, one that is so entrenched in our belief system no one dares to question its virtue. The quest for reusable components is one of the foundations of object oriented programming and all of the tools and languages that OOP has spawned. Yet, my observations suggest that at least in the embedded space reuse has been a dismal failure. First, let me define "reuse." We can talk about carrying-over code, or salvaged code, both of which imply grabbing big source files and beating them into submission till a new product appears. Not to knock that; it's much better than starting from scratch each time (but see my comments towards the end). We reach the nirvana of reuse, though, when we leave the source code alone, when we're able to pluck a module from the virtual shelf and drop it in to a new project, unchanged. Martin Griss and others have observed that a module isn't really reusable till it has been reused three times. No matter how good our intentions, the first time we try to reuse something we discover a facet of the new problem the old module just can't manage. So we tune it. This happens a couple of times till the thing is generally reusable. That's not because we're stupid; it's simply because domain analysis is hard. No one is smart enough to understand how a function might get used in other apps. It's expensive to do a forward-looking design of a function or module. You'll always save money -in the short term - solving today's very specific problem while ignoring the anticipated demands of future projects. If you elect to pursue a careful program of reuse your projects will initially come in late and over-budget. Reuse is hard. It's like a savings account. My kids complain that if they stick a few bucks in the bank then that's money they can't use. and it's just a piddling sum anyway. Sure. The value of savings comes after making regular deposits. Ditto for reuse. The cost is all up-front, the benefits come from withdrawals made in later years. Sure, we all know the long-term outweighs today's concerns. (Though the recent financial meltdown suggests that's a lesson some CEOs have missed). Most bosses buy into the idea of the benefits of reuse, without being willing to stand the pain of creating the reusable components. And that's the rub. When the ship date looms closer, too many bosses will tell us to toss out any sort of discipline that has long-term benefits in pursuit of a near-term release. So, in practice, reuse often fails since schedules generally dominate over any other parameter. I also suspect most of us don't want to reuse code. 35% of RTOSes are homebrew, despite at least 100 commercial - free and otherwise - products on the market. Nothing is easier to beg, borrow or buy than an RTOS, yet most of us still refuse to practice even this most simple of all reuse strategies. Why is this? I've heard many specious arguments (too expensive, yet there are plenty of freebies; we don't trust the code, but some are safety certified, etc), plus a few really good arguments (it's all legacy code, no one is willing to make risky changes). I think aggressive reuse is our only hope of salvation from the morass of expensive and unreliable code. Building correct firmware is so difficult that we and our bosses have a fiduciary responsibility to find ways to make it reusable. But we're not doing it. Sure it's hard. Yes, it's initially expensive. And of course we cannot reuse everything; a lot of what we build will always be inherently unreusable, like hardware drivers that get tossed with each new spin of the design. So what's the deal? Why is reuse such a failure? Is the best we can do, or chose to do, is to salvage old source files? A closing comment: In "Empirically analyzing software reuse in a production environment," Selby et al showed that hacking source has quickly-diminishing benefits. Once one changes more than about a quarter of the code there's not much cost saving over starting from scratch. Jobs! ----- Let me know if you're hiring firmware or embedded designers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words. Netrino has multiple open positions for embedded software developers and FPGA and board-level electronics designers, in Maryland and California. Join the Embedded Systems Experts(tm) in a fun work environment that offers challenge and variety. Learn more at http://www.netrino.com/Embedded-Systems/Jobs-Muse . --- Watt Stopper/Legrand has 3 openings for Electronic Design Engineers and one opening for an Electrical Analog Design Engineer in Carlsbad, CA. Products include occupancy sensing wall switches, home lighting control devices, commercial lighting control panels, and day lighting control products. Apply for these jobs online: http://jobs-legrand.icims.com/jobs/intro --- Are you an experienced Embedded Software Engineer? Do you envy people whose work doesn't require them to live close to a major city, who have a five minute commute to the office, and who have a ski resort, world class fishing, and even a glacier minutes from their home? If so, check out Pacific Insight Electronics Corp. in Nelson, BC (pacificinsight.com). We are looking for an Embedded Software Engineer. If you are driven to build high-reliability, automotive-quality software, and you dream of doing this in land of lakes, mountains and eagles, give us a call. We need someone who is bright and motivated, with solid experience writing top-quality C code for real-world applications. Experience with LIN, CAN, instrumentation and software modeling would be a bonus, but mostly we want someone who learns quickly, who has proven C experience, and is able to work well in a team. Of course, we need you to have an Engineering degree and preference will be given to candidates who are registered as a Professional Engineer. Contact Amanda at alaughton@pacificinsight.com. Joke for the Week ----------------- Guillermo Zepeda-Lopez sent this: There is an effort in our company to find ways to make our automotive ECUs lighter. Two of my SW colleagues (Ricardo Garcia and Antonio Lozano) turned in some great ideas to reduce weight through the SW in our product: - Write "lighter" code. - Declare all variables as "volatile". - Recursive calls to function ReduceWeight(int CurrentWeight). - Use more powerful microcontrollers so that we reduce the CPU "load". - Delete all comments from the code. - Use an operating system with a bigger "footprint". That way, we distribute the weight on a bigger area (less pounds per inch). - Leave all I/O pins "floating". - Always use "Tiny" memory model. - Stop using processes. Use only "light-weight processes". - Do more "on-the-fly" processing. - Stop drawing state diagrams with rectangles, use "bubbles" instead. - Don't eliminate all bugs. Remember some bugs can fly. About The Embedded Muse ----------------------- The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com. The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information. -- If you do not want to receive any more newsletters, http://www.jackganssle.com/lists/?p=unsubscribe&uid=e054cf7788a17a7ea25d9054032f2c06 To update your preferences and to unsubscribe visit http://www.jackganssle.com/lists/?p=preferences&uid=e054cf7788a17a7ea25d9054032f2c06 Forward a Message to Someone http://www.jackganssle.com/lists/?p=forward&uid=e054cf7788a17a7ea25d9054032f2c06&mid=37 -- Powered by PHPlist, www.phplist.com -- From jwbruce at ece.msstate.edu Wed Oct 29 14:31:31 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Oct 29 14:31:34 2008 Subject: [ece4723] ECE4723 exam tomorrow Message-ID: <7563164.187121225308691521.JavaMail.root@zimbra.ece.msstate.edu> Just a friendly reminder about the ECE4723 exam tomorrow at 11AM. Bring your calculator if you want. There are a few numbers to crunch. You can probably do it in your head, but a calculator may make you feel better. jwb ------------------ J.W. Bruce, Ph.D., Associate Professor Department of Electrical and Computer Engineering Mississippi State University 406 Hardy Road, Simrall 335 Mississippi State, MS 39762-9571 Office: (662) 325-1530 FAX: (662) 325-2298