Skip navigation

Embedded

10 Posts authored by: squadMCU    

On Tuesday (June 19, 2012) at Freescale Technology Forum (FTF) Americas, an impressive energy-efficiency killer demo was presented during the opening keynote. Showcased were the first MCUs built on the ARM® Cortex™-M0+ processors: The brand new Freescale Kinetis L series MCUs.

 

Kinetis L series MCUs enable engineers of Legacy 8-bit and 16-bit architectures to migrate to  32-bit platforms without increasing power consumption, raising cost, or sacrificing space. The ARM Cortex-M0+ processor delivers 2—40 times more performance by consuming 1/3 of the energy of any 8-bit or 16-bit processor available today.

 

In traditional MCUs, the main clock and processor core must be activated to perform even trivial tasks (sending or receiving data, capturing or generating waveforms, or sampling analog signals). Kinetis L series MCUs improve battery life by performing these functions without involving the core or main system; A super cool feature!

 

Applications, like small appliances, gaming accessories, portable medical systems, audio systems, smart meters, lighting, or power control, can now leverage 32-bit capabilities and the scalability needed to expand future product lines—all at 8-bit and 16-bit reduced power consumption levels and price.

 

Development with Kinetis L series MCUs is made simple with the Kinetis KL25Z Freedom Board: a small, low-power, cost-efficient evaluation and development system. Combining an industry-standard form factor with a rich set of third-party expansion board options, the Freedom Platform is perfect for quick application prototyping and demonstration.

 

The Kinetis L series MCUs are ideal for the new wave of connected applications, combining the required energy efficiency, low price, development ease, and small footprint with the enhanced performance, peripherals, enablement, and scalability of the Kinetis 32-bit portfolio.

 

If the Kinetis L Series are not Energy-Efficient MCUs for you… then we really don’t know which ones could be.

StarCore technology offers fully scalable and flexible solutions at low cost, these high-performance low power programmable devices for baseband, aerospace, defense, medical and test and measurement solutions allow to get to market faster.

 

CodeWarrior for StarCore is based on the Eclipse platform, enabling support of eclipse community which leverages larger ecosystem, and provides a framework that combines build, debug, simulation, and analysis tools.

 

Definitely, creating applications for complex multi-core DSP targets is overwhelming without the best development tools. CodeWarrior Development Studio for StarCore 10.2.10 meets this challenge by providing you with some new cool features:

- Updated SmartDSP Operative System

- Improved Debugger Motor

- Continued support to MSC815x family

- Continued support to PSC 9131

- Preliminary (lightly tested) support for PSC 9132

 

The CodeWarrior Developer Studio for StarCore 10.2.10 is ready for digital processing!

Start designing now with CW10.2.10 now!

http://www.freescale.com/files/graphic/tn/CW_Thumb_NEW.jpg

CodeWarrior Development Studio is one of the most robust Integrated Development Environments (IDE) in the debugging industry; allowing highly automated visual framework for complex embedded applications.

 

The combination of flexibility and scalability of Power Architecture technology and the broad–based community collaboration model of Power.org accelerates platform innovation by reducing development costs allowing engineers powerful, consistent, and simplified communications.

 

Why you should consider the new CodeWarrior 10.1.2 for Power Architecture release?
Easy!  This release includes these cool features:
- New device support and capabilities across all aspects of the tools
- Improved build tools—One for Bare metal and one for Linux targets
- Debugger and software analysis tools

 

CodeWarrior developers will be pleased with this new release and from this point on, each supported core will have its own build tool (Bare metal and Linux), and therefore having better core-specific code performance.

 

Experience the newest version of CodeWarrior Developer Studio. Its is all about Power engineers!

Start developing with CW10.1.2 today!

 

http://www.freescale.com/files/graphic/tn/CW_Thumb_NEW.jpg

By Robert Thompson

 

Last week, Google announced the launch and availability of Android  4.0, Ice Cream Sandwich. The first product that will use the new  operating system will be the Galaxy Nexus from Samsung, which was  created in direct collaboration with Google to enable an optimized  hardware and software experience. Both smartphones and tablets are  expected to follow as Google recombines the OS tree to provide a unified  user experience and toolkit for developers for both form factors.

 

What does 4.0 deliver to the user? For me, it breaks into three main categories: personalization, communication and sharing.

 

The ability to personalize the user interface has always been one of  Android’s main strengths. This 4.0 flavor improves personalization to  allow the user to do things like re-size widgets and flip through the  entire calendar without launching the app. Users can group apps from  home screen folders. A new voice-to-text feature allows for extended  dictation in multiple languages — I’m not entirely sure how this will  compare to Siri, the new iPhone assistant. To meet the needs of users  with tiered or metered data plans, Android 4.0 adds new controls for  managing network data usage. However, the main new addition for  personalization is “Face Unlock,” which is based on facial recognition  and allows the users to unlock their device with their faces.

 

Communication improvements center on the new “People app,” which  connects social networks including Google+, and new camera capabilities.  The camera interface has been redesigned to include built-in panorama  mode and the ability to shoot video in 1080p. New camera features  include “Live Effects,” which allows the user to change backgrounds, and  “Silly Faces,” which speaks for itself. Once the images are stored, the  user is able to edit photos inside the gallery using a range of new  editor tools. These images can also be viewed directly from the home  screen via a new Picture Gallery Widget.

 

The ability to share data and apps from an Android device, a much  sought-after usage model as people look to replace traditional content  services, is enabled a number of ways via Ice Cream Sandwich. Android  Beam, a Near Field Communications technology, allows people to instantly  exchange their favorite apps, contacts, music, videos by just touching  two Android-powered devices together.  Looking to share data with  non-Android devices? Use Wi-Fi Direct, which allows for connection to  other devices via Wi-Fi for sharing of files, photos or streaming video  to audio, enabling for the Android device to be the home hub for  entertainment. Finally, as Android expands beyond consumers, the  addition of Bluetooth Health Device Profile will enable users to connect  with a range of devices from wireless medical devices and sensors in  hospitals, machines in fitness centers and energy management devices in  the home.

 

Most of the reviews of Android 4.0 have focused on the new end user  features (for good reason). These are numerous, and will deliver a much  improved experience over Android 2.3 and 3.0. However, 4.0 also delivers  a number of improvements for developers. To enable developers to  explore and add functionality to their apps, Google has released APIs  for social, calendar, visual voicemail, keyboard, spell checker and text  to speech. The new sharing features from Android to Bluetooth Health  Device Profile also allow developers new ways for end users to interact  with their apps and share between users. Android has not forgotten about  the enterprise with keychain and VPN APIs for managing credentials and  connections, and a new administrator policy for disabling the camera.  However, most importantly is the unified user interface toolkit,  including components, styles and capabilities that will enable  developers to simplify code and resources and streamline development and  deployment of apps across all devices.  This is critical as the fight  for developers across the different mobile ecosystems is far from over.  Android needs to continue to entice developers to work with Android:  Revenue from the Android apps is still a challenge for the majority of  developers, however sweet the latest OS might be for end users.

By Jim Trudeau

 

Sometimes real gems are hiding in plain sight. We are bombarded by  data, and who knows what brilliant discoveries we miss in the cacophony  of noise. A friend might point out something. “Hey, have you seen…” and  call our attention to an item. We take a look and, lo and behold, that  magic something emerges – a piece of music, an idea, a book, a tool that  fills a real need. You wonder how you lived without it, and it has been  in front of you all along.

 

FreeMASTER may be such a discovery for you. It has been available in Freescale’s  roster of development tools for years. Really. With almost no fanfare or  publicity, this little gem has been startling discoverers and  generating smiles on the face of its users. So, what is it?

 

FreeMASTER is a real-time debug monitor. Ho hum? Let’s define the  problems it solves. You’re writing software for a real-time system,  like: a motor running an appliance; the engine control in a car; the  sensors in an airbag; the control surface of an airplane; or anything  that has a feedback loop. Now, try to debug that dynamic system  real-time. Yes, sometimes you need to stop the system to study its  state. More often you need to see it operate dynamically, to control it  dynamically, to see why it goes wrong as it works! You cannot do that with a normal debugger. You need FreeMASTER.

 

 

Data visualization

With FreeMASTER you establish a communication channel to the target.  You monitor variables of interest in real-time, at sampling rates you  determine. You can modify those variables real-time, that is, you can  push data down the pipe to the target to modify the behavior of the  system dynamically.

The native data visualization display within FreeMASTER is the  oscilloscope. You can display multiple variables, and have all the  control options you’d expect of a scope.

Figure one shows FreeMASTER tracking two simple variables. One is a  short value rising to maximum and falling to zero. The other generates a  sine waveform by reading data from a table. I changed the step  increment about halfway through to show you that you can push values to  the target.

 

Figure 1. FreeMASTER tracks and displays variable values real-time

Figure 1: FreeMASTER tracks and displays variable values real-time.

 

But it gets much better.

The display area is arbitrarily extensible via HTML. If you master  FreeMASTER, you can add third-party instrumentation “widgets” based on  ActiveX and embed them in the display area. You can wire them up to  variables analogous to the way the oscilloscope works, reading and/or  changing values. In this way you can create as elegant or complex a  dashboard as you like to represent the system you are testing or  demonstrating. This open-ended design makes FreeMASTER an  extraordinarily flexible and powerful tool. Figure 2 is an example  screenshot of an animated display representing engine knock behavior and  feedback control as handled by our Qorivva MCUs based on Power Architecture technology.

Figure 2. The data visualization area of the FreeMASTER tool is arbitrarily extensible

Figure 2: The data visualization area of the FreeMASTER tool is arbitrarily extensible.

 

As they say with Ginsu knives, “but wait, there’s more…”. You can  embed slide shows, presentations, data sheets, or entire packages of  information around a product or a problem. We do it. A really solid  example is the FreeMASTER project for the Tower System for Automotive Sensors that I wrote about here. That has data sheets, block diagrams, and prebuilt scopes for all the sensors, all inside a single FreeMASTER project.

 

 

Data recording

FreeMASTER also implements a data trace capability called the  Recorder. The Recorder uses an on-target buffer to store data readings  and then downloads the buffer to the data display. It captures data at a  higher and more reliable sampling rate than the oscilloscope (near  ten-microsecond resolution). Clearly this can have some impact on the  real-time performance of your application, but the data capture can be  invaluable for analysis. You identify the variables (up to eight) you  want to capture, and specify the size of the on-target buffer.

You also specify a trigger event to start the sample.

 

In the “real time” analysis that you can do with the scope, you see  things as they happen. That is actually a relatively coarse view with a  fair degree of interpolation in the data visualization. You have no  ability to zoom into the data to analyze it at a fine level of  granularity. The sampling rate is not precisely consistent. A lot can  happen during the intervals between the samples. For example, if we were  to pull that same sine wave data at a high increment “real-time,” it  would get pretty ugly. Figure 3 hardly looks like a sine wave at all  and, depending on how fast your data is changing, this display may not  be adequate for you.

Figure 3. Real-time in the oscilloscope has its limitations

Figure 3: Real-time in the oscilloscope has its limitations.


The resolution of the recorder, at microsecond level, is much finer.  In Figure 4 you can see a data trace using the same high increment. That  sine wave looks pretty smooth at millisecond resolution.

Figure 4. The data recorder captures data at fine time resolution

Figure 4: The data recorder captures data at fine time resolution

 

Even still, everything is relative. Figure 5 shows you that you can  zoom in on data. When looking at the data at microsecond resolution, you  can see the stepwise increases induced by the fact that we are pulling  data from a table of values.

Figure 5. A conceptual representation of the FreeMASTER zoom capability.

Figure 5: A conceptual representation of the FreeMASTER zoom capability.

 

All of this should demonstrate that you can use FreeMASTER to study  your data as you need, at the level of detail demanded by your  application. You can also capture the data to a text file for later  analysis in other tools if you wish. Setting up the data trace is typically a matter of configuring the  recorder in FreeMASTER to specify what variables you want to trace. If  you want to change the default buffer size, then you’ll modify a header  file. It is pretty simple stuff.

 

 

Platform support and connections

Real-time data monitoring does not come without some performance  price. It takes cycles to read or store data and push it up the pipe.  But, FreeMASTER has multiple ways of communicating, some of which are  very-low intrusion, such as OSBDM. Others require an on-target driver.  The Table below summarizes platform support and connection protocols.  The BDM connections are very near to zero-intrusion on the running  software. The data trace we were just talking about requires a target  driver.

Table 1. Where and how you can use FreeMASTER.

Table 1: Where and how you can use FreeMASTER.

 

 

Hardware-in-the-loop-simulation

Perhaps the most exciting capability of the tool is that the data  output can be retargeted. Like the design of the data visualization  engine, the data stream itself is not restricted to FreeMASTER. The data  is accessible through an ActiveX interface to any application that can  consume ActiveX services, such as MATLAB®, Excel, Internet Explorer,  PERL, VBScript, Jscript, and so on. What you can do is limited only by  your imagination.

 

Here are two high level use cases involving FreeMASTER feeding data into MATLAB or Simulink.

You might use real-time, real world data rather than theoretical data  to feed input into a complex simulation, and see how the model would  respond.

Alternatively, take a set of identical inputs and run them  simultaneously in both the processor and the model, using FreeMASTER to  stream the results out of the processor. Compare the results from the  two systems to see how the model does against reality, thus establishing  whether the model is valid, and if so, under what conditions.

FreeMASTER enables both of these scenarios for testing models of  highly complex dynamic and non-linear systems. Talk about way cool.

If you’ve read this far, I think I’ve got you hooked. However, here’s one more facet on the gem.

Integrating FreeMASTER with the CodeWarrior tools is simple.

 

Since there is typically an on-target driver involved, you often will  add source code and integrate it into your project. This gives you the  flexibility, as noted above, to do things like change buffer sizes  really easily. When you configure FreeMASTER itself for your  visualization displays, you’ll save the information in a FreeMASTER  project file. I added that FreeMASTER project file into the related  CodeWarrior project by drag and drop, done. Double click inside the  CodeWarrior tools, FreeMASTER launches. Simple and sweet, no need to go  hunting for anything.

True to our overall enablement philosophy, of course you aren’t  required to use a particular development environment. FreeMASTER is a  separate application. You can download it, and the required  communication driver software, here. You can build them in other development environments, like the IAR tools for example.

Also, true to its name, FreeMASTER is complimentary. Seriously. This much functionality at this price?

I told you it was a gem.

squadMCU

Common sensing ~

Posted by squadMCU     Sep 20, 2011

By Jim Trudeau

 

Freescale covers a lot of territory horizontally – industrial, consumer, networking, medical … the list is long. Our technological breadth and depth is immense as a result. We’re famous for it. So what? You are always right to ask, “What’s in it for me?”

 

Well, our technical scope serves you well. You have an orthogonal challenge to the one that we face – while we have to cover a wide area, you have to deal with one area in great detail. This is where solutions make all the difference. Our breadth is not skin deep. We’ve got the skill to put a package together that you may find appealing. Far more than appealing! If we’ve got it right we are going to help you solve a problem way better than the next bloke – which is the whole idea.

 

My premise here is simple: because we have our fingers in a variety of pies, we can cook up a delectable little treat for you that you might find really tasty. So let’s start at the bottom and head on up the menu. This time the topic is MEMS sensors aimed at the automotive market, packaged into the Tower System for Automotive Sensors, which supports the full range of Freescale Xtrinsic automotive sensors. Check out the video:

 

 

 

Boy do we love acronyms around here. As a short aside, one of my favorite is PCMCIA: People Can Memorize Computer Industry Acronyms. You thought it meant something else perhaps?

 

But really let’s talk about MEMS: – micro-electromechanical systems. These very tiny mechanical systems built using semiconductor fabrication technology form the basis for many Freescale sensors. Freescale introduced its first MEMS-based inertial sensors for airbags in 1996, so we’ve been at this for a while.

 

The sensor package under discussion here, shown in Figure 1, contains inertial sensors. The sensors are available individually as well. These are packaged as a Tower Plugin – a TWRPI. We call these “twerpies” around here. I love acronyms. They will plug into any Tower module that has the TWRPI socket.

 

Seriously, you might use these sensors for an airbag system, stability control, a braking system, tilt angle measurement for any purpose, and so on. In this case they plug into a mother board built around an S08 processor, designed as a Tower System module, shown in Figure 2. That board has four (count ‘em) TWRPI sockets for these sensors, and support for both DSI and PSI5 communication

protocols.

 

Figure 1. The “TWRPI” sensors and communication parts

Figure 1: The “TWRPI” sensors and communication parts

 

 

Figure 2. The Freescale Tower System Sensor Module

Figure 2: The Freescale Tower System Sensor Module

 

 

I wrote about the innovative, award winning Tower System here. I called it Legos for engineers; it really is a brilliant system of plug and play modules. Pick your processor, pick your peripherals, plug them together, and voilà! You have a reference design. These automotive sensors fit into this playground along with everything else, and the “everything else” is an amazing (and growing) list.

 

As I said, this particular mother board has an 8-bit S08 processor on board, with 6 kB of RAM and 96 kB of flash memory. You don’t need to plug it into a Tower System, you can use the module all by itself as a self-contained unit. Note the presence of debug headers on the board (of course) supporting OSBDM.

 

Now we start to head up the software stack – we started at MEMS, out of which we build sensors, put those onto TWRPI cards, put those into a package (if you want), plug those onto a mother board, which you can put into the entire Tower System. So far, it’s all hardware. Really neat hardware (I love the Tower System), but “just” hardware.  Given my software focus, I personally see all the magic and promise in those peripherals, and the software that makes use of them.

 

The S08 family is supported by the CodeWarrior Development Studio for Microcontrollers, from the complimentary Special Edition all the way up to the full Featured Professional Edition. Built on the Eclipse IDE, you have what you’d expect: build environment, code editors, debugger; the works. There is a vibrant community of third party tools as well. The CodeWarrior tools come with Processor Expert Software, the component management system for building reusable software components like peripheral drivers. This is better than a driver library, as you can build exactly what you need quickly and easily, optimized for your specific project. Depending on the nature of the software you’re writing, it may or may not be useful for you in this particular domain. You probably won’t use it much working with the sensors, but it could be useful for an end application working with system peripherals.  I wrote about Processor Expert most recently here.

 

Honestly, this is the same song I’ve played in this forum more than once. It’s a really good tune, but what else is new?

 

While some of us may write perfect software every time, most of us need really good debug tools at least occasionally. One of the intriguing software development needs of a sensor-based system is real-time debugging. You can’t stop the system to study what’s happening; you have to analyze it while it’s in operation. This is where FreeMASTER comes into play.  It is a debug monitor. Working over the BDM connection on an S08, it non-intrusively monitors specified variables (without a target-side driver) and displays values real-time on an oscilloscope-like display, as shown in figure 3.

 

Figure 3. The FreeMASTER data recorder display

Figure 3: The FreeMASTER data recorder display

 

That’s pretty cool. FreeMASTER is highly extensible. The data display area is (under the covers) HTML-driven, so highly extensible. As an example of this, and of the level to which we like to enable customers, accompanying the sensor package you can find a file called TWR_SENSOR_AUTO_FREEMASTER. Look in the Current Updates and Releases section on the linked page and download the file. It is a zip file that contains a FreeMASTER project file and a folder full of “stuff.” That “stuff” is worth having, trust me. As well, it shows you what FreeMASTER can do for you.

 

Through the FreeMASTER display it has, for each sensor and daughter card, product information, block diagrams, register maps, simple example apps, and links to additional information like data sheets. Figure 4 shows the block diagram for the MMA6900.

 

Figure 4. The block diagram for the MMA6900 accelerometer on display in FreeMASTER

Figure 4: The block diagram for the MMA6900 accelerometer on display in FreeMASTER

 

Maybe best of all, the FreeMASTER scope, and in some cases some neat gauges, are already wired up for you, as shown in figure 5. All you need to do is install FreeMASTER and get it hooked into the hardware.  The rest is already set up. This is almost too good to be true.

 

Figure 5. Gauges for the MMA6900 in FreeMASTER

Figure 5: Gauges for the MMA6900 in FreeMASTER

 

 

As you can see, FreeMASTER is highly extensible if you want to take the time to live up to the second half of its name and master it. In this case you don’t have to, we’ve done it for you. But with a little experience you can connect variables to user-implemented instrumentation widgets (gauges, dials, meters) and see what’s happening in a customizable interface. True to the first half of its name, it is complimentary. Like the CodeWarrior tool set and many of the tools from Freescale, it supports multiple targets; not just S08. Note that some target connections and some features require a target-side driver to push data up the pipe. You can get FreeMASTER here. Not your typical debugger.

 

At the top of the enablement stack you’ll find a community of developers at Tower Geeks, and a plethora of resources at the Freescale forums.

 

FreeMASTER comes to you courtesy of our long experience in motor control; our skill in building MEMS comes from our long history as one of the world’s premiere semiconductor manufacturers; the S08 is a reflection of our long 8-bit heritage (just look at the Freescale forums, the 8-bit product board has almost twice the messages as any other board). Software communities? We’ve been building those for a decade.

 

Focus that breadth of experience onto a particular domain, and you get something like the Tower System for Automotive Sensors – a vertical solution for a particular market that gets you a lot further up that steep slope toward a final product than just buying some chips.

The traditional approach to picking silicon involves data sheets; matrices of features; at best, a complex spreadsheet of all the many parts with all the many options laid out. Let’s call this the “top down” approach. You have to already be somewhat familiar with the universe of parts. Then you have to see if the part fits your need. Does it have SPI? Does it support JTAG? Can it support the touch capacitive screen your team wants? Even when it all comes together, how do you know that it can do SPI and JTAG simultaneously? What if those subsystems use the same pins? It’s ugly. You know it is.
Enter Solution Advisor from Freescale. Right now it covers the Kinetis MCU parts. This online tool takes a different approach. Let’s call it “bottom up.” Instead of attacking the problem from the top down perspective by starting with what we have, the bottom up perspective tackles the problem from your point of view. The question then becomes: What do I want? What do I need to do this? That basic assumption makes a world of difference. Suddenly you are freed from knowing anything other than what you already know: your design parameters. Hallelujah! That is good human-centered design.
So fill in the blanks. You need a segment LCD? Click and go. Need SPI capability? Just say so. Click the module you need on the left, and the Solution Advisor pops up a configuration window that lets you specify capabilities (Figure 1).

By Jim Trudeau

 

I admit it. I’m a sucker for a good human interface. So we’re going to depart from our usual software focus just a little bit. My excuse is that we’ll talk about a tool that gives you a better way to pick silicon based on a better human interface into the whole process. We are all about good solutions here.

 

The traditional approach to picking silicon involves data sheets; matrices of features; at best, a complex spreadsheet of all the many parts with all the many options laid out. Let’s call this the “top down” approach. You have to already be somewhat familiar with the universe of parts. Then you have to see if the part fits your need. Does it have SPI? Does it support JTAG? Can it support the touch capacitive screen your team wants? Even when it all comes together, how do you know that it can do SPI and JTAG simultaneously? What if those subsystems use the same pins? It’s ugly. You know it is.

 

 

Enter Solution Advisor from Freescale. Right now it covers the Kinetis MCU parts. This online tool takes a different approach. Let’s call it “bottom up.” Instead of attacking the problem from the top down perspective by starting with what we have, the bottom up perspective tackles the problem from your point of view. The question then becomes: What do I want? What do I need to do this? That basic assumption makes a world of difference. Suddenly you are freed from knowing anything other than what you already know: your design parameters. Hallelujah! That is good human-centered design.

 

So fill in the blanks. You need a segment LCD? Click and go. Need SPI capability? Just say so. Click the module you need on the left, and the Solution Advisor pops up a configuration window that lets you specify capabilities (Figure 1).

 

http://freescalehome.files.wordpress.com/2011/08/image1.jpg?w=578&h=276

 

Figure 1. Pick the capabilities the product design requires.

 

 

You can specify voltage, temperature range, package, and memory. The FlexBus interface is particularly sweet, and worthy of a picture (Figure 2). Again, we’re talking an intuitive human interface here that lets you define what you need based on how you think and see, not on a dry list of numbers or register diagrams

 

http://freescalehome.files.wordpress.com/2011/08/image2.jpg?w=578&h=336

 

Figure 2. Specifying the characteristics of the bus that ties everything together.

 

 

You mix and match the design elements as you will. The list of potential controllers that fit your needs changes automatically based on your choices. If it drops to zero, you are warned immediately – yet another great human interface touch (Figure 3).

 

Figure 3. Uh oh! Now you’ve done it.

 

 

When you’re done, you can pick a 100 percent solution, or a non-preferred solution (you’re a grown up). Once you’ve picked the processor, you can check the pin muxing to see if your particular choice of modules work together (Figure 4). Talk about cool – within a minute or two you know if your design is going to have problems. (I purposefully set this up to show you a failure case.)

http://freescalehome.files.wordpress.com/2011/08/image4.jpg?w=578&h=271

Figure 4. Sorry, these components won’t play together in the same box.

 

 

Continue reading on Software Meets Silicon blog

Earlier this week a friend told us he was having hard times when installing his codewarrior on a brand new PC...

"maybe he were doing something bad" you might think, but no...

After a few tries (and failures), we start thinking this was related to something "else"

regarding, some funny virus scan from his McAfee antivirus appeared each time:

 

Yesterday we found McAfee Antivirus and Code Warrior Special Edition Download forum entry

and we tried its solution... now, our codewarrior installer already did its job, and he is now debugging

 

Basically, the work around is to disable the antivirus while you install the application,

once is installed, you can turn on the McAfee software... pretty easy... right? (after three days) ¬¬°

 

The past couple of days were quite interesting, trying to understand the missing step (you know, we engineers are quite stubborn)

We asked some friends on Freescale, and it seems this bug is affecting Code Warrior 7.2, on all Windows OS versions,

but ONLY with McAfee antivirus...if you find it is affecting some other OS or antivirus, please let us know!

So back in November 2009 I posted an article about my starting to play around with RTOS to grow in my technical knowledge. I must confess something: I haven’t really played with MQX or others as much as I would have liked…at least not during 2010. But then something happened: Freescale’s Kinetis family of ARM microcontrollers was launched and now my worked has forced me (in a good way) to work with the MQX RTOS quite a lot more. It’s been great fun.
In my self-training of MQX I’ve run into basically two ways of doing things. One way is to subdivide all functions into tasks, using all sorts of RTOS goodies like semaphores, priorities and mutexes (is that the right plural? How about mutexii?). This way, as far as I understand RTOS, is the right way to do it, it’s elegant.
On the other hand, I’ve seen code were the author basically creates two or three tasks and then proceeds to manually do the application control manually i.e.: switch-case statements with binary flags and stuff. Almost as doing a bare metal application where the RTOS is only there for the drivers. Correct me if I’m wrong, but, doesn’t that beat the whole purpose of using an RTOS?

So back in November 2009 I posted an article about my starting to play around with RTOS to grow in my technical knowledge. I must confess something: I haven’t really played with MQX or others as much as I would have liked…at least not during 2010. But then something happened: Freescale’s Kinetis family of ARM microcontrollers was launched and now my worked has forced me (in a good way) to work with the MQX RTOS quite a lot more. It’s been great fun.


In my self-training of MQX I’ve run into basically two ways of doing things. One way is to subdivide all functions into tasks, using all sorts of RTOS goodies like semaphores, priorities and mutexes (is that the right plural? How about mutexii?). This way, as far as I understand RTOS, is the right way to do it, it’s elegant.

 

 

Continue reading on EmbeddedStories blog

Embedded software engineers only need to know one programming  language to get through life: C. Most embedded software projects are  written in C. So that leaves most other languages out of use (I insist,  for embedded programmers). I always wonder if I need to start learning a  new language, and if so, which one. With so many things to keep  learning about, I usually barely have time to read up on the latest  developments in the technologies I work with, so learning a new language  has been constantly left “for later”.


C++ seems to be a pretty obvious choice as a next programming  language, as far as I know, it’s the second most used language in  embedded systems. There are also some less obvious choices out there  like Ada or B# (yes, you read correctly).


 

Continue reading on EmbeddedStories blog

Filter Blog

By date: By tag: