thingSoC defines a physical, hardware socket system for inter-operable printed circuit boards, with a data centric firmware model for automatic device discovery, and a software API for interacting with the system.
Live as if you will die tomorrow. Learn as if you will live forever.
There is a saying that every nice piece of work needs the right person in the right place at the right time.
I've worked on a number of Real-Time Location Systems (RTLS) over the years, including Global Positioning Systems (GPS), and Radio Frequency Location Systems (RFLS), and all of them have had their share of problems with accuracy, signal interferance, and signal loss. My friend David just demonstrated a new Real-Time Location System (RTLS) for me this week, based on the the IEEE_802.15.4 standard, using an Ultra-Wide Band (UWB) tranceiver from decaWave, the DW1000. With up to ten centimeter (10cm) indoor position accuracy of moving objects, it's accuracy sets a new standard.
We're still in the first minutes of the first day of the internet revolution.
There have been a number of purpose built System-on-Chip (SoC) devices intended for connecting to the Internet of Things (IoT). Examples include the ESP8266 (WiFi), the CC2530 (Zigbee), or the Spirit1 (sub-1GHz), for different wireless connection standards. In the Bluetooth & ANT IoT connectivity space, Nordic Semiconductor has been playing a winning hand with their ARM Cortex-M0 based nRF51822 IoT SoC, and they have just seriously upped the ante with their new ARM Cortex-M4F based nRF52832 IoT SoC. It's a multiprotocol RF SoC that supports Bluetooth Smart, ANT, Near Field Communication (NFC), Out-of-Band Pairing (OoB), Ultra-Low Power (ULP), and more.
Variety's the very spice of life, that gives it all its flavor.
Those of you who have been following what's been happening with hardware platforms like the Android, Beaglebone Black, Raspberry Pi, and several other small Linux systems, have probably noticed a bit of divergence with respect to the Device Tree EEPROM formats used on these platforms. So far, it's not seemed like the simplification or standardization that everyone had hoped for; and what about cross-platform peripherals?
It’s not in the dreaming, it’s in the doing.
Internet Protocol Smart Objects (ISPO) have the potential to provide much better interoperability for Internet connected devices, by standardizing the data (and the meta-data) exchanged between those devices. While the market has seen an explosion of new IoT devices, the vast majority can not "talk" to each other in any meaningful way, since they don't know each others data formats and device capabilities. Internet Protocol Smart Objects (ISPO) outlines several "Smart Object" classes for sensors and actuators with well known data formats. For the past several articles, I've been discussing Device Trees and their application in describing the hardware capabilities of various embedded platforms, which seems to be exactly what we need to automatically generate the directory of Internet Protocol Smart Objects (ISPO) for IoT devices. I think it's time for Smart Objects to meet Smart Device Trees...
A new word is like a fresh seed sown on the ground of the discussion.
There has been considerable progress in the just the past few years with implementing the Device Tree format on embedded platforms, particlarly in the ARM portion of the Linux Kernal. It has been an interesting an interesting time with all the growth and changes, but a little hard to locate all the different efforts underway. I've been working to collect what I can find, and index some of the topics under discussion.
A smart man makes a mistake, learns from it, and never makes that mistake again. But a wise man finds a smart man and learns from him how to avoid the mistake altogether.
—Roy H. Williams
Lately, I've been working on automatic discovery and configuration of devices and peripherals, using
Binary Level Objects, like the
IPMI FRU, the
Devicetree Overlay formats.
Typically these have been implemented using just a "dumb" storage device,
like an EEPROM, or an
SDcard, or perhaps a
Dynamic NFC/RFID tag.
So, what then, do I mean by a "Smart" Devicetree?
Education is the most powerful weapon you can use to change the world.
Unless you've been living under a rock since the late '70's, you've probably heard about
Modbus, the communications protocol used
for a wide variety of industrial systems, from
programmable logic controllers(PLCs).
Modbus can be found in most factories and automated assembly lines.
Modbus devices can be quite complicated; but what if we used
an embedded Device Tree to describe them?
That would enable the automatic discovery and configuration
of Modbus devices and peripherals, wouldn't it?
Why do they always want to do it the hard way?
—Wile E. Coyote, Genius
Imagine that Wile E. Coyote has just finished watching
"Rise of the Drones" on PBS, and he has had a "Eureka!" moment. He immediately dials Acme Corporation and orders several dozen T-4 Aerial Drones. As the new manager of Acme Corporation, you realize that Wile E. Coyote will in all likelyhood crash the majority of them, and you will need a good way to track warranty claims and product repairs;
as he seems to have an unlimited line-of-credit, and he has also
purchased the platinum service plan with every one of those Drones.
If a tree dies, plant another in its place.
In my last article, I gave a general overview of the Device Tree format, and some basics on how it is being used for automatically configuring the hardware of embedded computing platforms like the Beaglebone Black, Xilinx Zynq, and many other System-on-Chip (SOC) devices. Device Tree Overlays, originated by Pantelis Antoniou are now being used to support add-on devices and expansion boards, allowing automatic discovery and automatic configuration on several computing platforms. In this article, I'll discuss the Device Tree Overlay and why it is getting adopted for even more computing platforms.
In nature, nothing is perfect and everything is perfect. Trees can be contorted, bent in weird ways, and they're still beautiful.
Recently, I've been working with the Device Tree format, which is becoming widely used for automatically configuring the hardware of embedded computing platforms like the Beaglebone Black, Xilinx Zynq, Altera Arria, and many other System-on-Chip (SOC) devices. The Device Tree is read during the computing platform boot up sequence, and it describes all the hardware of the embedded computing platform. It contains descriptions of all the platform parameters, like how much memory, what kind of interfaces, how many peripherals, etc. are expected to be present in that make and model of platform. In this article, I'll introduce the Device Tree format, and discuss how it is being used on current embedded computing platforms.
It isn't what we say or think that defines us, but what we do.
There are several efforts underway to define and unify sensor abilities and parameters, both for normal (user) applications as well as for standardized (manufacturer) testing. Today it can be quite difficult to change sensor elements (either because newer, better sensor products become available, or because of the obsolescence of older, existing models) due to the amount of software changes involved. In this article, I'll discuss some of the evolving standards efforts underway, and what that means for those of us trying to keep up with the latest sensor technologies, and those of us trying to determine whether or not a particular sensor meets our requirements.
Obstacles are those frightful things you see when you take your eyes off your goal.
There are a number of different metadata formats for containing low-level configuration information, some of them are in plain ASCII text, and others are in various encoded binary formats. The encoded binary formats, or Binary Level OBjects, are commonly referred to as "BLOBs". In this article, I will discuss how some of those formats are being used in existing products.
There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.
—Shakespeare - "Hamlet"
In order to design an automatic discovery and configuration mechanism for popular small form factors like Arduino, rfDuino, LaunchPad, and others, we first need to decide on simple connection chain that can connect all the subsystems, one which is already included in each of these form factors. We need to be able to describe the heirarchy of devices, and the connections between them, in order to understand the topology of our embedded system.
Do the difficult things while they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step.
I spoke at the Portland thingTuesday meeting this week about some of the limitations of currently popular small form factors like Arduino, rfDuino, TI LaunchPad, and others. My personal opinion is that one of the biggest limitations of these small form factors is the lack of an automatic configuration standard.
Give a man a fish and he has food for a day; teach him how to fish and you can get rid of him for the entire weekend.
PatternAgents has just released a new library of MinnowBoard Lures (expansion board patterns) for the MinnowBoard project. The library includes Type A, B, and C Lures, with both single board patterns and "stackthru" patterns, which allow multiple Lures to be stacked up on top of each other. If you are thinking about designing your own set of Lures, then this is the place to start.
In theory there is no difference between theory and practice. In practice there is.
In this post we'll discuss some of the "best practices" for implementing capacitance sensing widgets and control surfaces on your printed circuit boards. We've done a mash-up of several tasty tracks from different vendors and technologies to give you a mastered mix-down...
I think that things happen individually first, and then collectively. It's not the other way around.
—Neale Donald Walsch
PatternAgents has been developing open source parts libraries for the Eagle CAD package, and we have now developed a library of Capacitive Touch Widgets to provide a number of different control surfaces for your projects. This How-To will cover instructions for using them in your own projects.
You feel touched and honored and alive when you give to someone.
—Daphne Zuniga (Princess Vespa)
The PatternAgents Touch Widgets Library for Eagle is a schematic and layout library that provides the symbols and layouts for commonly used capacitive sensing control surface widgets, such as Buttons, Linear Sliders, Radial Sliders, X-Y Touchpads and more.
When we are touched by something it's as if we're being brushed by an angel's wings.
Capacitive Sensing is ubiquitous now, from your smartphone screen, or your Apple iPod, to the "buttons" on your new TV remote control. Today we'll be talking about how capacitive sensing works and how you can use it on your next project.
When I write, I disturb. When I show a film, I disturb. When I exhibit my painting, I disturb, and I disturb if I don't. I have a knack for disturbing.
It is a wonderful time for makers, we have terrific resources for getting things built now, with new resources appearing every day. Today we're going to talk about a few of the resources available to you, no matter where you live (almost).
A library is the delivery room for the birth of ideas, a place where history comes to life.
We have several man-years of effort invested in developing professional grade parts libraries for Eagle, and now we've made them available to you, our user community, on our Github Repo. The PatternAgents EagleCAD Libraries are schematic and PCB layout libraries for various electronic components and systems for use within the Eagle CAD program.
Life is like riding a bicycle. To keep your balance you must keep moving.
This week we've been working on a custom lighting System for the Quattrocycle, a four wheeled, family quad-cycle with independent gearing and suspension.
Write it. Shoot it. Publish it. Crochet it, Saute it, whatever. MAKE.
Thank You to everyone who stopped in at Booth 18 and said hello! We were very pleased that we had visitors from Canada to Mexico stop in, as well as many old and new friends from all over the Portland/Vancouver area.
Clouds come floating into my life, no longer to carry rain or usher storm, but to add color to my sunset sky...
Y'un means “Cloud” in Chinese, and the latest small form factor board from Arduino is clearly intended for “cloud applications”, and enabling the “Internet of Things”. The Y'un includes an Atheros/Qualcomm AR9331 System-on-Chip device that includes a MIPS processor with a Wi-Fi radio, as well as wired USB and Ethernet connections. In order to maintain backward compatibility with the Arduino IDE tools, it also includes a legacy ATMega324 for running standard Arduino sketches.
Many men go fishing all of their lives without knowing that it is not fish they are after...
—Henry David Thoreau
We attended an "Internet of Things" meeting here this week, and Scott Garman introduced us to a new small form factor, the MinnowBoard. The MinnowBoard is very high performance single board computer (SBC) using a 1Ghz Intel Atom processor, but unlike most SBC's it has the General Purpose I/O (GPIO) expansion connections needed to expand the system using low cost peripherals. More akin to SBC's like the Raspberry Pi, it runs the Angstrom Linux Distribution and is compatible with the Yocto project. This looks to be a very nice high-end SBC for embedded work that requires the power of an Intel CPU.
Success is the sum of small efforts, repeated day in and day out...
—Robert J. Collier
There are dozens of different Small Form Factors in use today. The largest volume of those being used in Embedded Personal Computers (PC's), such as the Mini-ITX, Nano-ITX and Pico-ITX form factors. However, what we're going to talk about today are even smaller form factors, typically those used for embedded microcontrollers in application specific uses, such as smart devices and process controllers. Today we're talking about form factors for processors, and in upcoming segments we'll also be covering those used for adding small peripherals and interfaces to other (larger) form factors.