1 2 3 Previous Next

Embedded

422 posts

After migrating from an Arduino to a Raspberry Pi, Maker Jonathan Peace discovered that there were still some things that he just couldn’t do with a barebones Unix platform. In search of a way to help alleviate this problem, Ardhat was born

6a406bc3c11fed4a8387966dd8473198_original.jpg

Billed as the “missing link that connects the Raspberry Pi with the real world,” Ardhat embeds an Arduino-compatible MCU (ATmega328P) in a Raspberry Pi-compatible HAT, which responds quickly to real-time events while letting the Pi do all of the heavy lifting.

For those unfamiliar with HATs, or Hardware Attached on Top, the Raspberry Pi B+ had been designed specifically with add-on boards in mind that conform to a specific set of rules that make life easier for users. A significant feature of HATs is the inclusion of a system that allows the ARM Cortex-A7-based Pi to identify a connected HAT and automatically configure the GPIOs and drivers for the board.

“Ardhat adds the environmental protection and awareness, real-time performance, and low-power operation that a real world system needs. In a super-compact Raspberry Pi compatible HAT, Ardhat protects and enhances the Raspberry Pi for real applications, and is accessible to everyone that has used an Arduino,” Peace writes.

0e9456e2a36ca0a04b07adb02076e86f_original.png

The Ardhat comes in four different models — two equipped with long-range radio modules, the other two without. Each unit is packed with analog sensors, a real-time clock, user interface controls, supply monitoring, 5V Arduino shield capability, a wide operating voltage range (including automotive), high-current outputs for driving peripherals and full power/sleep management — all of which are accessible from either the Raspberry Pi or the Ardhat’s on-board chip. Makers looking for a little more oomph can also choose between the Ardhat-I and Ardhat-W. The first adds a 10-DOF inertial measurement unit, while the latter boasts a long-range ISM wireless node (with up to 15km range) to make it IoT ready right out of the box.

Not only does it accept most Arduino shields, the Ardhat sports a ‘FlatTop’ design which leaves plenty of space for any battery or a prototyping board. It even comes with an optional tailored high-capacity 1800mAh battery that plugs directly into the standard JST connector and fits snugly between the shield headers of the flattop board design.

09254e8a0f99bd9fff20dc1a3f37b2e0_original.jpg

Ardhat’s smart power management features a power switch and charge control, and enables a Raspberry Pi to run on real world power supplies, ranging from automotive to LiPo batteries, for months. This allows the HAT to connect to and drive 5V systems like servos, quadcopters and smart LEDs.

The Ardhat doesn’t just protect the Raspberry Pi from external voltage spikes and power outages, an optional laser-cut perspex ‘TopHat’ enclosure can physically safeguard it as well. However, Makers can still gain access to the Arduino shield pins for experimenting and teaching purposes, without the danger of damaging the delicate circuitry of the Raspberry Pi circuit board.

4f9c564ea65f8b3559d1e16cf080aa27_original.png

In true Maker fashion, Ardhat’s scheduler and applications are entirely open-source. Though its real-time software is supplied as a preloaded sketch, Makers can modify and update it as they wish using the Arduino IDE.

So whatever you’re building, whether it’s a self-balancing robot, an IoT gateway or a mind-blowing light show, Ardhat has you covered. Those wishing to learn more can head over to its official Kickstarter page, where the ubIQio team is currently seeking £25,000. Shipment is expected to begin in August 2015.

This blog originally appeared on Atmel Bits & Pieces.

When it comes to obtaining an embedded Linux devices like the Raspberry Pi and BeagleBone for a project, most Makers would simply head online and purchase one. That is unless you’re “hak8or,” who decided to produce his own uber mini board based on an Atmel | SMART AT91SAM9N12 that runs Linux off of a USB drive
dsc_9624_s-1.jpg

Inspired by Henrik Forstén’s recent device, hak8or’s system measures just two square inches in size, features 64 MB of DDR2 DRAM, a USB host and OTG port on-board.

dsc_9625_s.jpg

“NAND Flash doesn’t work for some reason, so dataflash is used instead. The dataflash chip is attached to the SPI bus from the chip to the SPI bus pads while also using it’s own board. DRAM is also underclocked to 100 Mhz instead of 133 Mhz via the main system bus downclock, causing the processor to run at 300 Mhz instead of 400 Mhz. AT91 Bootstrap and U-Boot are located on dataflash at0x00 and 0x8400 respectivly, with U-Boot pulling the kernel from a flash drive connected via USB OTG as well. The kernel then pulls the rootfs off the flash drive in a dedicated ext2 rootfs as rw (read write). GCC has been cross compiled to this board and compiles programs correctly, so this board was used for completion of the project,” hak8or notes.

dsc_9626_s.jpg

Those wishing to delve deeper can head over to the project’s Github page, where the Maker has provided an elaborate readme.md covering the boot process, the root filesystem and the toolchain. He also goes on to list a slew of useful resources for anyone looking to boot Linux on the chips.


This blog post originally appeared on Atmel Bits & Pieces.

In a number of different fields – notably medical, military, avionics, industrial and automotive – there is an increasing focus on safety and security, which results in a higher demand for certification of systems. Such certifications include FDA 510K [medical], DO-178C [avionics], IEC 61508 [industrial] and ISO 26262 [automotive].

