web analytics


Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1067

Warning: Creating default object from empty value in /home/davidgs/public_html/wp-includes/comment-template.php on line 1067

Intel Edison: Big Hat, No Cattle

Intel Edison

It was almost exactly a year ago that I bought my first Intel Edison development kit. I was all excited about the prospects of it, as you can see here. It’s a nice, small, powerful (if power-hungry) IoT board that held a lot of promise for development and prototyping.

I wish I were still as excited about it. 

I’ve tried, a couple of times, to use it for some development project or another. I’m even trying again now. My experience has been less than positive. In fact, it has been downright disappointing. Now, one of my initial gripes about the platform was the ease of use and the non-intuitive process for flashing/upgrading/etc. the board. To be fair, Intel has worked on this, and there are now some fairly decent tools for managing the board. 

That being said, there is way more that doesn’t work on this board than does. For instance, SPI. That’s set of a big one, for me. I spent about a month working on getting a SPI device to work with the board and encountered nothing but problems. Repeated posts to the Intel Developer Forums elicited a series of cryptic responses indicating that I was hooking things up incorrectly, the SPI device wasn’t working properly, etc. It was an experimental device, so those things were plausible. Until I got a logic analyzer and actually debugged the signals coming out of the Edison. It then became abundantly clear that SPI on the Mini Breakout Board was hopelessly broken. At that point, Intel acknowledged that SPI was broken. They could have saved me a bunch of time had they copped to that earlier. So SPI is out.

Ok, SPI is hopelessly broken. Let’s try I2C. So far, the experience with I2C has been roughly similar. I will say that having internal pull-up resistors on the pins that I can set to pre-defined values is quite helpful. Documentation on I2C — and the pull-up resistors — like all the Edison documentation, is pretty thin but if you’re persistent in searching the web, you’ll find the answers you need (Hint: cd /sys/kernel/debug/gpio_debug/<pin number> and then look in available_pullmode, available_pullstrength for acceptable values, then put the value you want into current_pullmode and current_pullstrength. Never say I wasn’t helpful.) 

I got the SDA/SCL pull-up resistors set correctly, and the direction set correctly, and the device I’m working with is now at least seen on the I2C bus. But that’s about as far as I can get. In theory, the I2C buss has several speeds, but in reality it is pretty well stuck at 300kHz. My device is 100kHz. Again, in theory, you can change the speed, but in reality, at least according to all the posts and responses, the only way to effectively do this is to rebuild the entire Linux kernel, and even then, YMMV. 

Needless to say, my mileage did vary. I’ve tried using Javascript (Node.js), Python, C and Arduino sketches to gain access to the I2C bus and this device and each one fails — in entirely different ways. That’s not a good thing. 

The device I’m using, a Melexis MLX90614 (PDF) IR Thermometer, also has a PWM mode. Ok, last chance Edison. Game on!

Guess what? Intel Edison only does PWM out. No PWM in. So I can’t read the device. If it were a servo, I’d be all set. But it’s not. So once again, I find the Intel Edison to be full of promise, with no ability to deliver. 

I’ll keep banging away on it, and see if I can eventually get the Edison to do anything useful but so far, it’s a cute little device that is not the least bit useful. Powerful, but useless.

Tutorial: lwip With FreeRTOS and the Freescale FRDM-K64F Board

This tutorial is about how to create a lwIP project with FreeRTOS using the Kinetis SDK V1.3.0 with Kinetis Design Studio on the Freescale FRDM-K64F board.
I would like to thank Frank Bargstedt for providing me the many hints and steps for this tutorial. Without his contribution I think I would not have been able to create this article. THANK YOU!

How Software Issues in Cars Cost Automakers Billions [Infographic]

Code complexity has reached new levels with more than 100 million lines of code in a single automobile.  Due to the massive amount of code that is being introduced to vehicles, understanding the software and its quality has never been more important.  The recent discovery of Volkswagen’s “Defeat Device” sparked an investigation into other car manufactures processes and emissions claims.  During the process, there were a number of news worthy findings.  We now know that Volkswagen isn’t the only manufacturer that is not meeting emissions targets.
Over the past 10 years, almost every major car company has had recalls due to software issues. Although none have been as news worthy as the recent Volkswagen findings .  Toyota was also investigated when it was found that their vehicles were unintentionally accelerating.

IoT Makes “As Good as the Day I Bought It” a Thing of the Past

Product Lifecycle Report

Insights into the Internet of Things

IoT Makes “As Good as the Day I Bought It” a Thing of the Past

By Jim Brown Published on October 26, 2015

A recent Harvard Business Review article, How Smart, Connected Products Are Transforming Companies, shares insights on the way today’s intelligent, sensored products and the Internet of Things are changing the fabric of manufacturing companies. One particular area that caught my eye is the discussion on “Evergreen Design.” As the article points out, “Smart, connected products … can be continually upgraded via software, often remotely.”

