1 2 3 Previous Next

Embedded

315 posts

The KickStarter campaign for the RPiSoC is about to end. If you're interested in the board go take a look at some of the videos and pledge a few bucks to get one.

RPiSoC is made by Embedit Electronics. It's a nifty, Cypress PSoC 5LP-based board that gives you easy access to lots of I/Os and is compatible with Arduino and Raspberry Pi. Hop over to the their KickStarter page to see some videos on cool things the inventors, Robert Barron and Brian Bradley, have already done with it. As far as I can tell, they give away all the source code for their projects so you can modify what they have done to your heart's content.

 

This weekend they were at the Maker Faire in New York, where they received a Maker Faire editors choice award! This is a really nice platform for PSoC development that is so much more than the hardware. Embedit have added support for Python and Scratch, and the board is pre-programmed with some seriously powerful analog functions than you will never find on other board like this.

makerfaire2.jpg

Did I mention that you can sponsor them on KickStarter?

 

[Re-posted from Cypress Developer Community]

AN89610.pngI’ve been writing about memory optimization for a few weeks now, both here and on the Cypress developer community site. In all those posts I (hopefully) provide a useful tidbit of information but it’s not a forum for all the details, options and consequences of a given technique.

 

Some colleagues of mine published an Application Note discussing PSoC 4 and PSoC 5LP ARM Cortex Code Optimization and it is a fantastic resource for engineers looking to become proficient at writing embedded application on ARM devices, like PSoC.

 

Unlike my posts it covers performance optimization as well as code size concerns. It explains some good coding habits that ensure you get the results you want and really delves into the linker script options for both GNU compilers and the ARM MDK.

 

 

PSoC 5LP users should particularly benefit from the sections on bit-banding (which is only available on Cortex-M3) and Cypress DMA. There is also a great section on embedding assembler instructions and using compiler intrinsic for things like the Cortex-M3 saturation functions.

I could go on and on. I’ve been in embedded software for more years than I care to admit, and this document definitely clarified a couple of things for me. I highly recommend giving it a read. And keep it handy as a reference for when you need to get a little more from your toolchain.

About a week ago I wrote about how we try to respond to user feedback at Cypress. As a result of one such interaction we discovered that, with debugging enabled, the v4.8 GNU ARM compiler optimizes for code space far more efficiently than the prior versions. We’ll be updating the compiler in our next release.

 

Another thing that came out of our tests was that there is a new command-line flag, “-Og”. This flag turns on debugger-friendly optimizations so that the code size can be compressed even closer to the fully-optimized value, while still allowing the use of the debugger (debugging fully optimized code is worse than listening to Coldplay – believe me, it's really painful!). Re-running last week’s tests, I found that the new option brought the code size down from 36710 to just 23798 bytes, which is pretty close to the best case (all optimization enabled) of 21534! The work being done on Launchpad for this compiler toolchain is really yielding good results right now!

 

We’ll be starting an “early access” program for PSoC Creator 3.1 in a few days. You will be able to get a sneak peak at the new software a couple of months before it goes on general release. The main change is actually support for new PSoC devices (I’ll post more on those soon) but the new GNU ARM compiler is included and we’d love to hear from you about that.

 

The default GNU compiler remains v4.7 but you can choose the new one from the Build Settings (shown) and re-build to see the code size savings (note that this improvement is in the DEBUG mode, with most optimizations disabled). If you like the results you can also add the –Og flag and get even better code compression. And you will still be able to debug!

 

Please give this a try and let us know how you get on. I watch for comments here and you can email us directly on psoc_creator_feedback@cypress.com. Let us know what you think – good or bad – it all helps to make our software better.

It's that time again! It's what you've been waiting for all week (just kidding, I know better than that). This 'Friday Finding' isn't finger friendly, it's all thumbs! This week's question hails from the ARM Connected Community: Difference between thumb machine directives by techguyz. The question is:

 

"What is the key difference between the following directives

 

.thumb

.thumb_func

.force_thumb

.thumb_set

 

What is the exact use case where the above things can to be applied ?"

 

Let's take these one at a time:

 

1) .thumb

This directive is important when you want to tell the assembler to interpret instructions as Thumb (16-bit) as opposed to the 32-bit ARM instructions. This can also be done with the directive ".code 16" and is the same as a Thumb directive at the start of your source file. It is important for you to include either this directive or ".arm" / ".code 32" at the time of a branch or return: the processor doesn't automatically know which instruction set is used after a procedure call, a procedure return, or after a branch so it needs to be told ahead of time.


2) .thumb_func

The ".thumb_func" directive specifies that the following function is Thumb encoded and implies a ".thumb" directive. This declaration is necessary for the processor to allow the assembler and linker to generate correct code for inter-communication between Arm and Thumb instructions. Even if inter-working is not going to be performed for that particular case it should still be included or else you will have to set the least significant bit before branching which will add more code.


3) .force_thumb

The .force_thumb directive forces the processor to select of Thumb instructions regardless if the processor does not support thumb instructions. A use-case of this function is to switch the code to correct instruction set before a procedure return.


4) .thumb_set

The .thumb_set is the equivalent of calling the .set directive since it creates an alias symbol for another symbol. It also marks that alias as a thumb function in a similar way as the directive ".thumb_func". A good use of this directive is to provide weak aliases for exception handler to the default handler so any function with the exception name will override the default.


Example:

.weak SysTick_Handler

.thumb_set SysTick_Handler, Default_Handler


Sources:

https://www.sourceware.org/binutils/docs-2.12/as.info/ARM-Directives.html

ARM Information Center

assembly - When are ELF directives needed? - Stack Overflow


Read my past 'Intern Inquiry' posts intern_inquiry

I have written before about multicore systems – here for example – and looked at AMP vs SMP and various other aspects of the technology. As the use of multicore designs has become increasingly mainstream, the options and possible configurations available has increased drastically.

A particular facet is the incorporation of a hypervisor in an AMP system …

All embedded systems have finite resources, which need to be managed. It may be argued that this is the crux of what embedded software development is all about. For the purposes of this discussion, I want to consider a hypothetical example system which has a single serial port. There are various ways that this port may be managed, depending on the configuration of software and CPU hardware.

On a single core system, the operating system can manage access to the serial port and arbitrate between multiple tasks that might wish to make use of it. There are lots of ways that this might be achieved and this is a well trodden path.

If the system has multiple, identical cores, it might be useful to configure it as SMP – a single operating system instance running across all the cores. SMP versions of many RTOS products [like Nucleus] are available and Linux with SMP support is also an option. This approach is ideal if the application benefits from the OS being able to distribute CPU power as needed. The OS can manage access to the serial port in much the same way as on a single core system.

On many systems SMP is unattractive, because more precise control is required or the system has so many cores that performance degradation is likely. On others, SMP is impossible, because the cores are not identical. In these cases, an AMP configuration, with a separate OS instance on each core, makes sense. This presents a challenge: how might the single serial port be managed?

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

ScreenClip-520x309.png

A few years ago I was working as an embedded systems contractor for a small company that made chemical analyzers. The code was written in PALASM and involved a bunch of timers and if/then statements that controlled an autosampler(a rotating tray of test tubes with a needle that would lower to extract a sample, lift, and then move over to dispense the sample into an analyzer).  I remember thinking to myself how the same instructions were being used over and over again with increasingly cryptic numbers. What did all these numbers actually refer to in the context of this hardware?(job security)

 