Certification of software is a big subject, requiring specialist expertise and often a large budget. But all embedded developers would be wise to have a grasp of the basics …

Broadly speaking, the certification of an embedded software application entails the inspection, analysis and testing of the code on a line by line basis. This is a specialized and, hence, potentially expensive exercise. There are some key points to note:

  1. the certification process is applied to the entire application, including OS, middleware etc.
  2. all of the source code must be available [this is only an issue if 3rd party IP, like an RTOS, is used]
  3. the more lines of code, the greater the cost of certification

Taking these points in turn:

To read the rest of this entry, visit the Colin Walls blog via Mentor Embedded.

ScreenClip.png

My colleague, Tom De Schutter, wrote a good blog about a recent accomplishment of the Synopsys Press book "Better Software. Faster!" -- more than 3,000 copies in distribution to designers in more than 1,000 companies. The success of the book highlights the interest in using virtual prototyping as a key methodology to "shift left" product development.

 

You can download a free Better Software. Faster! eBook in English or Chinese by using either your SolvNet ID or email address. The Japanese edition is underway as well, so stay tuned for that.

 

The book, which includes case studies from thirteen companies, including one written by Rob Kaye of ARM, dives deep in to virtual prototyping as the key methodology to enable concurrent hardware/software development by decoupling the dependency of the software development from hardware availability. .

 

As we look in depth at the rapid increase of ARM based Embedded Computing Boards (ECBs) coming to market we are talking to industry experts, analysts, silicon partners and board vendors to help us understand the market dynamics. One really interesting use case for an ARM ECB is in the Google Lunar X-Prize competition where teams compete for a chance to send a robot to the moon.  But first some background:  simon collins.jpg

 

I spoke to Simon Collins who is a product manager with GE Intelligent Platforms a major player in the embedded market and proponent of the industrial Ethernet.  GE came to my attention when they released a new COM Express format board based on the NVidia Tegra K1 (the mCOM10-K1 pictured below).

mcom10-k1_hr.jpg

The move by GE to working with NVIDIA is very new but Simon told me that because market forces are changing so rapidly in Embedded they had to find a lower power solution to their customers imaging needs.  Video processing of some kind is becoming a must have in the IoT and especially in autonomous vehicles so the SWaP (Size, Weight and Power) requirements mean a whole new approach. Another key factor is that in many video applications the systems don’t need to be real time in the true sense of hard deterministic avionics type systems and Simon coined the term “real time enough” to describe what his customers want.  So in these applications a system might run Linux or even Windows because interrupts aren't going to be catastrophic and it’s better to have some video than none.  Another tipping point that led to the ARM based board decision was the availability of many versions of Linux that can cross platforms from x86 to ARM by using a different compiler. In this case the Linux version that GE offers is based on Ubuntu which runs on both X86 and ARM so the same source code can be used but compiled for the NVIDIA Tegra K1 processor.

 

Another key factor for Simon and the GE team was the power saving nature of the NVIDIA Tegra K1, they could offer the customer what they needed within a 10w power budget compared to past designs that may need up to 100w to deliver similar capabilities.  Today many vehicles are essentially “driven by video” so drivers and their robot companions can see multiple views of their surroundings so this level of video processing is becoming a standard.

 

Since we are talking about ruggedized applications its critical we talk about the difference between boards that are sold as development kits and the COM Express boards that GE produces.  Simon told me that the mCOM-10 board has memory soldered on and doesn’t use gold edge connectors because over time vibration and temperature change movement can degrade the connections so military grade connectors are used throughout. Different board form factors have been standardized depending upon the application (see my blog on Board standards association VITA for example) and you can search the ARM Embedded Computing Board (ECB) Resource Guide  by form factor for your needs.

 

So now we can get to the fun part and thats going to the moon!  Simon and the GE Intelligent Platforms team have been working with one of the Lunar XPRIZE competitors, Astrobotic to help them get their vehicle to land safely on the moon. Astrobotic, with its partner, Carnegie Mellon University, is pursuing the Google Lunar XPRIZE and is scheduled to launch the first mission during the second half of 2016  At the recent NVIDIA TechCon I got a shot of Simon and one of the XPRIZE prototypes:

IMG_2118.JPG

So what exactly is the GE board going to be doing on the Astrobotic lander?  To me this is the best part of this whole project and why you never know what you are going to learn when you talk to end users of ARM technology.  The XPRIZE Lunar landing is going to take place on a more "interesting" part of the moon (the North pole) where there are many more hazards than the relatively flat areas where previous spacecraft have landed so the Lander needs to steer clear of obstacles in real time to land safely.  But, and its a big but, there is a 10 second communications latency between the Lander and Earth so its going to have to autonomously land itself and it will do that with the video processing on the GE mCOM board.  In exactly the same way a self driving car can spot pedestrians and traffic lights, the Astrobotic Lander will steer its way around boulders and craters using the video processing of the NVIDIA Tegra K1 and (hopefully) land safely.  To me its a perfect example of how the low power of ARM based bards combined with incredible embedded vision capabilities are changing the way engineers can solve difficult problems not just on earth but on the moon. Oh and lets not forget why the Astrobotic Lander needs to steer itself in visually all the way;  there is no GPS on the moon, duh!

