Skip navigation

Blog

1 2 3 Previous Next

Embedded

689 posts

You need a customized ARM based Computer?

Cortex-A9 or Cortex-A7? Or Maybe even a combination of Cortex-A7 and Cortex-M4?

You checked the Market but the solution you want is not there? Or you need your customized solution anyway?

 

No problem, there are easy ways to achieve this. Large companies when they intend to produce huge quantities (there are different Numbers available some talk about 50k/year, some talk about 100k/year) take some of

There are different ways to achieve this.

If you go for volume (lets say bigger than 50k/year) it makes sense to make a complete customized design). If you stay below  a good choice is to go for a SOM (System on Module), which is a standard off-the-shelf computer Module and a customized Carrier board. All you need is to do this Carrier board. No problem you put all your Engineers at work and they will deliver something soon after a few weeks.

What do you do if you don't have the Engineers but you know what you do?

You could hire some one to do it for you.

 

Or you use a Web based Drag and Drop System to create your board by yourself.

Gumestick integrated TechNexion tiny (36mm x 40mm) PICO Modules into their Geppetto (https://geppetto.gumstix.com) web based Custom Carrier boards.

You can check the tool and make your design here:

https://www.gumstix.com/blog/product-releases/technexion-pico-launches-geppetto-custom-design/

 

It's pretty cool as it shows you directly how much everything cost and you can arrange all the IO's you need,a s you need and only the one you need.

It also gives you a cool 3D preview.

Geppetto_ui_PICO.png

 

There is also a sample made already which you can purchase directly for verifying or just play inside the Geppetto and see how it feels/work.

 

I personally think this can be a great tool for many Companies who have great ideas but lack the Engineer force needed to bring them alive, but also for small projects to use.

Yes, it still cost money to do so, but you get an direct overview on how much and then can decide if yo push forward or not.

 

Thanks to the Geppetto Platform and TechNexion rich Software offering, including Linux, Yocto, Android, all up-to-date and available both as Demo and as Source Code it is now even more simpler to create the customized product for especially your needs!

Cool thing is also that due the PICO Modules are a Family which will keep upgrading you can start with a NXP i.MX6 on it, then later upgrade it to the NXP i.MX7 and more later even to the next family of NXP compatible devices.

 

 

I would love to hear successful use cases where the Geppetto was used to implement a project, please feel free to share here in the comments.

 

Internet of Things ARM Development Platforms

SOMNIUM DRT is is a set of development tools for ARM Cortex-M based devices such as the STM32 devices from STMicroelectronics. It is fully compatible with industry-standard tools such as the GNU toolchain and Eclipse IDE. DRT uses our patented techniques to produce highly optimized code by exploiting information about the embedded processor and the memory system to deliver improved performance, lower code size and reduced energy use.

There are three main routes for creating an STM32 project in DRT.

1. You can use the New Project Wizard in DRT to quickly create a project targeted at the STM32 device you are using. This will not immediately give you access to all the STM32Cube software enablement.

2. You can use the STM32CubeFx package for the board or device you are using. This includes a number of example projects that can get you started with specific peripherals and middleware. It also includes a blank "template" project to get you started.

3. You can use the STM32CubeMX program to create a new project for your target, including all the necessary libraries, drivers, middleware and initialization code.

This articles will discuss those last two options in a bit more detail. We also have a couple of videos that will talk you through the process.

 

Using STM32Cube

STM32Cube is a set of tools and software from STMicroelectronics to make it easier to develop applications for STM32 microcontrollers. It consists of firmware and software package for specific device families. These include the hardware abstraction layer (HAL), drivers, middleware, examples, and so on. There is also a tool called STM32CubeMX which provides a graphical interface to create and configure a project then generate the appropriate initialization code.

There is an STM32Cube software package for each class of devices, for example STM32CubeF0, STM32CubeF4 and so on. You can download the software for your target from the STMicroelectronics website. This is a zip file containing the libraries, drivers, middleware, documentation and examples.

Under the Projects directory there are examples for several boards. These are organized as follows:

 

  • The Example programs only use the hardware abstraction layer (HAL) and board support package (BSP) libraries.
  • The Application demos show how to use the available middleware. They are organized either by middleware or by product feature.
  • The Demonstrations directory contains programs that use the maximum number of peripherals and middleware stacks to demonstrate the product features.
  • Then there is a Template directory, which contains an "empty" program with the essential infrastructure to get started with your target hardware.

 

All of these examples are available for several different developments systems. You can easily import any of these examples into DRT by selecting the Atollic TrueSTUDIO project. DRT will import that and convert it into a DRT project. You can then build it, run it one the target hardware, and use it as the basis for your own application.

This video will explain the whole process in more detail. It shows how to import one of the standard STM32Cube examples.

Using SOMNIUM DRT with a STM32 device - YouTube

 

Creating a project with STM32CubeMX

STM32CubeMX is a program that runs on your PC to generate projects for STM32 systems. You can select the target for the project by choosing a specific microcontroller or a development board. This creates an initial configuration for the project. You can use the GUI to set up the pinouts, select middleware components, configure the clocks and other settings. For example, you can configure the GPIO pins to drive an LED.

When you click the "generate code" button, a project will be created in the workspace you specify. You should choose the Atollic project format as this can be automatically imported into DRT. After importing the project into DRT, you can add your own code, build and run the project on the target hardware.

This video will explain the whole process in more detail. It uses STM32CubeMX to create a program that flashes the LED on the board.

Using SOMNIUM DRT and STM32CubeMX - YouTube

 

 

Summary

DRT provides industry-leading optimization, resulting in smaller and faster code which uses less energy. It supports the latest C and C++ standards, including C++ exceptions and is extensively tested by several test and validation suites. Comparing the "out of the box" (that is, with no attempt to apply any toolchain-specific optimizations) figures for one of the standard STM32Cube demo programs we can see that DRT significantly reduces the memory requirements.

.text.data.bssROMRAM
DRT 3.3 31,36821218,91630.818.7
SW4STM3238,78422418,92338.118.7
Atollic50,3321,44818,96850.619.9

 

When built using DRT, the program uses significantly less ROM space. This could mean that you can use a lower cost device, or you can add more functions to your system. For more information on benchmarking and results, see the white paper on our website.

In addition, DRT has some advanced debugging tools which can speed your development process. This includes live view of expressions while the program is running, trace and fault diagnosis.

A free trial of DRT is available from the SOMNIUM Portal.

DRT provides automatic import of projects from other Eclipse-based development environments, making it simple to evaluate. Download your free trial today from the SOMNIUM Portal and try it for yourself.

Yesterday we ran our live webinar covering our ARM® TrustZone® CryptoCell technology. We covered how attacks on devices are becoming more sophisticated and the impact this has on your security solution. We also gave viewers an introduction to platform security and the benefits of hardware-based security. We learnt how security delivers improvements on power and performance, whilst offering new use cases and business models. Thanks to everyone who joined us for the webinar, we had a great attendance and some insightful questions.

 

If you missed the webinar the good news is that you can still catch up, just click the link below. Keep reading to catch up on some of the questions you may have missed…

Webinar Button.png

If you are interested in other security related webinars, check out:

Meet the Experts: ARM TrustZone - understanding system security -webinar

How to Build Trust and Security into your Embedded Device -webinar series

 

 

What use cases do you see for security in IoT?

Security Graphic-01-NoText.jpg

We see that use cases are split into two categories:

  • The first is “horizontal” security services that are applicable everywhere and are application agnostic. These are aimed at protecting brand-name and protecting the R&D investment from different stakeholders.
  • The second use case refers to specific security needs. This could be the protocols of aß certain home automation ecosystem that prescribes specific crypto constructs and specific assets to protect, or a payment scheme requiring certain processing over a datagram.

 

Can you use CryptoCell without TrustZone?

Yes, CryptoCell can be used with any execution environment capable of running code (for example a processor dedicated for security tasks or even the main application processor). The decision of where to execute the CryptoCell code from (i.e. security related SW) should take into consideration both PPA and threat model considerations.

 

We believe the combination of CryptoCell with TrustZone® isolation technology (for both Cortex®-A and Cortex-M CPUs) provides an excellent “operation point”, addressing many use cases.

 

If I implement CryptoCell does this mean I won’t get hacked?

Unfortunately, such guarantees cannot be made. At the end of the day, the robustness depends on the threat model that is addressed (and mainly – what is not addressed within the assumptions constructing the threat model) and how well designed, tested and reviewed the system is. As there is lots of code going into today’s devices, it is almost impossible to assure there are no flaws through which hackers can gain privileges they were not supposed to get. However, within the applicable threat model (i.e. a reasonable set of assumptions on the attackers funding and expertise), CryptoCell can assure the security of critical assets and operations.

 

Real randomness plays a big part in security. How do you address that?

The ability to provide an unpredictable stream of bits or numbers, is important for multiple security needs. This includes generation of keys or assuring that stale messages are not being replayed over a communication channel. Nowadays there are different sources of entropy and different ways to extract entropy from a given source. In the CryptoCell case the TRNG is completely digital and made out of standard library cells. When it comes to entropy, some standards require “the statistical behaviour of the digitized noise signal to be inconspicuous". Others omit this requirement for perfect statistical properties of the generated data and emphasize the entropy contained in that data and how to extract it. CryptoCell offers support for different standards and drafts like the NIST800-90B draft and the German AIS-31 standard.

 

The IoT ecosystem is quite fragmented, and in many cases there are no relationships between the suppliers (chip vendor and a module maker or a device maker). How can trust be established in such cases?

This is a very fragmented ecosystem and different organizations are involved in the creation of a device and a service, these organizations often don’t even know each other, let alone trust each other. However, they still own execution environments and assets on the final device. Naturally these organizations want to protect their assets, against the other parties involved in forming the device. ARM allows secure multiple ownership of assets in CryptoCell, by having multiple sets of roots of trust, owned by different entities. Let’s take debug as an example - the scheme we support allows separation of debug and access rights, where one entity cannot grant debug rights related to domains and assets belonging to another entity. In this example, an OEM can own the execution space where market applications execute and a chip vendor can own the execution environment running the communication stacks.

 

Can I use CryptoCell-3xx for larger designs as well?

Tes, larger SoCs tend to have “control plane” security needs as well (for example - not only data intensive use cases) and CryptoCell-3xx can be used in that context. As both families of CryptoCell - the 300 aimed at efficiency and the 700 aimed at performance – offer the same set of services, they are interchangeable, based on the desired performance grade.

 

Can only Cortex-M cores be used for IoT and Cortex-A cores be used for client and server systems?

Although this does seem a fit for the different profiles, there is enough variance in the Cortex-A families and Cortex-M families to ensure there is overlap. A good example of this is the Cortex-M7 processor, which has a cache and a good PPA. This processor may have the required performance for some wearable devices, equally as much as the lower end Cortex-A processors such as the Cortex-A5 or Cortex-A32 processors.

 

You mention the RTOS available in the IoT space as the mbed OS and uVisor, are there any examples of TEE for the Cortex-A processors?

Yes, there are a number of Trusted OS’es available for Cortex-A processors, there are open source developments such as the Linaro OP TEE (Open source TEE), as well as commercial TEEs such as the TEEs from Trustonic and Sierrawear. The development of TrustZone systems is bringing a lot of TEE’s from many vendors.

Picture1.pngA lot can be learned from studying the evolution of mobile security and considering which aspects can be applied to lower cost IoT platforms.  Now that ARM TrustZone for v8-M is becoming available on microcontrollers and the trend to build in security subsystems gathers pace, it is possible to consider an IoT security architecture that has a lot of similarities to modern smartphones.

 

Keeping mobile devices updated and agile to evolving threats is a given today.  For a large part of the IoT market having secure firmware updates pushed Over The Air will be part of their security requirements.  This will in turn require a range of secure services including identity, authentication, attestation, crypto and secure communications.  Security subsystems such as CryptoCell can help by providing Root of Trust management, crypto acceleration and a ‘toolbox’ of dependable security functions.  Above the lower level security layers, a trust architecture will need to be established for the distribution of keys and certificates.

 

Slide35.png

Transport Layer Security (TLS aka SSL) is the de-facto standard for communication security between devices, browsers and remote servers. The protocol provides protection from eavesdropping and tampering using symmetric crypto following a TLS handshake. The availability of high quality, open source and commercial TLS libraries has driven its growth in embedded products.  If a security subsystem is added to a microcontroller that can accelerate crypto operations, TLS becomes a practical proposition at very low cost points.

 

Most mobile devices and application processors incorporate a TrustZone based Trusted Execution Environment, where TEE APIs, services and certification is standardized by Global Platform.  The TEE enables Trusted Apps to be downloaded and run in isolation from the Rich OS benefitting from its security properties of integrity and isolation. A full TEE and management framework is probably too highly featured for an IoT product, particularly if it does not need to run downloaded Trusted Apps.  However there is a need to provide protected regions for assets, that can be kept confidential from the rest of the code and also benefit from integrity that is rooted in hardware.  For this purpose ARM is creating ARM mbed uVisor for TrustZone enabled ARMv8-M platforms. The mbed uVisor’s purpose is to create isolated security domains. This solves the problem of flat address space and little privilege separation that has previously made security on microcontrollers challenging to implement. You don’t have to wait for the v8-M based mbed uVisor as it has also been written to work with non TrustZone enabled micros, so it can be immediately adopted across existing as well as next generation product lines.  You can get started with mbed OS and uVisor here.

 

ARM aims to provide its partners with the security hardware and low-level software building blocks necessary to implement a system-wide security solution.  The availability of security sub-systems such as ARM TrustZone CryptoCell, TrustZone based uVisor and TLS on next generation microcontrollers will enable an architecture familiar to mobile chip designers but right sized to these lower cost and performance points.

 

 

 

You can also watch some of our previous webinars:

How to protect your systems with ARM TrustZone CryptoCell

Meet the Experts: ARM TrustZone - understanding system security

How to Build Trust and Security into your Embedded Device

In this March, Forlinx launched a brand new item which is based on Freescale i.MX6UltraLite processor and with low price and excellent Linux performance. It belongs to Cortex-A7 family with main frequency only 528MHz. It is a complete ready-to-use single board computer with all 200 CPU pins mostly drawn out and its SoM even smaller than Freescale original SoM. Now let's have a look at its details.

i.MX6UL CPU Module Features

CPU

NXP i.MX6UL

CAN

2-ch

Architecture

Cortex-A7

USB   DEVICE

2-ch

Main Frequency

528MHz

SD/MMC/SDIO

2-ch

RAM

512MB LvDDR3

Ethernet

2-ch, 10/100M Ethernet

ROM

4GB eMMC

UART/IrDA

8-ch

Working Voltage

5V

EINT/GPIO

Supported

GPU

PXP

Video   Coder

Software codec

Dimentions

50mm*40mm

EBI BUS

Supported

Connection Type

Board-to-board pin connectors

JTAG

Supported

OS

Linux   3.14.38

CAMERA

1-ch, 5.0M Megapixel  parallel interface

LCD

RGB 24-bit

PWM

8-ch

AUDIO

3-ch

ADC

10-ch

I2C

4-ch

ISO7816-3

2-ch

SPI

4-ch

Keypad Port

8*8

QSPI

1-ch

SPDIF

1-ch

 

i.MX6UL Carrier Board Features

AUDIO

1x Phone,1x MIC, 2x Speaker

JTAG

Supported

I2C

2-ch, pinned out

ADC

4-ch for resistive touching

SPI

Supported

DIP

8

CAN

2-ch

Reset

1

CAMERA

1-ch, 5MP parallel interface camera, OV5640

PWM

1-ch for LCD backlight

SD/MMC/SDIO

1

LCD

1-ch for 7'' resistive LCD

USB Host

3x USB2.0 Host

EINT

Supported

USB Device

1x USB micro 2.0 device

GPIO

Supported

Ethernet

2x 10/100M Ethernet, RJ45

EBI BUS

Supported

Serial Port

3-ch, pinned out

WiFi&BT

1

Power adapter

5V

GPS

Serial port GPS module

LED

4x LED

3G

USB 3G module

RTC

Supported

 

 

Linux console

Cross-compiler

arm-fsl-linux-gnueabi-gcc-4.6.2

OS Image Flashing

Flash image via SD card, USB OTG

SD card/OTG brush

Single file/mutilple files flashed via SD card

EXT4 system file flashing

UBOOT

Booting selection (eMMC)

RAM: 512M

UBOOT boot LOGO(provided soon)

Linux Kernel

Version: Linux-3.14.38

File system EXT4/NFS/FAT32/NTFS, etc.

eMMC driver

Watchdog driver

RTC driver

IO driver

SPI driver

Camera OV5640 driver

PWM driver

LCD backlight driver, 255-rating

LCD driver(standard definition: 7'')

Linux kernel USB Host driver: U-disk, USB Hub, USB keyboard, etc. are all supported

USB Device driver

TF/SD/MMC card driver: up to 32GB

Serial port driver

Audio driver: video recording and playing are both supported, ALSA interface, D amplifier

Ethernet(RJ45, 100/10Mbps)

3G driver

USB to serial port driver

Utility APP

WiFi configuration tool

Source code provided by sourcing orginasition

Telnet

Provided with source code

RTC testing

Provided with source code

Flexcan

Provided with source code

IP/MAC address modifying

Provided with source code

sqllite

Source code provided by sourcing orginasition

TTL to RS232

Provided with source code

Audio recording/playing testing(ALSA interface)

Provided with source code

GPRS network

Provided with source code

3G network

Source code provided by sourcing orginasition

USB camera testing

Source code provided by sourcing orginasition

Speaker testing

Provided with source code

RGB LCD backlight testing

Provided with source code

Video displaying and mp4 file testing

Provided with source code

Watchdog

Provided with source code

MMC/TF/SD card and U-disk mounting and uninstalling

Provided with source code

FTP network tool

Provided with source code

Boa 的Web Server

Source code provided by sourcing orginasition

 

 

Linux qt4.8.5

Cross-compiler

arm-fsl-linux-gnueabi-gcc-4.6.2

ARMv7 instruction set, hard FPU supported

  OS Image Flashing

Flash image via SD card, USB OTG

SD卡/OTG machine brushing

Single file/multi-file flashing via SD card

EXT4 system file flashing

UBOOT

Booting selection (eMMC)

RAM: 512M

UBOOT LOGO(provided soon)

Linux Kernel

Version: Linux-3.14.38

EXT4/NFS/FAT32/NTFS, etc. file systems are all supported

eMMC(8G) driver

Watchdog driver

RTC driver

IO driver

SPI driver

Camera OV5640 driver

PWM driver

LCD backlight driver, 255-rating adjustable

LCD driver(standard definition:7")

Linux kernel USB Host driver: supporting U-disk, USB Hub, USB keyboard, etc.

USB Device driver

TF/SD/MMC card driver: up to 32GB

Serial port driver

WM8960 audio driver: recording and playing

Ethernet(RJ45,100/10Mbps)

3G driver

USB to serial port driver

Utility APP

WIFI configuration tool

Source code provided by sourcing rginasition

Telnet

Provided with source code

RTC testing

Provided with source code

Flexcan

Provided with source code

IP/Mac address modifying

Provided with source code

Sqllite

Source code provided by sourcing rginasition

TTL to RS232

Provided with source code

Video recording/playing testing(ALSA interface)

Provided with source code

GPRS network

Provided with source code

3G network

Source code provided by sourcing rginasition

USB camera testing

Source code provided by sourcing rginasition

Speaker testing

Provided with source code

RGB LCD backlight testing

Provided with source code

Video displaying and mp4 file testing

Provided with source code

Watchdog

Provided with source code

MMC/TF/SD card and U-disk auto mounting and uninstalling

Provided with source code

FTP network tool

Provided with source code

Boa Web Server

Source code provided by sourcing rginasition

 

 

 

Breaking News

From Sep.15, 2016 to Sep.30, 2016, Forlinx will do a big promotion to this item. During promotion, price details are as below

Single board computer i.MX6UL: $50/pc (with WIFI&BT module, limit one pc per purchasing)

Single board computer i.MX6UL with 4.3’’ resistive LCD: $60/pc (with WIFI&BT module, limit one pc per purchasing)

SoM/CPU module i.MX6UL: $35/pc  (limit ten pc per purchasing)

 

For further product information, pls just feel free to contact the sales.

5 Steps For Makers Targeting Rapid High Volume Production

 

1. Log on to Geppetto® Design-To-Order Free Online Development Tool

 

2. Choose from over 30 pre-designed expansion boards for 96Boards, Intel, Colibri, Rasberry Pi, MitySom, BeagleBone and more to jumpstart your design or start your design from scratch in the Geppetto Workspace

 

3. Utilize the simple drag and drop interface to create and save your design in Geppetto

 

4. Click to order a market-ready device. The Geppetto automated online manufacturing cycle completes the PCB routing, fabrication, sourcing, component purchasing, assembly and board bring up which drastically reduces cost and time of production.

 

5. Production ready board is tested and shipped to you in 15 business days

 

Learn More and Watch a 96Board Demo Here

Making the AeroCore 2 for 96Boards in Geppetto D2O

The latest Bluetooth® low energy (Bluetooth 5) standard introduced an increased data rate of 2Mbps as demonstrated with the ARM® Cordio® IP in Prithi Ramakrishnan’s  blog ‘Bluetooth 5: faster, farther, stronger – And still low power!’. This data rate could allow enhanced quality audio experiences to be delivered with the same ultra low- power envelope that Bluetooth low energy introduced.

 

The past week’s debates around whether Apple were removing the headphone jack in their latest product have now been put to rest. While many had expressed concern, there is plenty of recent precedent for similar industry disruption.

 

In 2012 Apple introduced the lightning connector ending almost a decade of the 30-pin connector, and an entire line of audio accessories became obsolete over the coming year. Jawbone captured this moment and rode the market disruption to deliver consumers a new product and experience in audio, the Jambox.

 

 

The demise of the headphone jack could herald similar opportunities for the industry. In the short term it is clear that user adoption of wireless headphones will rise. A range of existing Bluetooth products are ready to serve this initial demand, but just as the Jambox fired the starting gun on innovation in wireless speaker design we can expect similar innovations in wireless headphones.

 

The announcement, described as courageous, may kick-start the industry to deliver smaller in ear wearables that give us the ability to have truly wireless audio. In a few years we are less likely to be talking about the form of the product, and more likely to be looking at the functionality. As the recently announced collaboration between Bragi and IBM shows, the future of the earbud is likely to be about new user experiences. Similar to the film Her, the in-ear personal assistant may be the next development that began with the removal of a decades old physical connector.

 

So what might we expect?

Truly wireless earbuds are likely to hit the mainstream. Following innovations by Bragi with the Dash, wireless stereo earbuds are becoming more popular with consumers while long standing brands such as Samsung and Jabra have introduced their own take on the format.

 

Taking it to the next level

As with most battery powered accessories, we should expect to see smaller, energy-efficient form factors appear on the hearing aid and headphone markets in the future.  The Bluetooth 5 enhancements could help to achieve even longer active use and standby time for the user, enabling devices that can be worn with constant connection to your smartphone, for listening to music/audio, or collecting a range of sensor data such as heart rate measurements.

 

To be able to deliver longer listening time and smaller products, semiconductor companies will need to respond with greater integration in the SoC. ARM is ready to support semiconductor partners with drop-in silicon-proven Bluetooth low energy IP with ARM’s sub-1V Cordio radio IP. This is a key component in delivering further highly integrated in-ear Bluetooth low energy wireless ear bud, and is ideally combined with the uA/MHz power and area optimized Cortex-M4 processor.

Hearing Graphic 8-02.jpg

Learn more about ARM Cordio IP on www.arm.com/cordio

 

See also: What's next for headsets?

Conquering the IoT with the FlexIO peripheral — with help from the masses

It is difficult to pinpoint the exact date, but over the past few years, IoT has evolved from being an industry specific term, to a concept that’s more commonly understood by people from all walks of life.

 

There is a race among technology providers to conquer the challenges associated with bringing connected intelligence to the things we interact with. The challenges are diverse – spanning physical size, security, performance, time to market and power consumption … just to name a few. Living on the edge of the IoT are MCUs, like NXP’s Kinetis and LPC product lines. These microcontrollers collect raw data generated by various sensors providing real-time decision making to applications. As our world becomes more connected, the MCUs and even the embedded peripherals like FlexIO are becoming smarter and providing essential functionality to improve performance, decrease power consumption and speed time to market.

 

As consumers expect more from their devices, more is also expected from every aspect of the MCU — even the peripherals.  So, NXP teamed up with Hackster.io to create the “Flex Your Mind with Kinetis FlexIO” contest to challenge the embedded community to put the smart FlexIO peripheral to work.

 

Though the contest was focused on the FlexIO peripheral, many of the submissions tackled the challenge of adding connectivity to the base components they were provided. Using any boards they could get their hands on and hard work, contestants improved their designs with WiFi, Bluetooth and even NFC. The contestants overcame a broad range of challenges and it was amazing to see the creative applications from the dedicated participants.

We witnessed gracious collaboration as participants shared their learnings and offered advice to one another to help bring ideas to life.

 

One of my favorite submissions is a great example of the type of strategies that will conquer the IoT. The submission itself was built to provide a foundation for further innovation by delivering a “Flexduino” platform utilizing the maximum capabilities of the FlexIO.  This idea offers Arduino compatibility to the FlexIO advanced driver module to build new drivers to interface with high speed multimedia devices such as cameras, digital microphones and others.

IoT FlexIO - 1

The Air Mouse with NXP FRDM-K82F and FlexIO project presented many opportunities in gaming, entertainment systems and even CAD design.  With its 3-D printed form factor, the Air Mouse takes the traditional mouse or pointer to new heights by removing the limitations of controlling a mouse on a surface.  In his project the FlexIO allow emulation of various serial communication protocols, specifically I2C.  A full description of the project hardware and software set up can be seen on the contest page.

IoT FlexIO - 3

From Ultrasonic Radar to robots, drones and more, we were blown away at the creative applications that came out of this contest! IoT is here and FlexIO is helping to inspire innovations around home security, robotics, monitoring, automation and much more that can be applied in a variety of industries.  While the contest may be over, the possibilities live on! I encourage you to try out FlexIO for yourself or check out these projects and add your own unique spin.

IoT FlexIO - 2

No one can predict which disruptive applications will drive growth of the IoT. With the FlexIO contest we see an example of how the embedded community and their ideas will be an essential part of how the future unfolds. Provided with a bit of hardware and a goal in mind, the results are a step towards a smart, connected and secure tomorrow.

IoT FlexIO - 4

Security Graphic-01-NoText.jpg

If you are interested in learning more about security and ARM TrustZone CryptoCell technologies, check out our recent webinar Watch now: How to protect your systems with ARM TrustZone CryptoCell.

 

Connected devices have become a vital part of our lives, from our homes to our offices and factories, even improving our health and fitness. However, these IoT devices have also become an increasingly attractive target for cyber criminals. More connected devices mean more attack vectors and more possibilities for hackers to target us.

 

A previous blog post ‘Securing the embedded IoT world’ by jim_wallace explores some of the key attack vectors and explains how appropriate security must be baked into every system, at every level. It is clear that we have started to depend on the ever-increasing connectivity around us. We expect more speed, more personalization and greater reliability with anytime-anywhere access. For this to continue, security must be an integral part of the platform and be treated as a hygiene factor.

 

As devices become more connected, there are lots of things to think about surrounding security.

  • Connected devices will need an identity provisioning process and as they move into active service they will need to be commissioned. This will allow both the relying party and the connected device to authenticate each other and to enforce a policy related to the control and exchange of information.
  • Connected IoT devices also generate, store and communicate sensitive information. Which if compromised may negatively affect users’ privacy and/or the financial performance of a service provider. These assets (belonging to operators and users) need to be well protected.
  • Manufacturers will also want to protect their research and engineering investment, as well as their brand reputation against the damage caused by knockoff and counterfeited devices.
  • Finally, renewability and update-ability will be key to future-proof these devices with the ever increasing set of threats and attacks these devices will face over their lifetime in the field.

Developing secure platforms is not easy. Designing and implementing these security solutions requires high levels of expertise and lots of experience to get them right.

 

Normal-Secure-World.png

ARM TrustZone Technologies

ARM® TrustZone® technologies enable you to do just that and focus your valuable engineering resource on differentiation.

A TrustZone-enabled system allows you to perform isolation between secure and non-secure environments. TrustZone isolates software stacks from other potentially malicious, ‘normal-world’ software.

ARM TrustZone CryptoCell IP complements TrustZone and enables even greater separation of assets through hardware, ensuring different levels of trust across different suppliers in the value chain.

The integration of both these technologies creates a tightly coupled, high-performance security solution combining hardware and software components.

 

ARM TrustZone CryptoCell

ARM TrustZone CryptoCell provides a suite of security services that include cryptography, roots of trust management and assets protection in-transit, at-rest and in-use. The ARM TrustZone CryptoCell package includes hardware (RTL), on chip software and off chip tools. This allows the establishment of trust between the parties involved in various IoT ecosystems (manufacturers, service providers, users), the trust needed in the manufacturing lifecycle and the trust needed in the field.

During a device’s lifecycle, multiple entities will be involved in the process of; making it, shipping it, using it and End-of-life (EOL)-ing it. ARM TrustZone CryptoCell is key to this lifecycle process and provides a rich set of security services to protect the integrity, authenticity and confidentiality of various assets (code and data) belonging to different stakeholders (e.g. semiconductor vendors, OEMs, service providers, users) by associating a different security policy with each of the device’s lifecycle states.

 

ARM TrustZone CryptoCell is already protecting your systems today.  It is used in millions of devices around the world—enabling and shielding critical assets and high-value content. A good example of this is the systems SK Telecom have in place today.

 

SK-Telecom-logo.jpg“SK Telecom has wide range of IoT systems, these systems include smart factory and asset tracking management as well as a range of smart home applications. Once gathered from multiple sensors the data for the IoT systems is processed and analyzed at SK Telecom’s ThingPlug IoT platform to inform the stakeholders of the IoT systems. Much of this data needs to be securely protected and SK Telecom uses CryptoCell technology to do just that for a number of applications.

 

These secure systems will enhance productivity and management efficiency while maintaining a safer, more secure environment.”

 

Moojin Woo, Team Leader, SK Telecom

 

If you are interested in learning more about security and ARM TrustZone CryptoCell technologies, check out our recent webinar Watch now: How to protect your systems with ARM TrustZone CryptoCell.

 

Webinar Button.png

MYIR Tech Limited is a global provider of ARM hardware and software tools, design solutions for embedded applications. We support our customers in a wide range of services to accelerate your time to market.

 

MYIR is an ARM Connected Community Member and work closely with ARM and many semiconductor vendors. We sell products ranging from board level products such as development boards, single board computers and CPU modules to help with your evaluation, prototype, and system integration or creating your own applications. Our products are used widely in industrial control, medical devices, consumer electronic, telecommunication systems, Human Machine Interface (HMI) and more other embedded applications. MYIR has an experienced team and provides custom services based on many processors (especially ARM processors) to help customers make your idea a reality.

2.png 

 

 

 

 

 

 

 

 

 

1.png

It has been a while (my apologies) but a few weeks ago I posted about how you can Magically Reduce Coding Time with PSoC Creator. The thrust of the article was, in these days where no-one has time to read and digest multi-thousand page chip reference manuals, you really need a tool that generates the device code interface for you and guides you into making good decisions with your chosen hardware. Today I want to expand on that and show you how PSoC Creator implements a radical "pins-in" approach to configuring the device.

With traditional MCUs you get, or find, (or steal!!!) some driver code for a given peripheral and toil away making it work in your board. Typically the problem you face is not with the driver itself but that you need to figure out which block to use and what pins to route signals to (a peripheral block that does not connect to pins in some fashion is, after all, a bit boring). Taking a UART as my trusty example how do I choose between the half-dozen communication blocks in the device without knowing which one(s) connect to the pins I have access to on my board? Most development tools don’t help you make those choices. You just need to know that block 7 connects to pin 3 of port 4 and that is pin 26 on your device package, which is connected to the level shifter on your board. If you have a memory for numbers like I have then you'll soon be surrounded by sticky notes and feel like you have a picture of the device tattooed on the inside of your eyelids.

The usual "solution" to this from the device vendor is a library of examples for the peripherals. Example projects are really useful - we include hundreds of them with the PSoC Creator distribution after all - but their real purpose is to show you how to the use the peripheral, not how to configure the device. The reason why examples don’t help you configure the device in a real project is that they are all simple designs. When you have nothing else to support on the device it is easy to find a block that supports the functionality and connectivity you need. Where it goes wrong is when you are using most of the pins and your choice of UART block is making it impossible to get all the ADC channels connected. As soon as that happens you enter the trial-and-error process of iterating through pin choices to find a good fit. After a while having a real tattoo applied directly on the eyeball starts sounding like a good idea.

What you really need is a tool that understands the device fully. PSoC Creator only supports Cypress devices and we expend a lot of energy making sure it makes things like device configuration as easy as possible. In PSoC Creator you do not have to choose the communication block for the UART - you just choose the Rx and Tx pins. Why? Because that is the information you most likely have to hand when you are designing! When you put a UART into your project the pin editor is automatically updated with the IO that must be assigned physical pins. You just pick the pins you want to use by drag-and-dropping into the device picture or through drop-down menus.

The PSoC Creator Pin Editor Highlights Legal Pin Choices

The Pin Editor does not let you choose a pin that cannot support the function. Even without building the design you see the "legal set" of pins for the UART and once you make a choice the tool figures out which communication block to use. When you build the project the component API uses the right block and you never get a right-block-wrong-pin problem.

With serial communication blocks you, naturally, have a pair of signals to map. Once you have made a selection for the Rx then you will have reduced the legal set for the Tx. PSoC Creator helps you out again by highlighting the choices for Tx that are compatible with the Rx pin in green. It also shows the legal alternatives in gray because, if you pick one of these, the tool will force you to move the Rx pin onto a compatible location instead. You just cannot mess it up!

Pin Editor Guides You to Compatible Pin Combinations

PSoC fans will know that the devices include a lot of flexible routing that give you a lot more choices for pin selection than is available on other MCUs. As a result you can map the UART pins virtually anywhere but, while some pins are directly connected, some require routing resources to be used. The routing is, of course, calculated by PSoC Creator and your application never needs to care about the route but you might want to save those resources for another function entirely. To help you make resource-efficient decisions the tool highlights indirectly-accessible pins in yellow. When you see yellow pins in the editor there is no warning or error condition -  the tool is just saying "you can get to that pin and I will generate the routing for you, but there might be a better route that uses fewer routing resources."

Pin Editor Menus Showing Direct and Indirect Pin Choices

Because it is developed along with the devices that it supports, PSoC Creator is able to reduce your development time by avoiding all the annoying setup errors that are famous with traditional MCUs. Interested? Download it from here. It’s free. And there are lots of examples!

London, UK: 30th August 2016: SOMNIUM are pleased to announce version 3.4 of their DRT embedded C/C++ software development tools.

SOMNIUM® DRT Cortex M-IDE now includes support for Atmel’s (now a subsidiary of Microchip Technology Inc.) ARM ®-based microcontrollers and software ecosystem, with fully automatic import from Atmel START - an innovative web-based tool for intuitive, graphical configuration of embedded software projects. Further improvements to DRT’s advanced C/C++ code generation and IDE have further extended its benefits to embedded developers.

DRT is unique – fully source compatible with industry standard GNU (including the latest C11 and C++14 dialects and C++ exception handling), whilst offering significantly better code generation than vanilla tools. DRT’s patented resequencing optimizations typically provide up to 20% smaller code, 30% higher performance and 30% energy savings, with no source code changes required. DRT’s correctness is verified using a mixture of on-host (simulated) and on-target (real silicon) tests to ensure robust, functionally correct operation, and best possible code size and performance.

DRT's IDE is built on the industry standard Eclipse IDE, extended with leading edge debug and productivity features and is available on multiple host environments (Microsoft Windows and Linux, with MAC OSX support launching in Q4 2016). DRT’s advanced debug features address real problems faced by embedded software developers:

Live expressions view : Extract and display variables without needing to breakpoint (a vital feature for debugging hard real time systems).

Trace : Automatic configuration and extraction of MTB trace (on supporting devices). Using a small amount of on-chip RAM allows program trace to be gathered and viewed in a fully featured debug environment to allow faster detection and correction of complex software bugs.

Fault diagnosis : Automatic extraction of state and source navigation

DRT customers also benefit from full product support, direct from SOMNIUM's customer engineering team.

Dave Edwards, SOMNIUM's CEO/CTO said “We are pleased to add support for Atmel | SMART devices to DRT Cortex-M IDE as we continue to enhance DRT’s optimization and debug features. Free of charge tools are often based on the vanilla GNU and Eclipse technologies and offer great entry level features. Many commercial products use the same vanilla GNU and Eclipse components, or even older versions, giving you no benefits over free products and often contain code generation bugs. DRT Cortex-M IDE uniquely combines SOMNIUM’s rigorous approach to quality and correctness, full integration with Atmel’s software ecosystem, patented code optimizations and advanced debug in a single professional development tools product “.
“We are very excited about the addition of support for our hardware and software ecosystem to the SOMNIUM Cortex-M IDE”, said Henrik Flodell, Sr. Product Marketing Manager, Development Tools at Microchip. “Having access to DRT’s high quality code generation and state of the art debug on multiple host platforms will add a lot of value for our customers and help them reach the market faster, with higher performance, more energy efficient and more profitable designs”.

Payment card fraud

For every $100 in volume spent through payment cards, 5.65¢ was fraudulent in 2014 – and the numbers continue to climb. The attacks on payment systems that lead to card fraud amount to billions of dollars in losses annually. All of us are paying for it – both directly through personal loss and indirectly through added cost for payment transactions.

How can technology help protect us from these attacks and fraudulent use of our cards?

Let’s look at what the SLN-POS-RDR is designed to do and the meaning behind its nomenclature:

SLN = Solution
POS= Point of Sale
RDR = Reader

This is a class of products from NXP that brings together hardware, software and certifications, enabling you to implement devices that accept payment cards.

Picture the devices you use to pay in the check-out at the grocery store, coffee shop, clothing store or small food truck. Now that you have some idea of the type of device this solution supports, let’s focus on what a solution is.

There are a couple of common definitions for the word solution. A solution can be the means of solving a problem or dealing with a difficult situation. The word solution is also defined as a mixture in which the solute is distributed within the major component (the solvent). Both of these definitions can be applicable to the SLN-POS-RDR, the secure card reader solution that address the problems of developing a payment terminal with a high level of security integration.

Solving a problem

Solutions are built with an end goal in mind and to address specific problems. In the case of the secure card reader, the solution addresses the needs around the payment card interfaces. Beyond the software drivers and stacks that run on the microcontroller, there are hardware components for IC card readers (contact interface), and the NFC front ends (contactless interface). Bringing these pieces together and performing compliance testing leads to components that more completely address the specific challenges that a payment terminal manufacturer will face.

 

To show how the application problems are solved, the solutions being created by NXP are measured by certification and compliance testing where applicable. In this way, instead of simply showing the answer to the problem, the collateral built around the compliance testing provides the user of the card reader solution with the methodology that can be used to solve the problem.

 

A secure card reader is a complex device, having functions related to user interaction with display and a pin pad, the card reader interfaces and USB communications to a host. Bringing all of these functions together into one application means that interactions and dependencies for MCU resources have to be considered. The influence on the hardware and software components of the solution leads to a robustness and usability that benefits the user as they develop their end products.

 

A solution of security

A look inside the SLN-POS-RDR: Point-of-Sale Card Reader Solution

A look inside the SLN-POS-RDR: Point-of-Sale Card Reader Solution

 

Central to building a solution for payment systems is meeting the security requirements set in place to combat the staggering card fraud problem. For a secure card reader, there are two standards that are considered throughout the development and deployment of these devices. These standards are the Payment Card Industry Security Standards Council requirements for Pin Transaction Security (PCI PTS) and the EMVCo EMV Specifications.

 

In order to meet these standards, security has to be considered in all aspects of the card reader design. As an example, to achieve PCI PTS certification, the software development has to be shown to be secure and robust.  More about how processor features align to the security standards for payment systems will be covered in an upcoming ARM TechCon Session. For a payment application solution, security is distributed throughout the design creating a solution of security into the payment application.

 

There are many resources highlighting the MCU technology needed to meet security requirements. These are the trust, cryptography and anti-tamper capabilities for NXP MCUs. For the card reader solution, we get to see the technology in use. Some examples include the use of cryptography to secure the data transfers from payment cards to the card reader.  In addition to adhere to security requirements for card holder PIN information, the software functions that handle this data are protected by memory clear functions to ensure that sensitive data does not persist longer than necessary. The solution software also makes use of the system memory protection unit of the MCU, separating software functions with logical protection in order to protect highly secure data.

 

With regards to anti-tamper capabilities, there is an example built into the solution to demonstrate the capabilities of actively monitoring a tamper mesh. This example makes use of NXP’s Kinetis Software Development Kit in order to initialize the DryICE peripheral to detect a physical attack. In addition, grouped into the card reader solution will be documents related to the PCI evaluations done for the MCU and associated hardware. These documents will provide guidelines on which MCU features are necessary to meet the PCI PTS requirements.

 

Summing up

The benefits of creating a solution can go beyond the targeted use case. Just as complex mathematical problems can be broken down, so can the challenges of embedded design. With a solution, like the SLN-POS-RDR, not only are we addressing industry problems such as card fraud, but also the challenges of embedded design. Bringing security along with other common embedded functions around human interfacing and communications will enable the developer to confidently bring their devices to production.

Forlinx will attend ELEXCON 2016 as an exhibitor held in Shenzhen EXPO Center at booth no. 3C32 from August 24, 2016 to August 26, 2016. On the exhibition, some new items such as EV charger billing control unit TCU 335xD, single board computers i.MX6Q/DL/UL, OK335xD/S/xS-II etc.

Welcome to visit us at that time.

[re-printed from http://www.cypress.com/blog/psoc-creator-news-and-information]

 

One of the really nice features of the PSoC Creator schematic editor is the ability to copy-paste parts of the design to replicate functionality. When you copy a component instance all the parameter settings come along for the ride and so you can set things up once and use the metaphorical cookie-cutter as often as you like. The tool even renames everything to avoid name space collisions. It is a feature I use all the time.

Until it goes wrong. This happens when I decide that I need to change a parameter and start making the edits in copied components. Then someone roams up to my desk and asks a difficult question (such as "ready for lunch?"). One extra-large burrito and a bucket of chips later I have forgotten which components I had edited and the whole system stops working! As a result this I always look for alternatives to making multiple copies of components and a hobby project of mine illustrates a good example of how to do that.

 

When not eating burritos or writing articles for the PSoC Creator Start Page I often play with a PSoC-powered robot car. I can drive it from my phone because it has a Bluetooth module on-board, and I can set it up as either an automated line follower or maze solver. It happens to be the fastest line follower in the company by the way but that is probably more an indication of my lack of article writing than my skills as an embedded programmer. Anyway… the front of the car has a row of 5 reflectance sensors, connected to PSoC pins, that I use to detect the presence and position of the car relative to a line on the floor. The photodiodes are always powered on and the resistance of the phototransistor side varies according to the reflectance of the surface it is facing. By repeatedly charging up a capacitor and timing how long it takes to decay through the transistor I can detect a black line on a white surface (or vice versa). And it is 100% digital so I am not being forced into the kind of mathematical gymnastics I abandoned a long time ago!

 

Here is a picture of the circuit to handle one sensor. I am using a 2-output PWM to drive the pin's output enable terminal high, which charges up the capacitor (cap_charge). Then I disable the output and wait a "while" for it to decay. A second pulse (sensor_sample) copies the state of the pin through a flip-flop into a status register. I can read the register at any time and the flip-flop ensures the data is always good.

As you can imagine, making 5 copies of this circuit is dangerous. In my time I have messed up the PWM frequencies, the drive modes and initial states of the pins, the reset state of the flip-flop and, well, pretty much everything else! Here is a part of the full design showing just two of the five sensors.

While this design works fine, every time I edit it I manage to make a mistake. The wiring between the PWM and the status register gets complex and it is easy to make a parameter change in some, but not all, components. The fix is to use just one PWM for all the pins (pretty obvious I know) and use the other component's "size" parameter. Starting with the pin, you open the parameter editor dialog and set the "Number of pins" to 5 and, on the Mapping tab, select "Display as bus". The wire from the component becomes thick to indicate that it is a 5-bit bus rather than just a single wire. Notice how there is is just one Output Enable terminal so I can control all the pins with one PWM signal. Then you do basically the same thing with the flip-flop and the status register - give them a size of 5 and display their terminals as buses.

Et voila! Using buses allows me to compress the whole design into the minimum number of components and wiring. Best of all I can make parameter changes to all pins with just a single edit. I have a 5-sensor implementation that helps make my car super-fast but is barely more complex than the single sensor version. Best of all, it is really easy to maintain, regardless of all my burrito-fueled distractions!

Filter Blog

By date:
By tag:

More Like This