A few years later, I started playing around with Arduino/Energia on embedded platforms and realized that all those cryptic numbers had been abstracted to describe the behavior of specific pins on a micro-controller. With these abstractions, what had previously taken me a week to understand could be understood(and modified) in a few hours!  I realized that these abstractions could enable anyone with a computer to become an embedded systems developer.  I decided to virtualize these abstractions over a wireless connection to a smartphone in an open source project "rekam1" - mirrorwrite(rekam1);  Come check out my talk: "The Consumer Programmable IOT" to see where I believe we're going with Cortex-M wireless embedded system development and how the maker community could change the way we all write and share embedded systems code.  If you're at the World Maker Faire in NYC this weekend, drop me a note to see a demo!

Carissa Labriola

Intern Inquiry 9/12

Posted by Carissa Labriola Sep 12, 2014

It's Friday findings time again! This week I decided to focus on a question from the Connected Community: Question about RTOS debugging with MDK-ARM and STM32CubeF4.

 

"Hi, All

 

I'm working on following environment.

     Tool chain: Keil MDK-ARM 5

     Device/Board :STM32F429NI / STM32429I-EVAL1

     Code generator:STM32CubeMX

     RTOS:FreeRTOS wrapped by CMSIS RTOS

     Debug Trace Unit:ULINK Pro

     Debug Interface:+ETM, SW port(SWJ)

     Trace:Sync Trace Port 1-bit Data, Trace Enabled, ETM Trace Enabled, ITM port 0 and 31 enabled

 

I can use following Keil's debug tool.

     Debug (printf) Viewer

     Performance Analyzer

     Watch

     Memory window

 

But, I can't use Keil's Event Viewer.

 

Please help me."

 

The problem with this particular feature is the use of FreeRTOS. The debug viewer is based on printf for its output (Debug (printf) Viewer), the performance analyzer is based on the execution of functions (Keil µVision Debugger), watch evaluates your registers (µVision Watch Window) and the memory window is evaluating the memory (µVision Memory Window). I say this because they all have one thing in common: they are not dependent on your choice of RTOS. Then there is the Keil Event Viewer, which is written specifically for ARM's RTX RTOS (http://www.keil.com/download/files/sam3x_ek_lab.pdf section 15). It is not made for the FreeRTOS kernels and why you won't see them work together. FreeRTOS instead extended a plug-in to use the Logic Analyzer to display their kernel information (FreeRTOS extends support for Keil MDK). It will give you the same data just in a slightly different format. Also you should use Trace Port 4-bit Data since the Keil Performance Analyzer is derived from the ETM instruction trace. You will get more information passed with 4-bits than 1-bit.

Recently, a new kind of transparent solar panels have been developed.

Imagine what that could do for your ARM-based gadget.

Now it's no longer a question if there's a touch-panel display on your device.

The question is: Does it have a built-in solar panel ?

 

Tablets and phones would be self-charging when they're laying in the kitchen window.

-The tablet might be charging while you're using it.

 

So what are you going to use this transparent solar panel for ?

Will you be combining it with holographic projections as well ?

carlosfm

Tricopter on a LPC1758

Posted by carlosfm Sep 12, 2014

Code name Cerberus

 

CmpE146 s14 tricopter Cerberus-Blake.jpeg

 

Abstract

The goal of this project is to produce a stable hovering tricopter. This craft will hover using three motors with three propellers, one of which is mounted on a swivelling piece that allows the raft to have more yaw control. The plan for this project is to use COTS parts for all but the flight controller which will be our software on an SJ One Board (NXP LPC1758 - ARM Cortex-M3). The flight controller is responsible for determining how fast each motor spins and the angle of the swivelling motor using inputted data from an accelerometer, a gyroscope, and possibly a magnetometer. The tricopter will elevate itself to a fixed height and using a barometer will stay stabilized at this height.


Introduction

 

Fig 1.Orientation

 

Multrirotor unmanned arial vehicles (UAV), have recently grown in popularity due to the reduced cost in parts. A highly agile variation of these multirotor copters are the tricopters. Tricopters apply equivalent principles of balance and orientation to that of traditional multirotors. Unlike symmetrical multirotors, tricopters require an additional servo to counteract yaw. Roll is controlled exclusively by the front left and right motors, where pitch is adjusted through a combination of all three.

Objectives

 

The objective of this project is to produce a Tricopter capable of rising to a given altitude, hovering in one position for at least 15 seconds, and then landing safely in the same position it took off from.

 

Maintaining stable flight is the key requirement for this project. Orientation is calculated using an accelerometer and gyroscope. The height above ground is determined using the output of an ultrasonic sensor.

 

Team Members & Responsibilities

  •   Carlos Fernandez-Martinez
  •   Shane Loretz
  •   Michael Schneider

Schedule

Week#DateTaskActual
13/21Create scheduleDelayed due to wiki-login issues
23/28Build Tricopter frame, establish PWM communicationCompleted, PWM driver had to be replaced
34/4Establish connection with IMU, create an orientation taskCompleted, no issues encountered
44/11Complete the wiring of the frame, build power regulator for 5vCompleted, regulator circuit unneeded, ESCs provide adequate power
54/18Integrate motor control task with orientation taskCompleted, no issues encountered
64/25Balancing and orientation testIn progress


Parts List & Cost

NameQuantityPrice
Turnigy Park480  3$61.47
Hobby King 30A ESC  3$30.45
Corona 919MG Servo  1$7.01
Sunkee 10DOF  1$20.00
Hobbyking X900  1$32.16
Prop 9047  3$9.48
Truningy 5800mah  1$27.85
Cables / Connectors  N/A$20.00
SJSU One Board  1$80.00
Total$292.00


Design & Implementation

Hardware Design

 

Construction

All components were attached to the tricopter frame. The SJ One board and Sunkee 10DOF board were both bolted to the center section of the frame. The frame was lacking a mounting point for the ultrasonic sensor, so it was taped on.

 

All three motors were attached to the frame with a motor mount and two screws. The servo was mounted at a dedicated servo mount point provided on the frame. The motor speed controllers were attached with zip ties, due to a lack of good mounting options both on the frame and on the speed controllers themselves. Wires for PWM control and power were routed along the tricopter arms, and also attached with zip ties.

 

Fig 2.Motor Attachment

 

Fig 3.Built Frame

 

Interfaces


 

Fig 4.System Wiring

 

IMU

 

Fig 5. IMU mounted upside down on Tricopter


The Inertial Measurement Unit (IMU) we used is the SUNKEE 10DOF. It has an Accelerometer, Gyroscope, and Barometer accessible via an I2C bus. For our project we only used the Accelerometer and the Gyroscope. I2C uses only two signals: data and clock. We used I2C port 2 on the SJOne board to interface with the IMU.

 

The IMU is mounted upside down on a perforated prototyping board. Cables connect 3.3V power, ground, data, and clock lines to the IMU. The 3.3V supply pin on the SJOne board was used to power the IMU for sake of convenience.

 

Ultrasonic Sensor

 

Fig 6. Ultrasonic Sensor