As we take a deep dive into the world of Embedded Computing Boards (ECBs) here on the Community it was important to not just focus on hardware and take a look at software in all its forms. If you are regular here in the community you may know Colin Walls who is a prolific writer, speaker and teacher of all things Embedded.  Colin's latest book is “Embedded Software: The Works”, he also has a day job at Mentor Embedded Software division. Colin Walls headshot.jpg

 

Colin has seen the rise of ARM ECBs himself and gave me an interesting and I think important perspective on multi-core processing on these boards.  Not many years ago Multicore processors were seen as exotic, expensive and hard to code but a major shift is taking place where the full potential of multicore is now coming to markets other than servers and supercomputers.

 

Colin told me that there are 2 approaches to harnessing multi-core processors,  the first is to run code across all the cores to speed up throughput (called symmetric multiprocessing or SMP) and this works well up to about 8 cores and then the code management overhead offsets the speed increase.  The other approach is to use different cores for different tasks at the same time, this is called asymmetric multi-processing (or AMP) and one core may be running a real time operating system (RTOS) and another running in bare metal mode (no operating system) for simpler  low power tasks like battery management.

 

ARM has embraced asymmetric multiprocessing (also known as heterogeneous computing) with a concept called big.LITTLE where in its first incarnation a Cortex-A15 core could run more complex processes and the Cortex-A7 core might run low power supervisory tasks.  Later big.LITTLE was introduced on the Cortex-A57 and Cortex-A53 cores for the increasing demands of the mobile industry.  In continuing development of this trend the newly announced Cortex-A72 core can be combined with a Cortex-A53 for even more performance. Point of clarification; in any big.LITTLE configuration all cores are based on the same ARM instruction set architecture.

 

So now designers have a highly powerful and flexible platform to run their code and there are two added advantages of ARM ECBs to take into consideration, the first is the dramatically lower cost of the boards with some selling for less than $100 and second these boards consume far less power (1/10th in most cases) than boards from competing architectures.  We have gathered a list of over 120 ARM based board vendors for you here: Embedded Computing Board (ECB) Resource Guide.

 

So as Colin pointed out there is a lot of interest in asymmetric processing on ARM boards but there are software questions you need to answer.  First you will need a hypervisor and you will need to choose operating system(s) and the code development tools.  Mentor has an AMP framework for systems like this with a choice of RTOS (Nucleus), Linux (for UI and networking) and the tools needed to develop a powerful but low power and low cost systems (see schematic below) mentor nucleus.jpg

Another interesting point Colin raised is that Windows 10 is destined to run on ARM very soon so there may be a whole new market created for systems that run Windows 10 as the UI and IoT connectivity layer and other cores could run an RTOS for machine control or a bare metal approach.  Whichever approach you choose to implement a system using a single board computer it’s clear that we are at an inflection point where multi-core processing on low power, high performance yet inexpensive boards could transform computing in the Embedded and IoT market.  What's your take on this trend?

Anyone taking a serious look at the embedded market really has to speak to Freescale because the whole market came about because Motorola (Freescale’s former parent) was so successful with the 68000 architecture in embedded computing boards.  The good people at Freescale connected me with Alexandra (Alex) Dopplinger who is a business development manager focused on getting Freescale designed into industrial applications.

Alex Dopplinger.png

Alex told me that Freescale had a great year in 2014 with their “proven” board partners supporting more than 20,000 end customers.  Here is a proof point of how the real world of product development takes place; Freescale creates a flexible and powerful ARM-based product like the i.MX 6 series of applications processors, and then innovative companies put it on boards with software and support for hundreds of vertical applications.  If you want to see the process in action then consider attending the annual Freescale Technology Forum where Freescale and their partner network collaborate on the next design cycle.  According to Alex, a major reason why Freescale embraced the ARM architecture was the number of developers who are familiar with the software. Freescale has other processor architectures in their single board computer portfolio based on their storied history going back to the aforementioned 68000 and later the PowerPC (now OpenPower) architecture.  Alex told me that the fastest growing markets for ARM-based products are industrial and healthcare and this may be due to the widespread adoption of open source software in these markets.   Freescale has embraced the open source movement and offers Linux, Android and their homegrown but open MQX RTOS.  Freescale has had great success over the last 2 years with the i.MX 6 series product line and that may be due in part to not just their own development tools (like CodeWarrior) but the number of third party tools and software available from Mentor, Green Hills Software, IAR and QNX for example.   Freescale has also worked closely with ARM tools like DS-5, Keil and mbed.  So let’s take a deeper look at the i.MX 6 series portfolio roadmap:

iMX6 roadmap.jpg

Newly announced (at Embedded World 2015) was the i.MX 6SoloX applications processor which paired an ARM® Cortex®-A9 core and a Cortex-M4 core which I believe is an important trend in processors that you should be aware of.  The concept of asymmetric multi-processing (AMP) means that different cores can perform different functions in a system based on processing needs.

 

An SoC that contains cores with different capabilities is not unlike the ARM big.LITTLE concept which combines different cores for high performance and low power depending on the needs of the system. What’s interesting is how architectures like the i.MX 6SoloX will appear in so many different applications and systems that leverage the smaller core to save battery life, reduce board size, increase system security, and increase reliability. Here is a video from Embedded World on the i.MX 6SoloX. Freescale has a long history in the Embedded Computing Board  (ECB) market and when you check out the Embedded Computing Board (ECB) Resource Guide (registration required) you will see that Freescale is being utilized in over half of all the boards and they continue to innovate. Have you used a Freescale-based board in a design recently?

ARM’s Fixed Virtual Platforms have become a key vehicle to enable software development for the most recent ARM processors and ARM System IP. ARM’s Fast Models for the processors have proven to fulfill the software developer’s needs in terms of execution performance, debug and trace capabilities.  Even after 10 years of working with ARM on virtual prototypes, it is still surprising to me that you can boot 64-bit Android Lollipop on a multi-cluster, multi-core platform in less than 10 minutes without giving up debug visibility. Where other processor simulation approaches are motivated from the user-level software simulation, ARM Fast Models execute native software down to the lowest firmware layers including all software relevant processor details such as exception levels, MMUs etc. The fidelity enables development of a complete ARM software stack long before development boards become available.

 

Of course, software bring up for an ARM SoC does not stop at the boundary of the processor. Moreover   tight time-to-market timelines mean that  SoC software development cannot wait anymore until the SoC has been taped out. Project timelines are not the only driving factor for early software development.  Late software availability causes high risks onto the overall project as SoC architecture flaws would be revealed far too late in order to correct them. Specifically, the SoC’s power management infrastructure such as the clock management units, system control processor (SCP) and the off-SoC power management IC (PMIC) are critical pieces which need significant software to be brought up and tested as early as possible. With ARM’s power state coordination interface, the software integration of the SoC power management today even goes beyond the OS, deep into the firmware. Furthermore, the increased complexity of the boot architecture with multiple boot loader stages and UEFI requires new firmware specific interface IP device drivers to be developed and tested. Thus, there is some work to be done before Android boots on a custom SoC which cannot wait until the hardware is ready.

 

Synopsys Virtualizer Development Kits (VDKs) are software development kits with a virtual prototype as target.  VDKs embrace ARM Fast Models and there are reference VDKs available that follow the ARM FVP’s “Base” platform specification, plus allow extension and customization of the platform towards a custom SoC.

pic1.pngFigure 1 – VDKs are extending the software development scope from the CPU to the full SoC

 

The reference VDKs are binary software compatible with the FVPs and as a result the same software stack such as ARM’s trusted firmware, UEFI and Linaro’s Linux kernel can be used with these VDKs. VDKs can be incrementally extended and enhanced using IEEE 1666 SystemC TLM-2.0 compliant IP models.


DesignWare Interface IP software bring up

A VDK is extensible through an extension interface oriented at ARM’s LogicTile Express interface. This ensures software compatibility with standard drivers for the LogicTile Express infrastructure. Transaction-level models (TLMs) representing Synopsys DesignWare Interface IP are available. Users can simply instantiate these inside a VDK:

  • USB: DesignWare USB (including the new USB3.1)
  • Flash: DesignWare Mobile Storage, DesignWare UFS
  • Ethernet: DesignWare Ethernet GMAC, DesignWare Ethernet XG-MAC,  DesignWare Ethernet QOS,
  • PCIe: DesignWare PCI Express and Intel 82599

Some of the above mentioned IP blocks are essential even for the early SoC boot phases such as the UFS or Mobile Storage flash controllers. Here, next to the main OS, drivers also need to be integrated with firmware such as UEFI.  The IP models provide virtual and real world IO capabilities. As an example the USB 3 model supports up to SuperSpeed real-world IO. In this case host or device mode drivers can be developed and tested along with the real device or host on the remote side of the USB cable. The VDKs can also be connected to physical (e.g. FPGA) prototypes. In context of those DesignWare Hybrid IP Prototyping Kits, DesignWare digital core is mapped onto a HAPS-DX FPGA along with a PHY daughterboard. Now the real RTL of the IP can be used for the final validation of drivers.


 

Figure 2 - USB in host mode, real-world IOFigure 3 - USB in device mode, virtual IO
pic2.png
pic3.png

 

 

Other IP is relevant to complete e.g. an ARM based micro-sever software stack. As an example, the PCie and NIC models implement the IO virtualization (SR-IOV) feature and can be used to develop low latency pass-through virtualization drivers . In the figure below, you can see a Linux-KVM based micro-sever software stack integrating DesignWare Ethernet GMAC being executed on a VDK.

 

debug_64bit_arm_v8_linux_and_kvm_using_ds5.pngFigure 4 - Complementing ARM's DS-5 with VP Explorer’s platform level HW/SW debugging

 

For software debugging, a VDK is integrated with major 3rd party debuggers for ARM processors, including ARM DS-5 and Lauterbach TRACE32. On top of that, the debug visibility is extended to the peripherals and their connectivity.  In the figure, the DesignWare Ethernet GMAC registers are exposed next to the details of the processor and software.

 

In order to jump start the DesignWare IP driver integration, an entire download and build framework for the ARM’s trusted firmware, UEFI, Linux kernel and filesystem is available with the VDK. This allows software developers to immediately edit and rebuild the Linux software stack without having to search numerous community web pages with complex readme, download and installation steps. Also, the device tree kernel configuration file is automatically generated and therefore any ARMv8 kernel can be exercised without going through manual porting steps.


If you want to find out more I would like to invite you to register at TechOnLine for a live or recorded webinar on this topic.

 

In my next post I will elaborate how ARM FastModel based VDKs are used for SoC power management software bring-up.

I received my STM32F411RE Nucleo board last weekend(Thanks to Carissa Labriola for selecting my idea). Overall board looks good and worth it's price with powerful STM32F411RE and on board ST Link debugger. The only drawback I noticed was missing USB OTG connector for STM32F411RE. This platform is mbed enabled and the on board ST Link debugger provides standard mbed interface such as drag-drop programming with virtual serial port connected to USART2 too.

 

To get started, download the ST Link drivers from here, and then download ST Link FW update software from here. First Install the drivers and then run the debugger FW update software "ST-LinkUpgrade.exe"  and click on "connect device", which will recognise any ST Link debugger connected to host system. This step also retrieves the current debugger FW version. Click on "Yes>>>>" which will initiated the update procedure.

 

After update the debugger FW, I used this board to achieve something meaningful. I connected Grove temperature sensor along with ultra low cost ESP8266 WiFi module to use as web-server to fetch realtime temperature. Below is my setup,

IMG_20150407_214617950.jpg

 

I used mbed framework which is easier for prototyping. Communication with ESP8266 WiFi module is using "AT" commands over UART lines. There are lot tutorials available on internet on how to update the ESP8266's FW. The connections are pretty simple. Grove temperature sensor is connected to "A0" of Nucleo board. ESP8266's Rx and Tx is connected to UART1 lines available on D2 and D8 of nucleo board. ESP8266's power lines are connected to 3.3v and GND. Rest of lines should be pulled high. Below is my mbed code which serves webpage on request,

 

#include "mbed.h"


#define BUFFER_SIZE 100


Serial esp(D8, D2);
Serial pc(USBTX, USBRX);
AnalogIn ain(A0);


uint8_t buffer[0x100];
uint16_t buffer_head;
uint16_t buffer_tail;
bool webreq = false;


void rxcallback(void) {
  uint8_t chr;
  static uint8_t state = 0; /* Invalid state */
  while (esp.readable()) {
       chr = esp.getc();
       pc.putc(chr);
       switch(chr) {
      /* look for GET token */
       case 'G':
            state = 1;
            break;
   
       case 'E':
            if (state == 1) {
            state = 2;
            }
            break;

       case 'T':
            if (state == 2) {
            state = 0;
            webreq = true;
            }
            break;
   
       default:
            break;
       }
       buffer[buffer_head++] = chr;
       if (buffer_head == BUFFER_SIZE) {
       buffer_head = 0;
       }
  }
}

void flush_fifo(void) {
  while (esp.readable()) {
  (void)esp.getc();
  }
  buffer_head = 0;
  buffer_tail = 0;
}


int find_response(const char *resp) {
  /* Give some delay for buffer to fill up */
  wait_ms(10);
  int timeout = 0xFFFFFF;
  int len = strlen(resp);
  do {
  if (buffer_head > (buffer_tail + len)) {
  if (!memcmp(&buffer[buffer_tail], resp, len)) {
  flush_fifo();
  return 0;
  }
  buffer_tail++;
  }
  }while(timeout--);
  flush_fifo();
  return 1;
}


float get_temperature(void) {
  int a;
  float temp;
  int B=3975; /* B value of the thermistor */
  float res;

  a=ain*1023;
  res=(float)(1023-a)*10000/a; /* fetch resistance of the sensor */
  temp=1/(log(res/10000)/B+1/298.15)-273.15; /* temperature conversion */
  return temp;
}


int main() {
  char webpage[] = "Temperatue: ";
  flush_fifo();
  esp.attach(&rxcallback, Serial::RxIrq);
  esp.printf("AT+RST\r\n"); /* reset module */
  MBED_ASSERT(find_response("OK") == 0);
  esp.printf("AT+CWMODE=2\r\n"); /* configure as access point */
  /* Error checking is not required */
  wait(2);
  flush_fifo();
  esp.printf("AT+CIFSR\r\n"); /* fetch ip address */
  MBED_ASSERT(find_response("OK") == 0);
  esp.printf("AT+CIPMUX=1\r\n"); /* configure for multiple connections */
  MBED_ASSERT(find_response("OK") == 0);
  esp.printf("AT+CIPSERVER=1,80\r\n");
  MBED_ASSERT(find_response("OK") == 0);
  pc.printf("\r\nESP8266 Initialization done!!!\r\n");
  webreq = false;
  while(1) {
  if (webreq == true) {
  find_response("OK");
  esp.printf("AT+CIPSEND=0,%d\r\n", sizeof(webpage) + 3);
  find_response(">");
  esp.printf("%s", webpage);
  esp.printf("%0.2f", get_temperature());
  find_response("OK");
  esp.printf("AT+CIPCLOSE=0\r\n");
  flush_fifo();
  webreq = false;
  }
  }
  return 0;
}



I am a strong advocate for not “reinventing the wheel”. Doing something from scratch, unless you really have a novel approach that will yield some improvement over what has been done before, is rarely sensible outside of an educational context.

But sometimes it can be useful to understand some of the underlying principles of something that you plan to utilize …

Networking is a specialist subject and I am not such a specialist. That is just one reason why I would advise any embedded developer to consider the purchase of an off the shelf networking stack, instead of an in-house implementation. Apart from the obvious productivity factors, compliance with standards is an enormous overhead; by definition, a networked device needs to talk with other devices and, hence, such compliance is necessary.

