1 2 3 Previous Next

Embedded

318 posts

At VIA Embedded we are experimenting with a number of ARM devices and use cases. We made developer boards and systems based on our own VIA SoCs of two separate lineage, as well as Freescale's chips. This makes us more experienced, but also leaves our efforts more fragmented and requires us to connect with multiple ecosystems. This latter is not too simple, since there are always a shortage of resources, both for making contact with other companies and potential partners, and then to support that effort.

 

When I heard that Freescale is doing an open community event for "Designing with Freescale" right here in Taiwan, I grabbed the opportunity to meet others in similar shoes.

freescale1.jpg

The event had three parts: two presentation tracks (one mostly on hardware, other mostly on software), and a showcasing area where Freescale partners were showing off their products and offerings. The presentations were all in Chinese (though the slides in English) and unfortunately my Chinese is not that great, I just picked up whatever I could along the way. Had a chance to have more in-depth conversation in the showcase area and at the lunch, though, and that was very illuminating.

freescale3.jpg

It was a great opportunity to learn about industry trends, and see how other companies handle their business.

 

The main codewords were iot and home_automation. The solutions were interesting and developed if I looked at them as an industry insider, though as a customer I feel there's a long way to go. The hardware is well done, but needs better use cases, and maybe a refinement who are the end customers. I'm more and more convinced that the users won't be the end customers but solution providers, infrastructure developers. Personal versions of these devices are evilishly difficult, while infrastructure versions will likely become the norm sooner rather than later.

 

Was interesting to see how different companies solved things differently. Licensing patterns, customer support patterns were different across the board. Hardware that is very popular in one region has no demand or even a pushback in another. The rationales of choosing different hardware solutions has varied a lot too: whether a team went with the cheapest adequate version of a chip or going for high-end overkill just in case. The buzzwords were different in each geographic/industry region as well, eg. it took a bit of explanation to get across the meaning of Digital Signage for someone who were providing solutions in exact area, just didn't call it Digital signage.

 

The other thing I've learned is that we (meaning VIA) are definitely not doing enough communication towards other industry partners. Pretty much nobody known at the event that we are doing more than chipsets now (compared to, say, 15 years ago), and that we are in developer boards, digital signage, software development, the full shebang... There are a lot of opportunities for collaboration, but only if people know that you exists...

 

I wonder what other participants took home from the event, or what's the expectation people have when they are attending such developer get-togethers? Would love to hear your comments!

 

A more general-public-facing version of the event summary has been posted on the VIA Springboard Blog.

 

Our Freescale based boards are VAB-800 (i.MX5) and VAB-820 (i.MX6Q).

Carissa Labriola

Intern Inquiry 8/29

Posted by Carissa Labriola Aug 29, 2014

I will apologize in advance that I only have 1 question this week. With TechCon fast approaching my week was more marketing-centric than developer. I did however find some long term questions that I've started investigating as well that will probably involve more hands on work than reading through documentation.

 

So I decided on this question for this week's post:

How to use the free rtos in lpc1768...?

 

I have several options that are really dependent on what development board you are using.

 

I will start off with the generic: this is the official FreeRTOS kernal from their website: http://sourceforge.net/projects/freertos/files/latest/download?source=files. You can download it and utilize their quick start guide here as needed: FreeRTOS - Quick start guide.

 

The specifics here will really depend on what you're using, so I'll give a few options just in case:

 

I have used a NXP LPC1758 on a custom development board (SJ One Board) with FreeRTOS ( Smart Planter Project on LPC1758) and I found them to work well together. This is the development package I used for my project: ARM Development Package. Download the zip file and unzip it under your C drive. Use the Eclipse32_Emb.bat and there will be sample projects available on the left bar of Eclipse. The package has LPC17xx driver libraries and FreeRTOS preloaded so it's a quick way to start off a project. Some of the other drivers are written specifically for the SJ One so depending on what you're doing you can delete or modify for your needs.

 

If you want to see a few more projects that used this development package I recommend you take a look here: Realtime OS on Embedded Systems - Embedded Systems Learning Academy

(scroll down to semester projects).

 

If you are talking about the mbed board: ARM mbed LPC1768 Board and using the online mbed compiler, adding FreeRTOS is fairly easy. Under your project in the compiler, go to import and search "freertos". Import this library:

rohit.PNG

Make sure to include "FreeRTOS.h" in your project!

 

If there is a specific board or environment you would like to see added or more detail on getting started with FreeRTOS just let me know!

I thought I'd share a project I made last semester as part of my real-time embedded systems course at San Jose State University. It was developed on the SJ One Board which utilizes the NXP LPC1758 (ARM Cortex-M3). It was a good exercise in external communications and gave me something to not kill my plants. Below is my project report, which was written so that other developers can learn from our process (original post: S14: Smart Planter). Enjoy!

Abstract

Most people don’t have the time in the day to remember to water a plant. When they do have a moment to water the plant, they over-water therefore wasting resources and hurting the plant. The solution is a system that takes in data on the moisture of the soil, temperature, and humidity of the environment to decide when to pump the necessary water resource accordingly.

Objectives & Introduction

This system will be achieved using two different types of sensors: the first will be a soil hygrometer inserted into the bottom of the plant to detect the amount of water the plant currently possesses in its soil. This will be the highest priority in determining whether the plant needs additional water. The second sensor is a combination of humidity and temperature sensor attached to a peg (for security and to keep the wires safe) that will relay the data back to the SJ One board. In order to conserve energy, the system will collect data twice a day (8 am and 3:30 pm) to determine how much water needs to be released. A real-time clock along with an alarm timer will be used to determine when to trigger the sensors and collect data. In addition, a push-button will be implemented as an alternate way to activate the sensors to check if the plant needs to be watered. It will only water the plant if the algorithm determines that the plant needs to be watered to prevent drowning the plant. A drip system was chosen because this method has shown it is the most effective in not wasting water as opposed to a spray sprinkler system that loses more water to evaporation. Finally, information including the last time checked, the temperature at this time, soil moisture, and the watered time will be displayed on an LCD screen for the user to view.

Team Members & Responsibilities

  • Carissa Labriola
    • Driver Development for sensors, Peripheral Device Hardware Integration, Software Layout, Wikipedia Documentation
  • Sovist Thou
    • LCD Driver Display, DC Motor Control, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation
  • Leeladithya Avala
    • FreeRTOS Software Design, Physical Layout, Circuit Board Design And Hardware Implementation, Wikipedia Documentation

Schedule

Week#DateTaskDescription
13/23Research and order partsA total of 6 hours were spent researching which parts would fit into the project such as the right DC motor, a dependable hygrometer (many corrode too quickly), an accurate temperature sensor, an LCD screen that isn't too big and doesn't need more than 12V, etc.
23/30Write drivers for peripherals and environmentInitial FreeRTOS environment complete, peripherals started
34/6Finish hardware set up, continue peripheralsHardware set-up for individual modules, LCD screen progress,
44/13Finish drivers and FreeRTOS environmentLCD screen, DHT22 drivers, DC motor control complete
54/20Test and Edit environmentDHT22 still experiencing issues, hygrometer complete, Motor module complete, adding modules to FreeRTOS
65/3Continue TestingDHT22 still experiencing issues, assembly of protoboard begins
75/10Continue TestingMoving to on-board temperature sensor, compiling individual modules into main environment, implemented push button logicTroubleshooting of protoboard connections
85/17Final testing and set upAll modules added to environment and protoboard, last fine tuning of software and hardware
95/21DemoComplete

Parts List & Cost

ItemDescriptionQtyUnit CostTotal CostSource
1Hygrometer1$6.00$6.00Happy Store Arduino Moisture Sensor Soil moisture sensor automatic watering special - Moisture Meters - Amazon.com
27mm Silicon Tubing1$8.00$8.007mm Inner Dia 1M Length Red Silicone Vacuum Hose Tubing - Air Tool Hoses - Amazon.com
3Submersible Water Pump1$15.00$15.00High temperature(100'C) 1.85L/Min (29GPH) mini DC12V. Food grade: Portable Power Water Pumps: Amazon.com: Industrial & S…
4LCD Screen1$25.00$25.004 x 20 Characters
5Plant Pot1$2.00$2.00Orchard Supple Hardware
6Water Basin1$4.00$4.00Target
7Plant1$3.00$3.00Trader Joe's
8Temperature And Humidity Measurement Sensor1$7.00$7.00Vktech Home Appliance DHT22/AM2302 Digital Temperature And Humidity Measurement Sensor - - Amazon.com
9Protoboard1$5.00$5.00RadioShack
10Misc Components (And gate SN1708, DC Jack, Power Regulator LM7805, N-Channel MOSFET NTD5865N)1$5.00$5.00HSC
11SJ One Board1$80.00$80.00Preet preet.wiki@gmail.com
Total$160.00

Design & Implementation

Hardware Design

The hardware for the project was broken down by the needs of the different sensors. To have the design function as expected, the team required circuitry to provide the appropriate power to each peripheral as well as the microcontroller. The Basic System Design, shown in the figure below, shows how each component was laid out onto the base board. The LCD, SJ One board, and prototype board is set inside a clear box to protect the circuitry from any water spills and allows viewing of the embedded design. The prototype board was used to build the circuitry, including the power unit for the system so that there could be a 12V and 5V power rail supplied by a 12 DCV wall supply, a ground rail, as well as a 3.3V rail supplied by the SJ One's Vout pin. The water supply includes a submersible DC water pump that sits at the bottom of the bucket since it is not self-priming and needs to be completely submerged to avoid damage. The silicon tubing coming out of the bucket is fed to the plant' s soil as a drip system. A single push button was implemented to allow the user to check the parameters at any given time in the day while not allowing them to over-water the plant.

pic1.png
Basic System Design

The Figure below shows the circuit design for our system. Not shown in the circuit box is the DC motor.

pic2.png
Circuit System Set-Up



Circuit System Design

Hardware Interface

Each of the peripherals utilized a different type of BUS communication. The soil hygrometer works by sending voltage through the pegs, measures the resistance between them, a value dependent on the moisture level, and translates this information into an analog output. Therefore, the pin is attached to one of the analog to digital pins on the board in order to translate the signal into a number that will determine the appropriate level. While the original intent for the project was to use the DHT22 temperature/humidity sensor, the protocol was more complicated than initially anticipated so the sensor was exchanged for the on-board I2C sensor. Since significant strides were made in the development of the DHT driver, its description has been included. The DHT22 utilizes a custom single-line open collector communication BUS connected to +5V, ground, and a 10kohm resister connected from voltage to the communication pin to pull it high. The sensor waits for the microcontroller to pull the line low for 1-20ms, then pulls the line actively high for 20-40us. The microcontroller then needs to switch to an input to receive the acknowledge signal followed by 40 bits. The bits are determined 0 or 1 by the length of how long the particular segment of data is high or low. The sensor needs to wait 2s in between reads and critical read times need to be protected from being interrupted in order to be successful.

DHT22 Sensor Waveform for acknowledge

The on-board temperature sensor utilizes an I2C communication which has two data lines: SDA for the address, acknowledge, and data while the SCL line is used for the clock to time the information. The read temperature class has the microcontroller acting as the master and reading from the slave device, the temperature sensor. The clock is provided by the master device to the slave so that the communication can be in sync. The connections for this device are internal and can be seen on the right:

I2C Temperature Sensor Set Up, Credit to SJ_One_V2 Schematics

The DC motor is a food-safe motor that takes +10-12DCV and has two inputs: the voltage and an active high signal that needs to be ~+3-5V to turn on the motor. This system was set up by attaching a GPIO pin located on the SJ One board to the input of a SN1708 AND gate with a high signal on the second input. This results in the AND gate outputting a high signal of +5V which is enough to activate the motor. An important note for the hardware implementation of the motor control is the use of zener diode 1N4001 to regulate feedback current to protect the MOSFET from blowing out. When the DC motor powers down, a high reverse voltage spikes back and could potentially damage the mosfet.
The LCD screen has an onboard controller or "backpack" that is capable of selecting different communication protocols (UART, I2C, and SPI). For this project, SPI (Serial Peripheral interface) was chosen as the appropriate communication for its simplicity and speed. To use the LCD in SPI mode, the SJ One board acts as a master providing SCLK (clock), display data to the LCD through MOSI data line, and SS (chip select). The chip select is used to start and end a transmission frame while in the process enabling the writing of data to the LCD. The LCD acts as a slave and only reads data sent by the microcontroller. Though the SPI bus works as an exchange protocol where a data byte is sent to receive a data byte, the MISO (slave output data) was ignored since the data sent by the LCD are not of interest.

Software Design

The software for the planter used FreeRTOS as a base with two main tasks for the scheduler: a standby task that passed the information to the LCD to be printed on the board and a check reading task. The standby task was not passed as a semaphore since the check reading task was only activated if either alarm semaphore handler or the button press handler was taken. The standby task was run automatically. The standby task reads as follows:

 

while (1)

get current time

send the last time plant was watered to first line of LCD

send the last temperature read to the second line of the LCD

send the last soil moisture read to the third line of the LCD

send the current time to the fourth line of the LCD

delay loop for 50ms


The check reading task, when activated, updates the temperature, soil moisture, and fetches the current time. If the moisture level, which ranges from ~14-50, is below 20 or the temperature is above 90*F, then the motor is activated for three seconds and the time last watered is updated. The motor is activated for two seconds if the temperature is between 80*F and 90*F or if the moisture level is less than 30. The motor is activated for one second if the temperature is between 70*F and 80*F or the moisture is below 40. If it does not fit into these parameters, than the plant is deemed to not need water and the power is not powered nor is the time watered updated.The individual drivers for the peripherals will be described in the implementation section.

State Diagram

Implementation

Since the overall system code has already been detailed, this section will be focusing on the software implementation of each of the peripherals.Temperature/Humidity Sensor: The temperature/humidity sensor DHT22 utilizes the tri-state properties of the open collector to operate. The microcontroller must first set up a single pin as an open collector GPIO with an output pulled high. Only when the user requests data does the pin pull low for 20ms the pull high actively for 40us. The pin then needs to switch to being an external interrupt pin activated on both the falling edge to capture the start of the acknowledge as well as start a protected time from the interrupts of the FreeRTOS. When the edge is triggered, a timer will start counting such that if the rising edge trigger is not found within 100us then there is a timeout on the acknowledge indicating an error. Else the interrupt again looks for the incoming 40 bits that represent 16 bits of humidity, 16 bits of temperature, and 8 bits of check sum. The counter for the bits is such that at the positive edge of a high the count is started and ends when the negative edge is triggered. If the counter is 26-28us, then the bit is considered a '0'. If the counter is 70us, then the bit is considered a '1'. The bits are concatenated accordingly for the humidity, temperature, and check sum and if the data compared appropriately with the check sum then the read is considered successful. If called, the data for the temperature can be converted into *F since it comes as *C.I2C Temperature Sensor: The I2C sensor had the driver pre-written and verified to be working, but we had to have a working understanding of how it works. The particular process needed for this sensor was a read command. For this command to work, the microcontroller, acting as master, sent a start signal over the data line with the slave address. Using the SCLK to stay synchronized, the sensor sent back an acknowledge signal. The start signal was sent again with an off address and after the second acknowledge was confirmed the read signal was sent, which places the sensor's data into a buffer. The buffer was then sent in a 16-bit package over the line back to the master, converted into degrees in Celsius and then converted again into Fahrenheit degrees.Hygrometer: The majority of the hygrometer data is processed through the hardware, since the analog signal is put into the Analog to Digital converter pin. Therefore, the pin must be set to it's ADC setting as an input pin. When the pin needs to be read, the BURST bit is set to start communications, a while loop waits until bit 31 is set to indicate transfer complete, and the data is transferred into an declared integer.RTC: The Real-Time Clock needs to be set in order for the alarms to be effective. Therefore the RTC header needs to be included in the main program, the initialize function called, and there needs to be a declaration of type rtc_t so that the program has it's own time parameters that can update the clock time and date for the local program and the actual RTC.DC Motor: The DC motor involves setting a pin to be a GPIO, setting it to be an output and pulling the line low. When the motor is to be activated, the pin is driven high, taking in as input the amount of time to delay in milliseconds before pulling the line low again.LCD Screen: To operate the LCD, the LCD data sheet details commands that can be deciphered by the LCD controller to perform specific functions such as a write to line one of the LCD. To perform this write to line one of the LCD, the following must take place in software: 1) Chip select is turned on to select the device. 2) Send the function command to the LCD. In this case a write of hex 0xFE followed by 0x45 and 0x00 sets the cursor position to line one of the LCD. 3) Send the text to be displayed to the LCD. 4) Deactivate chip select to complete an operation. The controller reads character commands therefore the text and the command itself is sent to the LCD through a character byte exchange function. In the project software design each line of the 4 line LCD has its own unique write function and message created with the procedure described. The function receives input information from the real time clock and sensors then displays the information in real time.

Testing & Technical Challenges

For testing this project, each of the sub-modules was completed individually and then compiled together to work in unison. The temperature/humidity sensor required the majority of the debugging time since it utilizes microsecond-precision in transferring the data. Across the board, the team found that when testing that making a separate project folder just for testing sub-modules made the debugging process more efficient. The team's procedure was to write the drivers for each of the devices with their own test code then one by one start to integrate each one into a main test program. Starting with the hygrometer being placed into the FreeRTOS frame, a button interrupt was integrated. Once this procedure was successful, the temperature sensor's input was added in. This was followed by the integration of the motor pump and lastly the LCD screen. The issues that were encountered along the testing procedure can be seen below:

Temperature Sensor Issues #1

While the documentation for the DHT22 temperature sensor says that the minimum voltage level is 3.3V and the board is supposed to output 3.3V, in reality this does not work. This was found to be a combination of the sensor really needing +5V to work properly and the board was found to only output 3.2V (tested using a multimeter). The fix for the issue was to alter the power line portion of the circuitry such that we now have the initial +12V set up to drive the DC motor then a +5V line for the microcontroller and the temperature/humidity sensor to connect to for power.

Temperature Sensor Issues #2

The first issue encountered was in writing the driver for the temperature and humidity sensor. The DHT22 works off of a single line for data transfer using the tri-state of an open collector to send start and acknowledge signals back and forth between the microcontroller and the device. The timing for sending the data is down to the microseconds so the driver timing has to be very precise or data would be missed. Hours were spent debugging a delay-based version that would hang while waiting for the end of the acknowledge from the sensor. In the end, time was running out for the DHT22 module was abandoned in favor of the I2C based temperature sensor on the board.

Hygrometer Issue #1

Programming the analog signal from the hygrometer sensor required a little research and debugging. Since this type of communication had not been experimented with before, it took a few hours completely of research to make sure that all of the correct bits were being set but ultimately this extra time spent double checking all of the inputs meant only a few trials on the board before it worked successfully.

LCD Issue #1

Initially, when sending a byte of data (command functions) to the LCD, the byte would be displayed on the LCD in ASCII representation rather than performing the operation such as setting a cursor on. This was noticed when a closer look was taken at the binary representation of the displayed character within the data sheet. The byte was taken as a literal write data rather than actually being read as a hex command. This was an occurrence that was unexplained online when researching for a solution. In search of a solution, multiple experiments with the LCD were conducted. It was found that while sending the clear hex command in a loop, the hex command at some point reads as an operation and clears the screen rather than be displayed as a literal. After consulting a generic LCD data sheet, it was soon discovered that in most cases an LCD controller needs a delay of 100ms after the chip select is on to synch the transmission frame for SPI. Once this delay was placed inside the software a simple clear command would take place. The following issue was how to send long messages written in continual byte streams rather than single byte characters.The solution was to create a function that would leverage our single exchangeByte function with another function that could write the Byte as a string. The lesson of this issue is to always buy products that are well documented.

DC Motor Issue #1

During the initial implementation phase of the motor control on a breadboard, the input signal voltage to drive the MOSFET to activate the DC motor was +3.3V. The DC motor control software was tested multiple times to validate the correctness of the software. However, when a final implementation of the DC motor control circuit was made on a prototype board, the DC motor would not turn on with the same software. After multiple tests, the DC motor would not function consistently until it no longer activated completely. After thorough testing with a multimeter and monitoring the voltage levels of the MOSFET, it was found out that the mosfet needed +5V to drive the DC motor. This posed an issue as the microcontroller GPIO pin can only output +3.3V max. As a solution we used an AND gate as a signal driver, using its output logic at +5V to drive our DC motor. The troubleshooting for this issue was an incredible task as the issue was neither in software nor hardware implementation but an internal change in the MOSFET that was not seen to the testers.

Water container #1

The plastic water container for the project needed to have two holes drilled in for the silicon tubing and the wires for the DC motor. While the sealing for the silicon tubing held up, the wires produced a small leak, which became a hazard around all of the electronics. The solution for this issue was to add more hot glue whenever a drip was noticed and to seal both sides of the hole for extra support. As a result the container is now successfully sealed.

Conclusion

The Smart Planter utilized a breadth of knowledge acquired in the embedded systems course to become successful. This included implementing I2C, SPI, GPIO, FreeRTOS, interrupts, Real-Time Clock alarms, analog-to-digital conversions, single line communications, and DC motors. Clean hardware implementation was reinforced as well as proper use of voltage regulators, MOSFETs, and setting up power lines. In the software portion of the project an understanding of interacting tasks and being conscious of the real-time operation was invaluable to the success of the project. How to troubleshoot problems across software and hardware modules was also an important learning lesson in this project. Being able to identify a problem, such as why the time function isn't updating on the LCD screen, and following the logic of the code to discover the RTC gettime function was not properly implemented, is an important skill to cultivate in engineering since the ones encountered in this project are minor compared to industry issues. A few improvements could have been made: for example, a water level sensor could have been added to the water tank so that if the water level got too low then the user could be warned, especially since the motor is damaged if it tries to run without water. A battery for the RTC would also have been helpful since currently the clock resets to a specified time and date every time it loses power. Had there been more time, a wireless connection to receive weather predictions from weather.com would have been a nice addition for the plant that the team did not have time to implement as an extra. Overall, this project was abundant in learning opportunities for the entire team so while the concept of the project was simple there was still plenty of valuable knowledge to gathered and problem solving to be had.

Project Source Code

References

References Used

LPC1758 User Manual
LPC1758 Hardware schematics
Socialledge I2C tutorial

     Now wearable design become more and more popular around the world. Lot's of designers choose ARM Cortex-M series core. Why choose Cortex-M, not the most famous Cortex-A series core? What is the real benifit for the designers? You can find answers from this blog:

 

AnandTech | ARM's Cortex M: Even Smaller and Lower Power CPU Cores

 

     Package , Power Consumption and Performace, you will find the part attract you easily.

 

RPiSoC is a PSoC 5LP-based electronics development platform that allows your software to interact with the physical world in a way that emphasizes power, flexibility, and accessibility.

 

It started life as a senior project for Robert Barron and Brian Bradley at Rensselaer Polytechnic Institute, who have now formed Embedit and launched the platform on Kickstarter.

 

They are running a Webinar tomorrow on the Element14 site.

RPISoC-small.jpg
RPiSoC can be used as a standalone embedded board for instrumentation, data acquisition, and mixed signal projects. But it really gets interesting when you hook it up to a Raspberry Pi. The Cypress PSoC 5LP makes RPiSoC much more than a typical fixed-function expansion board; providing access to PWMs, high resolution DACs and ADCs, Opamps, DSP, Pmod and Arduino Shield interfaces, and much more! You can replace a bunch of peripheral boards with a single RPiSoC.
RPiSoC-RasPi.jpg
I really recommend taking a look at this new platform. Robert and Brian just launched the kickstarter project and there are some nice videos of the platform in action. I particularly like the face recognition one but there are a number of others on YouTube.

Although I enjoy writing articles and blogs and giving presentations – I am always hoping that I can impart some useful information and help engineers with their projects – the Q&A session after a presentation is often the moist interesting part. If I am doing a Web seminar, for example, I normally have a one hour slot; I try to talk for no more than 20-25 minutes, leaving plenty of time for Q&A. I find that so often it is the questions that trigger ideas for articles, blogs and further presentations. So, please keep them coming – comment here or email are always options.

I attended a recent Web seminar at which there were lots of interesting questions …

As is my common experience, there were far too many questions to cover in the available time, but my colleague made a fine effort to address as many as she could. I obtained a list of outstanding queries [to which she may well have sent replies by email to the appropriate attendees] and found a few that I though worth some discussion here:

If Linux is installed on two cores in an SoC, will processes be allocated to each core as needed/available?

The simple answer is: maybe. It depends on what software configuration you choose. If you use an SMP [Symmetric MultiProcessing] version of Linux, a single instance runs across both cores and processes will be allocated to a core on which to execute. The way this allocation is performed is a configuration issue. On the other hand, if Linux is installed individually on each core [it is now an AMP - Asymmetric MultiProcessing - system], code execution is managed separately and each process “belongs” to a specific OS instance and, hence, on a specific core.

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

ScreenClip-520x286.png

I have always liked writing. From an early age, I had an ambition to write a book. My first attempt, in my mid-teens, was a science fiction novel. It was not a success. I wrote about 100 pages and I may even still have the typescript. I remember being embarrassed last time I looked at it. One of the best days of my life was back in 1986, when a jiffy bag arrived in the mail containing a book with my name on the cover.

Since then, I have never really stopped writing …

With a few exceptions, just about everything I have written has been about electronics and/or software. Until the last few years, much of my output has been in print – lots of collateral materials, countless magazine articles and another book. Nowadays, the vast majority of what I do is online. This blog is a prime example. I post frequently on a wide range of topics, but, to some extent, I feel rather constrained – both by time and space. It takes time to write a few thousand words and a blog post is necessarily quite brief. So, I welcome opportunities to get into more detail and explore a topic in more depth.

I publish articles – many of which pick up on themes of blog posts – in a number of places. I have a “column” on embedded.com – that means that they publish my pieces on a fairly regular basis. I realized that I do not do a very good job of publicizing those articles, so I figured that it might be useful to provide a guide to some of my recent work on that site:

Binary Anyone?

Embedded software developers quite commonly need to think about individual bits. This is most commonly the case when working with CPU or peripheral device control registers. High level languages, like C, do not accommodate developers’ needs very well in this respect. This article outlines an approach whereby developers can code low level routines using binary in a natural, intuitive way.

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

Embedded software articles – from assembly language to software IP « The Colin Walls Blog.png

ARM University Program (AUP) and Freescale University Program, as part of their joint activities in India, conducted two one-day workshops (ODWs) for faculty on the Freedom board (ARM® Cortex®-M0+ FRDM KL25Z) on June 9 and 10 at the ARM office in Bangalore. The participants were from universities and colleges across India, including the Indian Institute of Science (IISc), the Indian Institutes of Technology (IITs) and the National Institutes of Technology (NITs). The workshops were aimed at bringing AUP’s flagship Lab-in-a-Box (LiB) on the ARM Cortex-M0+ based Freedom board from Freescale to faculty, students and researchers, targeting the area of Microprocessors and Microcontrollers and Embedded Systems in a university curriculum. An LiB of this type consists of 10 x Freedom boards donated by Freescale, 100 x licenses of Keil MDK Pro microcontroller software development tool donated by ARM and a full suite of teaching materials developed and donated by AUP. Participating faculty showed significant interest in the full suite of teaching materials around the ARM Cortex-M0+ based Freedom board which includes lecture notes and slides, exercises with solutions, lab manuals with solutions, sample pieces of code, projects with solutions, and even sample exam papers with solutions.

                                                                                          

Professor Dasiga of Nitte Meenakshi Institute of Technology (NMIT) Delivering Workshop

 

The workshops started off with an introduction to the ARM Cortex-M0+ architecture followed by hands-on lab sessions. Operating at near-single-digit µA current levels and selling at a student-affordable list price of 762 INR (9 GBP or 13 USD) at element14 India, the Freedom board is the perfect piece of lab hardware for students interested in the up and coming areas of study and research, such as sensor motes for wireless-sensor networks (WSNs) and wearable computing. The lab sessions used the onboard tricolor (RGB) LED and the onboard 3-axis accelerometer extensively, demonstrating the board’s considerable standalone utility. The on-board connectors compatible with off-the-shelf Arduino shields captured the imagination of those enquiring about ways to expand the board’s capabilities in a neat and compact way. Last, but not least, the participants appreciated the board’s mbed interface for providing them with a unique capability to rapidly prototype complex projects using the same Freedom board.

 

Flashing RGB LED
Hello World on LCD

                                                                             

The lab sessions started with an introductory lab in which participants learnt how to enable the board with firmware to be able to program the on-board flash and perform runtime debug using the Keil software-development tool. The following labs were engineered to impart the elements of programming microcontroller peripherals using their memory-mapped registers including GPIO, analog IO, PWM and I2C to name a few. These included a spirit-level simulator using the on-board accelerometer to detect changes in the position of the board and a bubble on an LCD peripheral as well as a lab demonstrating various power modes available in the Cortex-M0+ based microcontroller by configuring the microcontroller in various sleep modes, disabling parts of the board’s circuitry not relevant to the microcontroller’s operation.

Spirit-level Simulator - Balanced
Spirit-level Simulator - Left Tilted
Spirit-level Simulator - Right Tilted

                                                                   

The workshops ended each day with a message of continuity with each participant being given a Freedom board and a full box of accessories, such as a breadboard, resistors, IR diode, IR phototransistor, 2x16 LCD and jumper wires, to enable the participants to carry their experiences into their teaching roles.

I'll be posting on my wall some conclusions and studies I have done based on the readings for my AAME.

 

Today I studied a bit about ARM exception and behavior especially in Cortex-M0, the interesting thing is that there is not much to optimize the Assembly, the registers R0 to R3, R12 and R14, XPSR and PC are automatically stored in the Stack current, leaving only the need to reserve the remaining registers if this were to be used.

 

Stacking and unstacking besides, there are two interesting features in dealing with exceptions:

 

"Tail Chaining" where an exception is called right after the other when the same level / priority, without having to make the "stacking" and "unstacking" right now, just finished the first Exception, returning the EXC_RETURN value for LR, without being interfered with registers mentioned above, and then the next interrupt will already be ready to be handled by the Exception / interruption Handler.

 

The other feature is the "Late Arrival" where an exception occurs and then immediately Stacking occur during other higher priority, the process continues until terminated Stacking store registers, cited above, the Stack, then the second highest priority exception is called, to be terminated as standard (EXC_RETURN returning to LR) then the first exception occurs normally.

Embedded systems that include hardware that can change as you go (SoC FPGA anyone?), present a moving target during product development. Engineers will likely want the debug setup to adapt to hardware changes. While it may be workable to let the software team debug the processor core, (with their own debug cable, debug tool and debug flow), while the hardware team separately debugs the FPGA hardware, (with their own debug cable, debug tool and debug flow), what happens during software hardware integration testing?

 

A software debug view that automatically adapts to changes in the FPGA could prove handy at this point. The last thing you want is for the software team to have to learn the hardware design tools. So don't make them. View these videos to learn more about how adaptive SoC FPGA development tools can make a huge difference in getting through the system bring-up and debug phases.

 

Architecture Matters: Whole Chip SoC FPGA Debug

(make sure to go to the 'Tools' tab if the link doesn't take you there automatically)

Architecture Matters: Whole Chip SoC FPGA Debug

I started a couple of weeks ago, when I received an email from Sandeep Vasant from Ahmedabad University in India. For reasons that he has yet to reveal, he was having trouble with some code like this:

int a=10, b=20, c=0; c = a++ + a++ + b++ + b++ + ++a + ++b; 

He tried this with one compiler and the resulting values of a, b and c were 13, 23 and 96 respectively. He was satisfied with this result. Then he tried a different compiler, which yielded a final value for c of 98, which he found confusing.

I started looking into this, certain that the explanation was simple …

As I work for a company that sell embedded software development tools, I have a natural interest in programming languages and their quirks – even if the code is not specifically embedded. I believe that embedded developers are often more interested in what is going on “behind the scenes” than their desktop computer software development counterparts.

My first thought was that, although the precedence of the +and ++ operators is clear and the functionality of the pre-increment and post-increment versions of ++ is unambiguous, the order of evaluation of the the operators is not defined. Maybe they are evaluated left to right or perhaps right to left. So, instead of using a compiler, I decided to work it out by hand. Going left to right, I got 10 + 11 + 20 + 21 + 13 + 23 = 98; going the other way, I got 21 + 11 + 21 + 22 + 11 + 12 = 98. So it made no difference. In both cases I got the result that Sandeep had been confused by.

Now it was time to try a compiler [I used CodePad]. I wrote this:

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

undefinedbehavior.png

Software start-ups will dominate growth in the Internet-of-Things (IoT) as demonstrated by MindRDR’s application that combines Google Glass and Neurosky biosensor hardware.

The idea is simple enough. You see something that you’d like to capture with a camera. But rather than reach for your smartphone or tap the side of your smart glasses, you merely concentrate on the image that you want to capture. The sci-fi prediction of using your mind to operate smart electronics is here! More significantly, this application confirms a major trend in electronics and IoT growth.

In a recent interview, Zach Shelby Shelby, Director of Technology at ARM, explained that 80% of the value of the #IoT will come from software applications, while the remaining 20% of value will be split between the devices, the network, and the middleware. The analyst firm of Gartner put it this way: “Half of this activity will be new start-ups and 80 percent will be in services rather than in products.”]

The fact that a sizeable portion of hardware has become a commodity is nothing new – unless it’s unique hardware such as Google Glass or the Neurosky biosensor headset (more on that shortly). But a related observation from Gartner is that, “by 2018, 50% of IoT solutions will be from start-ups less than three years old.” In other words, start-ups that don’t exist today will represent 50% of the market in just three years!

InUse2.png

One such start-up may well be a company called MindRDR that has created a software application to control Google Glass with your thoughts. The application connects Google Glass with a device like Neurosky’s biosensor technology to monitor brain activity. One use of this application would be to allow users to take pictures and post them on Twitter or Facebook without the need for any physical interaction. In the medical field, this technology could be used to bring mobility to quadriplegics, suffers of multiple sclerosis, and  other debilitating diseases.

According to the company, the user experience for taking mind-controlled pictures is centered on one’s ability to briefly focus on the task. The MindRDR application appears as a line on the bottom of the Glass’s display. As the user concentrates, the line moves up to the top, at which point it snaps the picture that the user is viewing. The captured picture is then uploaded to a social network by following a similar process.

MindRDR has chosen to freely offer their application on GitHub to encourage new applications by other developers.

It doesn't take a mind reader or though control to realize that the next few years will see the rise of new and innovative application software. These will be exciting times!

Regular users of PSoC Creator probably already know about our useful Document Manager tool. We added this utility a couple of years ago and many users commented that it was really great for finding information and keeping tabs on your go-to PSoC documents. So we have taken the product to a new level.

This week we released a completely new version of the tool that supports all of the Cypress product lines. The search is much improved with filters for product, application, document type, and language (as well having access to a LOT more documents – over 60,000!). You can download local copies of web-based documents for off-line access. And you needn’t worry about them going out of date because the tool can check for updates at the press of a single button. And if this is not enough to find the information you want, there is a simple keyword Internet search.

Here is a screen shot of our fancy new GUI. You can see that we have 231 documents that match the keyword ARM in PSoC categories!

ARM_CDM_Capture.png

The Cypress Document Manager is available for download today and will also be distributed with the next release of PSoC Creator.

I often need to do a bit of programming – normally C or C++. I am not generally writing a real software application, as that is not my job, but I often need to produce chunks of code to illustrate a point in an article, presentation or blog post. This code can be anything from a single line to a few dozen. Obviously, all I need to do is create a text file for the code and build it using a suitable toolchain for execution on my PC or for inspection of the resulting assembly language output.


Recently, I was introduced to an interesting alternative …

 

Since I work for a company that supplies embedded software development tools, I have no shortage of compilers etc. And, of course, I will make use of these when the need arises. The problem is that I am intrinsically lazy and, if there are a just a few lines of code, I may not bother building/testing it. I just type the code into the article/slide/blog and hope that I have made no errors [or that, if there are, nobody will notice]. I am reasonably confident with C/C++ syntax, so I get away with this most of the time. However, I am not not totally immune to guilt and, particularly with electronic media, I would like to be 100% confident that I am providing my readers with [at least] syntactically correct code.

Just recently, my colleague Jon Roelofs drew my attention to a really interesting online tool: codepad.


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


codepad.png

Google's Project Ara, the so-called "Lego" smartphone architecture unveiled in April, means intriguing new design options and opportunity for IP providers in the near term and raises profound questions for open-source hardware in the long term.

 

If you missed the buzz, here's some background: Project Ara, which was initiated at Motorola Mobility, uses the MIPI Alliance UniPro and M-PHY protocols as the backbone for a modular electronics architecture inside a smartphone "endoskeleton." Using electro permanent magnets (they don't need a permanent charge to keep the bond), designers and consumers can affix various functional modules to build a customized smartphone--say one with special radios or more powerful imagers or other sensors.

 

Google Project Ara modules displayed

"Designs will have to be done modularly to work with the endoskeleton of the phone," said Arif Khan, product marketing director with Cadence. "Modules will need to play nice with each other, but if you can get it to work, the ideas and opportunities could be limitless."

 

MIPI UniPro is a multilayer protocol designed to enable the tunneling of multiple communications protocols within the system. Layer 1/1.5 include the M-PHY and PHY adapter; Layer 2, the data link layer for error correction, among other features; Layer 3 includes ID-based switching; Layer 4 is the transport layer interface to the application.

 

UniPro's Unique Opportunity

David Rutledge, chief technologist at Lattice whose FPGAs are being leveraged in the Project Ara Mobile Development Kit, as--among other things--the low-power programmable interface for UniPro, said:

 

"Project ARA is using (Lattice FPGAs) exactly as intended: high-speed communications of multiple protocols in an extremely low-power device. Ara is a good application of the technology, and it's exactly why UniPro was built. I think this is a major endorsement of the UniPro standard."

 

Khan said that for semiconductor makers, Project Ara will be about building chips that will be low power and work over the endoskeleton using the MIPI M-PHY and UniPro stack to communicate. At the same time, there is still the challenge of adapting the UniPort (UniPro + M-PHY) to be used with the adapter/connectors. However, beyond the use of UniPro for just the UFS and CSI-3 protocols, this is a great statement of the intended use for UniPro - a unified protocol bus, he added.

 

"Chip designers will need to understand the implications of using UniPro for system connectivity," he said. "As this is not widely used as yet, there will be a learning curve."

 

Some UniPro resources include:

 

Project Ara also raises intriguing design questions both near and long term.


Expanding IP Opportunity

On the IP front, it likely means renewed interest in MIPI and other IP, soft and hard, Khan said. If the module market takes off, the number of design starts will rise, potentially leading to increased IP consumption. "IP makers will renew their commitment to the mobile chip space with increased emphasis on low-power designs and technology," he added.

 

On the hardware front, consider the role of either an FPGA or an ASIC as part of the design. Paul Eremenko, head of Project Ara, who spoke at the developers conference April 15, described two variants his team examined, one design FPGA-based, the other ASIC-based.

 

Using the Motorola RAZR MAXX HD as a baseline, Eremenko showed FPGA and ASICs variants that were larger in size, weight, and power consumption:

             

 

Size

Weight

Power

Moto. RAZR MAXX

83.29cc

157g

1.5W

FPGA Var.

97.32cc

205.69g

2.4W

ASIC Var.

105.23cc

200.72g

1.9W

 

"Taking that (design) to a custom variant, with custom ASICs, we can shrink the modularity penalty down to about a quarter of the size, weight, and power consumption as compared to a traditional tightly integrated device," Eremenko said.

 

Lattice's Rutledge, however, sees plenty of opportunity for makers of small-size, low-power FPGAs since each module contains a standard interface to the backplane:

 

"On one side is MIPI UniPro. On the other side is the module developer's playground. Who knows what they're going to want to do? It's a perfect place to allow people to innovate. It's an ideal opportunity for FPGAs."


Long-Term Implications

One of the most intriguing questions surrounding Project Ara is the notion of open hardware architectures, applied on a broader scale. Open hardware to date has largely been confined to the "Maker" market through platforms such as Arduino and Raspberry Pi.

 

Khan sees potential but also challenges:

 

"Open hardware implies that there is no phone maker per se but an endoskeleton maker and module makers. This might seem interesting, but system compatibility challenges remain. One of the issues in the Android world is the fragmentation of the OS and customization done to it by various OEMs."

 

He added that in an open hardware platform, engineers are going to have to consider module compatibility with the other devices throughout system and OS upgrades:

 

"Anyone who has run into device driver issues after OS upgrades on a Windows system will know how challenging that is. This may make the phone brand meaningless per se, but it's more than likely that a single phone maker may build an endoskeleton and a line of modules that are optimized to run with it."


Module Movement

The longer term implications of such an open hardware platform could be significant. Imagine, for example, the modularity philosophy ported to design in the Internet of Things or automotive design and so forth.

 

Lattice's Rutledge said we're seeing it already. A device teardown may identify a number of ICs in a given smartphone, but they're really modules, he said.

 

"They're pre-built systems in an SIP that provide dedicated functionality--WiFi, antenna management, or touchscreen management modules. People don't recognize that," he said.

 

"The module ecosystem is developing like the IP ecosystem, and over time different standards will evolve," Rutledge added.

 

Motorola's Project Ara allow people to build them own phone. Do you think it is a good idea?

 

Related stories:

--MIPI Protocols-Making Mobile Happen at MWC

-- Cadence Announces Verification IP for MIPI SoundWireTM and C-PHY

-- Whiteboard Wednesdays - How the MIPI Alliance Works to Enhance Mobile Devices

-- Mobile World Congress: It's (Almost) All About IP

Filter Blog

By date:
By tag: