From jwbruce at ece.msstate.edu Tue Sep 6 13:07:55 2011 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 6 13:08:14 2011 Subject: [ece4723] Fwd: The Embedded Muse 212 In-Reply-To: <201109061722.p86HMBiU027082@jade2.serverhost.net> Message-ID: <30898861.19531315332475079.JavaMail.root@zimbra.ece.msstate.edu> The latest Muse from Jack. 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: tem@freelists.org Sent: Tuesday, September 6, 2011 12:20:12 PM GMT -06:00 US/Canada Central Subject: The Embedded Muse 212 -------------------------------------------------------------- Embedded Muse 212 Copyright 2011 TGG September 6, 2011 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com Contents: - Editor's Notes - Quotes and Thoughts - Tools and Tips - The Tektronix MDO4104-6 - Contest! - NRE Response - The Dumbest Thing I Did - Jobs! - Joke for the Week - About The Embedded Muse Editor's Notes -------------- Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals? In fact it IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm . Alyona Lompar kindly translated that page into Belorussian! It's here: http://webhostingrating.com/libs/develop-better-be . What crazy times we live in. Companies are reluctant to hire, and even if that were not the case, there just aren't a lot of available embedded people. The implications are scary: each engineer will have to do more work. If we can't increase our productivity, we'll be doomed to more overtime, which is a sure way to lower productivity. Worse, time to market pressures are higher than ever, yet product complexity increases constantly. Companies are going to have to adopt different strategies to stay competitive. Unfortunately few teams keep detailed metrics, so usually have no quantitative productivity metrics. A few do. On average, these groups report a 40% increase in productivity when they adopt the suggestions from my Better Firmware Faster course. I'll be conducting public versions of this class in Chicago on October 21 and in London on October 28. Why not rev up your team? There's more info here: http://www.ganssle.com/classes.htm . Act now - there's a discount until September 21 for Chicago and the 28th for London. Many of you kindly filled out survey data for VDC. The summary of the results is here: http://www.vdcresearch.com/_documents/11_esdt_survey_hl.pdf . A couple of tidbits got my attention: - 51.9% report using C++ but only 11.9% use object oriented techniques. - 52% report the current engineering job market is better than last year; only 12% thought it was worse. Quotes and Thoughts ------------------ Be conservative in what you do, be liberal in what you accept from others. From RFC 793 Tools and Tips -------------- Keep those tools and tips coming. I've been playing with some new scopes and will post reviews. This week we'll look at a new offering from Tektronix; next issue I'll cover an iPhone scope. The Tektronix MDO4104-6 ----------------------- In the olden days we had scopes. Then digital scopes redefined the landscape, instantly obsolescing entire classes of storage tubes and scope cameras. In the 90s the mixed-signal scope unified both the oscilloscope and the logic analyzer, crucially adding cross-triggering so one could see how analog and digital events interacted in time. Tektronix has just taken the next logical step, though the idea had never occurred to me. Their new MDO4000 series of scopes marries an MSO to a spectrum analyzer (SA). (MDO is a new TLA for "Mixed Domain Oscilloscope.") Keeping true to the spirit of the MSO, the MDO can trigger off analog, digital or RF inputs. The company tells me that at least 60% of engineers who use a scope also use an SA. Really? That number seems huge. SAs have historically belonged to the domain of the RF engineer. But Tek says since 2006 the rise of wireless has changed all of this. 60% is still a bit much for me to swallow, so for those of you who have never used a spectrum analyzer, the SA is much like a scope, except it displays amplitude vs frequency, instead of amplitude vs time. The units have lots of associated features, of course, but their essence is working in the frequency domain. They kindly sent me a loaner MDO4104-6, which has four 1 GHz analog channels, 16 digital, a 5 GS/s sample rate and 6 GHz RF input. (Analog channels 3 and 4 are 2.5 GS/s). For some applications combining a SA and scope makes a ton of sense. Working on a frequency-hopping radio you could see the digital signals that initiate a hop, the associated analog, and the resulting RF to discover when the signal stabilizes, or if it overshoots, etc. Or you could watch the behavior of a PLL as it establishes a lock, which I did. Watching the PLL in the frequency domain was really enlightening. Each of the scope's three sections (analog, RF and digital) can be individually enabled. If only RF is on the entire screen becomes a full-featured spectrum analyzer. And what a screen it is, 10.4" of TFT crispness and color. Or just enable the analog to use this as a conventional oscilloscope. If the RF is on as well as analog and/or digital channels, the latter are on the top half of the display, and the spectrum on the bottom. A lot of scopes today have a built-in FFT math function, which rotates the time domain into the frequency domain. But those have significant limitations, starting with bandwidth. Cross-talk and other issues can (and do) corrupt the display. I find that these FFT functions are only crudely useful. In contrast, Tek's MDO has an RF stage that looks like one from a real SA, with plenty of shielding and lots of gain. For instance, I connected the RF input to an antenna (a short clip lead) and tuned to the FM band. Here in Finksburg, MD we're pretty far out in the country. A single top 40s station overpowers most of the others, and, sure enough, it popped up with -67 dBm of energy (on the order of 100 microvolts into a 50 ohm load). I enjoy listening to Car Talk Saturday mornings while working with loud woodworking machines in my shop, but my Peltor Worktunes headphones can barely pull the PBS affiliate out of the interference. Turns out that station tunes in with just -104 dBm of power. This is an impressive tool with all of the quality one expects from Tektronix. With a couple of exceptions I think it's ideal for people blending RF into their embedded systems. First, the boot time is appalling. A minute and twenty seconds. That's even longer than my old 545 tube scope used to take. Second, at times it's slow. An example is: if the RF side is enabled the analog channels' vertical positioning lags control inputs by a second or so. With RF on and the unit configured to acquire 20m points, horizontal panning is sometimes jumpy and erratic - and sometimes not. A hugely important feature is that you can pan through acquired RF spectra. It takes a bit of head scratching to understand, though. Suppose you acquire a single-shot of some analog data while also sucking in signals into the RF section. You can, of course, pan through the analog, and, as on any MSO, see pre-trigger and post-trigger events. The buffer holds up to 20 million points, so you can pan pretty far away from the trigger event. But, as the MDO acquired those 20m points, it also grabbed spectrum data from the RF input. So panning through the analog waveform also pans through spectrums on the bottom display. If you're watching a PLL stabilize you might see the VCO voltage on the top, analog display, and, as you pan across that, watch how the PLL's frequency moves around on the bottom display till it finally locks in. The spectrogram display (which is not unique to this product) is to die for. If enabled, it's shown immediately above the frequency plot, and is that plot rotated towards the operator. Intensity is shown by color. So each acquisition on the frequency display is rotated into a single line, one pixel high. Successive acquisitions build up so the spectrogram's vertical axis is the history of all of the RF traces. If you're monitoring a slowly-changing input - perhaps the center frequency is changing - the spectrogram shows that change over time. Watching the FM band some extremely weak stations were so buried in the noise that I couldn't pick them out on the frequency display, but the spectrogram clearly showed dim lines at their center frequencies. Concentric pan and zoom knobs let you waltz through the captured signals with great ease. It's a great interface. Two multipurpose knobs' functions vary depending on which screen is displayed, but the visual prompts are very clear. The one exception is the tiny font used on-screen to indicate whether multifunction knob "a" or "b" is in play; my middle-aged eyes found it very difficult to distinguish the difference. The unit is packed with features which are detailed on their web site. Those include plenty of math operations, all kinds of automated measurements, bus decoding (depending on options purchased), and markers which automatically identify RF peaks. The RF bandwidth is selectable. I very much like the small keypad that you can use to enter parameters, such as center frequency. Though I didn't see this mentioned in any of the literature, Tek engineers tell me the MDO captures phase and quadrature data, which can be downloaded to a PC. An application they provide can then demodulate the captured signals. This is a truly complex piece of test equipment that's quite intuitive to operate. There are so many modes and so much capability that I was disappointed in the manual, which despite being 200 pages long, leaves a lot of questions unanswered. One of those questions is "what's with the odd proby things?" The TPP1000 probes supplied have the BNC connectors encased in plastic boxes. Instead of pushing a BNC in and twisting to secure it, one just pushes the box thingamajig onto the panel-mounted BNC. No twisting allowed or needed. To release you press a button on the box. It works fine but what is the advantage over the age-old naked BNC connector? I mentioned that the MDO is, at times, slow to respond. I also experienced some odd behavior where the unit was unresponsive to a control. Twist a knob and nothing happens; wait a few seconds and full functionality is restored. I suspect Tek will fix this in production versions. Units run a base price of $20k to $28k. Options can drive that cost up a lot. It's a lot of money. But given that Tek's RSA3303B entry-level spectrum analyzer starts at $35k, and the MSO4104B (the same scope without the RF side) runs $20k, the MDO's price seems reasonable. There's more info here: http://www.tek.com/mdo4000 . Contest! -------- Microchip has generously donated chipKIT Max32 Arduino-Compatible Prototyping Platforms (see http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,892&Cat=18) for a contest. I promised to send units to the three readers who send in the best jokes. Well, the esteemed panel of judges couldn't whittle the list to less than four. Here are those: From Phil Baurer: C isn't that hard: void (*(*f[])())() defines f as an array of unspecified size, of pointers to functions that return pointers to functions that return void. Fred Strathmann sent this: Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob and a lever. "What do you think it is?" One advisor, an engineer, answered first. "It is a toaster" he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype." The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years." "With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes and waffles; pork divided into sausage, links and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs and various omelet classes." "The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself'. The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs." "Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon if frying, so concurrent processing is required, too." "We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting Ubuntu 11.02' appears on the screen. (Ubuntu 11.03 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook." "Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform the implementation phase. An ARM 9 processor with 16Gb of memory and a 500Gb hard disk should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)" The king wisely had the computer scientist beheaded, and they all lived happily ever after. Vlad Pambucol had me ROFL: Job Ad: "Security INC, computer security firm is looking for highly motivated hackers. Please post your resume on the first page of the microsoft.com website." And Jon Titus sent: A programmer and a hardware engineer were riding in a bus in a third-world country when guerrillas sprang out of the nearby jungle and took the two hostages. They walked for days until all arrived at the rebels' base camp. After several weeks and no response to ransom requests, the guerrillas decided they had to kill the hostages but would give each one last request. They went to the programmer and asked for his last request. He said, "I'd like to give you all a lecture about my latest Java project." Then they went to the hardware engineer and asked for his last request. He said, "Shoot me first." Thanks to all who did submit jokes. I'll run them in successive issues of the Muse. NRE Response ------------ Geoff Patch had a response to the last issue: "I read your article about using COTS processor boards in embedded systems with interest. In general I concur with your comments, but as you might expect, there are "corner cases" where the general rule does not apply. "Products in the consumer electronics markets (including the Agilent scopes that you discussed) typically have fairly short lifetimes. On the other hand, some application domains have product lifetimes that are almost absurdly long. We are still supporting products in the field that were originally designed and manufactured in 1991, and we are still successfully selling products that were originally designed in the late 1990's. "I'm pretty sure that had we used COTS boards in those products then we would no longer be able to support or build them as required. As it is, with very few exceptions, all of the components are still readily available and we can produce our custom boards as required. Component obsolescence is an issue, but not nearly as much of a problem as PCB obsolescence. "I guess the ultimate issue is about having control over your products. A few years ago we started using a variety of COTS processor boards in a system with an expected 20 year lifespan. We experienced problems with these boards that we had no control over, so we decided that we should go back to designing our own processor boards once again. "Obviously our application domain is fairly unusual, so perhaps we should just be considered as the exception that proves the rule." The Dumbest Thing I Did ----------------------- When interviewing I always ask candidates (those with experience) about their dumbest mistake and what they learned from it. Those with no mistakes are generally those with no experience - or are perhaps truthiness-challenged. Do you have any? David Bley admitted: "I have done a number of dumb things in my life. One that comes to mind is a design that I participated in. We were designing a product and our schedule was very aggressive and we needed an extensive feature set. I made the suggestion to use a PC motherboard (SX386 16MHz at the time). The product was loved by the users. The problem came when the CMOS battery went bad, and the message came up to press a key on the keyboard - there was no keyboard. The product had to be opened up to plug in a keyboard. The battery also had a tendency to leak and dissolve traces on the motherboard." Tom Harris submitted this: "But the above reminded me of what seemed to me to be the natural reaction at the time, on my first job (designing a cable modem from wire-wrap up), to the two VAX computers we had in our government lab. They sat in a computer room in the back of our electronics lab, behind a large glass window (of course). "The door was not locked, but it was restricted access. From a senior person I learned how to log in, and also that you could then log in remotely from one computer to the other. To log off of the second computer, you had to have defined an escape key for that session. "No sooner after I was left alone, I tried out my new skill. I should mention that the terminal was outside the computer room. I logged into computer A, then from there to computer B. When it asked me to define an escape code, I picked a letter at random, and remembered it. I did a few directory commands on computer B, and then thought, Why not log from there back into computer A? Repeating my steps, I was now in a new world on computer A. I think I got one more step along this path when people came back into the lab. "I tried to log out by retracing my steps. Needless to say, too many escape codes. I thought I was off the hook when the senior guys walked right past me. They went into the computer room, leaving the door open just enough that I could match some sound to their excited motions through the glass window. Who crashed _both_ VAX machines, they wanted to know. "But all being engineers, I got to keep my job." Stefano Zammattio had a story for this section: "A long time ago my department received some shiny new IBM PCs that I had the job of setting up. I showed a colleague how great they were and decide to teach him how to use DOS. "Later on that evening he rang me up. "'The computer is behaving really weird and I need it to finish my work for tomorrows deadline..." "To which I responded: 'Umm try switching it off and back on again....' "A short period later: 'Oh now it seems completely messed up...it's not doing anything..' "'What were you doing before it messed up?' "'Oh I was bored, so I was trying out some of the things you showed me, I was using edlin to look at some files. Some weird stuff in there.' "'What was the last file you looked at?' "'Uh, something like command.com....'" 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. There were no jobs submitted this week. Joke for the Week ----------------- Note: These jokes are archived at www.ganssle.com/jokes.htm. David Kramer found a great ad on Craigslist. Though not a joke it's pretty good, and reads, in part: In order to make sure the applicant has a working knowledge of the above skills, the following questions should be answered correctly. Each successful answer will result in a piece of an email address. Once a complete email address is constructed, the applicant can then use it to send their resume and a link to their A) Facebook page or B) LinkedIn page. Educational and professional experience qualifications are flexible. If you can solve the 5 puzzles below, and actually enjoy it, you're probably a good fit. For below, assume unsigned32 X, Y, Z; char foo[]; 1. Consider the MPC5674F processor. The 32 bit address of the Flash B Shadow Block starts at X. Use whatever resources you have to find X. 2. Y = ((X >> 16) & 0xFF) - 5; // use X from question 1 What is Y in hex? 3. Consider the S-record: S30B00EFBFFFFE635924182031 Using the above information, Z = (unsigned32) ( (*(byte *) X ); // use X from question 1 What is Z in hex? 4. sprintf( &foo, "Q%04x%2x\0", Y, Z); // use Z, Y from questions above 5. char foo2[11] = { 0x40,0x79,0x61,0x68,0x6F,0x6F,0x2E,0x63,0x6F,0x6D,x00 }; strcat( foo, foo2 ); puts( foo ); 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. From jwbruce at ece.msstate.edu Wed Sep 14 10:16:46 2011 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 14 10:16:50 2011 Subject: [ece4723] Task 3 files In-Reply-To: Message-ID: <22251187.58111316013406706.JavaMail.root@zimbra.ece.msstate.edu> I have placed the necessary Task 3 files on the lab website. jwb ----- Original Message ----- To: "J. W. Bruce" Sent: Tuesday, September 13, 2011 4:21:37 PM GMT -06:00 US/Canada Central Subject: Task_3 We were working on the task 3 assignment for the lab and ran into a particular problem. The lab instructs us to implement the i2cDeviceSerial module using the i2cDevice module provided by the TA. However, this module is not available through the lab website. Are we supposed to receive this module or implement it in addition to the i2cDevice serial? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ece.msstate.edu/pipermail/ece4723/attachments/20110914/3fa1bdfc/attachment.html From jwbruce at ece.msstate.edu Mon Sep 19 14:36:13 2011 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Mon Sep 19 14:36:29 2011 Subject: [ece4723] Fwd: The Embedded Muse 213 In-Reply-To: <201109191732.p8JHWvVE021834@jade2.serverhost.net> Message-ID: <26109737.79931316460973421.JavaMail.root@zimbra.ece.msstate.edu> the latest from Jack..... ------------------ 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: tem@freelists.org Sent: Monday, September 19, 2011 12:32:35 PM GMT -06:00 US/Canada Central Subject: The Embedded Muse 213 -------------------------------------------------------------- Embedded Muse 213 Copyright 2011 TGG September 19, 2011 -------------------------------------------------------------- You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com. EDITOR: Jack Ganssle, jack@ganssle.com Contents: - Editor's Notes - Quotes and Thoughts - The iMSO-104 - The Dumbest Thing I Did - Solution to the Job Ad - NRE - Jobs! - Joke for the Week - About The Embedded Muse Editor's Notes -------------- Lower your bug rates. And get the product out faster. Sounds too good to be true, but that's the essence of the quality movement of the last few decades. Alas, the firmware community didn't get the memo, and by and large we're still like Detroit in the 1960s. It IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm . I'll be conducting public versions of this class in Chicago on October 21 and in London on October 28. Why not rev up your team? There's more info here: http://www.ganssle.com/classes.htm . Act now - there's a discount until September 21 for Chicago and the 28th for London. ISO approved the new version of C++, named C++11. Does anyone in the embedded space care? I've talked to a number of embedded compiler vendors, and most told me it'll be a couple of years before their tools handle the new features. Any thoughts on C++11? Quotes and Thoughts ------------------ "You will say that I am always conjuring up awful difficulties & consequences - my answer to this is it is an important part of the duty of an engineer" Robert Stephenson, the engineer of the Britannia Bridge. The iMSO-104 ------------ The nice folks at Oscium loaned me a nifty mixed signal oscilloscope "plug-in" for the iPad, iPhone or iPod Touch. I put "plug-in" in quotes, as old timers will immediately think of the plug-in modules commonly used on scopes back when Maxwell had only figured out 2 of his equations. In this case, the entire scope, called the iMSO-104, is a tiny module that connects to the iThing's 30 pin connector. First reaction: the display is simply beautiful. Crisp, clean, simple in the ergonomic Apple way. I get to use a lot of scopes, and the modern high-end versions, too, have wonderful color displays. But those are often crowded with tons of information. Useful information, necessary, even. But simplicity can be stunning, and in the case of the iMSO it is. (A free demo version of the GUI is available from the App Store.) First, the biggest downer. At $297.99 I think it is overpriced. But it is cool. This thing is tiny, running about 1.5" x 2" x 0.3". It's not much more than a flat plastic box with a gold SMB connector sticking out for the analog probe. In operation a blue LED lights to let you know it has established comm with the iThing. The communications interface is very clean; if you disconnect the unit the app seamlessly goes to a demo mode, and it'll return to normal operation automatically when the hardware is plugged back in. The iMSO has a single analog and four digital channels, rated at 5 MHz and 12 MSPS. Its sample depth is 240 points. The vertical resolution isn't specified, but examination of a ramp waveform suggests it's 6 bits. As an MSO it has the usual cross-triggering between the analog and digital channels. The feature set is surprisingly rich. It will do a number of automated measurements, like peak-to-peak, RMS, frequency, etc. Pretty much all of the triggering modes you'd expect are included. It will do FFTs, and includes built-in calibration capabilities. You can vary the horizontal delay and hold-off. I tested the unit with an iPad 1 and an iPhone 4. The unit comes with a 1x/10x probe that has just over a foot of cable. I guess the idea is that even with the iThing connected it's all so small one can bring the tool to the work instead of snaking a cable to the scope. There are also 4 short digital leads that end in a connector that plugs into the iMSO. The unit takes full advantage of the iThing's features. There are no horizontal/vertical controls; one merely does the two-finger squeeze thing to expand or contract the display, which also sets the unit's sweep rate or vertical gain. Touch a balloon to the left of a trace and drag it up or down. Very unscope-like but it works extremely well. Trigger adjustments use the same paradigm: move a balloon on the right up or down to set the trigger level. The cursors, too, use the touchscreen interface. Screen shots are easier than on any other scope I've used. Just press the screen shot button, and then another to email it to yourself or someone else. The one problem is AT&T's miserable email service; it may take a while for them to deliver the mail. If you set the gain too high the signal will clip, just like on my fancy bench scope. But unlike that precision instrument, the iMSO helpfully displays a "Clipping" message. I couldn't find any accuracy claims, but the vertical measurements were low by about 10% when measuring a 100 Hz 0.5 volt peak-to-peak sine wave. A 5 volt input was accurate to better than 0.5%. But signals above 5 KHz yielded degraded voltage measurements; at 100 KHz a 5 volt sine wave was low by 10%. Frequency measurements were pretty much spot-on up to 500 KHz, and degraded rapidly after that. The triggering is somewhat erratic; a sine wave jumps a few pixels left and right with each acquisition. I wonder if the apparent 6 bit vertical resolution causes some trigger uncertainty. The device plugs into the iThing's charging connector and so is powered from the battery. The iPad/iPhone does not go to sleep as long as the app is running. But after 2.5 hours the iPad's charge level declined only from 100% to 78%, and the iPhone went from 100% charge to 67% after 1.5 hours of use. While the app is beautiful on the iPad, it nearly takes my breath away on the iPhone. Though the screen is, of course, much smaller, the idea of having a complete MSO in a pocket is pretty cool. Pretty soon we'll be able to fill our pocket protectors with an entire development lab. Most of these tiny scopes trade off features for size and price. The iMSO's 5 MHz bandwidth is about par for this class of device. It pales next to the big-bucks scope on the bench here, and is hopelessly inadequate for many, if not most, professional applications. But I can see a hobbyist or student getting a lot of use from it. And, have you ever lugged a big scope on a business trip? The iMSO sure appeals for travelers with low-bandwidth needs. One does wonder how it will fare in the market at nearly $300, when other similar units are available for much less, such as the DSO series from Seeed. I have not used those, yet, so can't make a comparison. There's more here: http://oscium.com The Dumbest Thing I Did ----------------------- When interviewing I always ask candidates (those with experience) about their dumbest mistake and what they learned from it. Those with no mistakes are generally those with no experience - or are perhaps truthiness-challenged. Do you have any? Jonathan Graham Harston had this confession: Ok, I'll bite. This was 28 (eek!) years ago. I was putting together some code to remotely control another computer on the local network. I'd forgotten that my skeleton code took a hexadecimal parameter. There I was sitting watching station 10 while I entered "remdb 10". Just as I was wondering why nothing was happening I heard a "hey!" from over at station 16.... Solution to the Job Ad ---------------------- In the last Muse I ran a job ad that David Kramer found on Craigslist. It was a puzzle whose solution yielded the email address one would apply to. I heard from quite a few folks who solved the puzzle. A couple had witty responses. And, the original author of the puzzle chimed in. I admitted to Dan Swiger that I hadn't looked for a solution, and he responded: Awwww come on! You mean you never spent an hour with your TiVo paused during "Adult Swim" on Cartoon Network, figuring out the all binary "bump" they had between shows? Well, at least post in your next Muse if anybody else chimes in with an answer. Here's my complete derivation, for the record. 1. Consider the MPC5674F processor. The 32 bit address of the Flash B Shadow Block starts at X. Use whatever resources you have to find X. >From Reference Manual: 0x00EFC000 2. Y = ((X >> 16) & 0xFF) - 5; // use X from question 1 What is Y in hex? 0x00EFC000 >> 16 = 0x00EF & 0xFF = 0xEF - 5 = 0xEA Y = 0x000000EA 3. Consider the S-record: S30B00EFBFFFFE635924182031 Using the above information, Z = (unsigned32) ( (*(byte *) X ); // use X from question 1 What is Z in hex? Sz Addr Data Chksum S3 0B 00EFBFFF FE 63 59 24 18 20 31 Z = The byte at 0xEFC000, which is the 2nd data byte Z = 0x00000063 4. sprintf( &foo, "Q%04x%2x\0", Y, Z); // use Z, Y from questions above foo[] = "Q00EA63" 5. char foo2[11] = { 0x40,0x79,0x61,0x68,0x6F,0x6F,0x2E,0x63,0x6F,0x6D,x00 }; strcat( foo, foo2 ); puts( foo ); "Q00EA63@yahoo.com" Chester Page sent this solution: Dear Dr[1] Jack -- I -- like most of your readers, I trust -- would, of course, no more let this red rubber puzzle just bounce by than Florence Ambrose [2] would let a red rubber ball just bounce by (or, for that matter, this red rubber puzzle). Making a few assumptions, I arrived at However, by the time I had arrived at that result, it was definitely a matter of Zwischenaugenbrauenabstand--. [3] Read on. : David Kramer found a great ad on Craigslist. Though not a joke it's : pretty good, and reads, in part: : : In order to make sure the applicant has a working knowledge of the : above skills, the following questions should be answered correctly. : Each successful answer will result in a piece of an email address. : Once a complete email address is constructed, the applicant can then : use it to send their resume and a link to their A) Facebook page or : B) LinkedIn page. I have neither a Facebook page nor a LinkedIn page, as I regard the former as pointless and the latter as useless; and I am given to understand that this is an attitude common among the unkempt-desk set. Is this perhaps a subtle trap for Those Who Tweet? And I have no resume: past the age of 50, why bother? : Educational and professional experience qualifications are flexible. : If you can solve the 5 puzzles below, and actually enjoy it, you're : probably a good fit. : For below, assume unsigned32 X, Y, Z; char foo[]; : 1. Consider the MPC5674F processor. The 32 bit address of the Flash B : Shadow Block starts at X. Use whatever resources you have to find X. Google trivially links to a datasheet for the part; a diligent search of the datasheet reveals that ++Moto apparently doesn't consider a memory map a necessary feature of a datasheet. Visiting the corporate Web site turns up a Reference Manual, which does include one; the address of the Flash B Shadow Block is given as 0x00EFC000. Note, however, that what this item *actually* states is X = &32bitaddressoftheFlashBShadowBlock rather than X = (uint32) &FlashBShadowBlock which must be assumed to have been *intended*, as the puzzle would otherwise be insoluble. : 2. Y = ((X >> 16) & 0xFF) - 5; // use X from question 1 : What is Y in hex? 0x00EF - 5 = 0x00EA (If this advert were aimed at Dan Saks, it would presumably have left out all of the parentheses here...) : 3. Consider the S-record: S30B00EFBFFFFE635924182031 : Using the above information, : Z = (unsigned32) ( (*(byte *) X ); // use X from question 1 : What is Z in hex? Happily, I have not had to deal with S-records for nearly two decades, and am quite content to be hazy on the interpretation of their entrails; but, as usual, Google knows all about them, so that I may be an S-record Expert for just long enough to parse this one as S3 0B 00EFBFFF FE 63 59 24 18 20 31 or 0x00EFBFFF 0xFE 0x00EFC000 0x63 0x00EFC001 0x59 --- usw --- It is necessary to assume that X points into an address space which has been initialized by at least the single S-record given prior to the value of Z being determined; otherwise, the puzzle would, again, be insoluble. : 4. sprintf( &foo, "Q%04x%2x\0", Y, Z); // use Z, Y from questions above It would be interesting to see what the compiler makes of the declaration char foo[]; given that it seems about one parameter shy of a load. Of course, if it's a Micro$oft compiler, it might helpfully supply a default value - perhaps 0 or 1? (Can you name a Crackers' Delight for which M$ browsers are famous?) And making the format string "Q%04x%2d\0" would have been a nice touch. : 5. char foo2[11] = { 0x40,0x79,0x61,0x68,0x6F,0x6F,0x2E,0x63,0x6F,0x6D,x00 : }; : strcat( foo, foo2 ); : puts( foo ); (Note that the last initializer of foo2[] is "x00", not "0x00". The absence of any obvious typos in this item suggests a cut-and-paste from the original, which suggests ... ?) First and foremost, with or without its pin pulled, mr is *not* your friend; I consider being unable to decide what third parameter to pass to a sure sign of a design decision inadequately decided. And what if memory -- perhaps by reason of legacy -- should prove to be structured something like this? char foo[5]; char foo2[11] = .... ; (I have found it advisable to do a complete cold power-off-and-on reboot when Window$ goes catatonic -- followed, of course, by running against every hard drive on the system.) One hopes that the Craigster is a truly *devious* custard, looking for replies viewing the puzzle as dubiously as does the above, as I should otherwise prefer to observe any system controlled by software developed by his operation from a prudent distance -- eg, light-seconds. [1] I reckon that, as no-one objects to ThemAsCant heaping honors upon ThemAsHaventYetAndMayNever, no-one can reasonably object to ThemAsDo doing the same by ThemAsDoEgregiously [2] Start at the beginning. Pee first. [3] inter-eyebrow separation Joe Craig - a pseudonym - wrote this: You recently put up part of a post that I had constructed on your "The Embedded Muse" (212) site under the "Joke of the Week" section. I never expected my post to go 'viral' (even in a small nerd way) and appreciate the notoriety. 11 of your followers took the challenge (although belatedly) and responded correctly. I enclose a message I sent to all. For all those who recently wrote in via "The Embedded Muse - 212" shoutout, you all did it! Cheers! Some background: I'm a working manager for an embedded software group in a large, all-too-Dilbert-like company. This 'puzzle' was a result of my extreme frustration with the standard process of hiring - either direct or contract. Very few applicants were getting through the main channel, and those that did were not what we were looking for. So, rather than admit defeat, I decided to go rogue. I posted on the LA CraigsList on Aug 4, 2011 and received 5 correct responses within a week, 2 within the first 4 hours, 2 more within 48 hours and a straggler at the 6 day mark. Apparently, after the gracious post in Jack's column on 09/06, 11 more came in. Since the ad was only up for a week I wasn't expecting any responses afterwards so I haven't been monitoring the q00ea63 account. I just logged in for fun and found - much to my delight - this unexpected avalanche of correct responses - apparently this is the site to go to for bright embedded systems folks. It gets better. I couldn't help but notice the post was filed under "Joke of the Week". Turns out this was an appropriate heading. After selecting two of the original applicants and conducting several phone interviews and eventually personal interviews over the course of a few weeks, getting them started in the 'official' chain of hiring, and interviewing them *again*, getting them set up with contract agencies and telling them to prepare for onboarding, upper management decides to implement a hiring freeze. I couldn't believe it. I know most of you who wrote in are just puzzle solvers (I am as well) and weren't really interested in the job. Most expressed appreciation for the manner in which I went about posting - To those folks: Thanks. I appreciate the sentiments and hope everyone gets a chance to do something equally satisfying. FYI, here is the complete job posting uploaded to the CraigsList "Gigs" section: Embedded Systems Software/Firmware Engineer, EE background a plus This opportunity is for those who wish to live and work within 4 miles of a beautiful beach in Southern California making $45-$55/hr. The initial position will be contract based. Qualified candidates who accept the position and can show they are a 'fit' will have the potential to hire on receiving full time permanent employee status. The position involves creating and maintaining very highly structured C code 'classes' for an organization involved in the automotive industry. The focus of our group is providing controls software for power electronics - we're enabling higher MPG in vehicles by creating viable electric propulsion systems. The primary skill set we're interested in for this position is as follows: *Proficiency in writing highly optimized C code *Proficiency in debugging and creating test cases *Some knowledge of electrical engineering, EE a plus *Fundamental knowledge of embedded processor architectures *Ability to master software simulation and 'hardware in the loop' testing *Good communication skills *Ability to follow and adhere to design processes In order to make sure the applicant has a working knowledge of the above skills, the following questions should be answered correctly. Each successful answer will result in a piece of an email address. Once a complete email address is constructed, the applicant can then use it to send their resume and a link to their A) Facebook page or B) LinkedIn page. Educational and professional experience qualifications are flexible. If you can solve the 5 puzzles below, and actually enjoy it, you're probably a good fit. For below, assume unsigned32 X, Y, Z; char foo[]; 1. Consider the MPC5674F processor. The 32 bit address of the Flash B Shadow Block starts at X. Use whatever resources you have to find X. 2. Y = ((X >> 16) & 0xFF) - 5; // use X from question 1 What is Y in hex? 3. Consider the S-record: S30B00EFBFFFFE635924182031 Using the above information, Z = (unsigned32) ( (*(byte *) X) ); // use X from question 1 What is Z in hex? 4. sprintf( &foo, "Q%04x%2x\0", Y, Z); // use Z, Y from questions above 5. char foo2[11] = { 0x40,0x79,0x61,0x68,0x6F,0x6F,0x2E,0x63,0x6F,0x6D,0x00 }; strcat( foo, foo2 ); puts( foo ); NRE --- Paul Carpenter had some thoughts: "I agree whole heartedly with Geoff, with some examples. "Lots of markets have VERY long lifespan, most of which are also ROHS exempt as well for the same reasons. Mainly military, transport and medical, where transport includes aviation, railways, busses and trucks. "Many of these have equipment 30 years old. "Around 2002 I was asked to look at designing some electronics to replace PART of an NMR machine, when asked how old it was they replied "The earliest date we have is a memo about moving it to the new building in 1968" "One of my testers for avionics parts was to initially have a 20 year support phase, to be able to be rebuilt if necessary from scratch. "Often PC motherboards are only available on EBAY as second-hand or surplus within a year. Let alone the fools who want to use a particular smartphone/PDA type device as the basis of their product, even down to power and mechanical mounting problems in trucks or vehicles. "The other issue with COTS is OS and software licensing, a lot of products from routers to TVs have a form of Linux in them for many reasons, one of which is ability to add your own drivers easily without extra cost or deal with the driver hell, certification etc. "Another good reason, it is easier to get much faster startup time -switch on to running. "Making products with Windows PCs and the ever changing OS version, processors, bus types, form factors and other hurdles is a right ongoing engineering and maintenance issue. Which you can take the HP attitude stop supporting as many printers and multi function devices as soon as a new OS appears. "This is already a problem for offices where they have printers and scanners, let alone multi-function printer/scanner, that now does not work because the manufacturer does not do the drivers and applications for the new OS. I am not talking about entry level inkjet models. "So why does this matter for scopes and the like, well any product that potentially supports USB, ethernet, sometimes WLAN and Bluetooth, you have to upgrade your support for new OS on the PC host. Already a lot of scopes with COTS internals have PC host applications, that can no longer be used as they don't support new OS for that OLD model of scope. "Imagine having the problem of USB drive/memory stick that has a new file format you scope does not support, or a memory size beyond its capabilities. Things like scopes are a higher assett value cost than a simple desk PC. "Scopes are around for at least 5 years (often longer), whereas a PC is normally around for a maximum of 5 years." 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. I have an upcoming need for two (perhaps more) individuals with embedded systems experience. Some embedded Linux experience is definitely a plus. Relocation not necessarily required, but ability to occasionally work at a client's site for up to two weeks (USA mostly, some international travel possible) at a stretch is. Candidate must be a legal USA resident and be fluent in English. The ideal candidates are teachable and have good communications skills. No whiners. Please email PDF resumes (no more than two pages) to me at bgat@billgatliff.com. The Firmware Engineering Manager (Englewood, NJ) will manage and coordinate the projects and activities of a team of firmware engineers to design, develop and test firmware. Duties will also include definition of the design methods used and the overall platform development. Please send all resumes to pgrant@furmanfeiner.com HP has 2 openings for BIOS/Embedded Engineers who are interested in designing/developing with UEFI. Please apply at http://www8.hp.com/us/en/jobsathp/index.html and search for Job Number 610348 or 657177. As the Firmware Engineering Manager of our new RTP North Carolina location, you will be afforded the unique opportunity to build a team from the ground up. You will create and lead a new team of firmware engineers to design, develop and test firmware for Crestron's leading edge technologies. Primary Duties and Responsibilities include but are not limited to: * Hire, motivate and manage a cohesive development team of firmware engineers to establish and meet aggressive project commitments and timeline deliverables. * Direct the activities of the firmware engineering group to design, develop, test and maintain Crestron products using industry best practices. * Continually look for ways of improving the development processes and delivery timelines. Please apply to www.crestron.com/careers Joke for the Week ----------------- Note: These jokes are archived at www.ganssle.com/jokes.htm. John Visosky sent this: The joke about the guerrillas and their hostages reminded me of this oldie: Three friends went on a vacation to a barbarous third-world country. One morning, after a night of wild partying that none of them could remember, they woke up in jail. It turns out they were to be executed that day. As the first one was strapped into the electric chair, he was asked if he had any last words. He said, "I hold a law degree from Harvard, and I believe in the power of Justice to save me!" The switch was thrown and nothing happened, so he was set free. As the second one was strapped into the electric chair, he was asked if he had any last words. He said, "I hold a divinity degree from Yale, and I believe in the power of God to save me!" The switch was thrown and nothing happened, so he was set free. As the third one was strapped into the electric chair, he was asked if he had any last words. He said, "I hold a masters degree in Electrical Engineering from MIT, and if you don't connect those two wires, this thing'll never work!" 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. From jwbruce at ece.msstate.edu Tue Sep 27 12:40:42 2011 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Tue Sep 27 12:40:55 2011 Subject: [ece4723] Fwd: Effective C Tip #9 - Use #warning In-Reply-To: <29206255.115761317145045724.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <23982099.115801317145242373.JavaMail.root@zimbra.ece.msstate.edu> Here's another newsletter.... this one is from Netrino who does embedded system development and consulting. During the development of the hardware support libraries and the port/revision of ESOS to the PIC24 architecture, Jones developed a set of run-time assertions and I developed a set of compile-time assertions. Most of these have been removed in the "shipping" code, but the compile-time assertions made great use of the #error and #warning pragmas described in Tip #9. Enjoy. PS: Maybe I should starting writing a newsletter or blog. It is getting quite rare that I see something in these that I haven't already done, seen, or experienced. ;-) ------------------ 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: "Michael Barr" To: jwbruce@ece.msstate.edu Sent: Tuesday, September 27, 2011 11:43:58 AM GMT -06:00 US/Canada Central Subject: Effective C Tip #9 - Use #warning Effective C Tip #9 - Use #warning Having trouble viewing this email? Click here ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Firmware Update - September 27, 2011 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ in this issue -- Effective C Tip #9 - Use #warning -- Embedded Software Forensic Analysis -- What's the State of Your Cortex? -- Industry News That's Not Boring! -- Last Chance to Master Firmware Engineering in 2011 Firmware Update is a free newsletter by embedded software expert Michael Barr. It is Copyright 2011 by Netrino, LLC, but may be reprinted for non-commercial purposes. Please forward it to colleagues who may benefit from the information. Effective C Tip #9 - Use #warning ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Back in 1999, my fellow embedded guru Nigel Jones wrote an article for Embedded Systems Programming magazine concerning the #error preprocessor directive . While the #error directive has remained one of his favorite tools for effective C programming, he has become an equally big fan of #warning. The use of #warning is simple enough. After showing how to use it, Nigel explains how and why he uses #warning to protect incomplete code and comment out code. Learn to use #warning... Embedded Software Forensic Analysis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's said that medical charts are written by doctors but only ever really read by lawyers. The same is sometimes true of the artifacts of our embedded software development and testing processes. To understand the perspective of the lawyers and experts who may someday review your code in a legal proceeding, read my latest blog post about best practices for firmware expert witnesses. Think like a lawyer for a few minutes... What's the State of Your Cortex? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Recently, Miro Samek was involved in a fascinating bug hunt related to a very peculiar behavior of the ARM Cortex-M3 processor. Given the incredible popularity of this core, he decided to blog about what he learned by digging deep into the mysteries of ARM Cortex and its RTOS-supporting features. Find out if Cortex has a bug... Industry News That's Not Boring! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An Interesting Software Liability Proposal http://t.co/rvRy1Qll What happens when the printed ballot face doesn't match the electronic ballot definition? http://t.co/qTLXf2Lv How to Navigate the New Patent Law http://t.co/PEcbpUBC New privacy invasions brought to you every day by increased processing power, new sensors, new algorithms. http://t.co/bUDw0Ua How to Build an iPad Oscilloscope: http://t.co/DiatT67 Military tanks test infrared camouflage cloak. http://t.co/BkzmD2m Amazing the things cheap, fast computing can do. Micrium's new MicroC/OS-III RTOS is now source code available, just as the earlier version was. Details: http://t.co/0DUZphx New from Google: Draw a graph and learn what real-world data correlate with your curve. Good clean geek fun: http://t.co/u9pxH2x Read more stuff like this... Last Chance to Master Firmware Engineering in 2011 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The final public Embedded Software Boot Camp of 2011 will be held in less than a month. This intense and fun hands-on educational program will quickly and dramatically improve the quality of the embedded software created by the individuals and teams who attend. Sign up before it is too late... Quick Links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ? Embedded C Coding Standard ? Free How-To Articles ? Embedded Systems Glossary ? Embedded Systems Blogs Contact Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ email: mbarr@netrino.com phone: 866.78.EMBED web: http://www.netrino.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forward email This email was sent to jwbruce@ece.msstate.edu by mbarr@netrino.com | Update Profile/Email Address | Instant removal with SafeUnsubscribe ? | Privacy Policy . Netrino, LLC | 6030 Marshalee Dr, Suite 355 | Elkridge | MD | 21075 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.ece.msstate.edu/pipermail/ece4723/attachments/20110927/c3b35136/attachment-0001.html From jwbruce at ece.msstate.edu Wed Sep 28 08:32:43 2011 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 28 08:32:48 2011 Subject: [ece4723] Re: LCD In-Reply-To: <23524485.118461317216459148.JavaMail.root@zimbra.ece.msstate.edu> Message-ID: <30977425.118501317216763732.JavaMail.root@zimbra.ece.msstate.edu> The pst_lcd structure should be filled in when calling the HW (*_pic24_config) config function. This function will do whatever is necessary HW-wise to prepare the display. In our case it will set the direction of the appropriate port pins, and put the LCD connection into the "idle" state. If we had some kind of HW between the MCU and the LCD, it would ready it at this time. If ESOS is ported to some other MCU, there would be an esos_MCUARCH_config_char_lcd() routine. It shouldn't be hard to imagine that another MCU might require a little or a lot more HW config depending on its capability or the way the LCD is connected. The pst_lcd structure is used again in calling the ESOS HW-independent function esos_lcd_configDisplay() to setup the ESOS structures and other misc. This routine only manipulates things that do NOT dependent on the HW. All ports of ESOS will call this function so it cannot assume anything about the HW or must use HW-specific routines that have already been resolved in the esos_MCUARCH_config_char_lcd() function. In summary: esos_pic24_config_char_lcd() -- SETUP ANYTHING PIC24-specific to driving the LCD module esos_lcd_configDisplay() -- setup ANYTHING that is NOT specific to the HW-implementation Typically ESOS structures, state, variables, etc. esos_lcd_init( ) -- "cause" the ESOS LCD service to run through the LCD init sequence described in the data sheet. Must be done AFTER the 2 config routines do their thing. Will conclude by putting the LCD service task into the "normal" running state ready to respond to LCD transactions. u16_lcdflags is a member of the lcdStruct that contains flags pertinent to the LCD state or operation. It is currently defined as the flags required during config and the state of operation like what the cursor/blink etc is doing. I am open to replacing the RESERVED flags with others if y'all find they would be helpful as you write the code. These flags are supposed to make your life a bit easier. ----- Original Message ----- From: "Andrew M. Turner" To: jwbruce@ece.msstate.edu Sent: Tuesday, September 27, 2011 5:31:34 PM GMT -06:00 US/Canada Central Subject: LCD There's some confusion about what the esos_pic24_config_char_lcd() function actually does. From our talk, I was under the assumption that it's just a placeholder where any necessary hardware configuration would take place (the PIC doesn't have to do any, so the function doesn't actually do anything in this instance). Is this correct, or is it where the struct is actually populated with all of the configuration info? Also, the u16_lcdflags is just an OR of all the flags that the LCD is currently using, correct? -AT From jwbruce at ece.msstate.edu Wed Sep 28 09:43:32 2011 From: jwbruce at ece.msstate.edu (J. W. Bruce) Date: Wed Sep 28 09:43:35 2011 Subject: [ece4723] Fwd: R&D Positions available at ARM In-Reply-To: <98F32EC512940D42A118DF04112005C3227226FE7E@SPOCK.usa.Arm.com> Message-ID: <24396448.118851317221012929.JavaMail.root@zimbra.ece.msstate.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Systems Graduate - Austin_v1.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 17976 bytes Desc: Systems Graduate - Austin_v1.docx Url : http://www.ece.msstate.edu/pipermail/ece4723/attachments/20110928/4a88ca33/SystemsGraduate-Austin_v1-0001.bin