标签: application

My chum, Rich Quinnell, recently wrote an article titled: Embedded systems survey uncovers trends concerns for engineers . Based on this, Bob Snyder emailed Rich some very interesting comments and questions.   Rich brought me into the conversation and -- with Bob's permission -- we decided I should post this blog presenting his comments and questions, and soliciting input from the community. So here is Bob's message: Richard, I really appreciate the hard work that the folks at UBM do to provide the embedded survey results. It seems as though non-real-time, soft real-time, and hard real-time applications have very different requirements. I have been closely studying the survey results for many years and trying to understand (or imagine) how the responses to some of the questions might be correlated. For example, it would be nice to know how the overall movement to 32-bit MCUs (most of which have cache) breaks down by application (e.g., non-real-time, soft real-time, and hard real-time). Are popular 32-bit MCUs, such as ARM and MIPS, being widely adopted for hard real-time applications where worst-case execution time is at least as important as average-case execution time, and where jitter is often undesirable? If so, do people disable the cache in order to achieve these goals, or simply throw MIPS at the problem and rely upon statistical measures of WCET and jitter? Performance penalty of completely disabling the cache Microchip's website explains how to completely disable the cache on a PIC32MZ (MIPS 14K core). The article says that doing this will reduce performance by a factor of ten: "You probably don't want to do this because of lower performance (~ 10x) and higher power consumption." Somebody at the University of Toronto ran a large set of benchmarks comparing various configurations of a specific ARM processor. When they compared a fully-enabled cache configuration to an L2-only configuration, the L2-only setup was six times slower (shown in the red rectangles below). It seems reasonable to assume that if L2 had also been disabled, performance would have been even worse.   Based upon this data, it seems reasonable to conclude that when the cache is completely disabled on a 32-bit micro, the average performance is roughly ten times worse than with the cache fully enabled. Why would anyone use a cache-based MCU in a hard real-time application? The fastest PIC32 processor (the PIC32MZ) runs at 200 MHz. With the cache fully disabled, it would effectively be running at 20 MHz. The 16-bit dsPIC33E family runs at 70 MHz with no cache. Admittedly, the dsPIC will need to execute more instructions if the application requires arithmetic precision greater than 16 bits. But for hard real-time applications that can live with 16-bit precision, the dsPIC33E would seem to be the more appropriate choice. I am having trouble understanding the rationale for using an ARM or PIC32 in a hard real-time application. These chips are designed with the goal of reducing average-case execution time at the expense of increased worst-case execution time and increased jitter. When the cache is disabled, they appear to have worse performance than devices that are designed without cache. Atmel's 32-bit AVR UC3 family has neither an instruction cache nor a data cache, so this is not a 32-bit issue per se. But it seems that the majority of 32-bit MCUs do have cache and are targeted at soft real-time applications such as graphical user interfaces and communication interfaces (e.g. TCP/IP, USB) where WCET and jitter are not major concerns. Breakdown by market segment It seems to me that there will always be a large segment of the market (e.g., industrial control systems) where hard real-time requirements would mitigate against the use of a cache-based MCU. It would be interesting to see the correlation between choice of processor (non-cached vs. cached, or 8/16 vs 32 bits) and the application area (soft real-time vs. hard real-time, or GUI/communications vs. industrial control). I wonder if it would be possible to tease that out of the existing UBM survey data. Looking at the 2014 results With regard to the question: "Which of the following capabilities are included in your current embedded project?" We see that over 60 percent of projects include real-time capability. The question does not attempt to distinguish between hard and soft real-time. And the 8/16/32-bit MCU question does not distinguish between cached and non-cached processors. Nevertheless, it might be interesting to see how the 8/16/32 bit responses correlate with the real-time and non-real-time responses, or signal-processing responses. I find it hard to believe that a large number of projects are using cached 32-bit processors for hard real-time applications. It is interesting to note that every response for the capabilities question shows a falling percentage between 2010 and 2014. This suggests that other categories may be needed. I suppose it is possible that fewer projects required real-time capabilities in 2014, but it seems more likely that there was an increase in the number of projects that required other capabilities such as Display and Touch, which are not being captured by that question. Thanks for considering my input, Bob Snyder.   Well, it's certainly true that non-real-time, soft real-time, and hard real-time applications have different requirements, but I'm not sure how best to articulate them. Do you have expertise in this area? Do you know the answers to any of Bob's questions? How about Bob's suggestions as to how we might consider refining our questions for the 2016 survey? Do you have any thoughts here? If so, please post them in the comments below.

Keeping a record of the design progress, measured results, decisions made, and calculations performed are all part of the job description for any engineer. There are many aspects to any project, and for a project involving microcontrollers and/or programmable logic, this is compounded by programs that are compiled down to object code. The reasons we need to keep the records include (but are not limited to):   Prove that the design works Obtain data for use in data sheets Determine approaches for testing the unit Patents Legal liability Accounting auditing (for tax credits or progress payments) ISO auditing. My current approach is very 20 th Century -- being completely paper driven. I have a 3-ring binder in which I keep requirements, data sheets, listings, schematics, sundry pieces of paper like POs as well as a notebook. In truth the notebook is more of a scrapbook. It contains hand written notes, drawings and calculations along with clippings pasted in like Excel worksheets, photos, ‘scope plots, design reviews and other details. It is all very clumsy and especially stressful when trying to follow a trail during an ISO audit.   The app I want would replicate the design binder (with improvements) as a single file. I imagine it would have to be distributed across a PC as well as a tablet. Of course it would start with the ability to enter text on a keyboard and have the ability to include MSWord and pdf files. It would be possible to add handwritten notes, preferably with a stylus since it works better than my finger for writing. Converting the handwritten text to machine readable format would be a plus when searching for something. The app would have the ability to add notation to the included pdf sheets. It would need a simple spreadsheet since I sometimes gather data at an environmental chamber away from my desk and then execute some simple calculations. But it would also need to be able to integrate more complex calculations from Excel or even Matlab although I would settle for screen shots with hyperlinks to the respective files.   I would like to see a feature to add bookmarks so that there could be cross linkages throughout the file. Cross linkages into source code would really be nice, since some data cannot be included in the source files.   Interfacing to instrumentation like DVMs or ‘scopes through USB or Wi-Fi is probably unrealistic in the short term, although if there was a script or programming language it could be customized.   Obviously there would be a central folder location where all the electronic files reside but synchronization should be as transparent as possible.   There are dozens of apps that address some aspects of my wish list, but so far I haven’t found any that allows any really cohesive approach. We have the technology, and I hope this blog nudges someone to produce this ultimate app. Sometimes I feel that a laptop may answer my hardware requirements and the Windows environment comes closest to the level of integration that I need, but the handwritten input is important and the clam-shell format is often inconvenient. The AceCAD Digimemo L2  also has potential as an input device, allowing the full pen and paper experience, but the approach lacks some of the other features I would like.   How do you document your projects? Do you know of any app that approaches my needs?   Aubrey Kagan

Max's recent blog ( I've been a naughty engineer ) sent me rummaging through my own notebooks for something I wrote a while back:    Keeping a record of the design progress, measured results, decisions made, and calculations performed are all part of the job description for any engineer. There are many aspects to any project, and for a project involving microcontrollers and/or programmable logic, this is compounded by programs that are compiled down to object code. The reasons we need to keep the records include (but are not limited to):   Prove that the design works Obtain data for use in data sheets Determine approaches for testing the unit Patents Legal liability Accounting auditing (for tax credits or progress payments) ISO auditing. My current approach is very 20 th Century -- being completely paper driven. I have a 3-ring binder in which I keep requirements, data sheets, listings, schematics, sundry pieces of paper like POs as well as a notebook. In truth the notebook is more of a scrapbook. It contains hand written notes, drawings and calculations along with clippings pasted in like Excel worksheets, photos, ‘scope plots, design reviews and other details. It is all very clumsy and especially stressful when trying to follow a trail during an ISO audit.   The app I want would replicate the design binder (with improvements) as a single file. I imagine it would have to be distributed across a PC as well as a tablet. Of course it would start with the ability to enter text on a keyboard and have the ability to include MSWord and pdf files. It would be possible to add handwritten notes, preferably with a stylus since it works better than my finger for writing. Converting the handwritten text to machine readable format would be a plus when searching for something. The app would have the ability to add notation to the included pdf sheets. It would need a simple spreadsheet since I sometimes gather data at an environmental chamber away from my desk and then execute some simple calculations. But it would also need to be able to integrate more complex calculations from Excel or even Matlab although I would settle for screen shots with hyperlinks to the respective files.   I would like to see a feature to add bookmarks so that there could be cross linkages throughout the file. Cross linkages into source code would really be nice, since some data cannot be included in the source files.   Interfacing to instrumentation like DVMs or ‘scopes through USB or Wi-Fi is probably unrealistic in the short term, although if there was a script or programming language it could be customized.   Obviously there would be a central folder location where all the electronic files reside but synchronization should be as transparent as possible.   There are dozens of apps that address some aspects of my wish list, but so far I haven’t found any that allows any really cohesive approach. We have the technology, and I hope this blog nudges someone to produce this ultimate app. Sometimes I feel that a laptop may answer my hardware requirements and the Windows environment comes closest to the level of integration that I need, but the handwritten input is important and the clam-shell format is often inconvenient. The AceCAD Digimemo L2  also has potential as an input device, allowing the full pen and paper experience, but the approach lacks some of the other features I would like.   How do you document your projects? Do you know of any app that approaches my needs?   Aubrey Kagan

Bosch’s Home Connect app, slated for release later this year, will control appliances, not only from Bosch and Siemens but from other brands as well, according to Claudia Häpp, digital transition project leader for Home Connect at the BSH group, the holding company that owns Bosch and Siemens.   Google’s recent acquisition of smart thermostat maker Nest Labs is fueling the market for connected appliances and the race to engage customers who want to control their home appliances via the Internet.   BSH will launch Home Connect for iOS this year and an Android version in 2015. The application is open to connect different types of products, brands, and services.   Speaking at the IFA Global Press Conference in Belek, Turkey, last month Häpp outlined the current level of connectivity in most households:   In Germany, for instance, four out of five households have WiFi access. At the same time, nearly half of the German population uses a smartphone. Up until today, over 50 billion apps have been downloaded from Apple's App store. In addition to that we have all those from Google Play and other app stores. That means that every person in the world owns about seven apps -- even those that do not have a smartphone.   From the BSH presentation at the IFA press conference.   "Even though we would like everyone to only buy our appliances, the reality is that about 90% of households own different brands of appliances," she told Forbes . "People want a free choice of different brands. But they want one simple app to control everything."   "It's the customer who decides. No one else," she noted during her presentation , pointing out that 66% of customers would like to control all their appliances with a single app.   Customers will be able to access the features of their appliances via the Home Connect cloud servers from anywhere. For instance, they could turn on the dishwasher or add an additional rinse cycle to the clothes washer or delay the heating going on if they’re going to be home late. The app will send service alerts and keep the user informed of the status of each appliance.   If BHS is successful with Home Connect it could amass a huge database of home appliance information, enabling it to analyze how people use their connected devices and what brands and models are most popular. This is the kind of information marketers want in order to design new products, adapt regional offers, and outsmart the competition.   Obviously, BHS competitors are not going to be inclined to share access to their appliances' connected features and will probably start blocking that access, effectively forcing users to have more than one app to control them.   The Internet of Things market for home devices is just beginning to heat up, and it will probably be a few years before apps such as Home Connect become the standard way for consumers to control their appliances.   Pablo Valerio i s a freelance blogger who writes about mobile and telecom issues for EE Times. He lives and works in Barcelona.

I'm not sure why, but I am having a picture of a Discworld-esque scene that takes place in the wee hours of the morning. A figure makes his furtive way down an alleyway and taps on a door. A flap opens and the following exchange takes place between the doorkeeper and the furtive figure: * Furtive Figure: " A gibbous moon hangs pendulously in the night sky." * Doorkeeper: "Monk fish croon their soothing songs of snooze." * Furtive Figure: "Yet still the dog doth grunt and snore." And back and forth they go with evermore obscure passwords. Sometimes my imagination runs away with me. I really should go back to taking my dried frog pills. But we digress... The point is that my wife (Gina the Gorgeous) and I have two stupid dogs that spend the night in our room under the bed. Henri (the French Pronunciation) is something of a glutton – he eats anything he can find – including cat food, bird food, and things I don't care to mention here. As a result, Henri is overweight, and he now grunts and snores his way through the night. It's gotten to the stage where it's hard for us to get a good night's sleep, so we decided to purchase one of those relaxing noise machine thingies. You know the sort of thing – they generate the sound of rain, or wind, or surf on the beach. You used to be able to get them from almost any store as standalone units or integrated into an alarm clock. We went to numerous stores including Best Buy, Walmart, and Target ... nothing. Even worse, when we tried to explain what we were looking for to the shop assistants (who are growing younger by the day), they looked at us like we were from another planet (my impression is that technology is now changing so fast that they had simply never heard of these devices, which is pretty amazing when you come to think about it). And then, while we were on our way out of the last store, Gina said "You don't suppose that there's an iPhone app for this, do you?" Well, put me in a dress and call me Laura! I felt like a fool (but where were we going to find a fool at that time of the day? Ah, the old jokes are the best ones). I really should have thought about this myself. As you may recall, when I built my Ukulele I found a bunch of Ukulele tuning apps in the iTunes Store, so I have absolutely no idea why I didn't think of looking there first. When we returned home, Gina looked online and found an amazing free app. The sound, when Gina's iPhone is played through our docking station, is amazing. As opposed to electronically generated versions, this uses real-world recorded sounds. The people who created this app have obviously done their research, because they have sounds in there that I would never have thought of, including a fan, an air conditioner, the sound of a city, the sound you hear while sitting in the back seat of a car, the sound of being on an airplane, the sound of the tracks when riding a train, and all sorts of other things. Of course they also have "White Noise" and "Pink Noise," plus they have "Blue Noise," which I – for one – had never heard about. But I just had a quick Google (it's OK, no one was looking) and found a Colors of Noise entry on the Wikipedia. Wow – in addition to White and Pink Noise, it turns out that there's also Brown, Blue, Violet, and Gray Noise. And these are just the ones with technical definitions – it seems that there are also "unofficial colors" such as Red, Orange, Green, and Black Noise. I learn something new every day...