The article shared two examples that, to me, explain why manufacturers need to pay attention to this discipline. In two separate instances, Tesla set themselves apart from traditional automakers using evergreen principles. In the first, they identified a hazardous driving condition that was leading to fires and remotely upgraded all existing cars’ suspensions to prevent the scenario from occurring. They made the car safer to drive and avoided an expensive recall. In another, they included “autopilot” capabilities into cars while the feature was still a work in progress. They avoided the difficult, traditional tradeoff of either omitting a new feature in a new model or delaying product introduction. They included what they could with plans to continually improve it and introduce the feature when it was ready.

So why should manufacturers pay attention to evergreen design? Let’s step back a bit.

Remember when the day you bought a product was the best it would ever be? With the exception of a few anomalies like blue jeans or a baseball glove that getter better with use, the brand new product was at its best. Then, after a while it slowed down, got weaker, wasn’t as responsive, would stop doing a function, or maybe a part broke off. Performance and features declined with time. The best you could possibly hope for was “as good as the day I got it.” Maybe your products are still that way.

But I distinctly remember the day that changed for me. I upgraded my BlackBerry to a new operating system and it turned into a brand-new and improved device! The user interface was much more graphical. I was giddy. It was like a new phone for free!  The way of the future for equipment has started to look a lot more like an upgradeable computer instead of a piece of equipment that could only deteriorate over time. The smarter devices have become, the more they can improve, evolve, and gain value as you own them.

But the real reason manufacturers have to pay attention to evergreen concepts is that it fundamentally changes the relationship between a manufacturer, the products they make, and the customers that use them.

The more connected products have become, the more engaged the manufacturer (or service provider) can stay in the product while it’s in the customers’ hands. This is why smart, connected products should be viewed as a major disruption as opposed to a simple step change in product capabilities. Now manufacturers can offer new services, like adding live traffic information or restaurant reviews to a GPS.  They can fix problems with devices before customers know they exist. They can leverage new design practices like soft buttons and controls that allow them to add new interfaces and functions to products in the field that the original designer may not have been able to anticipate.  They allow the manufacturer to experience what customers are doing with products in the field to gain new insights.

Let’s not celebrate this brave new world too quickly, though. There are plenty of obstacles for manufacturers to address.

I also remember the first device that “bricked” on me. I downloaded a new operating system and my phone downgraded itself into a paperweight. In that case, permanently. I also remember the fist time my car bricked on me. A sensor mistakenly determined that some mechanical parts were going to clash so it shut the motor off leaving my family stranded at a kid’s baseball game. That was a wakeup call on the potential pitfalls of smarter products.

The point is, designing smart products is hard. The industry has started to make strides in developing and validating “mechatronic” products that contain mechanical, electrical, and software components. But evergreen design takes advantage of smart products (systems) connected to other systems. It leverages connectivity to data sources in the cloud. It relies on feedback from devices to get to the manufacturer and make a round trip with updates. And it all has to work together. That’s a lot to design and validate. It’s even more difficult to manage as things change!  If manufacturers push updates to products running in the field, they have to be able to simulate and validate their behavior to avoid turning a potential positive upgrade into unplanned downtime.

The industry still has a lot to learn about how to effectively develop systems, and now we are pushing the boundaries further. Why? Because the value is there. Products can now get better over time. The relationship between the manufacturer and the user can be closer. That’s simply too compelling of an opportunity. The complexity has to be – and will be – met by new design disciplines and tools. Now, maybe we will love our old equipment as much as we love our old blue jeans and baseball gloves.

This is the second installment in a series of guest posts by leading industry analysts covering topics found in the new Harvard Business Review article, How Smart Connected Products are Transforming Companies, co-authored by PTC CEO, Jim Heppelmann, and Harvard Business School professor, Michael Porter.

Related Articles:

Share this article on

About the Author

Jim Brown

Jim Brown is the founder and President of independent research firm Tech-Clarity. Jim is a recognized expert in software solutions for manufacturers, with over 25 years of experience in application software, management consulting, and research. He has extensive knowledge about how manufacturers use Product Lifecycle Management (PLM) and other enterprise applications to improve business performance.

Jim began his career in manufacturing engineering and software systems at General Electric before joining Andersen Consulting (Accenture). He subsequently served as a strategy, marketing, and product development executive for software companies specializing in ERP, PLM, Supply Chain, and related manufacturing solutions.

Jim founded Tech-Clarity, Inc. in 2002 and actively serves in a research role. In 2005, Aberdeen Group acquired Tech-Clarity and Jim established and grew their Product Innovation & Engineering Practice, subsequently serving as VP and Group Director for Aberdeen’s PLM and Manufacturing Industry Research Practices. In 2008, Jim returned to Tech-Clarity to continue his mission to make the business value of technology clear.

Mr. Brown is an experienced author and speaker and enjoys the opportunity to participate in conferences and anywhere he can engage with people with a passion to improve business performance through software technology.

You can find Jim on Twitter at @jim_techclarity, on Facebook at TechClarity.inc, or read his research and blog at www.tech-clarity.com.

This entry was posted in Executive View and tagged , , , . Bookmark the permalink.

Leave a Reply

Given URL is not allowed by the Application configuration: One or more of the given URLs is not allowed by the App's settings. It must match the Website URL or Canvas URL, or the domain must be a subdomain of one of the App's domains.
Skip to toolbar

  • normal


  • normal normal
  • normal normal

Log Out