To read the rest of this entry, visit the Colin Walls blog via Mentor Embedded.

nucleus-networking.png

Markus Levy is well known in the Embedded world as President of the Embedded Microprocessor Benchmarking Consortium (EEMBC) but in his spare time runs the Multi-Core Association and the IoT Developers Conference and even finds time to be a volunteer firefighter.Markus.jpg  I asked Markus about benchmarking and his view of the rapid growth in ARM based Embedded Computing Boards coming to market.  Markus pointed out that many of the benchmarks you can get from EEMBC are applicable to the embedded board market. 

 

Here are the most relevant benchmarks that EEMBC offers:

 

Processor Benchmarks

 

AutoBench

  • Processor performance in automotive, industrial, and general-purpose applications.

 

CoreMark and CoreMark Pro

  • Simple, yet sophisticated test of the functionality of a processor core. Produces a single-number score allowing users to make quick comparisons between processors.

 

DenBench

  • Addresses digital entertainment products such as smartphones, MP3 players, digital cameras, TV set-top boxes, and in-car entertainment systems.

 

FPMark

  • Provides floating-point performance in graphics, audio, motor control, and other high-end processing tasks.

 

MultiBench

  • Analyzes multicore architectures, memory bottlenecks, OS scheduling support, and efficiency of synchronization.
  • Measures parallelization and scalability across both data processing and computationally intensive tasks.
  • Provides an analytical tool for optimizing programs for a specific processor.
  • Leverages EEMBC’s industry-standard, application-focused benchmarks in hundreds of workload combinations
  • Targets the evaluation and future development of scalable SMP architectures.

 

Networking

  • Approximates performance of processors tasked with moving packets in networking applications

 

OABench

  • Approximates office automation tasks performed by processors in printers, plotters, and other office automation systems that handle text and image processing tasks.

 

TeleBench

  • Telecommunications suite approximates performance of processors in modem, xDSL, and related fixed-telecom applications.

 

ULPBench

  • Ultra Low Power microcontroller efficiency test suite

eembc_logo_sm.png

All of the benchmarks are available here.

 

So as you can see there is a wealth of benchmarks you can choose from depending upon your application. Embedded computing boards (ECBs) in some ways need more attention than a single chip because as Markus points out the ECB will likely have multiple I/O functions and a memory subsystem that can dramatically affect overall performance.  Markus specifically pointed to the brand new CoreMark Pro benchmark which is now publicly available and can measure high capacity memory performance. Android is becoming a real option for industrial markets with the performance gains of ECBs and EEMBC has ANDEbench Pro for benchmarking Android systems,  it’s a free download on the Android Play store.  Anyone can use the benchmarks but if you want to promote a board based on these benchmarks you need to join EEMBC and get a license but that to me is a smart move in the rapidly growing ECB market.

 

For designers who have the classic engineering tradeoffs of performance, price, energy and form factor they need a way to find the right board for their application and looking at benchmarks is a good place to start.  You can find the ARM guide to ECBs here: Embedded Computing Board (ECB) Resource Guide.  What's your experience with board level benchmarks?

Happy Monday again folks! These seem to come around so much faster than I originally thought they would. Time flies, I guess! So I've had a few weeks of microcontrollers so it's about time that I mix it up and appease the SBC folks out there, don't you think? To your great fortune, Hardkernel was very generous and sent me their latest development board, the Odroid-C1! This was specifically mentioned as a requested board on the survey so I am happy to be able to come through on that request =). After my experience with the Odroid-XU3 right around the time this board actually came out, I was excited to get to test it. I had to be patient though because we decided to wait for this review so they could finish the new Ubuntu OS image with the ARM Mali GPU accelerated Web-browser integration (I'll let you know more about that experience later in the review). If you are wondering, the (1) winner this week will be supplied with an 8 GB SD card with the Ubuntu image pre-installed, a PSU, an HDMI cable, and a protective case in addition to the Odroid-C1 itself.

 

The real question now is how do YOU get your hands on this board?* Comment below (here in the Connected Community) with WHAT YOU WOULD MAKE with this board for a chance to win! Please submit your comment by 11:59 PM on April 16, 2015 in order to be considered. The winner will be announced by noon on Friday, April 17, 2015.

 

odroid-c1.PNG

[Image courtesy of hardkernel.com]

 

Hardware

From a design aspect I have needed to take the physical size of the board into account, what voltage supply/ battery pack to purchase, the number of break out pins available for sensors, price and available documentation. These aspects have therefore been taken down in case they are important to anyone else’s design.

  • Physical layout (width x length)
    • 56mm x 85mm
  • CPU specs: Performance, Memory, Power
    • Amlogic ARM® Cortex®-A5 (ARMv7) 1.5Ghz quad core CPUs

    • Input voltage: 5V @ 2A
    • Operating voltage: 5V
    • Flash memory: Micro-SD or eMMC storage options
    • RAM: 1GByte DDR3 32bit RAM (512MByte x 2pcs)
    • Clock speed: 1.5GHz
  • GPU: Mali™-450 MP2 GPU (OpenGL ES 2.0/1.1 enabled for Linux and Android)
  • I/O specs:
    • 4x USB Ports
    • 1x Micro Usb OTG Port
    • 1x Micro HDMI Port
    • 1x Gigabit Ethernet over RJ45
    • 1x IR Receiver
    • 2x I2C Ports
    • 1x Serial Port
    • 19x GPIO Pins
    • 2x ADC Inputs
    • 1x 1.8V Analog reference
    • 1x 3.3 Vout
    • 2x 5V Outputs
    • 1x SPI Output
    • 1x RTC with available battery backup.

