From pmw36 at msstate.edu Mon Sep 1 18:47:01 2008 From: pmw36 at msstate.edu (pmw36@msstate.edu) Date: Mon Sep 1 23:14:39 2008 Subject: [ece4723] Repos Message-ID: The ece4723 repos have been created for all the teams. They are located at svn.ece.msstate.edu/data/classes/ece4723/svn/mercury svn.ece.msstate.edu/data/classes/ece4723/svn/venus svn.ece.msstate.edu/data/classes/ece4723/svn/mars Michael From jwbruce at ece.msstate.edu Tue Sep 2 07:33:49 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 2 08:27:46 2008 Subject: [ece4723] Fwd: The Embedded Muse 164 In-Reply-To: <1e01fdfe825860d6138d1dfceb4487be@www.jackganssle.com> Message-ID: <1934802.3111220358829037.JavaMail.root@zimbra.ece.msstate.edu> Here is Jack Ganssle's email newsletter on embedded systems. There is usually something of interest or humor in these. 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 ----- Forwarded Message ----- From: jack@ganssle.com To: jwbruce@ece.msstate.edu Sent: Tuesday, September 2, 2008 1:58:12 AM GMT -06:00 US/Canada Central Subject: The Embedded Muse 164 -------------------------------------------------------------- Embedded Muse 164 Copyright 2008 TGG September 1, 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 - Free Book on Inspections - Jobs! - Joke for the Week - About The Embedded 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 . Nancy Van Schooenderwoert coaches teams about agile software development. She has written a paper, "The Four Pillars of Agile Adoption", about how to avoid some perils in the adoption and use of agile approaches. I found it fascinating: http://www.leanagilepartners.com/publications.html . Boy, did I ever screw up. In the last issue I attributed a review of SmartBear's book on Code Inspections to Tom Harris. Actually, Tom's review is on-line at Amazon.com, and the review in the Muse was from a reader who wishes to remain anonymous. Sorry, Tom. Are you using, or even considering, FOSS? If so do check out the Software Freedom Law Center's advice, embodied in their new paper "A Practical Guide to GPL Compliance." It's here: http://www.softwarefreedom.org/resources/2008/compliance-guide.html . **************************************************************** This issue of The Embedded Muse is sponsored by Netrino. The question "What is the difference between a mutex and a semaphore?" is short and easily phrased. Answering it properly is more challenging. Fortunately, the key differences between a mutex and a semaphore are among many RTOS usage issues addressed clearly and concisely in the free articles at http://www.netrino.com/Embedded-Systems/How-To-Muse **************************************************************** Free Books ---------- My parents came of age during the Great Depression. Consequently my siblings and I were raised in a strict, never-waste-anything environment that I've tried to inflict on my own kids. But despite trying to be minimally consumptive, we sure do acquire a lot of stuff. Books are my bane; Amazon's One-Click ordering makes it oh-so-easy to get the latest intriguing tome. Compounding that, a lot of publishers send me free computer books hoping to get a review. Some I save; some get passed along to friends, and too often I seem to acquire multiple copies. There's a stack of technical books here that I no longer need. It seems sort of unethical to eBay those that were sent as freebies, and I can't remember which were free and which weren't. So, you can have them. They're all free and I'll pay for shipping. If you want one, please send marybeth@ganssle.com an email. She'll probably get inundated, so here are a few rules to throttle the packets: - First come, first serve - Please include a shipping address (no PO Boxes) - One book per person - let Marybeth know which one you'd like. - I ask you to write a review of the book after you read it, so others can benefit. It'll run in the Muse, and with the other book reviews on ganssle.com, with appropriate credit to the reviewer. - Please don't feel offended when we've run out! Though the books are in good condition, some have annotations I made while reading them. Here's the list: MicroC/OS-II, The Real-Time Kernel (second edition) by Jean Labrosse. This is one of the best introductions to using an RTOS, and, I'm told, is the best-selling book about embedded systems ever. Two copies available (you can pry the third copy out of my cold dead hands!) Practical Software Estimation by M. A. Parthasarathy. I thought this work was very superficial and devoid of hard-hitting advice, but you may feel differently. Embedded Linux Primer by Christopher Hallinan. A good and useful intro to porting Linux to your board. Real Time UML Workshop for Embedded Systems by Bruce Powel Douglass. A worthwhile workbook to help developers get started on UML. Logical Design of Digital Computers by Montgomery Phister, Jr. This 1958 volume is still surprisingly relevant, though the circuit diagrams use vacuum tubes! The Propeller Development Kit from the good folks at Parallax. This is a book and board. Use it to get familiar with their very cool 8 core propeller chip. CMMI for Outsourcing by Hofmann, Yedlin, Mishler and Kushner. Too many authors yields a dilute message that's more common sense than insightful. Embedded Systems Design Using the Rabbit 3000 Microprocessor by Kamal Hyder and Bob Perrin. A really good reference for those using the Rabbit parts. MISRA C - Guidelines for the Use of the C Language in Vehicle-Based Software. A great firmware standard, but this is the older, 1998, version. The Devil's DP Dictionary by Stan Kelly-Bootle. An irreverent and amusing dictionary of computer terms. Though containing nothing of value it's a ton of fun. Response to the Joke of the Week -------------------------------- In the last issue I ran an idea from Phil Matthews about using OO paradigms to help software people solder. Rob Wehrli appreciated the humor but wanted to clarify the OO issues: This is an exemplification of WHY HW people often DO NOT understand OO. The new circuit board class does NOT inherit the properties and methods of the components that were added to the base class. This is a CLASSIC misuse of inheritance that is very often perpetrated by HW folks...partly because languages like C++ (and nearly all others) can not differentiate between good and "bad" inheritance. The new class aggregates the functionality as instances of those representative classes that it uses to perform its work. This is often called composition or, obviously, aggregation. To say that the base circuit board class inherits its properties (the preferred term in OO-speak is "attributes") and methods (preferred is "operations") is simply wrong. Here's why. The circuit board class does not become a type of "solder" or "IC" or "discrete component" or anything else that was "added" to it. It is still a circuit board. It won't become a type of LCD controller if one decides to place a pad on a mechanical drawing and makes the necessary etchings to route traces to other devices such as a ribbon cable connector with the appropriate pin-out for a TFT LCD panel with integrated 4-wire resistive touch key and LED front light. The circuit board class is not a type of object populated on it, it is still a circuit board. By using inheritance to say that a circuit board is a kind of "solder joint" or that it is a kind of resistor (with a 10K value attribute) even sounds a bit suspicious, doesn't it? Over the years I've tried to explain the notion of good inheritance in the face of situations where C++ will gladly let one declare: class Rock; class Bird : public Rock {}; ...a Bird is a kind of Rock. I use these two because birds use small pieces of rock in their gizzards in place of teeth. This is a classic use of the external object by the "host" object. Here is another: class Battery; class Calculator : public Battery {}; A calculator is not a kind of a battery. The calculator probably needs the battery for its as-designed operational objectives but (the litmus test of good inheritance) the calculator can not be used anywhere its base can be used. That is, we can not instantiate a calculator class inside of a flashlight class and invoke its On operation for the purposes of lighting the darkened area. In fact, most real-world instances of calculator objects won't actually display in the dark, which isn't very useful to the average category of likely user. The goal of OO is to model the SW after the real world, at least within the constraints of the language and the skill of its programmers. So, while the joke was certainly funny and aimed at putting HW skills in SW terms, it falls short and helps perpetuate the "mechanical myth" that if the compiler (or development environment) allows it to work, therefore it must be right. Mechanically, C++ will happily allow the following: #include class Window { public: Window() { std::cout << "I'm a Window..." << std::endl; } void open() { std::cout << "Window is now open!" << std::endl; }; void close() { std::cout << "Window is now closed!" << std::endl; }; }; class Building : public Window { public: Building() : Window() { std::cout << "I'm a Building..." << std::endl; } }; class Unsuspecting { public: Unsuspecting() { std::cout << "I'm an Unsuspecting..." << std::endl; } void hit() { std::cout << "Ouch! Who hit me?!" << std::endl; }; }; class WaterBalloon { public: WaterBalloon() { std::cout << "I'm a WaterBallon." << std::endl; } void toss() { std::cout << "...sailing as a result of being toss!" << std::endl; } void fall() { std::cout << "...falling!" << std::endl; } }; class Villian : public Building, public WaterBalloon, public Unsuspecting {}; int main() { Villian v; v.open(); v.toss(); v.fall(); v.hit(); v.close(); return 0; } Output: I'm a Window... I'm a Building... I'm a WaterBallon. I'm an Unsuspecting... Window is now open! ...sailing as a result of being toss! ...falling! Ouch! Who hit me?! Window is now closed! ...so when is it the right time for a "Villian" to be a "Window" or a "Building" or a "WaterBalloon" or an "Unsuspecting?" However, if the objective was to instantiate the objects, have them perform some tasks, one can argue that the job was completed. Does that make it "right" or "good" code? Debugging Busses ---------------- James Morrison asked about debugging serial busses like I2C, SPI, and RS-232. Lots of people replied with suggestions: Edward Gibbins wrote: Interestingly I am placing an order here: http://www.pctestinstruments.com . David Bevin sent: I don't think this answers James Morrison's question but I remember using a HP 4952A Protocol Analyser for monitoring and simulating RS232 comms. There's a picture of one here: http://www.atecorp.com/Equipment/HP/4952A.asp Harry Jones contributed: You could take a look at these tools: http://www.mcc-us.com/I2C_Tools.htm . Joy D. St. Amant suggested: A company named Willies Computer Software makes serial communications tools. Check out there products at: http://www.wcscnet.com/Default.htm . I have used their SI Scope; it is a good product. I believe they have an upgrade to the basic product which may be useful to Mr. Morrison. Rijo Varkey uses Tracii http://www.telos.info/traciixl/ for I2C which is a bit expensive and also TotalPhase's tools. Recently we came across USB scopes but not used http://www.usbee.com/busbee.html. If someone has already used this tool let know the feedback. Greg Harris wrote: For I2C bus monitoring/debugging/testing I have found the Corelis CAS-1000-I2C/E to be very useful. It is not cheap (but they are having a 40% discount right now), but it is very versatile. Ray Keefe sent: One very inexpensive way to do I2C and SPI debug is the RockyLogic ANT8. http://www.rockylogic.com/ It is the logic state analyser which has direct decoding of both I2C and SPI. We have found it to be easy and straightforward to use. So you can use it to monitor the transactions provided they aren't really long. You can purchase it from EasySync http://easysync-ltd.com/ although I noted it is marked as discontinued. RockyLogic also does the Ant18e which can debug address/data busses and the like and provides faster sampling and a greater sample depth. See http://www.rockylogic.com/products/ant18e.html Bill Brasch had a suggestion: I recently came across this 8-bit USB logic probe from Saleae that has I2C, SPI, RS-232 decoding. Low cost $149. I have not personality used it, but it looks promising. Check it out: http://www.saleae.com/logic/features/?q=i8&gclid=CPHgkeyDjJUCFQObFQod5SV . Jay D. Hall uses: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028600 with great success. Hope it helps him! Dave Clark wrote: The USBEE-AX and BX (http://usbee.com/usbeeax-standardtestpod.aspx) is a brilliant tool for analyzing USB and other serial protocols. We have the AX-Plus, but the next one up the range seems to have an I2C controller as well. I could not have even attempted a recent USB project without it. Imagine sampling a 8 signals at 24MHz with 1,500,000,000 sample depth and then decoding the result by hand? Colleagues have also used it for I2C as well as other protocols. For serial debugging, I use Telix, which has an excellent script language which can be used to decode protocols (I have written scripts for Multi-Drop Bus vending protocol and BACTA gaming protocols). The scripts can also be used to simulate a slave or master device. It appears to be a free download (http://www.telix.com/delta/deltacom/tfw/index.html) but I cannot be sure of this. We purchased it about 10 years ago and have upgraded to 1.15D. Christer Berg sent: You may want to look at Frontline's SerialTest and other products from same company. Excellent decoding of most industrial protocols. Martin Zacho wrote: I would use a FPGA dev kit (from your preferred manufacturer) and implement the relevant parts in it. The cost would be below $100,- and some spare time ;-) Bill Knight suggested: Have James Morrison check out RealTerm http://realterm.sourceforge.net for debugging serial port busses. Randy Glenn sent: In your most recent Embedded Muse, you passed on a question from James Morrison regarding an inexpensive I2C / SPI / UART debugging tool. The Microchip PICKIT2 programmer can handle all of the above (to some extent, at least) and comes in at $35. It can even act as a 3-channel 1MHz logic analyzer - not great, but still not bad for $35. Oh, and it programs and does ICD for microcontrollers, too. More info at http://www.microchip.com/pickit2. I should probably also include a link to the PICKIT 2 Serial Analyzer page, http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028600, where the firmware and software to do the I2C and SPI stuff lives. Ben Sweet contributed: Regarding James Morrison's question about debugging network interfaces. He might consider the Netway tool from Smart Engineering Tools, Inc.: http://www.smtools.com/ Paul Carpenter wrote: I have never really come across a completely multifunction device for doing insertion of commands and for most systems (I2C and SPI like) the hardware alone dictates, that adding another master device will require changes to hardware or jumpering out the bus to go via your pseudo master. Back to the problems of two drivers at same time on an SPI bus is a hardware issue, and blowing devices. In many cases you would have to have a device to pass all traffic, add extra, or takeover the bus. However for monitoring many digital scopes these days have the ability to do the monitoring. The problem of course is in the matching with SPI the clock and data phases, along with maximum data rate. I am reminded of something I did in a PLD the other year for testing ASICs, device being tested was its own I2C master, to continuously communicate with an I2C EEPROM containing calibration data. However I quickly discovered the amount of reads and writes required to test about 500 ASICs would exceed the EEPROM write cycles spec. Also the data sets that had to be stored in the EEPROM for device testing was in fact very simple (bit manipulation algorithms from the address and mode), some places were just binary inversions of symmetrical places, and some parts had to be read/write registers. By creating an SPI register in a PLD, I was able to compress all the function control to be configured for another block of the PLD to then operate as a simulator of the I2C EEPROM. This included encoded bits in the control register to ensure the next access would deliberately contain bit errors to force error conditions as part of the test process. One advantage of this was that alongside digital scope measurement of the signals to check frequency, levels etc.. we could determine if the ASIC was in a fault condition and driving the I2C bus at about 2 MHz, which the emulator happily coped with Considering the various speeds, clock relationships, let alone data protocols need to operate, especially serial memory devices. It may be easier to derive a mixture of scope and PLD/FPGA that suits your application each time. Datasheets ---------- Sick of incomplete and erroneous datasheets? They've been a problem ever since I became an engineer. Readers have been sending in funny/odd/annoying excerpts from datasheets for our agony or amusement. Tom Mosher and others suggested the real classic, the Signetics Write-only-Memory. That's on-line here: http://www.national.com/rap/files/datasheet.pdf Paul Carpenter wrote: Aaarrrgh..... those who may know of the older H8/3048, the problems with driving the flash write enable pin are legendary, until they bought out the 'B' version 5V only pins. Basic problem is the spread of information of modes, electrical characteristics, special functions through 800+ page manuals (PDF). So parts of the microcontroller are described in 20 different places. Often repeating some of the information. Most parts of the document, even the absolute maximum ratings, tell you that the pin can withstand 13V (must not peak above this). Hidden away on page 600 and something is the ONLY note that is only a few lines long - "..(Vpp) must be applied after the rise Vcc when the microcontroller is in a stable state. Shut off Vpp before Vcc..." In other words or absolute max rating of Vpp pins is "8V above Vcc" NOT 13V. This is not described in the programming examples or how to setup the device electrically for the modes. Luis G. Uribe sent this: The following is not about a datasheet; it is the Motorola (now Freescale) CPU08RM.pdf Reference Manual, http://www.freescale.com/files/microcontrollers/doc/ref_manual/CPU08RM.pdf . The last section is written to include programming examples to show the new instructions --those added over the ancient HC05, and their applications. There you can read (page 183): Code Examples: TAP Transfer Accumulator to Condition Code Register TAP * * NOTE: The TAP instruction was added to improve testability of * the CPU08, and so few practical applications of the * instruction exist. * In my opinion, the author of this infamous paragraph has no idea of what he is talking about. This instruction was NOT added to improve testability; it is one of the most important Op-Codes in the entire HC08 instruction set, and one that deserves a full example on using it! For example, to write some generic routine, one that could be used inside an ISR, if you need to disable interrupts, later you can not simply enable them: You must restore interrupts to the state they where at the beginning, something like this: TPA ; Transfer CCR to Acc (TPA is TAPs twin opcode) PSHA ; ..Save Acc (CCR) into stack ;... ;...Later you may recover the interrupt state, as follows: PULA ; Pop (er, pull) Acc TAP ; ..Transfer Acc to CCR ; ..(saved flags, including I Flag) ;... By the way, TAP stands for: Transfer Accumulator to Processor Status Word. You know, they began calling the flags, PSW and, then, change the name to Condition Code Register (CCR) but, the instruction codes, remain using the old nomenclature (TAP, TPA). 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. 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/Embedded-Software-Jobs . Joke for the Week ----------------- Definition of a security professional: A hacker with a mortgage. 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=33 -- Powered by PHPlist, www.phplist.com -- From jwbruce at ece.msstate.edu Wed Sep 3 10:46:32 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 3 10:46:39 2008 Subject: [ece4723] dissection proposals Message-ID: <18671483.10191220456792444.JavaMail.root@zimbra.ece.msstate.edu> If your dissection product is not listed on the class web site, please make your decision and send an email to me ASAP. thanks, 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 Sun Sep 7 15:06:11 2008 From: pmw36 at msstate.edu (pmw36@msstate.edu) Date: Mon Sep 8 08:04:26 2008 Subject: [ece4723] Lab 3 Message-ID: Some people had questions about median filtering. The idea is to store the ADC temperatures in an overwriting Fifo. Therefore the oldest temperature is overwritten each time. To get a valid temperature, the fifo is sorted and stored in another buffer. Then the median value is used as the valid temperature. Using median filtering removes spurious data that an occur with the ADC module. As for the lab 3 bonus, groups that do not do it will earn a maximum grade of a 90. However the bonus is opened ended. A bonus that performs the minimum requirements described by the lab specification will earn 10 points. The more professional and impressive the bonus is the more point I will award it. Therefore it will be possible to get over a hundred for this lab. Michael From pmw36 at msstate.edu Tue Sep 9 22:49:05 2008 From: pmw36 at msstate.edu (pmw36@msstate.edu) Date: Tue Sep 9 22:49:17 2008 Subject: [ece4723] Hex File Message-ID: Attached is a hex file for the PIC24H. It outputs a heart beat on pin (RB15) and echoes serial data. It has been compiled for the bootloader. Use it to test your hardware. Michael From jwbruce at ece.msstate.edu Wed Sep 10 10:14:54 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 10 10:15:02 2008 Subject: [ece4723] HW#1 due Thurs 18 Sept In-Reply-To: <13791106.53881221058945930.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <14975595.54081221059694865.JavaMail.root@zimbra.ece.msstate.edu> Embedded Systems dudes: HW#1 for ECE4723/6723 has been assigned. It is due next Thursday Sept 18th. HW#1 is a "team" assignment. One benefit of teaming is division-of-labor, but that does not mean everyone works on their bit in isolation. In the end, everyone need to have a very good idea of how it all works. (This will also help you to progress faster and faster as the semester goes on.) Do NOT attempt over-the-wall design where each person does a bit in isolation and throws their answer over the wall to the next person. This rarely succeeds, plus you only learn about your small assigned part. HW#1 requires you to develop a "service" for ESOS which involves a lot of learning. I would recommend the method called "jigsaw": Each of your 3 team members goes off for a day (2 at most) to become an "expert" in one of the required background areas. In this case, 1) PIC24 I2C hardware and the ECE3724 hardware support library for I2C 2) how parent-child tasks work in ESOS 3) ESOS communications service Then, come back together to work, AS A TEAM, on solving HW#1. You will have an "expert" in everything you need, so it go fairly quickly at that point. As you work together, everyone will quickly come up to speed on the other 2 ares since an expert is explaining it. In the end, you have a quality solution and everyone will have a fairly good feel for how the whole thing fits together. 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 Wed Sep 10 22:25:16 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 10 22:25:23 2008 Subject: [ece4723] ESOS changes In-Reply-To: <29502760.57611221103449103.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <8916649.57641221103516082.JavaMail.root@zimbra.ece.msstate.edu> FYI.... The __ESOS_TASK_SPAWN is a "hidden" helper function. Do NOT use it directly. You want to use ESOS_TASK_SPAWN_AND_WAIT instead, based on feedback from y'all that the macro should contain "_WAIT" in the name if it blocks. Be patient and flexible.... we'll still moving a few things around in ESOS. 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 ----- Original Message ----- From: "Thomas Donaldson" To: "J. W. Bruce" Sent: Wednesday, September 10, 2008 7:45:52 PM GMT -06:00 US/Canada Central Subject: ESOS changes Dr. Bruce, The latest commit of ESOS is missing the ESOS_CHILD_TASK_SPAWN( ), which looks like it has been renamed to __ESOS_TASK_SPAWN( ). I tried doing a simple find&replace in esos_comm.h, but it looks like some arguments are misnumbered. Just wanted to give a heads-up. Thomas Donaldson From jwbruce at ece.msstate.edu Thu Sep 11 14:06:55 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Thu Sep 11 14:06:57 2008 Subject: [ece4723] ESOS examples Message-ID: <10614534.61421221160015196.JavaMail.root@zimbra.ece.msstate.edu> I put an archive on the class website containing the code from today. It build for the PC version, but shouldn't be too much trouble to convert to real hardware. 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 Fri Sep 12 14:03:32 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Fri Sep 12 14:03:39 2008 Subject: [ece4723] [ECE4723/6723] updated ESOS in archive In-Reply-To: <2961243.66291221245973244.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <27285859.66341221246212273.JavaMail.root@zimbra.ece.msstate.edu> Embedded system dudes: You will probably want to pull down the ece3724 zip archive again. I fixed a fairly significant bug in the ESOS_TASK_WAIT_TICKS(...) code along with a few other minor defects. The zip up there now is a snapshot of our "trunk" as of right now (2PM on 9/12/08). I'll try to email you when the archive changes again in a way that will affect you. Thanks, 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 Fri Sep 12 16:42:57 2008 From: pmw36 at msstate.edu (pmw36@msstate.edu) Date: Fri Sep 12 16:43:13 2008 Subject: [ece4723] Team Evaluations Message-ID: Team Evaluations need to be turned in along with the other lab deliverables at the beginning of your next lab period. Evaluations will need to be done every time a task is due. The evaluation forms can be found on the class website or on the wiki. (http://www.ece.msstate.edu/wiki/index.php/ECE4723_Embedded_Systems). Forms can be turned in or the information emailed to the TA. The wiki is newly created page that contains some helpful information in one location. As the semester progresses, more information such as answers to common questions maybe added to the wiki. Michael From jwbruce at ece.msstate.edu Mon Sep 15 16:18:59 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Mon Sep 15 16:19:06 2008 Subject: [ece4723] Re: Exception class for homework 1 In-Reply-To: Message-ID: <16154541.77591221513539902.JavaMail.root@zimbra.ece.msstate.edu> We won't..... The error message approach in the HW library is not an option. Our systems will be connected to other computers. We just have to handle exceptions as gracefully as possible. Your I2C functions will just wait forever. All tasks not waiting on I2C should continue running. In practice, it is easy to figure out what happened. 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 ----- Original Message ----- From: cms261@msstate.edu To: jwbruce@ece.msstate.edu Sent: Sunday, September 14, 2008 6:02:19 PM GMT -06:00 US/Canada Central Subject: Exception class for homework 1 Dr. Bruce, We noticed that the PIC24 library was "reporting" errors whenever it got exceptions during I2C transactions. Since we cannot do this in ESOS, how should we handle exceptions? Thanks, Matt From jwbruce at ece.msstate.edu Mon Sep 15 16:44:10 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Mon Sep 15 16:44:17 2008 Subject: [ece4723] ESOS library changes In-Reply-To: <20608099.77631221513958064.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <28187575.77801221515050630.JavaMail.root@zimbra.ece.msstate.edu> Embedded system dudes: I have made wide-sweeping changes to the ESOS API. Mostly command name changes and changed a few arguments here and there. Your current ESOS code is completely broken with the new tree. The biggest change is that the "pstTask" that refers to the current task is no longer explicitly passed around. (It is still there, it is just hidden from view.) You only use a pstTask (now typedef-ed as ESOS_TASK_HANDLE) when you refer to tasks other than yourself. You will find several useful examples on the new ESOS in the chap14 folder. Of course, the online dox are crucial. The old ESOS tree is archived and available on the ECE4723 website. The new tree is available on the ECE3724 webpage. You will want to transition to the new tree ASAP. jwb PS: I am still tweaking on the interrupt API but the changes there should be quite small. ------------------ 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 Sep 16 08:03:22 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 16 08:03:42 2008 Subject: [ece4723] Fwd: The Embedded Muse 165 In-Reply-To: Message-ID: <31830501.79841221570202583.JavaMail.root@zimbra.ece.msstate.edu> For your reading enjoyment.... ------------------ 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: Monday, September 15, 2008 8:49:34 PM GMT -06:00 US/Canada Central Subject: The Embedded Muse 165 -------------------------------------------------------------- Embedded Muse 165 Copyright 2008 TGG September 15, 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 - Inheritance - Funny Datasheets - Code Inspections - Comm Monitors - Jobs! - Joke for the Week - About The Embedded Muse **************************************************************** This issue of The Embedded Muse is sponsored by Netrino. The job of writing reliable and maintainable embedded software is not rocket science. So why are there so many bugs in your company's firmware? Part of the problem has been the lack of quality training. Netrino has solved this by packing valuable lessons on the few dozen coding best practices that most reduce firmware bugs (in programs with and without an RTOS) into a 4-1/2 day hands-on Embedded Software Boot Camp. The next public session runs October 6-10, 2008. Visit http://www.NetrinoInstitute.com/Boot-Camp-Muse for full details. **************************************************************** 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 . 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. The Renesas Developer Conference will be in San Diego October 13-15. It's a heavily technical, hands-on, conference with sessions on CAN/LIN, Zigbee, RTOS, Ethernet, USB, Flash Technology, etc. They're also going to have the Mythbusters there for a special session. See http://devconrenesas.com . Venture Development Corporation (VDC) has completed its 2008 embedded systems engineering survey. To download a copy of the highlights, see: http://www.vdc-corp.com/misc/08_esdt_eu_survey_highlights.pdf . Inheritance ----------- What started out as a joke a couple of Muses ago about how hardware people can talk to software engineers has turned into an interesting discussion. James Thayer had this to say: Inheritance vs. containment is one those things that people seem to screw up all too easily. I've always found that the phrases "is a" (inheritance) and "has a" (containment) to be useful ways to distinguish the two... Bird "is a" Animal -- Inheritance Bird "has a" Rock -- Containment Bird "has a" Beak -- Containment Circuit Board "is a" Insulating Material Circuit Board "has a" Resistor Circuit Board "has a" Battery" But there are other things that people tend to screw up beyond containment/inheritance. It's possible to get that part right and still have bad decomposition of objects. The second set of examples is deliberately constructed to have some additional potential problems For one thing, what is a Circuit Board? Is it the blank PWB or is it the stuffed board? If it's poorly named, we might make bad assumptions (and worse we might mix our assumptions without realizing it). If I assume that Circuit Board is a blank PWB then inheriting from Insulating Material might make sense but containment of the resistor doesn't make sense. But if you assume that it's the stuffed board, then inheriting from Insulating Material wouldn't be right but the fact that it contains a resistor would make sense. (It might be better to say that Stuffed Board "has a" Blank PWB which "is a" Insulating Material.) Another pitfall is trying to inherit from things that have attributes you don't care about in your operating context. Blank PWB might, in fact, be a good insulating material but if you don't really care about the insulating characteristics of the PWB then it really doesn't make sense for me to inherit these attributes. This example may seem obvious but there seem to be plenty of examples where someone decides that it made sense to inherit because class A really "is a" kind of class B, but the attributes of B are never referenced. There is no value in inheriting just because you can. James Grenning wrote: The notion that OO's goal is to model the real world is not really up to date with current OO thinking. Some do use that way, and it does not usually lead to better designed software. The main goal of OO is dependency management, information hiding through encapsulation and the ability to define and program to interfaces. The typical problem of long dependency chains can be very effectively broken by inserting an interface. In C++ an interface is a base class with all pure virtual implementation. Essentially you get to define what an object is supposed to do, without revealing how it will do it. When a compile time dependency is broken by inserting an interface, essentially the top down dependency from client to server is inverted, making both the client and the server depend on the interface, without knowledge of the other. Being able to model things form the problem domain is a bonus on top of dependency management. Funny Datasheets ---------------- Stefan Wimmer likes the first sentence on page 7 of this datasheet: http://focus.ti.com/lit/ds/symlink/ucc37321.pdf Code Inspections ---------------- The recent discussions here about code inspections brought in an interesting email from Asbjorn Sabo: Nordic Semiconductor specializes in solutions for wireless communication. As a number of our chip designs contain microprocessors, embedded work and firmware development is a large part of the activity at our software group. For internal purposes we compiled an overview of the code reviews done in a part of one of our development projects. It then occurred to us that this might be of interest for you, maybe for presentation in your newsletter, The Embedded Muse. (While this is a small and not very rigorous collection of data, it is real life data none the less.) The code reviews cover a period of one and a half year, ending mid august 2008. The code in question is C code for an embedded 8051, controlling the radio part of the chip and implementing the lower layers of the protocol stack, developed by a team of four to five persons. (Jack notes: It's hard to put the data into this text-formatted newsletter, so it's on-line at http://ganssle.com/misc/nordic_reviews.xls . There were 23 reviews of a total of 66 files which uncovered 399 errors, or about 6 per file on average.) The rule is that before a review, the code shall compile cleanly and give no Lint warnings. The issues and errors found during the review are classified as major, minor, code that is correct but still should be improved, specification violations and code standard violations. In addition, some issues have not been classified. Both the number of issues and their classifications should be taken with a grain or two of salt, though. (Reviews have been done at different times, with different reviewers, some issues are difficult to classify, ...) Some issues are given multiple classifications, but they are only counted once in the "Total" column. A few more things: The code reviews are most often done by four persons (moderator, recorder, reader, author) who meet after preparations and read through the code, paraphrasing it. Another variant used include two reviewers reading the code thoroughly on their own, and then a short meeting with the author where the reviewers' give their comments to the code. On average, most of three to four man days are spent on a review. For the reviews in this collection, a grand total of around eighty man days is a quite good estimate of the time used. In an email exchange Asbjorn answered some questions for me: > - About how many lines of code were reviewed? That we have not tracked, actually. (But I can see that it might be a good idea to do so.) A rough estimate would be some hundred lines of code (not including comments and white space), maybe a bit more, per review on average. > - Do you know how many bugs remained and were fixed after the reviews? Not per reviewed module. But we have found around 45 bugs in total on this part of the project, that is on all the reviewed code together. These 45 bugs are typically functional errors (system does not work, does not work as intended, does not follow specification), often related to the interworkings of various software and hardware modules. > - Is the team satisfied with the results? Opinions are a bit divided, I think. Some feel that reviews are taking much time, others seem quite satisfied. This overview of the reviews was intended as input into this discussion, to see how many bugs we actually did catch and how useful the reviews were. We have been trying various approaches to the reviews, from the full reviews (four persons in meeting, paraphrase all of code) via somewhat lighter reviews (two other persons read the code on their own, making comments on errors and things they do not understand) to a few very informal ones on smaller pieces ("Hey, could you have a look at this?"). I think the discussion on, and search for, the "best" way of doing reviews for us will continue for some time yet. Comm Monitors ------------- Yet more suggestions for tools to monitor communications protocols have come in. Ajay Wazir suggested YAT (Yet Another Terminal) from http://www.lvr.com/serport.htm . Tjark van Dijk wrote: I followed the subject about protocol analyzing tools and maybe this product (indeed, one of my own) may be of interest to your audience. http://www.tildesign.nl/rs232_ttl_converter-20107101P2N .It's an RS232 to TTL converter, just Rx and Tx. The reason to develop a product like this was that I became soo tired making again an RS232-TTL converter on a breadboard because the controller board I had to work with just output TTL. And off the shelve solutions cost around $ 50 or more and were large. If a Muse reader wants to order and tells me MUSEDISCOUNT in the order they can buy the unit for 11 Euros plus shipping in any quantity. 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. 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 Ready to take your career to the next level with an innovative, growing company in West Michigan? Discover what's waiting for you as a Customer Software Development Engineer at Gentex Corporation. We're looking for people with a four year degree in Electrical Engineering that have a high proficiency in C and C++ languages, assembly languages, and real time operating systems. In this role, you will interface with customer software requirements engineering, software test, electrical development, and electrical systems in the creating and debug of embedded software. Learn more and apply online today at www.gentex.com. Embedded Software Developer required to join an established Irish company working on the next generation in automotive electronics. Requirements: - Expert C/C++ coding and debugging in an agile environment. - Minimum 5 years experience with low-power, real-time systems. - Track record of designing high-availability products using 16/32-bit microcontrollers with virtual memory. - Experience with CAN, embedded Linux, and GUI toolkits would be an advantage. We are located in Irelands fastest-growing city, and one of the sexiest cities in the world: http://en.wikipedia.org/wiki/Galway . Contact: careers@bluetree.ie . Joke for the Week ----------------- We in the US are preparing to switch to digital TV in 2009. Many might not know of the looming switchover of the power grid from AC to DC. For more on this see http://www.csl.sri.com/users/neumann/insiderisks08.html#214 . 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=35 -- Powered by PHPlist, www.phplist.com -- From jwbruce at ece.msstate.edu Tue Sep 16 08:41:44 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 16 08:41:50 2008 Subject: [ece4723] new .zip archive (again) Message-ID: <10058891.79931221572504851.JavaMail.root@zimbra.ece.msstate.edu> The .zip from late yesterday was missing a #endif in a header file. That's been fixed and a new .zip archive is now available. 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 Sep 16 15:10:19 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 16 15:10:26 2008 Subject: [ece4723] ECE4723 schedule for next few weeks Message-ID: <17277960.81591221595819206.JavaMail.root@zimbra.ece.msstate.edu> As we discussed in class today, here is the schedule of events for ECE4723 over the next two weeks: 9/16 Lecture: outputs Lab: Task #4 has been removed. All other tasks remain in place and will be due on their set dates. 9/18 Lecture: inputs (last lecture on PE#1) 9/23 Lecture: no class HW#1 should be committed into a SVN tag work on lab, HW#1, dissection, or study for exam Lab: work Task #5 9/25 Lecture: PE#1 (all material in readings, lecture, and lab thru 9/18) 9/30 Lecture: topic TBD Lab: work on Task #5 10/2 Lecture: topic TBD 10/7: FALL BREAK ------------------ 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 Sep 16 15:28:12 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 16 15:28:18 2008 Subject: [ece4723] new ESOS release In-Reply-To: <1504161.81641221596836683.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <21785138.81661221596891974.JavaMail.root@zimbra.ece.msstate.edu> ESOS constituents: There is a new release of ESOS up on the ECE3724 website. The previous release was only placed there this morning, but I found a bug that causes software timers to not work right on PIC24 hardware. This has been fixed and software timers seem fine now. I also made sure the MPLAB project files in chap14 are working. Please update your tree. Sorry for such frequent updates but I thought you'd like to have a tree that actually works. ;-) jwb FYI: ==== I am currently trying to track down a very strange bug. Today, I got a "reset" on the PIC24 and a "segfault" on the PC with an application. The problem lies in the code that does periodic garbage collection to clear the dead/ended tasks out of the task structure array maintained by the ESOS scheduler. The bug is weird because this particular code hasn't been touched in many months and has worked flawlessly for literally 100+ different ESOS applications I have built and run. Since both PIC24 and PC die on the same application at the same point, I know that the bug is fundamental and down in the guts of ESOS. This problem only occurs with a particular sequence of events, so it is unlikely to impact you. (Famous last words!) I should be able to fix it really soon. (More famous last words!) From jwbruce at ece.msstate.edu Wed Sep 17 08:42:57 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 17 08:42:58 2008 Subject: [ece4723] Re: new ESOS release In-Reply-To: <21785138.81661221596891974.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <32564502.84231221658977021.JavaMail.root@zimbra.ece.msstate.edu> I found the problem (difference between < and <= in one particular sequence of events) and fixed it. A new .zip archive is available on the ECE3724 website. Refreshing to this version is not critical as the error dealt with a particular sequence of events of user (parent) tasks "ending" their lives. Most of our tasks in 4723 are written with while(TRUE) and never end. Therefore, this bug is likely not to affect you. There will be another update in the next day or so, as I tweak the interrupt API as promised in class yesterday. 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 ----- Original Message ----- From: "J. W. Bruce" To: "ece4723" , "(Paul) Michael Weir" Cc: "Bryan A. Jones" <>, "J. W. Bruce" Sent: Tuesday, September 16, 2008 3:28:12 PM GMT -06:00 US/Canada Central Subject: new ESOS release ESOS constituents: There is a new release of ESOS up on the ECE3724 website. The previous release was only placed there this morning, but I found a bug that causes software timers to not work right on PIC24 hardware. This has been fixed and software timers seem fine now. I also made sure the MPLAB project files in chap14 are working. Please update your tree. Sorry for such frequent updates but I thought you'd like to have a tree that actually works. ;-) jwb FYI: ==== I am currently trying to track down a very strange bug. Today, I got a "reset" on the PIC24 and a "segfault" on the PC with an application. The problem lies in the code that does periodic garbage collection to clear the dead/ended tasks out of the task structure array maintained by the ESOS scheduler. The bug is weird because this particular code hasn't been touched in many months and has worked flawlessly for literally 100+ different ESOS applications I have built and run. Since both PIC24 and PC die on the same application at the same point, I know that the bug is fundamental and down in the guts of ESOS. This problem only occurs with a particular sequence of events, so it is unlikely to impact you. (Famous last words!) I should be able to fix it really soon. (More famous last words!) From jwbruce at ece.msstate.edu Fri Sep 19 10:38:25 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Fri Sep 19 10:38:35 2008 Subject: [ece4723] IEEE events Message-ID: <5528714.93551221838705849.JavaMail.root@zimbra.ece.msstate.edu> A public service announcement on behalf of the local IEEE chapter. Upcoming IEEE events ======================== Come learn more about Coop positions and Full time employment with Adtran! When: September 23rd, 2008 5:30pm Where: Simrall 203 Food will be provided! --------------------------------- Webmaster Position Opening Are you interested in becoming webmaster for the Mississippi State Branch of I.E.E.E.? Please contact our officers at ieee@msstate.edu or come to one of our many meetings this semester! Webmaster needs to know html and CSS. --------------------------------- Interested in Joining I.E.E.E? Visit the main website at www.ieee.org and sign up today! It?s quick and easy!! From jwbruce at ece.msstate.edu Fri Sep 19 15:45:34 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Fri Sep 19 15:45:40 2008 Subject: [ece4723] Re: Macro Issues In-Reply-To: Message-ID: <3429966.95981221857133993.JavaMail.root@zimbra.ece.msstate.edu> You can't. Because of the way that ESOS uses macros to implement the local continuations, multiple "WAITS" will map to the same LoC and can't be distinguished. I haven't try it yet, but a function qualified as "inline" may work. Otherwise, you are going to have to spell it out, or make a child task out of it. 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 ----- Original Message ----- From: "Matt Steiner" To: "J. W. Bruce" Sent: Friday, September 19, 2008 3:39:23 PM GMT -06:00 US/Canada Central Subject: Macro Issues Dr. Bruce, How can we use multiple ESOS_TASK_WAITs in a macro? We are getting "duplicate case value" errors since macros are considered one line. Thanks, Matt From jwbruce at ece.msstate.edu Fri Sep 19 15:50:19 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Fri Sep 19 15:50:26 2008 Subject: [ece4723] Re: Macro Issues In-Reply-To: <3429966.95981221857133993.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <26355306.96021221857419756.JavaMail.root@zimbra.ece.msstate.edu> More thoughts: Even if the inline function does work, you are playing with fire.... Inlining is a compiler optimization. The compiler do not have to inline it, even though you request it. Of course, once you call into a new function, you have a new scope. Variables are gone and the WAITs will not work. The best approach, and the reason they were invented, is to use child tasks. 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 ----- Original Message ----- From: "J. W. Bruce" To: "Matt Steiner" Cc: "ece4723" , "(Paul) Michael Weir" Sent: Friday, September 19, 2008 3:45:34 PM GMT -06:00 US/Canada Central Subject: Re: Macro Issues You can't. Because of the way that ESOS uses macros to implement the local continuations, multiple "WAITS" will map to the same LoC and can't be distinguished. I haven't try it yet, but a function qualified as "inline" may work. Otherwise, you are going to have to spell it out, or make a child task out of it. 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 ----- Original Message ----- From: "Matt Steiner" To: "J. W. Bruce" Sent: Friday, September 19, 2008 3:39:23 PM GMT -06:00 US/Canada Central Subject: Macro Issues Dr. Bruce, How can we use multiple ESOS_TASK_WAITs in a macro? We are getting "duplicate case value" errors since macros are considered one line. Thanks, Matt From jwbruce at ece.msstate.edu Fri Sep 19 19:00:39 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Fri Sep 19 19:00:48 2008 Subject: [ece4723] Re: HW1 Question In-Reply-To: <23588824.96781221868058818.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <10891588.96811221868839332.JavaMail.root@zimbra.ece.msstate.edu> The new ESOS API has only WAIT_ON_AVAILABLE_.... and SIGNAL_AVAILABLE_... macros. You don't need the third macro anymore. But, yes, you can create the additional macros. The specified HW#1 macros should assume the I2C peripheral is available. In a single-consumer case, there is no reason to signal or wait. The GET_I2C1 macro is a macro to SPAWN_AND_WAIT on a child task. The child task has the multiple WAITs in it and works. That was the main reason I got the child tasks working with input arguments. Look at esos_comm.h for more details 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 ----- Original Message ----- From: "Thomas Donaldson" To: "J. W. Bruce" Sent: Friday, September 19, 2008 4:57:56 PM GMT -06:00 US/Canada Central Subject: HW1 Question Dr. Bruce, In the spirit of ESOS's comm system, we would like make WAIT_ON_AVAILABLE(), SIGNAL_BUSY(), and RELEASE() macros for creating a mutually exclusive I2C interface. Additionally, our __GET_I2C1() macro has multiple ESOS_TASK_WAITs in it (from replacing the busy waits in pic24_i2c.c). We know that this breaks how ESOS local continuations work. The best solution would be to create more I2C macros than what is specified in HW1. Is it satisfactory that we add additional macros to our submission? Thanks, Thomas From jwbruce at ece.msstate.edu Mon Sep 22 06:00:27 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Mon Sep 22 06:00:36 2008 Subject: [ece4723] HW#1 In-Reply-To: <27679681.2451222080680052.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <31571735.2471222081227242.JavaMail.root@zimbra.ece.msstate.edu> HW#1 is due Tuesday at 5PM. Please place your submissions into a tag called "hw1" in your team svn repository. Team memberships in Section 2 have been reoriented. Please use your new team from this point forward. Members joining a new team are allowed to take bring their existing code with them. New teams can incorporate any bits of this code that they choose. PE#1 will be held on Thursday. Topics: all course material through last Thursday's lecture. Remember that there is no lecture on Tuesday. Use the time to finish Hw#1, work on this week's lab, study for PE#1, or work on your dissection. jwb From pmw36 at msstate.edu Mon Sep 22 23:46:56 2008 From: pmw36 at msstate.edu (Michael Weir) Date: Mon Sep 22 23:47:11 2008 Subject: [ece4723] Task 3 Code Message-ID: I have reviewed and marked up the microcode (user.c) for Task 3. Teams can pick up their marked up copy anytime tomorrow from 4 - 9:30. I will either be in the Senior Design Lab, the Embedded Systems lab or the IEEE ADTRAN meeting. Some of the markings are not in the lab manual but are suggestions to make your code better. Common Mistakes: -Module Headers (Coding Standard Section 9.3) * No Module header * Module Header lacked all requested information * Copied from the robotics examples (Thus Thomas seems to have written about half of the user.c files. Each time implementing it in a different way) -Function Headers (Coding Standard Section 9.4) * No function headers * Function headers lacked all requested headers -Random Numbers * Ex: maxRecordedTemp = 0xFFFF; minRecordedTemp = 0; This is bad because a person maintaining the code may not immediately know where theses constants come from. This example is especially confusing because 0xFFFF represents the minimum temperature and 0 represents the maximum. Looking quickly a programmer would think that these lines were incorrect. Last many groups created utility functions (Good Thing). However, I would encourage you to place these functions in different file(s) than user.c. The task will get more complex and placing everything in user.c will hurt the readability of the code. Michael From jwbruce at ece.msstate.edu Wed Sep 24 08:39:33 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 24 08:39:40 2008 Subject: [ece4723] draft of Chapt 14 Message-ID: <5252624.16001222263573288.JavaMail.root@zimbra.ece.msstate.edu> A draft copy of chapter 14 (on ESOS) is available from Ms. Martha in the ECE office. She should be available during business hours 9-5. Sorry for the late delivery, but I only finished it yesterday. You may want to look over it for your labs and the exam tomorrow. enjoy. JWB PS: This is the first complete draft of the chapter, so it is a bit rough. ------------------ 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 Thu Sep 25 01:47:51 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Thu Sep 25 01:48:06 2008 Subject: [ece4723] new ESOS repository on 3724 website Message-ID: <32853114.20081222325271382.JavaMail.root@zimbra.ece.msstate.edu> Embedded System dudes: I've refreshed the ESOS repository .zip on the ECE3724 website. You will probably want to update your tree with this copy. Remember us talking about the disaster of bug-fixes especially one-line fixes in class.... Well, the change I made a couple weeks back to the ESOS scheduler in changing a "<" to an "<=" was wrong. Remember you have a 50-50 chance on one-line bug fixes. It is now fixed correctly. (I think ;-) The new repository also has my I2C service in it. The service is described in Chapter 14. 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 Mon Sep 29 10:08:33 2008 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Mon Sep 29 10:08:36 2008 Subject: [ece4723] Fwd: LaTeX Seminar In-Reply-To: <48DC17E2.1080909@ece.msstate.edu> Message-ID: <119541.33881222700913540.JavaMail.root@zimbra.ece.msstate.edu> Some of you may find this seminar useful, especially if you think you might go to grad school. LaTeX is used widely in some areas of research in EE, CPE, and CS, among other sciences. 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: "James E. Fowler" To: grads@ece.msstate.edu Cc: faculty@ece.msstate.edu Sent: Thursday, September 25, 2008 5:59:46 PM GMT -06:00 US/Canada Central Subject: LaTeX Seminar Dr. Ed Allen will be presenting an introduction to LaTeX in the introductory CSE graduate seminar class on Wednesday, Oct. 1. We have plenty of extra seating in the room. If you would like and introduction to formating documents in LaTeX, you are welcome to attend the class on October 1, 2008, at 1:00pm in Butler 100. Dr. Allen maintains a LaTeX template for dissertations and theses and most journals and conferences provide LaTeX templates. -- ======================================================================= | Dr. James E. Fowler | | Professor and Interim Graduate Program Director | | Department of Electrical & Computer Engineering | | GeoResources Institute (GRI) | | Mississippi State University | | | | fowler@ece.msstate.edu | | http://www.ece.msstate.edu/~fowler | | | ---------- Postal Address ---------------------- Contact Info --------- | Box 9571, 406 Hardy Rd. | HPC2: Rm. 208, +1 (662)325-2578 | | Mississippi State, MS 39762 | ECE: Rm. 406, +1 (662)325-3640 | | USA | Fax: +1 (662)325-7692 | ======================================================================= _______________________________________________ Faculty mailing list Faculty@ece.msstate.edu http://www.ece.msstate.edu/mailman/listinfo/faculty