Univariate: considering a single variable
Multivariate: considering multiple variables
OMG! Three 32-bit processor cores each running at 300 MHz, each with its own floating-point unit (FPU), and each with more memory than you can throw a stick at!
In a recent column on Recreating Retro-Futuristic 21-Segment Victorian Displays, I noted that I’ve habitually got a number of hobby projects on the go. I also joked that, “one day, I hope to actually finish one or more of the little rascals.” Unfortunately, I’m laughing through my tears because some of my projects do appear to be never-ending.
For example, shortly after the internet first impinged on the popular consciousness with the launch of the Mosaic web browser in 1993, a number of humorous memes started to bounce around. It was one of these that sparked my Pedagogical and Phantasmagorical Inamorata Prognostication Engine project, which has been a “work in progress” for more than 20 years as I pen these words.
As you can see in the image to the right, the Prognostication Engine has grown in the telling. The main body of the engine is housed in a wooden radio cabinet from 1929. My chum, Carpenter Bob, created the smaller section on the top, with great attention to detail like the matching hand-carved rosettes.
The purported purpose of this bodacious beauty is to forecast the disposition of my wife (Gina the Gorgeous) when I’m poised to leave the office and head for home at the end of the day (hence the “Prognostication” portion of the engine’s moniker). Paradoxically, should Gina ever discover the true nature of the engine, I won’t actually need it to predict her mood of the moment.
As we see, the control panels are festooned with antique knobs, toggle switches, pushbuttons, and analog meters. The knobs are mounted on motorized potentiometers, so if an unauthorized user attempts to modify their settings, they will automatically return to their original values under program control. The switches and pushbuttons are each accompanied by two LEDs, while each knob is equipped with a ring of 16 LEDs, resulting in 116 LEDs in all. Then there are 64 LEDs in the furnace and 140 LEDs in the rings surrounding the bases of the large vacuum tubes mounted on the top of the beast.
I was just reflecting on how much technology has changed over the past couple of decades. For example, today’s “smart LEDs” like WS2812Bs (a.k.a. NeoPixels) can be daisy-chained together, allowing multiple devices to be controlled using a single pin on the microcontroller. It probably goes without saying (but I’ll say it anyway) that all of the LEDs in the current incarnation of the engine are tricolor devices in the form of NeoPixels, but this was not always the case.
The tricolor LEDs I was planning on using 20 years ago each required three pins to be controlled. The solution at that time would have been to implement a huge external shift register. The image to the left shows an early shift register prototype sufficient to drive only 13 “old school” devices.
And, of course, developments in computing have been even more staggering. When I commenced this project, I was using a PIC microcontroller that I programmed in BASIC. After the Arduino first hit the scene circa 2005, I migrated to using Arduino Unos, followed by Arduino Megas, that I programmed in C/C++.
One of the reasons I like the Arduino Mega is its high pin count, boasting 54 digital input/output (I/O) pins, of which 15 can be used as pulse-width modulated (PWM) outputs, 16 analog inputs, and 4 UARTS. On the other hand, the Mega is only an 8-bit machine running at 16 MHz, it offers only 256 KB of Flash (program) memory and 8 KB of SRAM, and it doesn’t have hardware support for floating-point operations.
The thing is that the Prognostication Engine has a lot of things going on. In addition to reading the states of all the switches and pushbuttons and potentiometers, it has to control the motors behind the knobs and drive the analog meters. Currently, the LEDs are being driven with simple test patterns, but these are going to be upgraded to support much more sophisticated animation and fading effects. The engine is also constantly performing calculations of an astronomical and astrological nature, determining things like the dates of forthcoming full moons and blue moons.
In the fullness of time, the engine is going to be connected to the internet so it can monitor things like the weather. It’s also going to have its own environmental sensors (temperature, humidity, barometric pressure) and proximity detection sensors. Furthermore, the engine will also boast a suite of sound effects such that flicking a simple switch, for example, may result in myriad sounds of mechanical mechanisms performing their magic. At some stage, I’m even hoping to add things like artificial intelligence (AI) and facial recognition.
The current state of computational play (Click image to see a larger version — Image source: Max Maxfield)
Sad to relate, my existing computing solution is not capable of handling all the tasks I wish the engine to perform. The image to the right shows the current state of computational play. As we see, there is one Arduino Mega in the lower cabinet controlling the 116 LEDs on the front panel. Meanwhile, there are two Megas in the upper cabinet, with one controlling the LEDs in the furnace and the other controlling the LEDs associated with the large vacuum tubes.
Up until a couple of years ago, I was vaguely planning on adding more and more Megas. I was also cogitating and ruminating as to how I was going to get these little rascals to talk to each other so that everyone knew (a) what we were trying to do and (b) what everyone else was actually doing.
Unfortunately, the whole computational architecture was becoming unwieldy, so I started to look for another solution. You can only imagine my surprise and delight when I was first introduced to the original ShieldBuddy TC275 from the folks at Hitex (see Everybody Needs a ShieldBuddy). This little beauty, which has an Arduino Mega footprint, features the Aurix TC275 processor from Infineon. The TC275 boasts three 32-bit cores, all running at 200 MHz, each with its own floating-point unit (FPU), and all sharing 4 Mbytes of Flash and 500 Kbytes of RAM (this is a bit of a simplification, but it will suffice for now).
Processors like the Aurix are typically to be found only in state-of-the-art embedded systems and they rarely make it into the maker world. To be honest, when I first saw the ShieldBuddy TC275, I thought to myself, “Life can’t get any better than this!” Well, I was wrong, because the guys and gals at Hitex have just announced the ShieldBuddy TC375, which features an Aurix TC375 processor!
O.M.G! I just took delivery of one of these bodacious beauties, and I’m so excited that I was moved to make this video.
I don’t know where to start. As before, we have three 32-bit cores, each with its own FPU. This time, however, the cores run at 300 MHz. Although each core runs independently, they can communicate and coordinate between themselves using techniques like shared memory and software interrupts. With regard to memory, the easiest way to summarize this is as follows: The TC375 processor has:
- 6MB Flash ROM
- 384 KB Data flash
And each of the three cores has:
- 240 KB Data Scratch-Pad RAM (DSPR)
- 64 KB Instruction Scratch-Pad RAM (PSPR)
- 32 KB Instruction Cache (ICACHE)
- 16 KB Data Cache (DCACHE)
- 64 KB DLMU RAM
Actually, there’s a lot more to this than meets the eye. For example, the main SRAMs (the DSPRs) associated with each of the cores appear at two locations in the memory map. In the case of Core 0, for example, the first location in its DSPR is located at address 0xD0000000 where it is considered to be local (i.e., it appears directly on Core 0’s local internal bus) and can be accessed quickly. However, this DSPR is also visible to Cores 1 and 2 at 0x70000000 via the main on-chip system bus, which allows them to read and write to this memory freely, but at a lower speed than Core 0. Similarly, Cores 1 and 2 access their own memories locally and each other’s memories globally.
Meet the ShieldBuddy TC375 (Click image to see a larger version — Image source: Hitex)
As for the original ShieldBuddy TC275, if you are a professional programmer, you’ll be delighted to hear that the main ShieldBuddy TC375 toolchain is the Eclipse-based “FreeEntryToolchain” from HighTec/PLS/Infineon. This is a full-on C/C++ development environment with source-level debugger and suchlike.
By comparison, if you are a novice programmer like your humble narrator, you’ll be overjoyed to hear that the ShieldBuddy TC375 can be programmed via the Arduino’s integrated development environment (IDE). As far as I’m concerned, this programming model is where things start to get very clever indeed.
An Arduino sketch (program) always contains two functions: setup(), which runs only one time, and loop(), which runs over and over again (the system automatically inserts a main() function while your back is turned). If you take an existing sketch and compile it for the ShieldBuddy, then it will run on Core 0 by default. You can achieve the same effect by renaming your setup() and loop() functions to be setup0() and loop0(), respectively.
Similarly, you can create setup1() and loop1() functions, which will automatically be compiled to run on Core 1, and you can create setup2() and loop2() functions, which will automatically be compiled to run on Core 2. Any of your “homegrown” functions will be compiled in such a way as to run on whichever of the cores need to use them. I know that, like Pooh, I’m a bear of little brain, but even I can wrap my poor old noggin around this usage model.
There’s much, much more to this incredible board than I can cover here, but if you are interested in learning more, then may I recommend that you visit this portion of the Hitex site where you will find all sorts of goodies, including the ShieldBuddy Forum and the ShieldBuddy TC375 User Manual.
Now, if you will forgive me, I must away because I have to go and gloat over “my precious” (my ShieldBuddy TC375) and commence preparations to upgrade the Prognostication Engine by removing all of its existing processors and replacing them with a single ShieldBuddy TC375.
Actually, I just had a parting thought, which is that the Prognostication Engine’s role in life is to help me predict the future but — when I started out on this project — I would never have predicted that technology would develop so fast that I would one day have a triple-core 300 MHz processor driving “the beast.” How about you? What are your thoughts on all of this?
Originally posted here.
Edge Impulse has joined 1% for Planet, pledging to donate 1% of our revenue to support nonprofit organizations focused on the environment. To complement this effort we launched the ElephantEdge competition, aiming to create the world’s best elephant tracking device to protect elephant populations that would otherwise be impacted by poaching. In this similar vein, this blog will detail how Lacuna Space, Edge Impulse, a microcontroller and LoraWAN can promote the conservation of endangered species by monitoring bird calls in remote areas.
Over the past years, The Things Networks has worked around the democratization of the Internet of Things, building a global and crowdsourced LoraWAN network carried by the thousands of users operating their own gateways worldwide. Thanks to Lacuna Space’ satellites constellation, the network coverage goes one step further. Lacuna Space uses LEO (Low-Earth Orbit) satellites to provide LoRaWAN coverage at any point around the globe. Messages received by satellites are then routed to ground stations and forwarded to LoRaWAN service providers such as TTN. This technology can benefit several industries and applications: tracking a vessel not only in harbors but across the oceans, monitoring endangered species in remote areas. All that with only 25mW power (ISM band limit) to send a message to the satellite. This is truly amazing!
Most of these devices are typically simple, just sending a single temperature value, or other sensor reading, to the satellite - but with machine learning we can track much more: what devices hear, see, or feel. In this blog post we'll take you through the process of deploying a bird sound classification project using an Arduino Nano 33 BLE Sense board and a Lacuna Space LS200 development kit. The inferencing results are then sent to a TTN application.
Note: Access to the Lacuna Space program and dev kit is closed group at the moment. Get in touch with Lacuna Space for hardware and software access. The technical details to configure your Arduino sketch and TTN application are available in our GitHub repository.
Our bird sound model classifies house sparrow and rose-ringed parakeet species with a 92% accuracy. You can clone our public project or make your own classification model following our different tutorials such as Recognize sounds from audio or Continuous Motion Recognition.
Once you have trained your model, head to the Deployment section, select the Arduino library and Build it.
Import the library within the Arduino IDE, and open the microphone continuous example sketch. We made a few modifications to this example sketch to interact with the LS200 dev kit: we added a new UART link and we transmit classification results only if the prediction score is above 0.8.
Connect with the Lacuna Space dashboard by following the instructions on our application’s GitHub ReadMe. By using a web tracker you can determine when the next good time a Lacuna Space satellite will be flying in your location, then you can receive the signal through your The Things Network application and view the inferencing results on the bird call classification:
No Lacuna Space development kit yet? No problem! You can already start building and verifying your ML models on the Arduino Nano 33 BLE Sense or one of our other development kits, test it out with your local LoRaWAN network (by pairing it with a LoRa radio or LoRa module) and switch over to the Lacuna satellites when you get your kit.
Originally posted on the Edge Impulse blog by Aurelien Lequertier - Lead User Success Engineer at Edge Impulse, Jenny Plunkett - User Success Engineer at Edge Impulse, & Raul James - Embedded Software Engineer at Edge Impulse
Question 1 : So, let’s start with the obvious question. What is DevOps and why is it inevitable for today’s businesses to adopt?
Answer : DevOps at the end of the day, if you look at it from a higher level, it is really the automation of agile, a better way to perform application design, development and deployment. This is far superior than the waterfall method which I actually started working on and was even teaching college, back in the 80s and 90s. So, the idea is that we’re going to, in essence, continuously improve the software through an agile methodology where we get together to deal with events versus some sort of a schedule or sequence, and how software is delivered.
So, DevOps really is the ability to automate that. And so, it’s the idea that we can actually code applications, say an application that runs on Linux, we can hit a button and it automatically goes through testing, including penetration testing, security testing, stability testing, performance testing. And then moves into a continuous integration process, then moves into a continuous deployment process and then is pushed out to a particular staging area and then it’s pushed out from the staging area to a production server.
The goal of DevOps is really kind of remove the humans from that process even though we haven’t done that completely yet. It is, in essence, to create a repeatable process as leverage with the number of tool sets that are working together to streamline the modification and delivery of software in a way that’s going to be better quality each time the software is delivered. There’s some cultural issues around DevOps as well, by the way, that are just important, it’s the ability to, in essence, understand that thinkers are going to be integrated iterative, the ability to deal with feedback directly from the testers and the operators, the ability to flatten the organization, and have a very open and interactive organization moving forward. And that’s the other side of the coin.
So people have a tendency to look at DevOps as just a tool chain with lots of cool tools, continuous integration, continuous testing, those sorts of things are working together, but it’s really a combination of a toolchain of process, and also a cultural change that’s probably more important than any of the technological changes.
Question 2 : One interesting point you mentioned about agile. So, I mean, as we all know, agile is a very commonly adopted methodology that’s in the software industry and I mean lot of companies are implementing agile successfully. So, as we talk about DevOps, I know it’s an extension, but how is this complementing to agile from a practical implementation standpoint?
Answer : Again, DevOps is really going to be very much of the automation of agile. So Agile is going to take a cultural change, an organizational change in order to make it effective. And ultimately, we’re leveraging a toolchain within DevOps as a way to automate everything that occurs in an agile environment. So, if we’re getting together on a daily basis to form a scrum and we’re talking about what needs to be changed, then typically the DevOps toolchain is where those changes are going to occur.
As small as a postage stamp, the Seeeduino XIAO boasts a 32-bit Arm Cortex-M0+ processor running at 48 MHz with 256 KB of flash memory and 32 KB of SRAM.
A couple of months ago, I penned a column, The Worm Turns, in which I revealed that — although I’d been bravely fighting my urges — my will had crumbled and I had decided to create a display comprising a 12 x 12 = 144 array of ping pong balls, each illuminated with a tricolor WS2818 LED (a.k.a. a NeoPixel).
The author proudly presenting his 12 x 12 ping pong ball array (Click image to see a larger version — Image source: Max Maxfield)
First, I found a pack of 144 ping pong balls on Amazon for only $11. I ordered two cartons because I knew I would need some spares. Of course, this immediately tempted me to increase the size of my array to 15 = 15 = 225 ping pong balls, but I’d already ordered 150 NeoPixels in the form of five meters of 30 pixels/meter strips from Adafruit, so I decided to stick with the original plan, which we will call “Plan A” so no one gets confused.
Thank goodness I restrained myself, because the 12 x 12 array is proving to be a lot more work than I expected — a 15 x 15 array would have brought me to my knees.
The next step was to build a 2-ball prototype because I wanted to see whether it was best to attach the NeoPixel to the outside of the ball (the fast-and-easy option) or inside the ball (the slow-and-painful alternative). Although you can’t see it from the picture or from this video, there is a slight but noticeable difference in the real-world, and one method is indeed better than the other — can you guess which one?
A prototype using two ping pong balls (Click image to see a larger version — Image source: Max Maxfield)
Have you ever tried to drill 3/8” holes into 144 ping pong balls? Me neither. Over the years, I’ve learned a thing or two, and one of the things I’ve learned is that drilling holes in ping pong balls always ends in tears. Thus, I ended up cutting these holes using a small pair of curved nail scissors (there’s one long evening I’ll never see again).
The reason for using the strips is that this is the cheapest way to purchase NeoPixels with associated capacitors in the easiest-to-use form. Unfortunately, the ball-to-ball spacing (43 mm) on the board is greater than the pixel-to-pixel spacing (33 mm) on the strip. This means chopping the strip into segments, attaching each segment to its associated ping pong ball, and then connecting adjacent segments together using three wires. So, 144 x 3 = 432 short wires to strip and solder. Do you have any idea how long this takes? I do!
The Seeeduino XIAO is the size of a small postage stamp (Click image to see a larger version — Image source: Seeed Studio)
Now, you may have noticed that I was driving my 2-ball prototype with an Arduino Uno, but this is too large to be used in my array. In the past, I would have been tempted to use an Arduino Nano, which is reasonably small and not-too-expensive. On the other hand, the fact that this is an 8-bit processor running at only 16 MHz with only 32 KB of flash memory and only 2 KB of SRAM would limit the effects I could achieve.
Sometimes (rarely) the fates decide to roll the dice in one’s favor. In this case, while I was pondering which processor to employ, the folks from Seeed Studio contacted me to tell me about their Seeeduino XIAO.
OMG! This little rapscallion — which is only the size of a small postage stamp and costs only $5 — is awesome! In addition to a 32-bit Arm Cortex-M0+ processor running at 48 MHz, this bodacious beauty boasts 256 KB of flash memory and 32 KB of SRAM.
As an aside, it’s important to note is that the Seeeduino XIAO’s programming connector is USB Type-C, which means you’re going to need a USB-A to USB Type-C cable.
The Seeeduino XIAO’s 11 input/output pins pack a punch (Click image to see a larger version — Image source: Seeed Studio)
In addition to its power and ground pins, the Seeeduino XIAO has 11 data pins, each of which can act as an analog input or a digital input/output (I/O). Furthermore, one of these pins can by driven by an internal digital-to-analog converter (DAC) and act as a true analog output, while the other pins can be used to provide I2C, SPI, and UART interfaces.
Sad to relate, there is one small fly in the soup or a large elephant in the room (I’m feeling generous today, so I’ll let you pick the metaphor you prefer). The problem is that, although it can be powered with the same 5 V supply as the NeoPixels, the Seeeduino XIAO’s I/O pins use a 3.3 V interface, but the NeoPixels require 5 V data signals, so we need some way to convert between the two.
In the past, I would probably have used a full-up bidirectional logic level converter, like the 4-channel BOB (breakout board) from SparkFun, but I only need a single unidirectional signal, so this seems a bit of overkill.
Happily, I recently ran across an awesome hack on Hackaday.com that provides a simple solution requiring only a single general-purpose IN4001 diode.
A cheap-and-cheerful voltage level converter hack (Click image to see a larger version — Image source: Max Maxfield)
The way this works is rather clever. From the NeoPixel’s data sheet we learn that a logic 1 is considered to be 0.7 * Vcc. Since we are powering our NeoPixels with 5 V, this means a logic 1 will be 0.7 * 5 = 3.5 V, which is higher than the XIAO’s 3.3 V digital output. Bummer!
Actually, if the truth be told, there is some “wriggle room” here, and the 3.3 V signal from the XIAO might work, but are we the sort of people for whom “might” is good enough? Of course we aren’t!
The solution is to add a “sacrificial NeoPixel” at the beginning of the chain, and to power this pixel via our IN4001 diode. Since the IN4001 has a forward voltage drop of 0.7 V, the first NeoPixel will see a Vcc of 5 – 0.7 = 4.3 V. Remember that the NeoPixel considers a logic 1 to be 0.7 * Vcc, so this first NeoPixel will accept anything above 0.7 * 4.3 = 3.01 V as being a logic 1. Meanwhile, the next NeoPixel in the chain will see the 4.3 V data signal coming out of the first NeoPixel as being a valid logic 1. Pretty clever, eh?
I’m currently about half of the way through wiring everything up. I cannot wait to see my array light up for the first time. Once everything is up and running, I will return to regale you with more details. Until that frabjous day, I will delight to hear your comments, questions, and suggestions.
Originally posted HERE.
Ever wanted the power of the all new Raspberry Pi 4 Single Board Computer, but in a smaller form factor? With more options to expand the I/Os and its functions? Well, The Raspberry Pi Compute Module 4 (a.k.a. CM4) got you covered! In this article, we’ll be taking a deep dive into the all-new CM4, see what’s new and how different the latest iteration is from its predecessor, CM3.
Introduction - The System on Module Architecture
The CM4 can be described as a ‘stripped-down’ version of the Raspberry Pi 4 Model B, which contains the same processor, memory, eMMC flash memory and the power regulation circuitry built-in. The CM4 looks almost like a breakout board with two connectors underneath, hence the name “System on Module (SoM)”. However, what differs the CM4 (all compute modules for that matter) from the regular Raspberry Pi 4 is that the CM4 does not come equipped with any hardware I/O ports such as USB, Ethernet and HDMI, but offers access to all the useful I/O pins of the cpu to be utilized to connect external peripherals that the designers include in their circuit designs. This offers the ultimate freedom to the designers and developers to use the computing power of the Raspberry Pi 4, while reducing the overall cost of their designs by only having to use what’s necessary in their designs.
What’s New In The CM4?
The key difference with the CM4, at first glance, is the form factor of the module. The previous versions, including the CM3 were designed to have the DDR2-SODIMM (mechanically compatible) form factor which looked like a laptop RAM stick. The successor, CM4 comes in a smaller form factor, with 2x 100-pin High-Density connector which can be ‘popped-on’ to the receiving board.
The CM4 comes in 32 different variants which has varying Flash and RAM options and optional wireless connectivity. Similar to the predecessors, there is also a CM4Lite version, which does not come with a built-in eMMC memory, reducing the cost of the module to a minimum of $25. However, all the variants of CM4 are equipped with following key features:
Broadcom BCM2711, Quad Core Cortex-A72 (Arm V8) 64-bit System on Chip, running at 1.5 GHz
1/2/4/8GB LPDDR4 RAM options
0(CM4Lite)/8/16/32GB of eMMC storage options (upto 100MB/s bandwidth)
Smaller footprint of 55mm x 40mm x 4.7mm (w x l x h)
Supports H.265 (4Kp60 Decode); H.264 (1080p60fps Decode, 1080p30fps Encode) using OpenGL ES 3.0 graphics
2.4/5GHz IEEE 802.11 b/g/n/ac Wireless (optional)
Bluetooth 5.0 BLE
On-board selector to switch between PCB trace antenna and external antenna
On-board Gigabit Ethernet PHY supporting IEEE 1588 standard
1x PCI Express Gen2.0 lane (5Gbps)
2x HDMI2.0 ports (upto 4k60fps)
1x USB 2.0 port (480MBps)
28x GPIO pins, with the support on both 1.8V or 3.3V logic levels along with the peripheral options:
2x PWM channels
6x UART (Serial)
1x SDIO interface
MIPI DSI (Serial Display)
1x 2-lane MIPI DSI display port
1x 4-lane MIPI DSI display port
MIPI CSI-2 (Serial Camera)
1x 2-lane MIPI CSI camera port
1x 4-lane MIPI CSI camera port
1x +5V Power Supply Input (on-board regulator circuitry available)
The Applications - DIY? Industrial?
The CM4 can be integrated into end products, designed and prototyped using the full-size Raspberry Pi 4 SBC. This allows the removal of unused ports, peripherals and components which reduces the overall cost and complexity. Therefore application ideas are virtually limitless and range all the way from DIY projects such as the PiBoy to industrial IoT designs such as integrated home automation systems, small scale hosting servers, data exchange hubs and portable electronics which require the processing power offered by the CM4, all while maintaining the smaller form factor and power consumption. Compute Module Clusters such as the Turing Pi 2, which harnesses the power of multiple Compute Modules are also an option with this powerful, yet small System on Module, the Raspberry Pi CM4.
How Can I Use Upswift Solutions On My Compute Module 4 Based Design?
Upswift offers hassle-free management solutions for all Linux-based embedded systems (CM4 included), by providing you a one-click solution to monitor, control and manage all your connected devices, from one place.
Originally posted HERE.
Arduino Mega footprint; three 32-bit cores all running at 200 MHz; 4 Mbytes of Flash and 500 Kbytes of RAM; works with the Arduino IDE; what’s not to love?
I tend to have a lot of hobby projects on the go at any particular time. Occasionally, I even manage to finish one. More rarely, one actually works.
Awesome Audio Reactive Artifact (Click image to see a larger version — Image source: Max Maxfield)
I also have a soft spot for 8-bit microprocessors and microcontrollers. Thus, many of my hobby projects are based on the Arduino Nano, Uno, or Mega platforms.
Take my Awesome Audio Reactive Artifact, for example. This little rascal is currently powered using an Arduino Uno, which is driving 145 tricolor NeoPixels. In turn, these NeoPixels are mounted under 31 defunct vacuum tubes (see also Awesome Audio-Reactive Artifact meets BirmingHAMfest).
The Awesome Audio Reactive Artifact also includes an ADMP401-based MEMS Microphone breakout board (BOB), which costs $10.95 from the guys and gals at SparkFun. In turn, this feeds a cheap-and-cheerful MSGEQ7 audio spectrum analyzer chip, which relieves the Arduino of a lot of processing pain (see also Using MSGEQ7s In Audio-Reactive Projects).
Sad to relate, 8-bit Arduinos sometimes run out of steam. Consider my Countdown Timer, for example, whose task it is to display the years (YY), months (MM), days (DD), hours (HH), minutes (MM), and seconds (SS) to my 100th birthday (see also Yes! My Countdown Timer is Alive!).
This little scamp employs 12 Lixie displays, each of which contains 20 NeoPixels, which gives us 240 NeoPixels in all. As the sophistication of the effects I was trying to implement increased, so did my processing requirements. Thus, I decided to use a Teensy 3.6, which features a 32-bit 180 MHz ARM Cortex-M4 processor with a floating-point unit. Furthermore, the Teensy 3.6 boasts 1 Mbyte of Flash memory for code, along with 256 Kbytes of RAM for dynamic data and variables.
All of which brings us to the pièce de résistance in the form of my Pedagogical and Phantasmagorical Prognostication Engine (see also The Color of Prognostication). This bodacious beauty sports two knife switches, eight toggle switches, ten pushbutton switches, five motorized potentiometers, six analog meters, and a variety of sensors (temperature, barometric pressure, humidity, proximity). All of this requires a bunch of analog and digital general-purpose input/output (GPIO) pins.
Furthermore, in addition to a wealth of weird, wonderful, and wide-ranging sound effects, the engine is equipped with 354 NeoPixels. These could potentially be daisy-chained from a single pin, although I ended up partitioning them into five strands. More importantly, the various effects require a lot of processing and memory.
When things finally started to come together on this project, I was initially thinking of using an Arduino Mega to power the beast, mainly because it has 54 digital pins and 16 analog inputs. On the downside, we have to remember that this is only an 8-bit processor gamely running at 16 MHz with a scant 256 Kbytes of Flash memory and 8 Kbytes of RAM. Furthermore, the Mega doesn’t have a floating-point unit (FPU), which means that if you need to use floating-point operations, this will really impact the performance of your programs.
But turn that frown upside down into a smile, because the boffins at Hitex (hitex.com) have taken the Arduino Mega form factor and slapped an awesome Infineon Aurix TC275 processor down on it.
These processors are typically found only in state-of-the-art embedded systems. they rarely make it into the maker world (like the somewhat disheveled scientist who is desperately in need of a haircut says in the movie Independence: “They don’t let us out very often”).
The result is called the ShieldBuddy. As you can see in this video, I just took delivery of my first ShieldBuddy, and I’m really rather excited (I say “first” because I have no doubt this is going to be one of many).
So, what makes the ShieldBuddy so special? Well, how about the fact that the TC275 boasts three independent 32-bit cores, all running at 200 MHz, each with its own FPU, and all sharing 4 Mbytes of Flash and 500 Kbytes of RAM (actually, this is a bit of a simplification, but it will suffice for now).
There’s no need for you to be embarrassed — I’m squealing in excitement alongside you. Now, if you are a professional programmer, you’ll be delighted to hear that the main ShieldBuddy toolchain is the Eclipse-based “FreeEntryToolchain” from HighTec/PLS/ Infineon. This is a full-on C/C++ development environment with source-level debugger and suchlike.
But how about if — like me — you aren’t used to awesomely powerful (and correspondingly complicated) Eclipse-based toolchains? Well, there’s no need to worry, because the guys and gals at Hitex also have a solution for the Arduino’s integrated development environment (IDE).
Sit up straight and pay attention, because this is where things start to get really clever. In addition to any functions you create yourself, an Arduino sketch (program) always contains two functions: setup(), which runs only one time, and loop(), which runs over and over again.
Now, remember that the ShieldBuddy has three processor cores, which we might call Core 0, Core 1, and Core 2. Well, you can take your existing sketches and compile/upload them for the ShieldBuddy, and — by default — they will run on Core 0.
You could achieve the same effect by renaming your setup() function to be setup0(), and renaming your loop() function to be loop0(), which explicitly tells the compiler to target these functions at Core 0.
The point is that you can also create setup1() and loop1() functions, which will automatically be compiled to run on Core 1, and you can create setup2() and loop2() functions, which will automatically be compiled to run on Core 2. Any of your remaining functions will be compiled in such a way as to run on whichever of the cores need to use them.
Although each core runs independently, they can communicate between themselves using techniques like shared memory. Also, you can use interrupts to coordinate and communicate between cores.
And things just keep on getting better and better, because it turns out that a NeoPixel library is already available for the ShieldBuddy.
I’m just about to start experimenting with this little beauty. All I can say is that everybody needs a ShieldBuddy and my ShieldBuddy is my new best friend (sorry Little Steve). How about you? Could any of your projects benefit from the awesome processing power provided by the ShieldBuddy?
Originally posted HERE.
On-chip UHD SS–MSCs as a device-unitized power source. Credit: Professor Sang-Young Lee, UNIST
by Ulsan National Institute of Science and Technology
A tiny microsupercapacitor (MSC) that is as small as the width of a person's fingerprint and can be integrated directly with an electronic chip has been developed. This has attracted major attention as a novel technology to lead the era of Internet of Things (IoT) since it can be driven independently when applied to individual electronic components.
Through the study, Professor Sang-Young Lee and his research team in the School of Energy and Chemical Engineering at UNIST have unveiled a new class of ultrahigh areal number density solid-state MSCs (UHD SS–MSCs) on a chip via electrohydrodynamic (EHD) jet printing. According to the research team, this is the first study to exploit EHD jet printing in the MSCs.
A supercapacitor (SC), also known as an ultracapacitor, can store much more energy than ordinary capacitors. The benefits of supercapacitors include having high power delivery and longer cycle life compared to lithium-based secondary batteries. In particular, it can be produced as small as the width of a person's fingerprint via semiconductor manufacturing process, and thus can be also applicable for wearables and internet of things (IoT) devices.
However, becuase the heat produced in manufacturing process may cause deterioration of the electrical characteristics of the supercapacitor, it has been difficult to connect them directly to electronic components. In addition, the fabrication method that combines supercapacitors with electronic components via inkjet printing technique has also the disadvantage of lower precision.
The research team solved this issue using EHD jet printing, a high-resolution patterning technique in microelectronics. EHD jet printing uses the electrode and electrolyte for printing purpose similar to that of conventional inkjet printing, yet it can control printed liquid with an electric field.
"We were able to produce up to 54.9 unit cells per square centimeter (cm2) via electro-hydrodynamic jet printing technique, and thus the output of 65.9 volts (V) was achieved in the same area," says Kwonhyung Lee (Combined M.S/Ph.D. of Energy and Chemical Engineering, UNIST), the first author of the study.
The team also succeeded in fabricating 36 unit cells on a chip (area = 8.0 mm × 8.2 mm, 54.9 cells cm−2) and areal operating voltage (65.9 V cm−2) that lie far beyond those of previously reported MSCs fabricated by printing techniques. Besides, upon exposure to hot temperature (80 degrees C), these cells maintained normal cyclic voltammetry (CV) profiles, and thus has proven they can withstand excessive heat generated during the operation of actual electronic component. In addition, these batteries can provide customized powere supplies, as they can be connected either in series or parallel.
"In this study, we have demonstrated on-chip UHD SS–MSCs fabricated via EHD jet printing," says Professor Lee. "The on-chip UHD SS–MSCs presented here hold great promise as a new platform technology for miniaturized monolithic power sources with customized design and tunable electrochemical properties."
Originaly posted HERE
PYNQ is great for accelerating Python applications in programmable logic. Let's take a look at how we can use it with OpenMV camera.
Things used in this project
- Avnet Ultra96-V2 (Can also use V1 or V3)
- OpenMV Cam M7
- Avnet Ultra96 (Can use V1 or V2)
- Xilinx PYNQ Framework
Image processing is required for a range of applications from vision guided robotics to machine vision in industrial applications.
In this project we are going to look at how we can fuse the OpenMV camera with the Ultra96 running PYNQ. This will allow out PYNQ application to offload some image processing to the camera. Doing so will provide a higher performance system and open the Ultra96 using PYNQ to be able to work with the OpenMV ecosystem.
What Is the OpenMV Camera
The OpenMV camera is a low cost machine vision camera which is developed using Python. Thanks to this architecture of the OpenMV Camera we can therefore offload some of the image processing to the camera. Meaning the image frames received by our Ultra96 already have faces identified, eyes tracked or Sobel filtering, it all depends on how we set up the OpenMV Camera.
As the OpenMV camera has been designed to be extensible it provides 10 external IO which can be used to drive external sensors. These 10 are able to support a range of interfaces from UART to SPI, I2C and PWM. Of course the PWM is very useful for driving servos.
On very useful feature of the OpenMV camera is its LEDs mine (OpenMV M7) provides a tri-colour LED which can be used to output Red, Green, Blue and a separate IR LED. As the sensor is IR sensitive this can be useful for low light performance.
How Does the OpenMV Camera Work
OpenMV Cam uses micro python to control the imager and output frames over the USB link. Micro python is intended for use on micro controllers and is based on Python 3.4. To use the OpenMV camera we need to first generate a micro python script which configures the camera for the given algorithm we wish to implement. We then execute this script by uploading and running it over the USB link.
This means we need some OpenMV APIs and libraries on a host machine to communicate with the OpenMV Camera.
To develop the script we want to be able to ensure it works, which is where the OpenMV IDE comes into its own, this allows us to develop and test the script which we later use in our Ultra96 application.
We can develop this script using either a Windows, MAC or Linux desktop.
Creating the OpenMV Script using the OpenMV IDE
To get started with the OpenMV IDE we frist need to download and install it. Once it is installed the next step is to connect our OpenMV camera to it using the USB link and then running a script on it.
To get started we can run the example hello world provided, which configures the camera to outputs standard RGB image at QVGA resolution. On the right hand side of the IDE you will be able to see the images output from the camera.
We can use this IDE to develop scripts for the OpenMV camera such as the one below which detects and identifies circles in the captured image.
Note the frame rate is lower when the camera is connected to the IDE.
We can use the scripts developed here in our Ultra96 PYNQ implementation let's take a look at how we set up the Ultra96 and PYNQ
Setting Up the Ultra96 PYNQ Image
The first thing we need to do if we have not already done it, is to download and create a PYNQ SD Card so we can run the PYNQ framework on the Ultra96.
As we want to use the Xilinx image processing overlay we should download the Ultra96 PYNQ v2.3 image.
Once you have this image creating a SD Card is very simple, extract the ISO image from the compressed file and write it to a SD Card. To write the ISO image to the SD Card we need a program such a etcher or win32 disk imager.
With a SD Card available we can then boot the Ultra96 and connect to the PYNQ framework using either
- Use a USB Ethernet connection over the MicroUSB (upstream USB connection).
- Connect via WiFi.
- Use the Ultra96 as a single-board computer and connect a monitor, keyboard and mouse.
For this project I used the USB Ethernet connection.
The next thing to do is to ensure we have the necessary overlays to be able to accelerate image processing functions into the programmable logic. To to this we need to install the PYNQ computer vision overlay.
Downloading the Image Processing Overlay
Installing this overlay is very straight forward. Open a browser window and connect to the web address of 192.168.3.1 (USB Ethernet address). This will open a log in page to the Jupyter notebooks, the password is Xilinx
Upon log in you will see the following folders and scripts
Click on new and select terminal, this will open a new terminal window in a browser window. To download and use the PYNQ Computer Vision overlays we enter the following command
sudo pip3 install --upgrade git+https://github.com/Xilinx/PYNQ-ComputerVision.git
Once these are downloaded if you look back at the Jupyter home page you will see a new directory called pynqOpenCV.
Using these Jupyter notebooks we can test the image processing performance when we accelerate OpenCV functions into the programmable logic.
Typically the hardware acceleration as can be seen in the image above greatly out performs implementing the algorithm in SW.
Of course we can call this overlay from our own Jupyter notebooks
Setting Up the OpenMV Camera in PYNQ
The next step is to configure the Ultra96 PYNQ instance to be able to control the OpenMV camera using its APIs. We can obtain these by downloading the OpenMV git repo using the command below in a terminal window on the Ultra96.
git clone https://github.com/openmv/openmv
Once this is downloaded we need to move the file pyopenmv.py
This will allow us to control the OpenMV camera from within our Jupyter applications.
To be able to do this we need to know which serial port the OpenMV camera enumerates as. This will generally be ttyACM0 or ttyACM1 we can find this out by doing a LS of the /dev directory
Now we are ready to begin working with the OpenMV camera in our applications let's take a look at how we set it up our Jupyter Scripts
Initial Test of OpenMV Camera
The first thing we need to do in a new Jupyter notebook is to import the necessary packages. This includes the pyopenmv as we just installed.
We will alos be importing numpy as the image is returned as a numpy array so that we can display it using numpy functionality.
import pyopenmvimport timeimport sysimport numpy as np
The first thing we need to do is define the script we developed in the IDE, for the "first light" with the PYNQ and OpenMV we will use the hello world script to obtain a simple image.
script = """
# Hello World Example
# Welcome to the OpenMV IDE! Click on the green run arrow button below to run the script!
import sensor, image, time
sensor.reset() # Reset and initialize the sensor.
sensor.set_pixformat(sensor.RGB565) # Set pixel format to RGB565 (or GRAYSCALE)
sensor.set_framesize(sensor.QVGA) # Set frame size to QVGA (320x240)
sensor.skip_frames(time = 2000) # Wait for settings take effect.
clock = time.clock() # Create a clock object to track the FPS.
red_led = pyb.LED(1)
img = sensor.snapshot() # Take a picture and return the image.
Once the script is defined the next thing we need to do is connect to the OpenMV camera and download the script.
portname = "/dev/ttyACM0"
connected = False
for i in range(10):
# opens CDC port.
# Set small timeout when connecting
pyopenmv.init(portname, baudrate=921600, timeout=0.050)
connected = True
except Exception as e:
connected = False
if not connected:
print ( "Failed to connect to OpenMV's serial port.\n"
"Please install OpenMV's udev rules first:\n"
"sudo cp openmv/udev/50-openmv.rules /etc/udev/rules.d/\n"
"sudo udevadm control --reload-rules\n\n")
# Set higher timeout after connecting for lengthy transfers.
pyopenmv.set_timeout(1*2) # SD Cards can cause big hicups.
Finally once the script has been downloaded and is executing, we want to be able to read out the frame buffer. This Cell below reads out the framebuffer and saves it as a jpg file in the PYNQ file system.
running = True
import numpy as np
from PIL import Image
from matplotlib import pyplot as plt
fb = pyopenmv.fb_dump()
if fb != None:
img = Image.fromarray(fb, 'RGB')
img = Image.open("frame.jpg")
When I ran this script the first light image below was received of me working in my office.
Having achieved this the next step is to start working with advanced scripts in the PYNQ Jupyter notebook. using the same approach as above we can redefine scripts which can be used for different processing including
script = """
import sensor, image, time
sensor.reset() # Initialize the camera sensor.
sensor.set_pixformat(sensor.GRAYSCALE) # or sensor.RGB565
sensor.set_framesize(sensor.QQVGA) # or sensor.QVGA (or others)
sensor.skip_frames(time = 2000) # Let new settings take affect.
clock = time.clock() # Tracks FPS.
clock.tick() # Track elapsed milliseconds between snapshots().
img = sensor.snapshot() # Take a picture and return the image.
# Use Canny edge detector
img.find_edges(image.EDGE_CANNY, threshold=(50, 80))
# Faster simpler edge detection
#img.find_edges(image.EDGE_SIMPLE, threshold=(100, 255))
print(clock.fps()) # Note: Your OpenMV Cam runs about half as fast while
For Canny edge detection when imaging a MiniZed Board
Alternatively we can also extract key points from images for tracking in subsequent images.
script = """
import sensor, time, image
# Reset sensor
# Sensor settings
sensor.skip_frames(time = 2000)
def draw_keypoints(img, kpts):
img = sensor.snapshot()
kpts1 = None
# NOTE: uncomment to load a keypoints descriptor from file
#kpts1 = image.load_descriptor("/desc.orb")
#img = sensor.snapshot()
clock = time.clock()
img = sensor.snapshot()
if (kpts1 == None):
# NOTE: By default find_keypoints returns multi-scale keypoints extracted from an image pyramid.
kpts1 = img.find_keypoints(max_keypoints=150, threshold=10, scale_factor=1.2)
# NOTE: When extracting keypoints to match the first descriptor, we use normalized=True to extract
# keypoints from the first scale only, which will match one of the scales in the first descriptor.
kpts2 = img.find_keypoints(max_keypoints=150, threshold=10, normalized=True)
match = image.match_descriptor(kpts1, kpts2, threshold=85)
# If we have at least n "good matches"
# Draw bounding rectangle and cross.
img.draw_cross(match.cx(), match.cy(), size=10)
print(kpts2, "matched:%d dt:%d"%(match.count(), match.theta()))
# NOTE: uncomment if you want to draw the keypoints
#img.draw_keypoints(kpts2, size=KEYPOINTS_SIZE, matched=True)
# Draw FPS
img.draw_string(0, 0, "FPS:%.2f"%(clock.fps()))
import sensor, image, time
sensor.set_pixformat(sensor.RGB565) # grayscale is faster
sensor.skip_frames(time = 2000)
clock = time.clock()
img = sensor.snapshot().lens_corr(1.8)
# Circle objects have four values: x, y, r (radius), and magnitude. The
# magnitude is the strength of the detection of the circle. Higher is
# `threshold` controls how many circles are found. Increase its value
# to decrease the number of circles detected...
# `x_margin`, `y_margin`, and `r_margin` control the merging of similar
# circles in the x, y, and r (radius) directions.
# r_min, r_max, and r_step control what radiuses of circles are tested.
# Shrinking the number of tested circle radiuses yields a big performance boost.
for c in img.find_circles(threshold = 2000, x_margin = 10, y_margin = 10, r_margin = 10,
r_min = 2, r_max = 100, r_step = 2):
img.draw_circle(c.x(), c.y(), c.r(), color = (255, 0, 0))
print("FPS %f" % clock.fps())
This fusion of ability to offload processing to either the OpenMV camera or the Ultra96 programmable logic running Pynq provides the system designer with maximum flexibility.
The ability to use the OpenMV camera, coupled with the PYNQ computer vision libraries along with other overlays such as the klaman filter and base overlays. We can implement algorithms which can be used to enable us to implement vision guided robotics. Using the base overlay and the Input Output processors also enables us to communicate with lower level drives, interfaces and other sensors required to implement such a solution.
Originaly posted here.
In a recent issue of IEEE Spectrum, Mikhail Dyakonov makes a pretty compelling argument that quantum computing (QC) isn't going to fly anytime soon. Now, I'm no expert on QC, and there sure is a lot of money being thrown at the problem by some very smart people, but having watched from the sidelines QC seems a lot like fusion research. Every year more claims are made, more venture capital gets burned, but we don't seem to get closer to useful systems.
Consider D-Wave Systems. They've been trying to build a QC for twenty years, and indeed do have products more or less on the market, including, it's claimed, one of 1024 q-bits. But there's a lot of controversy about whether their machines are either quantum computers at all, or if they offer any speedup over classical machines. One would think that if a 1K q-bit machine really did work the press would be all abuzz, and we'd be hearing constantly of new incredible results. Instead, the machines seem to disappear into research labs.
Mr. Duakonov notes that optimistic people expect useful QCs in the next 5-10 years; those less sanguine expect 20-30 years, a prediction that hasn't changed in two decades. He thinks a window of many decades to never is more realistic. Experts think that a useful machine, one that can do the sort of calculations your laptop is capable of, will require between 1000 and 100,000 q-bits. To me, this level of uncertainty suggests that there is a profound lack of knowledge about how these machines will work and what they will be able to do.
According to the author, a 1000 q-bit machine can be in 21000 states (a classical machine with N transistors can be in only 2N states), which is about 10300, or more than the number of sub-atomic particles in the universe. At 100,000 q-bits we're talking 1030,000, a mind-boggling number.
Because of noise, expect errors. Some theorize that those errors can be eliminated by adding q-bits, on the order of 1000 to 100,000 additional per q-bit. So a useful machine will need at least millions, or perhaps many orders of magnitude more, of these squirrelly microdots that are tamed only by keeping them at 10 millikelvin.
A related article in Spectrum mentions a committee formed of prestigious researchers tasked with assessing the probability of success with QC concluded that:
"[I]t is highly unexpected" that anyone will be able to build a quantum computer that could compromise public-key cryptosystems (a task that quantum computers are, in theory, especially suitable for tackling) in the coming decade. And while less-capable "noisy intermediate-scale quantum computers" will be built within that time frame, "there are at present no known algorithms/applications that could make effective use of this class of machine," the committee says."
I don't have a dog in this fight, but am relieved that useful QC seems to be no closer than The Distant Shore (to quote Jan de Hartog, one of my favorite writers). If it were feasible to easily break encryption schemes banking and other systems could collapse. I imagine Blockchain would fail as hash algorithms became reversable. The resulting disruption would not be healthy for our society.
On the other hand, Bruce Schneier's article in the March issue of IEEE Computing Edge suggests that QC won't break all forms of encryption, though he does think a lot of our current infrastructure will be vulnerable. The moral: if and when QC becomes practical, expect chaos.
I was once afraid of quantum computing, as it involves mechanisms that I'll never understand. But then I realized those machines will have an API. Just as one doesn't need to know how a computer works to program in Python, we'll be insulated from the quantum horrors by layers of abstraction.
Originaly posted here
A scientist from Russia has developed a new neural network architecture and tested its learning ability on the recognition of handwritten digits. The intelligence of the network was amplified by chaos, and the classification accuracy reached 96.3%. The network can be used in microcontrollers with a small amount of RAM and embedded in such household items as shoes or refrigerators, making them 'smart.' The study was published in Electronics.
Today, the search for new neural networks that can operate on microcontrollers with a small amount of random access memory (RAM) is of particular importance. For comparison, in ordinary modern computers, random access memory is calculated in gigabytes. Although microcontrollers possess significantly less processing power than laptops and smartphones, they are smaller and can be interfaced with household items. Smart doors, refrigerators, shoes, glasses, kettles and coffee makers create the foundation for so-called ambient intelligece. The term denotes an environment of interconnected smart devices.
An example of ambient intelligence is a smart home. The devices with limited memory are not able to store a large number of keys for secure data transfer and arrays of neural network settings. It prevents the introduction of artificial intelligence into Internet of Things devices, as they lack the required computing power. However, artificial intelligence would allow smart devices to spend less time on analysis and decision-making, better understand a user and assist them in a friendly manner. Therefore, many new opportunities can arise in the creation of environmental intelligence, for example, in the field of health care.
Andrei Velichko from Petrozavodsk State University, Russia, has created a new neural network architecture that allows efficient use of small volumes of RAM and opens the opportunities for the introduction of low-power devices to the Internet of Things. The network, called LogNNet, is a feed-forward neural network in which the signals are directed exclusively from input to output. Its uses deterministic chaotic filters for the incoming signals. The system randomly mixes the input information, but at the same time extracts valuable data from the information that are invisible initially. A similar mechanism is used by reservoir neural networks. To generate chaos, a simple logistic mapping equation is applied, where the next value is calculated based on the previous one. The equation is commonly used in population biology and as an example of a simple equation for calculating a sequence of chaotic values. In this way, the simple equation stores an infinite set of random numbers calculated by the processor, and the network architecture uses them and consumes less RAM.
The scientist tested his neural network on handwritten digit recognition from the MNIST database, which is considered the standard for training neural networks to recognize images. The database contains more than 70,000 handwritten digits. Sixty-thousand of these digits are intended for training the neural network, and another 10,000 for network testing. The more neurons and chaos in the network, the better it recognized images. The maximum accuracy achieved by the network is 96.3%, while the developed architecture uses no more than 29 KB of RAM. In addition, LogNNet demonstrated promising results using very small RAM sizes, in the range of 1-2kB. A miniature controller, Atmega328, can be embedded into a smart door or even a smart insole, has approximately the same amount of memory.
"Thanks to this development, new opportunities for the Internet of Things are opening up, as any device equipped with a low-power miniature controller can be powered with artificial intelligence. In this way, a path is opened for intelligent processing of information on peripheral devices without sending data to cloud services, and it improves the operation of, for example, a smart home. This is an important contribution to the development of IoT technologies, which are actively researched by the scientists of Petrozavodsk State University. In addition, the research outlines an alternative way to investigate the influence of chaos on artificial intelligence," said Andrei Velichko.
Originally posted HERE.
by Russian Science Foundation
Image Credit: Andrei Velichko
This complete guide is a 212-page eBook and is a must read for business leaders, product managers and engineers who want to implement, scale and optimize their business with IoT communications.
Whether you want to attempt initial entry into the IoT-sphere, or expand existing deployments, this book can help with your goals, providing deep understanding into all aspects of IoT.
When I work on a development project, I’ve become a big fan of using development boards that have the Arduino headers on them. The vast number of shields that easily connect to these headers is phenomenal. The one problem that I’ve always had though was that there is always a need to use a breadboard to test a circuit or integrate a sensor that just isn’t in an Arduino header format. The result is a wiring mess that can result in loose or missing connections.
I was recently talking with Max Maxfield and he pointed me to a really cool adapter board designed to remove these wiring jumpers to a breadboard. Max wrote about this board here but I’m so excited about this that I thought I’d add my two cents as well.
The BreadShield, which can be purchased at https://www.crowdsupply.com/loser/breadshield, adapts the Arduino headers to a linear set of header pins designed to be plugged into a breadboard. You can see in the image below that this completely removes all the extra jumpers that one would normally require which has the potential to remove quite a few jumper wires.
When I heard about these, I purchased three assembled units for about $28 which saves me the time from having to assemble the adapter myself. DIY assembly runs for about $15 for a set of three boards. Either way, a great price to remove a bunch of wires from the workbench.
Now I’m still waiting for mine to arrive, but from the image, you can see that the one challenge to using these adapters might be adapting the height of your breadboard to your hardware stack. While this could be an issue, I keep various length spacers around the office so that I can adapt board heights and undoubtedly there will be a length that will ensure these line up properly.
You can view the original post here
Does anyone remember in-circuit emulators (ICEs)?
Around 1975 Intel came out with the 8080 microprocessor. This was a big step up from the 8008, for the 8080 had a 64k address space, a reasonable ISA, and an honest stack pointer (the 8008 had a hardware stack a mere 7 levels deep). They soon released the MDS 800, a complete computer based on the 8080, with twin 8" floppy drives. An optional ICE was available; this was, as I recall, a two-board set that was inserted in the MDS. A ribbon cable from those boards went to a small pod that could be plugged into the 8080 CPU socket of a system an engineer was developing.
The idea was that the MDS could act as the device's under test (DUT) CPU. It was rather like today's JTAG debuggers in that one could run code on the DUT, set breakpoints, collect trace data, and generally debug the hardware and software. For there was no JTAG then.
We had been developing microprocessor-based products using the 8008, but quickly transitioned to the 8080 for the increased computational power and address space. I begged my boss for the money for an MDS, which was $20k (about $100k in today's dollars), and to my surprise he let us order one. Despite slow floppies that stored only 80 KB each this tool greatly accelerated our work.
Before long ICEs were the standard platform for embedded work. Remember: this was before PCs so there were no standard desktop computers. The ICE was the computer, the IDE (such as it was) and the debugger.
In the mid-80s I was consulting and designed a, uh, "data gathering" system for our friends in Langley, VA, using multiple NSC-800 CPUs. There were few tools available for this part so I created a custom ICE that let me debug the code. Then a light bulb went on: why not sell the thing? There was practically no market for NSC-800 tools so I came up with versions for the Z80 and 8085 and slapped a $695 label on it. Most ICEs at the time cost many thousands so sales spiked.
Back then we still drew schematics on large D-size (17" x 22") vellum with a pencil. I laid out the PCBs on mylar with black tape for the tracks, as was the norm at the time.
This ICE is perhaps the design I'm most proud of in my career. It was only 17 ICs but was the epitome of an embedded system. Software replaced the usual gobs of hardware. On a breakpoint, for instance, the hardware switched from using the DUT stack to a stack on the emulator, but since the user's stack pointer could point anywhere, and the RAM in the ICE was only a few KB, the hardware masked off the upper address bits and lots of convoluted code reconstructed the user environment.
At the time ICEs advertised their breakpoints; most supported no more than a few as comparators watched the address bus for the breakpoint. My ICE used a 64k by one bit memory that mirrored the user bus. Need a breakpoint at, say, address 0x1234? The emulator set that bit in the memory true. Thus, the thing had 65K breakpoints. One of my dumbest mistakes was to not patent that, as all ICE vendors eventually copied the approach.
The trouble with tools is support. An ICE replaces the DUT CPU, and interfaces with all sorts of unknown target hardware. Though the low clock rates of the Z80 meant we initially had few problems, as we expanded the product line support consumed more and more time. Eventually I learned it was equally easy to sell a six-thousand-dollar product as a six-hundred-dollar version, so those simple first emulators were replaced by much more complex many-hundred chip versions with vast numbers of features.
But the market was changing. By the mid-90s SMT CPUs were common. These were challenging to connect to. Clock rate soared making every connection a Maxwell Law nightmare. I sold the business in 1997 and went on to other endeavors. Eventually the ICE market disappeared.
One regret from all those years is that I didn't save any of the emulator's firmware or schematics. In this business everything is ephemeral. We should make an effort to preserve some of that history.
You can view the original post on TEM here
ADLINK is a global leader in edge computing driving data-to-decision applications across industries. The company recently introduced I-Pi SMARC for Industrial IoT prototyping.
- AdLInk I-Pi SMARC consists of a simple carrier paired with a SMARC Computer on Module
- SMARC Modules are available from entry level PX30 Rockchip to top of the line Intel Apollo Lake.
- SMARC modules are specifically designed for typical industrial embedded applications that require long life, high MTBF and strict revision control.
- Use popular off the shelve sensors and create prototypes or proof of concepts on short notice.
Additional information can be found here
About The Eclipse Foundation
The Eclipse Foundation provides our global community of individuals and organizations with a mature, scalable, and business-friendly environment for open source software collaboration and innovation.
Helium, the company behind one of the world’s first peer-to-peer wireless networks, is announcing the introduction of Helium Tabs, its first branded IoT tracking device that runs on The People’s Network. In addition, after launching its network in 1,000 cities in North America within one year, the company is expanding to Europe to address growing market demand with Helium Hotspots shipping to the region starting July 2020.
Since its launch in June 2019, Helium quickly grew its footprint with Hotspots covering more than 700,000 square miles across North America. Helium is now expanding to Europe to allow for seamless use of connected devices across borders. Powered by entrepreneurs looking to own a piece of the people-powered network, Helium’s open-source blockchain technology incentivizes individuals to deploy Hotspots and earn Helium (HNT), a new cryptocurrency, for simultaneously building the network and enabling IoT devices to send data to the Internet. When connected with other nearby Hotspots, this acts as the backbone of the network.
“We’re excited to launch Helium Tabs at a time where we’ve seen incredible growth of The People’s Network across North America,” said Amir Haleem, Helium’s CEO and co-founder. “We could not have accomplished what we have done, in such a short amount of time, without the support of our partners and our incredible community. We look forward to launching The People’s Network in Europe and eventually bringing Helium Tabs and other third-party IoT devices to consumers there.”
Introducing Helium Tabs that Run on The People’s Network
Unlike other tracking devices,Tabs uses LongFi technology, which combines the LoRaWAN wireless protocol with the Helium blockchain, and provides network coverage up to 10 miles away from a single Hotspot. This is a game-changer compared to WiFi and Bluetooth enabled tracking devices which only work up to 100 feet from a network source. What’s more, due to Helium’s unique blockchain-based rewards system, Hotspot owners will be rewarded with Helium (HNT) each time a Tab connects to its network.
In addition to its increased growth with partners and customers, Helium has also seen accelerated expansion of its Helium Patrons program, which was introduced in late 2019. All three combined have helped to strengthen its network.
Patrons are entrepreneurial customers who purchase 15 or more Hotspots to help blanket their cities with coverage and enable customers, who use the network. In return, they receive discounts, priority shipping, network tools, and Helium support. Currently, the program has more than 70 Patrons throughout North America and is expanding to Europe.
Key brands that use the Helium Network include:
- Nestle, ReadyRefresh, a beverage delivery service company
- Agulus, an agricultural tech company
- Conserv, a collections-focused environmental monitoring platform
Helium Tabs will initially be available to existing Hotspot owners for $49. The Helium Hotspot is now available for purchase online in Europe for €450.
This blog is the second part of a series covering the insights I uncovered at the 2020 Embedded Online Conference.
Last week, I wrote about the fascinating intersection of the embedded and IoT world with data science and machine learning, and the deeper co-operation I am experiencing between software and hardware developers. This intersection is driving a new wave of intelligence on small and cost-sensitive devices.
Today, I’d like to share with you my excitement around how far we have come in the FPGA world, what used to be something only a few individuals in the world used to be able to do, is at the verge of becoming more accessible.
I’m a hardware guy and I started my career writing in VHDL at university. I then started working on designing digital circuits with Verilog and C and used Python only as a way of automating some of the most tedious daily tasks. More recently, I have started to appreciate the power of abstraction and simplicity that is achievable through the use of higher-level languages, such as Python, Go, and Java. And I dream of a reality in which I’m able to use these languages to program even the most constrained embedded platforms.
At the Embedded Online Conference, Clive Maxfield talked about FPGAs, he mentions “in a world of 22 million software developers, there are only around a million core embedded programmers and even fewer FPGA engineers.” But, things are changing. As an industry, we are moving towards a world in which taking advantage of the capabilities of a reconfigurable hardware device, such as an FPGA, is becoming easier.
- What the FAQ is an FPGA, by Max the Magnificent, starts with what an FPGA is and the beauties of parallelism in hardware – something that took me quite some time to grasp when I first started writing in HDL (hardware description languages). This is not only the case for an FPGA, but it also holds true in any digital circuit. The cool thing about an FPGA is the fact that at any point you can just reprogram the whole board to operate in a different hardware configuration, allowing you to accelerate a completely new set of software functions. What I find extremely interesting is the new tendency to abstract away even further, by creating HLS (high-level synthesis) representations that allow a wider set of software developers to start experimenting with programmable logic.
- The concept of extending the way FPGAs can be programmed to an even wider audience is taken to the next level by Adam Taylor. He talks about PYNQ, an open-source project that allows you to program Xilinx boards in Python. This is extremely interesting as it opens up the world of FPGAs to even more software engineers. Adam demonstrates how you can program an FPGA to accelerate machine learning operations using the PYNQ framework, from creating and training a neural network model to running it on Arm-based Xilinx FPGA with custom hardware accelerator blocks in the FPGA fabric.
FPGAs always had the stigma of being hard and difficult to work on. The idea of programming an FPGA in Python, was something that no one had even imagined a few years ago. But, today, thanks to the many efforts all around our industry, embedded technologies, including FPGAs, are being made more accessible, allowing more developers to participate, experiment, and drive innovation.
I’m excited that more computing technologies are being put in the hands of more developers, improving development standards, driving innovation, and transforming our industry for the better.
If you missed the conference and would like to catch the talks mentioned above*, visit www.embeddedonlineconference.com
Part 3 of my review can be viewed by clicking here
In case you missed the previous post in this blog series, here it is:
*This blog only features a small collection of all the amazing speakers and talks delivered at the Conference!
I recently joined the Embedded Online Conference thinking I was going to gain new insights on embedded and IoT techniques. But I was pleasantly surprised to see a huge variety of sessions with a focus on modern software development practices. It is becoming more and more important to gain familiarity with a more modern software approach, even when you’re programming a constrained microcontroller or an FPGA.
Historically, there has been a large separation between application developers and those writing code for constrained embedded devices. But, things are now changing. The embedded world intersecting with the world of IoT, data science, and ML, and the deeper co-operation between software and hardware communities is driving innovation. The Embedded Online Conference, artfully organised by Jacob Beningo, represented exactly this cross-section, projecting light on some of the most interesting areas in the embedded world - machine learning on microcontrollers, using test-driven development to reduce bugs and programming an FPGA in Python are all things that a few years ago, had little to do with the IoT and embedded industry.
This blog is the first part of a series discussing these new and exciting changes in the embedded industry. In this article, we will focus on machine learning techniques for low-power and cost-sensitive IoT and embedded Arm-based devices.
Think like a machine learning developer
Considered for many year's an academic dead end of limited practical use, machine learning has gained a lot of renewed traction in recent years and it has now become one of the most interesting trends in the IoT space. TinyML is the buzzword of the moment. And this was a hot topic at the Embedded Online Conference. However, for embedded developers, this buzzword can sometimes add an element of uncertainty.
The thought of developing IoT applications with the addition of machine learning can seem quite daunting. During Pete Warden’s session about the past, present and future of embedded ML, he described the embedded and machine learning worlds to be very fragmented; there are so many hardware variants, RTOS’s, toolchains and sensors meaning the ability to compile and run a simple ‘hello world’ program can take developers a long time. In the new world of machine learning, there’s a constant churn of new models, which often use different types of mathematical operations. Plus, exporting ML models to a development board or other targets is often more difficult than it should be.
Despite some of these challenges, change is coming. Machine learning on constrained IoT and embedded devices is being made easier by new development platforms, models that work out-of-the-box with these platforms, plus the expertise and increased resources from organisations like Arm and communities like tinyML. Here are a few must-watch talks to help in your embedded ML development:
- New to the tinyML space is Edge Impulse, a start-up that provides a solution for collecting device data, building a model based around it and deploying it to make sense of the data directly on the device. CTO at Edge Impulse, Jan Jongboom talks about how to use a traditional signal processing pipeline to detect anomalies with a machine learning model to detect different gestures. All of this has now been made even easier by the announced collaboration with Arduino, which simplifies even further the journey to train a neural network and deploy it on your device.
- Arm recently announced new machine learning IP that not only has the capabilities to deliver a huge uplift in performance for low-power ML applications, but will also help solve many issues developers are facing today in terms of fragmented toolchains. The new Cortex-M55 processor and Ethos-U55 microNPU will be supported by a unified development flow for DSP and ML workloads, integrating optimizations for machine learning frameworks. Watch this talk to learn how to get started writing optimized code for these new processors.
- An early adopter implementing object detection with ML on a Cortex-M is the OpenMV camera - a low-cost module for machine vision algorithms. During the conference, embedded software engineer, Lorenzo Rizzello walks you through how to get started with ML models and deploying them to the OpenMV camera to detect objects and the environment around the device.
Putting these machine learning technologies in the hands of embedded developers opens up new opportunities. I’m excited to see and hear what will come of all this amazing work and how it will improve development standards and transform embedded devices of the future.
If you missed the conference and would like to catch the talks mentioned above*, visit www.embeddedonlineconference.com
*This blog only features a small collection of all the amazing speakers and talks delivered at the Conference!
Part 2 of my review can be viewed by clicking here
Note: this page contains paid content.
Please, subscribe to get an access.
Note: this page contains paid content.
Please, subscribe to get an access.