40 pin odroid.PNG

[Image courtesy of hardkernel.com]


Software

The benchmarking for software was determined by the environments, native languages, time to get started and the like

 

Projects & Community

Whenever you take on a new project it is always nice to see what other people have done. Therefore the last section is dedicated to the resources already available.


Opinion time:

What I appreciate about the Odroid-C1

odroid_test.jpg

Test of GPU acceleration


After the update to the latest kernel to take full advantage of the latest GPU acceleration, I tried out the test page and it did pretty well. It had a small glitch in the rendering (I don't know the cause, sorry), but other than that it performed very well. For curiosity sake I played a youtube video before the update and then after and there was a very clear improvement in the video processing with the update. If you currently have the Odroid-C1 or are planning on getting it I would recommend taking a look into it.


It's a very inexpensive board and easy to boot up and get going. I could definitely see this as a Linux computer for everyday work or a project that needs computer vision. I am impressed by the power in the small package and I like how the design makes it easy for interfacing both connections and peripherals. It was fun to test and if facilities lets me keep the extra monitor for a few more days I'll play with it more to see what else it can do!

 

*Please be aware that if there is an export restriction you may not be eligible to receive the board. Please PM if you have any questions or concerns.


Warning on biases: I am a senior Computer Engineering student with a background in embedded systems. I have worked with a variety of ARM-based boards for projects over the years. I acknowledge that I have my own set of preferences based off of what has worked well in the past but I have tried to be as impartial as possible since not everyone has the same project goals.I am an intern at ARM but these opinions are my own. If you have had a different experience I welcome your feedback!

As we started to research ARM based Embedded Computing Board (ECB) manufacturers for our Embedded Computing Board (ECB) Resource Guide Dave Tokic of Xilinx told us that there are now 25 companies making ECBs based on the Xilinx Zynq-7000 SoC.  Dave Tokic.jpg


If you haven't come across Zynq before it’s a very interesting part, it take a dual core ARM Cortex-A9 processor combined with a Xilinx FPGA.  For any designer it’s a very flexible and powerful platform that bridges best in class processing with ARM and a programmable fabric that can be optimized for their application.

Zynq block diag.jpg

I asked Dave about the evolution of Zynq and he told me that Xilinx has been incredibly successful in FPGAs but wanted to enter the broader embedded market which is comfortable with the ARM architecture.  Xilinx chose to work with ARM because of the robust ecosystem, low power and a compelling roadmap into the future.  For Xilinx the fact that by joining the ARM ecosystem they could take advantage of all the IP, software, services and tools offered by 3rd parties meant they could help customers get to market faster.  Being very frank, Dave told me they thought the Zynq would be a no-brainer device for system on module (SOM) and Embedded Computing Board companies but even they were surprised at the speed with which it has been adopted.  Avnet was first to market with their Zedboard about 2 years ago when the silicon went into full production and I can personally attest to the vibrancy and growth of the Zedboard community.

 

All the research I have seen over the years about FPGAs showed they were intriguing to designers but intimidating to many because the perception was they needed special skills in HDL (hardware description language), unfamiliar software and the parts were expensive and used too much power.  Old perceptions die hard but with Zynq, designers can enter the world of FPGAs using their ARM experience and easy to learn tools from Xilinx.  Zynq was designed with a “processor first” approach, so designers can bring up the ARM side of the Zynq first and then program the FPGA directly or through a companion EPROM.  Dave told me that Xilinx knew they would have to invest in tools to help software designers further simplify the design process on Zynq and Zynq-based modules.  The recent announcement of the SDSoC development environment provides a greatly simplified ASSP-like C/C++ programming experience for the software design community and enables module providers  to simplify and accelerate their customers design process.

 

Dave pointed to several SOM vendors that have taken the capabilities of the Zynq and created amazing products:

 

National Instruments is an iconic test and instrumentation company (if you ever get a chance to go to their NI week, don't miss it) and are famous for cutting edge data acquisition and measurement hardware with their visual programming software called Labview.  In many types of science and engineering NI is the gold standard and now by using a Zynq based SOM (pictured below) the complex processing and algorithms needed can happen in a single system.

Zynq SOM.jpg

Another clever use of Zynq in a SOM comes from Holland via  Topic Embedded Systems who have built a compact SOM called Miami complete with software aimed at the medical/clinical design market:

Topic medical.jpg

Xilinx are not resting on their laurels in this market and just announced a new hardware platform called Ultrascale MPSoC which takes the Zynq concept and moves up the ARM processor roadmap:

mpSoC.jpg

As you can see in the block diagram above MPSoC not only has dual core ARM Cortex-A53 processors but dual Cortex-R5 real time processors and an ARM Mali GPU.  This means that customers of Xilinx’s board partners who expect real time processing, video, multiple data flows, streaming data and touch interfaces can get it all on a single SOM.

So as you can see by combining the best of the ARM portfolio with leading edge FPGAs designers of systems and boards have capabilities that were unheard of in a single device. How would you use Zynq or MPSoC?

As David Blaza wrote in his blog, single board computers have been around for a while. In addition to the traditional use cases such as digital signage, factory automation and video conferencing, these platforms are increasingly the first way that emerging applications are addressed with technology. Today, areas like robotics, drones and a range of embedded vision systems are embedding these platforms as the fundamental compute building block....and, yes, even that (overused) phrase of IoT is relevant. These types of platforms fit into various forms of Industrial and Enterprise gateways that developers can deploy quickly with the goal of creating the next set of amazing applications to improve cost efficiencies and/or support new revenue-generating services.

 

For me, the big story from Embedded World 2015 was the rise of ARM technology in this area of embedded applications; a fact not lost on Embedded Weekly. In addition to the strong ARM partners supplying technology into the embedded market for a number of years such as Freescale and Texas Instruments, new entrants like Qualcomm have joined the fray. Qualcomm has partnered with Arrow Devices to enable a broad set of companies to gain access to very high performance, small form factor boards. As my ARM colleagues walked the show we found boards based on ARM technology from Amlogic, Rockchip, nvidia and other ARM partners. The support of Windows running on Raspberry PI is also set to light up a wide range of additional embedded applications previously closed off to ARM technology.

 

This is a fast moving space. So far we have managed to identify in excess of one hundred different ARM based boards. Based on this ramp of interest, ARM decided to create an area of the connected community focused on embedded computing. The intent here is to be the "go to" place to assist system architects, developers and procurement managers to idenfity the ARM bsed platform(s) that best address your requirements and to act as forum for getting your first pass questions addressed. One thing I guarantee is that we are missing many products. Our commitment is to keep this portal as up to date as possible with useful (as deemed by you!) information.So we welcome your commentary and feedback about

- Which products you are aware of you feel we should added to this guide

- What types of applications you are looking to deploy such hardware

- What additional commentary/material ARM should be putting onto this portal to make it as useful to you as possible

 

Provide that feedback loud and clear to us. We are listening!

 

Ian

As we launch the ARM Embedded Computing Board (ECB) Resource Guide I spoke to Toby Colquhoun of IHS about the market he covers and learned some interesting things about what I thought was a stable and sleepy market.  My first question was simply how does he define the market?  As it turns out defining this market isn’t easy because it’s so diverse but in its simplest terms Toby sees it  as a merchant market of boards and modules that are open and off the shelf. One key factor in the ECB market is that the end customers tend to face the classic build vs. buy decision and due to the relatively low volume of systems being built (using less than 10k boards per year) they decide to save on development costs and buy off the shelf boards for integration into their products.

Toby Colquhoun.jpg


The ECB market also tends to be standards driven with around 33 form factors in use and some having been around many years such as VME for Mil/Aero and ATCA for telecommunications, but new ones appear regularly such as the new VNX standard from VITA (see VITA article here).  Some module form factors can be used in multiple markets so this can lead to double counting of data but all in, Toby sees the total market size as $5billion to $6billion in 2014.  Interestingly the 60-40 rule comes into play with 60% of the market being held by the top 5 board vendors and Toby estimates there are roughly 70 to 80 major companies involved in total but new entrants coming in all the time.


As we all know in technology even a market which has been as traditionally stable as this one can go through dramatic changes and Toby sees a lot happening right now. The most dynamic market segment is COM modules (mainly ARM based) with a current annual run rate of $700-800m but will double to $1.5b in 5 years.


Even more interesting is that Toby estimates the ARM based share of the total ECB market at about 20% (in $ terms) today but is growing at twice the rate of the x86 architecture and is set to exceed x86 in volume terms in 2015.  This is a classic tipping point and it’s clearly at work in segments of the market such as digital signage and retail where change happens quickly and this is where ARM based modules are coming in to play.  At the other end of the spectrum, the Mil/Aero market is slow to change because of long design and deployment cycles but Toby is seeing ARM based boards using the VPX standard coming to market in the last year with Curtiss Wright being an early entrant.

VPX3-1701-3U-ARM-SBC (1).jpg

Pictured above:  Curtiss Wright VPX3-1701 3U VPX ARM Cortex A7 SBC


I asked Toby if he saw IoT as the driver of change in the SBC market but he thinks it’s difficult to separate out IoT because new ECB based systems (like HMI or PLC nodes) were getting internet connected anyway.  One interesting fact I heard from Toby for the first time was the German concept of Industry 4.0 (Industrie 4.0) which was new to me. Industry 4.0 literally means the 4th industrial revolution, the first being manufacturing using mechanization,  the second was mass production, the third was the digital revolution and now the fourth will be the computerization of machinery and automation using robotics. It has a more defined ring to it than IoT which is everything and nothing at the same time so I will dig into Industry 4.0 in more detail in another blog.


In the Embedded market it’s always a mistake to focus solely on hardware so I asked Toby what were the key technical challenges for software developers?  As expected, change is always hard and with a large code base in x86 systems there is a barrier to switching to ARM based ECBs but in segments that are cost sensitive or so new there is no installed code base then ARM based systems will be utilized at a far faster rate.  Toby latest report on the Global ECB market can be purchased here.

So I think there are 2 key takeaways from my chat with Toby, first is the shift in ECBs to the ARM architecture (in volume) that will only accelerate due not just to the rise of the IoT but Industry 4.0.  What is your take?

Filter Blog

By date:
By tag: