Aasemoon'z Cluster

Introduction: The proliferation of multicore processors and the desire to consolidate applications and functionality will push the embedded industry into embracing virtualization in much the same way it has been embraced in the server and compute-centric markets. However, there are many paths to virtualization for embedded systems. After a tour of those options and their pros and cons, Freescale Semiconductor’s Syed Shah shows why the bare metal hypervisor-based approach, coupled with hardware virtualization assists in the core, the memory subsystem and the I/O, offers the best performance.

It is no secret that field-programmable gate arrays (FPGAs) are getting bigger and more complex all the time. The fabrication process creates smaller transistors and makes more dense chips packing more digital processing per nanometer. Engineers love to see advancement because it means they can do more with modern silicon, and many times NI LabVIEW FPGA Module technology helps by abstracting the complexity to a higher level so that engineers can more smoothly take advantage of these improvements.  Unfortunately, there is one issue with FPGAs that continues to be a time sink and only gets worse with denser FPGAs: compilation time.

Clearly the most attractive super hero power for nanotechnology at the moment is invisibility. Last month we had a nano-enabled coating that managed to make aircraft invisible to radar. Now we have a metamaterial consisting of fishnet-like film containing holes about 100 nanometers in diameter that could serve as an invisibility cloak. While I personally might be persuaded to choose Spider-like climbing abilities for my nano-enabled super hero power, invisibility does pose an attractive option. However, invisibility is far from the point of this research conducted at the Birck Nanotechnology Center, Purdue University and appears in the August 5th edition of the journal Nature.

If you had a dinner invitation in Utah's Escalante Valley almost 10,000 years ago, you would have come just in time to try a new menu item: mush cooked from the flour of milled sage brush seeds.

Researchers from Leeds University are working on a camera and drill-weilding robot known as Djedi to solve the mystery of the blocked shafts inside the Great Pyramid at Giza. In 1992 and 2002, remote cameras were sent through the shaft under the watchful eye of antiquities master Dr. Zahi Hawass only to be stopped by limestone doors. Dr. Robert Richardson of the Mechanical Engineering department said their goal is to find out what is beyond the blocks and go as far as possible to discover the purpose of the shafts, all while doing minimal damage to the structure. Final preparations are being made now with hopes of sending the robot in before year's end. Place your bets now!

Perhaps the most difficult control problem for a drive servo is that of going down a ramp. Any back drivable drive servo will exhibit a freewheeling velocity on a given ramp. This is the speed at which the robot will roll down the ramp in an unpowered state. At this speed, the surface drag and internal drag of the servo are equal to the gravitational force multiplied by the sine of the slope. The freewheeling speed is thus load dependent.

Last week Wim Jongman bloged about the Nebula Oscilloscope widget. It’s just an awesome widget for monitoring activity. See Wim’s post to form an opinion yourself. So, for me as a RAP developer, the first question I always ask myself when seeing such a cool thing is: “Will it run on RAP?”. I followed the steps Wim described to get the Oscilloscope running, changed the target to RAP, commented out one line of code and started the application. You can see the result in the screencast below.

First, right off the top here: Scala has true blue Java-like null; any reference may be null. Its presence muddies the water quite a bit. But since Beust's article explicitly talks about Haskell he's clearly not talking about that aspect of Scala because Haskell doesn't have null. I'll get back to Scala's null at the end but for now pretend it doesn't exist.Second, just to set the record straight: "Option" has roots in programming languages as far back as ML. Both Haskell's "Maybe" and Scala's "Option" (and F#'s "Option" and others) trace their ancestry to it.

platform :   Linux   Windows   MacOSX Intel type :   diskmag release date : august 2010 release party : Evoke 2010

The science behind gecko toes holds the answer to a dry adhesive that provides an ideal grip for robot feet. Stanford mechanical engineer Mark Cutkosky is using the new material, based on the structure of a gecko foot, to keep his robots climbing.

Can a team of soccer-playing robots beat the human World Cup champions by 2050? That's the ultimate goal of RoboCup, an international tournament where teams of soccer robots compete in various categories, from small wheeled boxes to adult-size humanoids. IEEE Spectrum's Harry Goldstein traveled to Singapore to attend RoboCup 2010 -- and check out how the man vs. machine future of soccer is playing out.

The R programming language was featured about a year ago in a New York Times article (http://bit.ly/iaqQ). I've been an R user since 2000, so I've collected some resources for people who want to get started with R.   The first place to start is the R Project web site at http://www.r-project.org/. Next, you'll actually want to install R itself. There are several options, depending on your environment.

Single-walled carbon nanotube (SWCNT)-based thin film transistors (TFTs) could be at the core of next-generation flexible electronics – displays, electronic circuits, sensors, memory chips, and other applications that are transitioning from rigid substrates, such as silicon and glass, to flexible substrates. What's holding back commercial applications is that industrial-type manufacturing of large scale SWCNT-based nanoelectronic devices isn't practical yet because controlling the morphology of single-walled carbon nanotubes is still causing headaches for materials engineers.

When a data (typically a variable) can be accessed by several threads, you must synchronize the access to the data to ensure visibility and correctness.

Oracle made a big noise in the Linux community yesterday by announcing its own spin on the Linux kernel on top if its so-called Unbreakable Linux. Oracle presented the announcement as offering a "modern" Linux kernel on top of its own clone of Red Hat. Underneath the hype, what's Oracle really offering, and what does it mean for Linux? For years, Oracle has ridden Red Hat's coattails and tried to present it as a good thing to its customers. Oracle rebrands Red Hat Enterprise Linux (RHEL), slaps its own support package on it, and lets Red Hat do all the heavy development lifting while it tries to poach Red Hat's customers. All perfectly legal according to the licenses that RHEL is shipped under, but a bit skeezy nonetheless. Or perhaps parasitic might be a better word.

Dave Megginson (who drove the development of the SAX API that will be familiar to many XML developers who use Java) recently wrote Java is dead. Java stood out as a programming language (though not as a platform) in that Sun had refused to standardize it through an independent and reputable standards organization (a lot of the hard work had been done in one attempt to put it through ECMA and one to put it through ISO, both times Sun pulled out and eventually made their highly unsatisfactory JCP Java Community Process system.) Without the ability to alter Java significantly in ways that might go against their druthers, Java suffered two major forks (Microsoft's J++ then its C#, and IBM's SWT) where significant players disagreed with a major component (the graphics library). Java succeeded in middleware, and but failed to take advantage of the rise of browsers on the deskop: their HTML parser was great for the middle 1990s but was deliberately neglected to the point of being unusable: it is hard not to see this as a deliberate attempt by Sun to leave the browser market to its friends and enemies. I really liked Java, and bet my company on it (in a sense): I would not do that today.

Japan’s Explay Ltd recently announced that it has begun to ship its pico projector engines to developers around the world. The Explay Projector Engine is only 6.7 cubic centimeters in size and just 7mm thick (~1/4 of an inch). Despites its tiny dimensions, the pico projector generates 14 lumens laser light on just 1.3 Watts of power (1.8 with control circuits) and can produce images 7 to 70 inches in size. Resolution is a respectable 852×480 and with a laser based system it should stay in sharp focus over a wide range (20 to 200cm). While Explay has yet to announce which manufacturers will be using their projector they did say that they expect it to appear in devices as early as February of 2011. Looks like we’ll need to watch for it at CES. Explay plans on improving their projector engine further. They hope that the end of 2011 will see the arrival of a 25 lumens WXGA 1366×768 version. A member of the R&D team in Israel (part of XDM Ltd) shows off the 14 lumens pico projector in a prototype testing rig in the video below. Not a bad image for the world’s smallest laser projector.

Earlier in this series, we touched on one problem that can arise when sampling an analog signal, namely the problem of aliasing. There are three other issues with signal sampling to which we now turn our attention: digitization effects, finite register length effects, and oversampling. So far, weve assumed that all of the signals were measuring are continuous analog values; i.e., our measurements are completely accurate. Even in the cases in which we have noise, the underlying assumption is that the measurement itself, for example the noisy sensor output voltage, is known precisely.

This article features an example chapter from a new *Hot-off-the-Press* book on FPGA Design that just recently hit the streets in August 2010. This chapter is reproduced here with the kind permission of the publisher – Springer. This book -- FPGA Design: Best Practices for Team-Based Design -- describes best practices for successful FPGA design. It is the result of the author’s meetings with hundreds of customers on the challenges facing each of their FPGA design teams. By gaining an understanding into their design environments, processes, what works and what does not work, key areas of concern in implementing system designs have been identified and a recommended design methodology to overcome these challenges has been developed.

In this session, Don McCrady discusses how C++ programmers can fully utilize multicore in their applications using the Concurrency Runtime (ConcRT), the Parallel Pattern Library (PPL), and the Asynchronous Agents Library that ship with Visual Studio 2010.