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!
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!
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.
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 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
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
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
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).
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).
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
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.)
Figure 4. Sorry, these components won’t play together in the same box.
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.