Originally, height for the tricopter was to be determined using the Z-axis of the accelermoter. However, this method proved inaccurate. A HC-SR04 Ultrasonic sensor was chosen to determine the height. Height was determined by measuring the time delta from the echo's rising edge to the falling edge. To ensure accuracy in a multi-threaded environment, hardware timers and interrupts were used to track this timing interval. Time was kept by marking a timer register on the rise of every system clock edge. Once timing was captured it was converted from system clicks to seconds using the formula:

                                                   read_height = ((.120 * total) / 148); 
Motors/Servo

 

Fig 7. PWM signals sent to servo and ESCs

 

 

Fig 8.ESC Wiring

 

The motors are controlled using electronic speed controllers (ESC). The motors themselves are brush-less out-runner motors. The ESCs are controlled using the servo motor PWM interface. This interface expects a high pulse every 20 milliseconds. The width of this pulse dictates the motor speed. When the pulse is 1ms wide, the ESC interprets this as throttle of 0%. When the pulse is 2ms wide the ESC interprets this as a throttle of 100%.

 

The ESCs will not start running until the throttle position is set to 0% until the ESC stop its start up beeping routine. This is a safety feature that prevents the motor from spinning up unexpectedly. Our software sets the throttle position to 0% when it boots, and it holds this position for 5 seconds before spinning up the motors. This is enough time for the ESCs to complete their start up beep sequence.

 

The servo motor takes the same PWM signal. A pulse width of 1ms tells the servo to be rotated fully one direction, and a pulse width of 2ms has it rotated fully the opposite direction. Our software sets this signal to 46% at boot, which we determined was the most level position.


Software Design


Orientation


 

Fig 9. Sunkee 10dof

 

The orientation is calculated with a combination of the accelerometer and gyroscope readings.

 

Orientation is expressed in radians from a level position

X (roll)Y (pitch)Z (yaw)
PositiveRolled leftPitched downYawed counter clock wise
NegativeRolled rightPitched upYawed clock wise

 

Angular velocity is specified in radians per second

X (roll)Y (pitch)Z (yaw)
PositiveRolling leftPitching upYawing counter clock wise
NegativeRolling rightPitching downYawing clock wise

Accelerometer

The accelerometer readings give the instantaneous acceleration. When the accelerometer is not moving, the only acceleration comes from gravity. If the device is flat, the entire gravitational acceleration is in the vertical (Z) component of acceleration, as shown on the left:

 

Fig 10. Flat acceleration

The accelerometer reading in this instance would be <0g, 0g, 1g>, where g ~= 9.8m/s^2. However, if the accelerometer is not flat, the gravitational acceleration splits into both horizontal and vertical components, as shown on the right:

 

Fig 11. Tilted acceleration

With simple trigonometry, the angle that the accelerometer is at can be calculated using these two components and an inverse tangent function:

 

146 s14 tricopter accel angle calc.png

 

 

Gyroscope

The gyroscope readings give the angular velocity. To calculate an angle, these readings can be integrated:

 

146 s14 tricopter angle calculation.png

 

However, these readings are subject to "drift", where they do not return back to 0 due to small errors in the integration process.


Orientation Calculation

The solution to both of the accelerometer and gyroscope shortcomings is to filter and combine them. The accelerometer data can be trusted in the long term, since it is accurate when the craft is stable. Therefore the accelerometer data is low pass filtered. The gyroscope data can be trusted in the short term, since it is accurate when the craft is moving. Therefore, the gyroscope data is high pass filtered. The two are then combined to produce a fairly accurate orientation value.

 

146 s14 tricopter orientation x formula.png

 

 

146 s14 tricopter orientation y formula.png

 

 


The accelerometer cannot give any acceleration data for the Z (yaw) axis, so the orientation is only calculated using the integral of the gyroscope data. In testing, this proved to be accurate enough for our uses since the craft does not yaw significantly.

 

146 s14 tricopter orientation z calculation.png

 

Motor Control


Motor speeds are increased and decreased to get back to an orientation of (0,0,0) (level flight). The motors are controlled by electronic speed controllers (ESC's). These take a servo PWM signal as input and use the pulse width to control the speed of a 3-wire brush-less motor. The tricopter has three motor/ESC pairs. The tricopter also has a servo which takes the PWM signal directly

 

Motor 1Front left
Motor 2Front right
Motor 3back (with servo)

 

Each motor is controlled by setting a percentage. 0% is the lowest speed, and 100% is the highest speed. Each motor's speed is set by adding a baseMotorPercentage with the motor's specific correction. The base motor percentage is used to set the throttle of the tricopter, while the correction terms are used for balancing. The base motor percentage was intended to be set by the term height_output. This was intended to control how high the tricopter would fly. Unfortunately our balancing algorithm takes too long to stabilize to allow for flight, so when balancing on the stand the base motor percentage is set to a fixed value: 20%;

 

Balancing Algorithm


We came up with many algorithms while working on this project. They can be divided into two families: the first are all algorithms that adjusted motor speeds based only on our current orientation, and the second are all algorithms that adjusted motor speeds based on our angular velocity and our orientation.

Algorithm Type I: Adjusting motor speeds in response to just our orientation
Accumulating motor speed to target orientation

One of the earliest algorithms we tried was extremely simple. It Increased or decreased motor speeds by a fixed amount based on the current orientation. While the craft was rolled right, it would increase the front right motor and decrease the front left motor by a fixed amount. The same was implemented on the pitch axis.

 

This algorithm resulted in a thrashing behavior. One motor would wind up and tilt the craft quickly. While the craft was rolled right, the right motor speed would be increasing quickly. The roll angular velocity would increase until the craft was rolling left, but as long as it was still rolled to the right, the velocity at which it rolled left would continue to increase. This caused it to over shoot the target orientation. This process repeated itself and the tricopter would continue to thrash back and forth.

Fixed motor speed adjustments to maintain orientation

Another algorithm we tried in this family relied on knowing what motor percentages were needed for the craft to hover normally. We tested the tricopter on the ground and adjusted the motor speeds until it just lifted off. We hard coded these values in our algorithm.

 

We used these values in our balancing algorithm as the normal motor speeds. Increasing height was done by increasing the motor speeds by a fixed amount. If the craft was rolled right, the left motor would be decreased by a fixed amount from the hover value and the right motor would be increased by a fixed amount. The same was done on the pitch and yaw axes.

 

This algorithm also did not work. It has some obvious problems. The craft would still overshoot the target orientation because the fixed adjustments were the same at all orientations no matter how great or small. Our hover motor speeds were inaccurate, and didn't account for ground effect.

 

Closer to the ground our motors generate more lift, so the motor speeds are smaller to maintain hovering. The motor speeds also did not differ by a fixed amount. At higher speeds, the difference between motor speeds to maintain level flight was much higher than at lower speeds.

Change motor speeds that scale based on how far off the orientation is

This is an important concept that is used in our final balancing algorithm. Variations of the above algorithms were tried that scaled the corrections to the motor speeds based on how far off the orientation was. When our orientation was just a little off, our corrections would be smaller. This still did not solve the fundamental problem with this family of algorithms. By targeting orientation only, our angular velocity went unchecked. We would still overshoot our target orientation and get an oscillating or thrashing behavior.

Algorithm Type II: Adjusting motor speeds in response to orientation and angular velocity

 

Fig 12. Orientation Coordinate System

This family of algorithms divides balancing into two steps. The first step used current orientation to create target angular velocities, and the second step compared our actual angular velocities to our target angular velocities and adjust the motor speeds until to make them match. Three angular velocities were considered: roll, pitch, and yaw. Our actual velocities come from the gyroscope and are converted to radians per second before they are used. Our target velocities were set depending on our current orientation. We tried different variants just like the Type I algorithms. We tried setting the target angular velocities to fixed values depending on our current orientation. Later we tried setting our target velocities based on the magnitude of our orientation error. This concept is what we stuck with.

 

We tried many different ways of adjusting our motor speed based on our target and actual velocities. They can be divided into the next two groups


Setting motor speeds based on the difference between target and actual angular velocities

We tried setting our motor speeds directly based on the difference between our actual and target velocities. If we were rolled right our target_roll would be set to rolling left at a speed depending on our orientation. While our actual_roll was not rolling left as fast as our target specified, our front right motor correction would be set to a higher value and our front left value would be set to a lower value depending on the magnitude of the error between the actual and target angular velocity.

Increasing and decreasing motors speeds based on angular velocity differences.

The next variant of the Type II algorithms accumulated motor speeds by amounts that depend on the magnitude of the error between the target and actual values. While the actual_roll was less than the target roll, the motor speeds would be incremented by an amount that scaled with the error.

PID control of motor corrections

At this point in the project we decided to look at the source code for ArduCopter for ideas. Looking through the code we discovered that ArduCopter also adjusts motor speeds to target an angular velocity. We discovered that ArduCopter used something called a PID controller to accomplish this. A PID controller is a closed loop controller used to guide industrial processes. It works by adjusting a term based on the magnitude of the current error (P), the accumulation of past errors (I), and the expected future error (D). We modified our project to operate on the same principles as ArduCopter. We implemented a PID controller class and used it to control four axis outputs: roll_output, pitch_output, yaw_output, and height_output.

 

There are four correction terms: frontLeftCorrection, frontRightCorrection, backCenterCorrection, and servoCorrection. These correction values are set according to axis output values.

 

Each output term is the value determined by the PID controller at each motor control step. These values are calculated 50 times per second. The PID controller is fed the target angular velocity, the actual angular velocity, and the time elapsed since the last output calculation. The PID controller uses these values to calculate the next axis output. These are factored into the motor correction terms as shown in the following table.

 

Correction termsEquation
Front Left-roll_output + pitch_output/2
Front Rightroll_output + pitch_output/2
Back Center-pitch_output
Servoyaw_output

 

The height_output is the base motor percentage. All motors are are set to the base motor percentage plus their correction term.


Fail safe


The fail safe kills all power to the motors by sending the lowest throttle position signal to the ESCs

 

The following conditions trigger the fail safe:

  • Orientation roll or pitch tilted beyond configured value
  • Height above configured value
  • Time elapsed since boot longer than configured value

 

The failsafe is disabled while the tricopter is mounted on the stand.

Testing & Technical Challenges

Testing Methodologies

Phase #1

Initial testing of the Tricopter was purely electrical. Being that all the components where purchased individually, custom wiring was needed to interconnect the components. As each component was connected and shrink tubed, continuity tests where performed to ensure no shorts existed. To power the system a variable 17AMP external power supply. By using a power supply in place of a battery back, we were provided the ability to current limit and thus protect the various components.

Phase #2

 

Fig 13.Motor Testing

Following the verification of the electrical components, rudimentary flight and motor control tests began. During this phase no propellers were attached to the motors due to safety concerns. The main objective was to fully comprehend the correlation between motor speed and pulse width percentage. It was during this phase that the team encountered issues with the included PWM class. The issue and solution are documented in Issue #1, below. Once PWM had been calibrated to function properly, motor speed was configured to be controlled by the SJSUone Board accelerometer.

Phase #3

Following the integration the Sunke10dof IMU, elementary fight tests began. To ensure a safe testing environment the tricopter was tied down to weights. This approach allowed for testing of the full range of motion, while preventing the tricopter from flying out of control. This method in the end proved ineffective as it only accommodated short testing periods. Footage from this can be found here.


Phase #4

 

Fig 14.Testing Rig


After various days of testing utilizing a tied down approach, ultimately making minimal progress, the team decided to switch a more flexible solution. A testing apparatus was devised using a ball bearing and a metal tower to allow prolonged testing of the tricopter. After a short period of testing, the team discovered a flaw in the approach we had used for balancing. Once the flaw had been rectified the tricopter began to self balance on the testing apparatus.

 

 

Issue #1

The first issue encountered was related to interfacing the ESCs with the SJSU-ONE PWM driver. The PWM driver would provide a pulse-width of 5ms, thus exceeding the required 1-2ms range. To resolve this issue, the team wrote a new driver in order to preserve the 1-2ms pulse-width range.

 

The new driver largely mimicked the provided one, however the calculation for the pulse-width was modified to:

                         pulseWidth = sys_get_cpu_clock() * ( (percent/100 * (MAX_PULSE - MIN_PULSE) ) + MIN_PULSE ); 

Issue #2

As a result of being a low end device, the Sunkee 10DOF IMU proved to be susceptible to the vibrations from the motor. This susceptibility lead to erratic measurements. To resolve this issue the motors and IMU were placed on rubber mounts. This aided in reducing the erratic measurements, however due to the severe vibrations induced by the motors additional software filtering was needed. Both the gyroscope and accelerometer data where placed through a rudimentary low-pass software filter. To further counteract system noise, an average of the calculated orientation value is computed prior to being sent to the balancing algorithm.


Conclusion

Although the project ultimately did not achieve its goal of stable hovering, a large amount of information and concepts were learned in the process of building and testing the tricopter.

 

The initial testing and development of our sensor drivers and orientation function taught and/or reinforced the following concepts:

  • I2C bus
  • PWM control of motors and servos
  • Driver development for ARM processor peripheral hardware
  • Accelerometer and gyroscope sensors
  • Basic calculus, trigonometry, and physics (for orientation calculation)

 

The second phase of testing and developing the balancing function and integrating it with the orientation function taught and/or reinforced the following concepts:

  • Real time operating systems concepts, including tasks and queues
  • FreeRTOS API
  • PID controllers
  • Flight dynamics, including the ground effect and induced yaw


Project Source Code

carlosfm1989/Tricopter at ang_vel · GitHub

 

Team Members:

Ehten Shane

Micheal Schneider

Carlos Fernandez-Martinez

References

References Used

Hyperintelligent NFC Locker of the Future

Abstract

The team's idea behind the Hyperintelligent NFC Locker of the Future was to reinvent the currently outdated system of rental lockers. Current rental lockers require a user to input money to release a key and lock the locker. Then, when the user is done with the locker, they use the key to unlock the locker and the key is now stuck there for the next user. The Hyperintelligent NFC Locker of the Future is modernizing this process by using NFC technology from a user's smartphone as the "key" holder.

Objectives & Introduction

Objectives

The objectives of the Hyperintelligent NFC Locker of the Future include:

  1. Constructing a fully functional locker system
  2. Interfacing NFC with the locker system
  3. Allowing our phones to lock or unlock the locker

Introduction

A user of the Hyperintelligent NFC Locker of the Future will walk up to a locker not being used and request a key by placing his/her phone on the NFC module. The key will save to the phone application. After receiving the key, the user can now lock the locker by issuing a lock command with the phone application and saved key. After unlocking the locker, the key will now be erased so the user can't use the lock again unless they go through the process again.

Team Members & Responsibilities

  • Devin Villarosa
    • Driver Development, System Architecture, Project Manager
  • Hien Nguyen
    • Locker Construction, Mobile Application Development
  • Gregory Pace
    • FreeRTOS Software Design, Networking

Schedule

Week#TaskProjected Completion DateActual Completion DateStatusNotes
1Order Parts3/213/21CompletedSome changes to the designs were made and extra parts were ordered after the initial date.
2NFC Module3/28IncompleteDocumentation was limited and getting started on the code was difficult
3Locker Application4/44/18CompletedConstructing the locker was fairly quick and simple. However, figuring out how to attach our locking mechanism and place our components in the box took longer than expected.
4Android Smartphone Application4/115/16CompleteA lot of documentation on NFC applications is provided by Android.
5Communication Between Phone and Locker4/18IncompletePhone was able to detect PN532 Module, but was unable to send or receive application data from it.
6Implementing a Two Locker System4/25IncompleteActual completion date was pushed back to do difficulties of finishing the NFC module component. Can not be completed without completion of NFC.
7Reserved to Catch Up5/2IncompleteUsed time to figure out how to get NFC module to work. Corrected major errors in NFC code. Full packets finally received from PN532.
8Reserved to Catch Up NFC5/9IncompleteResearch NFC-DEP protocol to understand information from PN532.
9Final Tests and Aesthetics, Continue on NFC5/16IncompleteResearch NFC LLCP, attempted to write code to handle NFC LLCP processing on SJ-One Board.

Parts List & Cost

QuantityPartPrice Per Unit
1(3)SJ One Board$80
2(1)1 in. x 12 in. x 8 ft. Select Pine Board$33.46
3(2)ITEAD PN532 NFC MODULE$17.00
4(2)Universal Heavy Duty Power Door Lock Actuator Motor 2 Wire 12V$5.13
5(2)Leegoal L298N Stepper Motor Driver Controller Board Module$7.50
6(1)Logisys 480W 240-Pin Dual Fan 20+4 ATX Power Supply PS480D2$13.99
7(1)Cast Acrylic$26.51

Design & Implementation

Hardware Design

CmpE146 S14 NFCLocker BlockDiagram.jpg

As shown above, the NFC locker system is composed of three uC: Two masters and one shared slave. The two masters drive their independent actuator subsystem, independent NFC module subsystem, and shares the slave.The masters pull data from its NFC subsystem, and sends the data to the slave. The slave will either accept or reject the password. If the password is verified, the slave will then send information to the master, where the actuator subsystem will either lock or unlock the locker.

Power System Design

CmpE146 S14 NFCLocker PowerDiagram.jpg

SubmoduleVoltage NeededVoltage Supplier
1SJOne Board+5VATX Power Supply
2NFC Module+3.3VSJOne Board
3Actuator Submodule+12VATX Power Supply

The system ranges in using three different voltages: +12V, +5V, and +3.3V. Because these voltages are standard in computer systems, the team used an ATX power supply. The ATX power supply provides a +12V, +5V, and a +3.3V output. All ATX power supplies has a "safe power-up" feature in which the power supply will not turn on. In order to turn on the ATX power supply, the P.ON wire must be shorted to ground.

Hardware Interface

Actuator Subsystem Interface

CmpE146 S14 NFCLocker Actuator Submodule.jpg
An actuator is used as the physical locking mechanism for the locker. An actuator can only extend or retract depending on the direction a PWM signal is given. Because there are only two wires for the actuator, the actuator can only extend or retract, but not both. In order to obtain both functionalities, a motor controller is used. The motor controller that is used has two input signal pins. These input pins allows the PWM signals to flow in both directions. With software, the team used two PWM ports in which PWM port 1 will flow with a duty cycle of 99%, while port 2 has duty cycle of 0%. Depending if the actuator needs to lock or unlock, the two PWM ports are toggled. This allows a change of direction within the actuator

NFC Interface

CmpE146 S14 NFCLocker NFCModule.jpg

The NFC module can accept High Speed UART (HSU), I2C, or SPI. Out of those three, SPI was chosen for this implementation. In total, seven wires were used to interface the host processor to the PN532. To power the PN532 we used the 3.3v and ground pins available on the SJSU one board. SPI requires three more wires, and the reset and interrupt pins were the last two. The interrupt pin is optional and is not needed for the PN532 to function. The team used the NFC module's interrupt pin because this software's framework is interrupt driven. The interrupt output tells the uC when it is ready. This will be discussed in more detail under the software implementation section for the PN532.

UART Micro-Controller Interface

CmpE146 S14 NFCLocker UART.jpg

Originally, the team wanted to use Ethernet as the networking medium between microcontrollers. Due to time constraints, the team abandoned Ethernet implementation and decided to use UART instead. In this UART implementation, a master uC initiates the communication with the slave. A master uC will send data from the NFC module to the slave uC. The slave will process the data and either send a verification frame or rejection frame to the master which will enable the master to lock or unlock the locker. In this design, two separate UART ports are used. This allows the slave uC to take in data from both masters when they send data concurrently.

Software Design

NFC Software Design

Communication from the host controller between and the PN532 is done with packets. Each Packet is structured as follows:

CmpE146 S14 NFCLocker NFCFrame.jpg

Where

  • Preamble: The start of a packet form Host to PN532
  • Start of Packet: The indicator for the start of every packet
  • LEN: Length of the packet data including the TFI
  • LCS: Checksum for the Length, LEN + LCS = 0x00
  • TFI: Frame identifier, 0xD4 for communication from the host to pn532, 0xD5 for communication from the pn532 to the host
  • PD#: Byte of the payload
  • DCS: Data checksum, TFI + PDO + PD1 + ... + PDN + DCS = 0x00
  • Postamble: Ending byte for the frame.

For SPI communication, a byte with the value of 0x01 must also be sent before the packet when transferring packets from the host controller to the PN532.Packets from the PN532 to the host controller generally do not include the Preamble byte.Commands sent form the host controller to the PN532 follow a certain pattern. First the host controller sends a packet to the PN532. Then the PN532 sends an interrupt to the host controller telling it to drive the SPI connection to receive an acknowledgement (or non acknowledgement) from the PN532, indicates that the PN532 has registered the send command as valid (or invalid). The PN532 then interrupts the host controller again much later after the command has finished and the host controller can fetch the result for the command. Using the interrupt is optional, another system can instead constantly poll the status register of the PN532 to see when it is ready to sent the host controller something.

Normal Operation of SPI interface:

CmpE146 S14 NFCLocker NFCSPIFRAME.jpg

When the PN532 is turned on (or after the reset pin is inactivated), the PN532 goes into LowVBat mode. When ever the PN532 is in a low power consumption state (like lovVBat mode), it requires some time before the packet can be sent from the host to the PN532. This can be done in two ways with SPI,

  • The host controller asserts the chip select pin and waits some time before sending the packet (one millisecond should be fine).
  • The host controller asserts the H_REQ pin and waits for an interrupt from the PN532 to tell the host it is ready for the command (this was not implemented in this design).

Before the PN532 can start NFC, it needs to be configured into what mode it is going to emulate. The host processor needs to send the command SAMConfiguration to put it into the mode the system designer want it to be in. This design puts the PN532 into normal mode which will allow for the peer-to-peer communication needed. The SAMConfiguration command also tells the PN532 to enable the interrupt, but the default value is for it to be on. **If one wants to use the other modes of SAMConfiguration they need to purchase a SAM module and interface it with the PN532**.

To configure the NFC as a target, the TgInitAsTarget command needs to be sent from the host processor to the PN532. This design sets the mode of communication to DEP (Data Exchange Protocol) to enable peer-to-peer communication. A ten byte ID is then needed for the PN532 which can be set but should be randomly generated (for this design it is set). Lastly the general bytes need to contain the NFC magic number (0x46666D) and any LLCP (logic link control protocol) needed to interface the PN532 with an Android phone. Once this command is sent to the PN532 it will go into power down mode until another NFC device starts the NFC initiation sequence. Once this happens the PN532 will interrupt the host processor (and set its status register to indicate it is ready) and the host processor will receive a NFC status (and possible more) from the host processor. The status will indicate whether or not the packet was accepted by the host processor. The TgSetData and TgGetData can be used to send and receive data to and from the initiator NFC and PN532 module.

The protocol used to communicate between two NFC devices is entitled DEP (data exchange protocol). The module supports sending and formatting this protocol, but it still relies on the host processor to do some of the interpreting of the information of this protocol.

 

NFC-DEP commands

This section is included because trying to find reliable information on these commands took too much time away from the development of our system. These are listed as a quick reference for others to quickly grasp the DEP (data exchange protocol) for implementing a PN532-like device.

ATR_REQ, An attribute request
This command contains the information from an initiator to a target to configure the NFC connection. It contains the 10 byte NFC identification number of the initiator, a 1 byte identification number for a target, the bit rates the initiator can send and receive, the maximum payload supported, and optional general bits that can be used for anything (but Android uses them to setup up NFC LLCP). Each initiator can have up to 15 NFC targets.
ATR_RES, The response to the attribute request.
The same as ATR_REQ except its from a target to the initiator. It sends the same fields (but different values for the bit rates and optional general bits) of the ATR_REQ back to the initiator.
PSL_REQ & PSL_RES, parameter selection request/response
PSL_REQ is used by the initiator to reconfigure the connection, can change the bit rates and payload size. The PSL_RES is sent by the target to agree to the parameter changes.
DEP_REQ & DEP_RES Data exchange protocol request/response
Used for the initiator/target to send data, ack/nack, or request a timeout extension (for when host needs more time to process data)
DSL_REQ & DSL_RES Deselect request/response
Initiator wishes to deactivate a target.
WUP_REQ & WUP_RES Wake-up request/response
An initiator uses this to wake-up a deselected device (for active mode only).
RLS_REQ & RLS_RES Release a target request/response
When an initiator wishes to end the communication with a target.

The PN532 incorporates these DEP commands its own commands, but doesn't explain these DEP commands at all in its user guide. It took too much time for this team to search for these commands and understand their meaning. This is only a brief explanation of DEP. To see the full requirements listing for DEP, download the NFC Digital Protocol Technical Specification at NFC-Forum and look at section 16.

NFC LLCP

This was the crippling roadblock for implementing an Android driven locker system.

In order to send data between and Android phone and the PN532 the host processor needs to process the packets on the LLCP (logic link control protocol) level. LLCP is modeled after the OSI layer-2 protocol of 802.2. It's there to enable reliable data transfer by providing connection and connectionless transport. This team did not have enough time to implement LLCP due to the work needed to do so. The NFC-Forum gives a good explanation of NFC LLCP from its website. Download the NFC Logical Link Control Protocol (LLCP) Technical Specification from NFC-Forum to get a good idea on how to implement NFC LLCP.

If one wishes to implement any NFC device into an embedded system, they should check out http://nfc-forum.org/ and http://www.ecma-international.org/ for more information on the protocols. The PN532 user guide expects its readers to understand much of the protocols of NFC, and these links should provide resources into understanding them. If this team had known where to look for this information, it might have been possible to complet the NFC LLCP code needed and enable communication between an Android phone and the SJ-One board.

Phone Application Software Design

 

 

Android NFC Phone Test Application

The team decided to use the Android platform for our phone application since two of the members had a Samsung Galaxy S4 which made testing on the NFC module much easier. The application's main design principle is simplicity. It's important for the application to be quick and easy to use because a user would want to be able to lock or unlock his/her locker as quickly as possible. The flow of the application begins when you start up the application. The first thing that occurs is that the application will enter the idle state until the user enters a password. After entering a password, the password will then be saved into the application. The phone is actively checking for an NFC device and will keep looping until a device is found. When the user is ready to place the phone near the NFC module, the application will then detect the NFC module and send the password to the module. After sending the password, the phone application then goes back to idle and waits for the next password to be entered. It is up to the module to figure out if the password is correct and what action to take if so.


UART Communication Software Design

The locker system has multiple masters and one slave. In order to implement this design, multiple UART lines are used. The slave acts as a databank of passwords for the masters to communicate with. Because multiple masters may access the slave concurrently, the slave must be able to context switch to perform concurrent password checks.

 

Actuator Sub module Software Design

For this actuator's submodule, PWM is needed to control the actuator's state (either extending or retracting). PWM is composed of a frequency and duty cycle. Because the actuator submodule has an "on" or "off" state, the duty cycles used are either 99% (max) or 0% (min). Additionally, a specific frequency is not important for this module

As shown in the hardware implementation of the actuator sub module, in order to extend or retract the actuator, 2 PWM outputs are needed. Each PWM output is connected to the motor controller's inputs. The motor controller inputs dictates the direction of the signal. In order to extend, one PWM1 output must be active, while PWM2 output must be off. Likewise, in order to retract, PWM2 output must be active, while PWM1 output is off.

Actuator StateDuty Cycle of PWM1Duty Cycle of PWM2
1Extend99%0%
2Retract0%99%

Implementation

NFC Implementation

The SJ-One Board used SPI communication to configure and retrieve data from the PN532. The module we purchased came with an antenna built into the PCB allowing the PN532 to communicate with another NFC device. This team got as far as configuring the PN532 into target mode and having the Android initialize the NFC connection to the system. The phone could detect the PN532 but could not establish a connection because the SJ-One board could not handle the NFC LLCP commands the phone was sending. If this team managed to write the code to have NFC LLCP commands processed by the SJ-One board, this system would have been able to transfer data from the phone to the board (and vise versa).

Phone Application Software Implementation

CmpE146 S14 NFCLocker PhoneAppScreenshotOne.jpg CmpE146 S14 NFCLocker PhoneAppScreenshotTwo.jpg

The Android application was relatively easy to implement due to the vast amount of community support for developers. As seen above in the screenshot of the phone application, you can clearly see the simplicity of the application which was one of the design principles. There is a textfield where a user can enter his/her password to open the locker and then hit the save password button. After hitting the save password button, the password is then stored into a string. After the phone detects an NFC device, it uses the Android NFC API to create an NDEF (NFC Data Exchange Format) message that is now ready to be sent. As seen in the screenshot above, when an NFC device is detected, the phone application will display on the screen "Touch to beam". After touching the application, it will now send the password to the NFC module on the locker. The microcontroller on the locker will now decide the next action.

UART Communication Software Implementation

CmpE146 S14 NFCLocker Software UART.jpg


The system consists a master and a slave. There are two components within this password structure: The locker ID(1 byte) and the NFC password(4bytes). Once the master uC has received the NFC data, it sends the password structure to the slave. The slave is predefined with an array of passwords. The slave will search the array of passwords. If the slave finds a matching password, it will send a verification byte to the master uC. If it does not find a password, the slave will send a rejection byte. After receive the verification or rejection byte, the master uC will then toggle its actuator to lock or unlock the locker. Additionally, in this implementation, there are multiple slaves with its independent UART Buses. Because more than one slave that may want to communicate to with the slave uC concurrently, the slave uses FreeRTOS to context switch. This will allow the slave to process the passwords concurrently.

 

Testing & Technical Challenges

Testing

Android Application

The first set of testing was dedicated to the Android application because it was one of the first task completed and that could be tested on its own. In order to test our application, we just used another Android phone to receive the NDEF message being sent. We were able to successfully validate our phone application when we were able to send and receive our "locker password" between two NFC-capable phones.

NFC Module

Testing the NFC Module required an NFC enabled phone. It would act as the initiator and would be brought to the NFC module after the PN532 was set as a target. The resultant packets sent from the PN532 to the host processor were then output to a computer via USB. The output was then presented to us for analysis with the application Hercules.

Locking System

To test our locking system, we hooked up our microcontrollers, motor driver controller boards, and actuators. The actuators were then toggled to show the functionality of the locking system.

Technical Challenges

NFC Module

The most difficult part of this project was to get the NFC module to work as intended. Connecting everything was straightforward since everything was labeled on the NFC module. However, figuring out how to actually integrate the NFC module into our locker system was extremely difficult because it requires a deep and existing knowledge of NFC. In addition to just NFC knowledge, there was a lot of overhead because we had to also know about networking. Trying to get the NFC module to work took extensive hours of reading the datasheet and researching online about what was being read.

Ethernet

Initially, our goal for the networking portion of our locker system was to use Ethernet. This is because Ethernet provides high speed, long range, and the ability to expand if we were to add additional lockers. However, after working on integrating the Ethernet module into our system, we discovered that there was too much overhead for the scope of our project. We decided that it would be best to just use UART for this project, but Ethernet would definitely be something we would use if we wanted to improve our project.

Android Application

At first, developing the Android application was slightly difficult because none of the team members had any experience in developing a phone application. However, after reading the Android Developers page and using Google to find the answer to other questions, the phone application started developing nicely. The Android Developers page had an excellent guide to NFC basics. Using Google search, we were able to find out how to properly integrate a textfield and button into our application.

System Implementation and Time Constraints

All submodules of the locker system functions independently (with the exception of NFC), but putting all of the submodules together into one system was a failure due to time constraints. We failed to put everything together, because we did not identify how difficult it will be to finish the NFC module. We were able to create initial communication with the NFC module and phone, which led us to believe that we were almost finished. After weeks of research, and numerous attempts to finish the NFC module, we then realized that there was a lot more to complete for the NFC module to communicate with the Android phone. We wanted to finish the NFC module, because the entire system is based on the NFC application, but we found this problem too late. Because we diverted all of our attention on finishing the NFC module, we did not have time to put the entire locker system together. We realized that we spent the majority of our time on researching on NFC. This project will need at least 6 full months to complete in order to get a fully functional system

Conclusion

Coming into this project we didn't expect NFC to be nearly as complicated as it was, and the lack of knowledge about it hindered the development in this project. The PN532 does a good job of doing much of the work for NFC specific protocol and physical layers. Unfortunately in order to interface with the Android phone we would need to fully implement the NFC LLCP standard, which we learned about too late. We were unable to access the full data sheet for the PN532 but we were able to access the user guide. Unfortunately the actual protocols were referred to by their acronyms, and finding the documentation to give the description of these protocols took time. After taking the time to understand these protocols we were able to generate responses from the phone but were unable to understand the data that was sent to us. It took more time to discover that LLCP was required to communicate to an Android device. By the time we finished researching LLCP, we were out of time for the project.

Ultimately, our project idea might have been a bit too ambitious for our scope of knowledge. Working with the NFC module required an extensive knowledge of NFC and networking. In addition, there is not much documentation or community help with regards to NFC as compared to making the Android application.

Carissa Labriola

Intern Inquiry 9/5

Posted by Carissa Labriola Sep 5, 2014

It's time again for my Friday findings! You may notice for a while that my questions will have a pattern of mainly pertaining to mbed and NXP LPC boards because that's where my current experience lies in addition to a little BBB. In a month or two I will hopefully have some fun information to share about OpenCV and Mali as well (I'll share more on that project when the plan is finalized). Anyway, this week's question comes from stackoverflow, which is:

 

"I'm using the mbed platform to program a motion controller on an ARM MCU. I need to determine the time at each iteration of a while loop, but am struggling to think of the best way to do this.

 

I have two potential methods:

 

  1. Define how many iterations can be done per second and use "wait" so each iteration occurs after a regular interval. I can then increment a counter to determine time.
  2. Capture system time before going into the loop and then continuously loop, subtracting current system time from original system time to determine time.

 

Am I thinking along the right tracks or have I completely missed it?" - while loop - Keeping Track of Time With Mbed - Stack Overflow

 

Your first option isn't ideal since the wait and counter portions will throw off the numbers and you will end up with less accurate information about your iterations.


The second option is viable depending on how you implement it. mbed has a library called "Timer.h" that would be an easy solution to your problem. The timer function is interrupt based (using Timer3 if you use a LPC1768) you can see the handbook here: Timer - Handbook | mbed. ARM supports 32-bit addresses as part of the Cortex-M3 processors, which means the timers are 32-bit int microsecond counters. What that means for your usability is that this library can keep time up to a maximum of 30 minutes so they are ideal for times between microseconds and seconds (if need more time than that then you will need a real-time clock). It's up to you if you want to know the count in milliseconds or microseconds. If you want micro, you will need to call the function read_us() and if you want milli you will use read_ms(). You can see all of your available calls under this library here - mbed-src. The utilization of the Timer interrupts will affect your time by 1-2 microseconds, so if you wish to keep track down to that level instead of milliseconds you will have to bear that in mind.

 

Here is a sample code for what you are trying to accomplish (based on an LPC1768 and written using the online compiler):

#include "mbed.h"
#include "Timer.h"
Timer timer;
Serial device (p9,p10);
int main() {
    device.baud(19200); //setting baud rate
    int my_num=10; //number of loops in while
    int i=0;
    float sum=0;
    float dev=0;
    float num[my_num];
    float my_time[my_num]; //initial values of array set to zero

    for(int i=0; i<my_num; i++)
    {
        my_time[i]=0; //initialize array to 0
    }

    timer.start(); //start timer
     while (i < my_num) //collect information on timing
     {
        printf("Hello World\n");
        i++;
        my_time[i-1]=timer.read_ms(); //needs to be the last command before loop restarts to be more accurate
     }
    timer.stop(); //stop timer
    sum=my_time[0]; //set initial value of sum to first time input

    for(i=1; i < my_num; i++)
    {
        my_time[i]=my_time[i]-my_time[i-1]; //making the array hold each loop time
        sum=sum+my_time[i]; //sum of times for mean and standard deviation
    }
    sum = sum/my_num; //sum of times is now the mean so as to not waste memory

    device.printf("Here are the times for each loop: \n");
    for(i=0; i<my_num; i++)
    {
        device.printf("Loop %d: %.3f\n", i+1, my_time[i]);
    } 

    device.printf("Your average loop time is %.3f ms\n", sum);
        for(int i=0; i<my_num; i++)
        {
            num[i]= my_time[i]-sum;
            dev = dev +(num[i])*(num[i]);
        }
        dev = sqrt(dev/(my_num-1)); //dev is now the value of the standard deviation
        device.printf("The standard deviation of your loops is %.3f ms\n", dev);

      return 0;
}


 

Another option you can use is the SysTick timer functions DMA_M2M | mbed, which can be implemented similar to the functions seen above and it would make your code more portable to any ARM device with a Cortex-Mx since it's based on the system timer of the microprocessor (read more here: ARM Information Center). It really depends on how precise and portable you want your project to be!

I was recently asked about the issues of using C++ templates in deeply embedded systems (i.e. not Linux, etc.)

Here is the original question:

[snip]

But, it might increase footprint of code. Because compiler will add auto generated code for template.

e.g. let we define two variable SimpleHashTable<int,string> s1 and SimpleHashTable<float,string> s2.

Then they generate two different classes from template

1> with int, string

2> with float, string.

Hence it is trade-off to use template in code base. I am from embedded background so we don't use much of template.

Please let me know your input. Thanks.

 

The writers concerns about increased footprints with templates are well founded, and have been a major reason many embedded programmers have avoided templates.

 

Going back to early cross-compilers supporting templates, then the memory footprint was an issue, however things have move on significantly and modern compilers have some very neat tricks up their sleeves.

 

First, you are correct that given the two different instantiations there will be two versions of the code base in the image. However, modern compilers do something called “instantiation-on-demand or lazy-instantiation”, meaning that code is only ever generated if that member function is actually called. So instantiation of a large template class doesn’t automatically lead to a large code base. Also, a historic problem with templates, was that if, for example, we instantiated the SimpleHashTable<int, string> in two different .cpp files, we would get copies of the code in both .o files; this no longer happens and there will only be one instance of the instantiated code for a concrete type. This also means there is no need for link-time optimization and there is never any redundant generated code (compile-time optimization vs. link-time optimization).

 

Second, the template code generators are very smart. Template code is about algorithmic abstractions and container management. When writing template code we make requirements of type-traits rather than concrete types (e.g. to use this template code a type must support operator<). If the type-traits match two instantiated types, and their memory size match, then a compiler may reuse and existing template instantiation (this is most common with pointers as template parameters). Given you example of SimpleHashTable<int,string> s1 and SimpleHashTable<float,string> s2, the complier will generate code for s1. When it looks at the s2 instantiation it may be able to reuse the code generated for s1 as, for example on an ARM core, sizeof(int) == sizeof(float).

 

I’d say there are two separate issues with templates and deeply embedded systems (i.e. constrained memory system with virtual memory management).


First, using existing templates, i.e. the STL; the issue here is that, by default, the STL containers allocate memory dynamically for the free-store/heap. So to use them safely you need to provide your own allocators. It’s also worth noting that there have been major steps forward in the C++11 STL(such as an array container and static initialization) which makes them very useable for embedded.

 

Second, writing your own maintainable templates is non-trivial. It’s very easy to get carried away with templates (they are very cool after all), but can end up being used inappropriately.  This then leads to maintenance issues.

 

Remember, templates, generally, should be used only for library style code, not application level code.


The use of templates and the associated issues in embedded systems is covered extensively in the Feabhas training course Advanced C++for Embedded Systems

At Cypress we’re pretty serious about customer surveys. The responses get reviewed very carefully and we try to implement many of the suggested improvements.

 

Sometimes though, the responses just don’t make sense. I recently got a report from a customer complaining that PSoC-based applications use more code space than a competitor’s MCU. I was confused because the MCU he mentioned had a Cortex-M0 core, just like the PSoC! How could the code size be significantly different?

 

I’ll spare you the details of all the software installations and the hunt for suitable application code to make the all the comparisons but, after a lot of “please wait – do not reboot your PC” and compiling, compiling, compiling, I finally figured out the root cause – we needed to update our compiler!

 

We ship the GNU ARM toolchain with PSoC Creator. Our last big release, v3.0, was in September 2013 and it includes v4.7.3 of the GNU tools. We released a service pack, PSoC Creator 3.0 SP1, earlier this year but we did not update the compiler tools because we do not wish to constantly force users to migrate. I tried building some applications with the new v4.8 GNU ARM toolchain and got some very surprising results.

 

My application was just one of my (8 task) demos that runs on top of any of our supported RTOS. I chose Micrium’s uC/OS-III because it uses no library functions (eliminating compiler library optimizations from the calculation) but I could just as well have used Segger’s embOS, Keil’s RTX or FreeRTOS. When I crank up the code size optimization the 4.7 compiler generates 21574 bytes versus 21534 on v4.8 - a small, but potentially valuable, improvement.

 

What was much more telling was the difference in code size when optimization was disabled. The v4.7 compiler produces 45454 bytes to the 36710 from v4.8! That’s a huge difference and very likely accounts for our customer’s comment about PSoC code size.

 

PSoC Creator 3.1 is coming out this Fall and we’re definitely updating the compiler that will ship with it!


This customer survey really woke us up to the need to update the shipping compiler. We really do read every response and it’s amazing how many times we make adjustments based on the feedback. Look out for upcoming announcements about PSoC Creator 3.1, with the new compiler, and remember to respond to the surveys!

As I mentioned on a previous occasion, I always welcome questions whenever I make a presentation, do a web seminar, write an article or blog post or whatever. Even very simple queries give me ideas for topics to discuss. I always take the view that, if one engineer poses a question, there are probably a bunch of guys who would also like the answer.

Once again, I am turning my attention to C++ …

What are the advantages of omitting parameters (which leads to creation of default values)?

I strongly believe that a software engineer’s primary responsibility [whatever kind of software they are developing] is to write clear, understandable and maintainable code; everything else is secondary to that goal. At first sight, it might seem that having the option of making function calls, without the requirement to include a value for every parameter, might lead to obscure code. Indeed this is certainly a way to write obfuscated code, but, used properly, default parameter values in C++ can make code easier to read.

This is particularly obvious with the API [Application Program Interface] to various types of software libraries. For embedded developers, a good example is an RTOS, which may have some very complex API calls, giving the programmer much flexibility. In many cases this is a degree of flexibility that is rarely required. For example, here is the prototype for the API call to the Nucleus RTOS to create a semaphore:

STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name, UNSIGNED initial_count, OPTION suspend_type); 

The first two parameters are clearly unique to each call: pointers to the semaphore control block and its name. It is quite common for a semaphore to start off with a value of 1, which makes it a simple binary resource controller. It is also common to want the calling task to be suspended, pending semaphore availability and that suspension to respect the task priority. The prototype for a C++ Nucleus API call might look like this:

STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name, UNSIGNED initial_count=1, OPTION suspend_type=NU_PRIORITY); 

The result is a simple call might look like this:

ReturnStatus = NU_Create_Semaphore(&MySemaphore, "My semaphore"); 

instead of:

ReturnStatus = NU_Create_Semaphore(&MySemaphore, "My semaphore", 1, NU_PRORITY); 

Do you ever run into determinism as a potential roadblock to using C++ or any other OOP language?

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

Default parameters  C   determinism and other C   questions   Mentor Graphics.png

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).

Filter Blog

By date:
By tag: