Tag Archives: MCUs

Random Challenge / Response Authentication in Plain English

By: Gunter Fuchs

Working deep down in the guts (bits and bytes) of a computer, it becomes hard to explain concepts, once the electronic world has taken them over. I wondered about a simple way to explain authentication without referring to the world of computers, so that someone who isn’t savvy with technology can readily understand it.  Well, there is an authentication scenario in one’s modern day-to-day affairs that does not involve any computer (except if you consider the human brain to be one). This scenario is plain and simple: putting a signature on a piece of paper.

How can we describe a signing process in system security terms for authentication? Specifically, what has putting one’s signature on a contract or bill to do with “challenge / response authentication”? The analogy is quite simple. The challenge is the request by – say – the cashier to sign the bill. The response is your signature. That way, you prove that you are the person who owns the credit card. The cashier authenticates your signature by comparing it with the one on your credit card. In computer security terms, that means that the host (cashier) compares a stored response (your signature on the credit card) with the actual response (your signature on the bill). If the host (cashier) comes to the conclusion that both signatures are equal, it accepts the generator of the response as being authentic.

This scenario is quite insecure because someone can easily forge a signature. The reason in cryptographic terms is because this system can generate only one challenge / response pair. An adversary knows what the challenge will be, and if she has seen / copied the response (signature) only once, she can, after some practice, reproduce it relatively fast and easily. A way to improve the security in such a system is to increase the number of possible challenge / response pairs. An example in the online world is a list of question / answer pairs. Sometimes when you log in, a question pops up asking the name of your favorite pet, teacher, or band. Only you and the online host know the correct answer. Such a list increases the security of a system, but since this list is usually short, finding out the few answers by eaves-dropping is not a huge obstacle for an adversary. The advantage of such a short list of challenge / response pairs is that a human brain can manage it. But in a system where only computers play with each other, we can introduce much bigger lists. They are nowadays pairs  as big as 2^32. In such a system, with a huge number of challenge / response pairs, the host chooses one randomly. An adversary would now have to replicate this huge table, and once it has done that, search through this table for the challenge to find the correct response. Well, you could argue, why not? And how can an authentic client find the correct response in a feasible time? This issue is solved by introducing a cryptographic algorithm and a key into the system. By using a key and an algorithm, tables of challenge / response pairs don’t have to be generated and stored, but a host only has to generate a random number to “choose” a challenge. When the client receives this random number as a challenge, it combines it with a key using a cryptographic algorithm and sends the result back to the host (response). (The cryptographic algorithm “hides” the key so that an adversary cannot extract it from the response.) The host now performs the same calculation using the same key and compares the received response with its calculated one. If the two match—voila!—the host finds the client to be authentic.

With a system that incorporates the process of random challenge / response authentication, an adversary would have to monitor many, many (depending on the biggest number – “number space” – used in this system) authentication sequences between host and client and store them in a table. And after that, it would have to find the challenge in this table to come up with the correct response if it wants to pretend to be the authentic client. Finding it would practically take eternities, “would be infeasible” in cryptographic terms. The quality of the randomness of the random number is important, because the better the quality of the random number generator the less an adversary can predict the next challenge. If an adversary could predict the next challenge, he could search his table in advance.

random challenge response, cryptographic algorithm

random challenge response, cryptographic algorithm

Weighing the Benefits of Hardware- vs. Software-only Security

By: Steve Jarmusz

I have seen many software programs touting that they have security built into the code.  I don’t think having the algorithm in software is such a bad thing, but having the keys or roots of trust stored in a non-secure, external Flash device or internal non-volatile memory within the MCU is.    I think it leaves the system vulnerable to attacks.  I have learned that software-based security schemes often use the hardware accelerators that are in a MCU or they implement them in software.  We have seen hack shops in Asia that will extract the keys from a binary file for a nominal fee, so that is not secure.  Even if the engineers bought a microcontroller that has crypto accelerators inside, normally the hardware accelerators inside the MCU are not protected from tampering.    In contrast, hardware-based security schemes use a device that has been created specifically to address a particular security need.  Hardware devices usually have secure key storage so that the key cannot be read from the outside nor changed.  The algorithms used by these devices are developed in hardware in a way that is secure and tamper resistant.  Hardware devices usually have built-in protection mechanisms in case they are being attacked either environmentally or physically.  So in your next design, I highly recommend that you spend a little time to research hardware security.

The Atmel Xplained platform is going Pro

By: Eirik Slettahjell – Sr. Development Engineer Atmel

Having been on the team that created the new Atmel® Xplained Pro platform,  let me share some more details about these new boards and the platform we are providing. Xplained Pro is the result of Atmel’s engineers aiming to make life easier for designers working with Atmel MCUs. In other words: designed by engineers for engineers:

“The work of engineers forms the link between scientific discoveries and their subsequent applications to human needs and quality of life.”1

Capture

SAM4L Xplained Pro MCU board

The Atmel Xplained Pro platform provides the full Atmel microcontroller experience, combining hardware and software. It equips you, the engineer, with a smart platform that makes it easy to excel with the complete application prototype up and running an hour after your boss discusses a new product idea. We want the Atmel Xplained Pro platform to inspire and enable new ground breaking designs and applications.

SAM4L Xplained Pro MCU board details

SAM4L Xplained Pro MCU board details

“How is this possible?”

Atmel Xplained Pro platform is capable of being a product prototype. With the evaluation kits, Atmel Studio and Atmel Software Framework you can put together the complete application prototype – really fast.

Start Atmel Studio and connect the Xplained Pro kit to your computer. You will discover the kit and its capabilities since Atmel Studio knows exactly which Atmel Xplained Pro evaluation kit you connected and what extensions are plugged into the kit. Download applications examples or software building blocks from Atmel Software Framework and build the prototype.

You also get direct access to datasheets and board documentation by connecting your kit to your computer.

Thanks to the embedded debugger, Xplained Pro are easy to use, yet provide powerful debugging capabilities.

You do not have to connect any external debugger or programmer. With only a USB cable connected to your computer you get:

  • Device program and debug with all the same capabilities as Atmel’s standard programmers and debuggers
  • Data Gateway Interface (DGI) for enhanced application data streaming and debug through standard interfaces
  • Virtual COM port (USB CDC) to easily allow printf-style debug and data logging directly into Atmel Studio

The Xplained Pro platform has been designed for flexibility. A standard Xplained Pro header makes it easy for anyone to design extension boards that connect to the Xplained Pro evaluation kits. Available boards can be found here, including IO, prototyping, OLED and segment LCD extension boards.

If you can’t wait for the extension that you want – just make your own.  The Extension Developer’s Kit (XDK) gives you a design guide that tells you everything you need to create an Xplained Pro extension board.

Xplained Pro Extension boards

Xplained Pro Extension boards

The Xplained Pro offering will continuously expand, covering the latest MCUs and technology available. More information about boards and kits is available on Atmel’s web site and can be purchased from one of Atmel’s distributors or at store.atmel.com.

References

1. Bureau of Labor Statistics, U.S. Department of Labor (2006). “Engineers”. Occupational Outlook Handbook, 2006-07 Edition. Retrieved 2006-09-21.

Interview with Pinoccio co-founder Eric Jennings

By Eric Weddington, Marketing Manager, Open Source & Community

Pinoccio and Atmel - complete ecosystem for the Internet of Things

Pinoccio and Atmel – complete ecosystem for the Internet of Things

Pinoccio is a new Open Source Hardware business, building “a complete ecosystem for the Internet of Things”. They recently completed a successful crowd-funding campaign on Indiegogo to help them build their first product: A pocket-sized microcontroller board, with wireless networking, rechargeable LiPo battery, sensors, and the ability to expand its capabilities through shields, much like an Arduino board. It features an Atmel microchip from the ATmega microcontroller product family.  This is the new Atmel ATmega256RFR2, a single-chip AVR 8-bit processor, a low power microcontroller with 2.4GHz transceiver for IEEE 802.15.4 supporting WPAN (ZigBee, ISA100.11a, WirelessHART, IrDA, Wireless USB, Bluetooth, Z-wave, Body Area Network, and MiWi) communications. In January, Ingolf Leidert posted a preview of the Pinoccio here on Bits & Pieces.

Eric Jennings, co-founder of Pinoccio

Eric Jennings, co-founder of Pinoccio

Eric Jennings, along with his partner Sally Carson, co-founded Pinoccio. Eric Jennings and I met at the first Hardware Innovation Workshop before the Maker Faire Bay Area in 2012. We discussed microcontroller radios, RF, mesh networking, Open Source projects, and kept in touch while he was working on the design of the Pinoccio. We talked recently about their design and process, Open Source, Open Hardware, and the future of Pinoccio…

Eric Weddington (EW): What inspired you, and your partner Sally, to create Pinoccio?

Eric Jennings (EJ): We’ve both been interested in hardware projects for quite a long time.  The first inspiration for Pinoccio was a book Sally and I both read by Bruce Sterling, called “Shaping Things”.  That book influenced us to what it would be like if a device like Pinoccio existed.  In that book, he describes an early concept of the Internet of Things–devices he called “Spimes”.  Spimes, he writes, are objects that can be tracked through space and time throughout their lifetime.  We extend that definition to include physical instantiations of data, that could exist all around us.  The book was written about a decade ago, so it may sound quaint today, but it was visionary when it was written.

EW: Most Open Source projects usually start off by “scratching your own itch”. What need did you see in the Arduino community, that Pinoccio can fill?

EJ: I have been involved with Arduino since first picking up Tom Igoe’s book “Making Things Talk” back in 2008.  I had dabbled in 68HC11 hardware hacking before then, and 8088 at the University before that, but it was always incredibly difficult to get started.  Over the years I built several personal projects on the Arduino platform.  I loved the platform, I loved how open it was, and how I could quickly learn the best ways people had found to solve all sorts of practical problems.

However, when it came to doing anything wireless or battery-powered, things kind of fell apart.  Price went up quickly with having to purchase additional shields, XBee modules, and lots of 9V batteries.  We wanted a tiny, pocketable Arduino-compatible microcontroller that was battery-powered, rechargeable, and had a built-in wireless radio.

So you could say that Bruce’s book gave us the insight of what things could become in the future, and the Arduino community gave us the hands-on experience to know what worked well today and what could be improved upon.

EW: What design principles did you and your partner follow, when designing Pinoccio? What were the “rules of thumb”?

EJ: Sally Carson, Pinoccio’s other co-founder, is an expert in the intersection between humans and technology.  What I mean by that is that she thinks very deeply and carefully about the psychology of humans interacting with computers.  Human-computer interaction, user experience, and usability all fall under her umbrella.  I consider her contribution a secret weapon in what we’re trying to achieve with Pinoccio.

So one of the major design principles Pinoccio follows is that of “how will this feel to a person?”  We’ve defined UX personas, which are defined as fictional examples of people within the user base.

We’ve defined two main personas for Pinoccio today, and every decision we discuss–from what power management IC to use, all the way up to the feel of the device in your hands–is debated through the lenses of the personas.  We’ve even named the personas, so when we talk about features or capabilities, we’ll say things like “do you think Edwin will care about this as much as Theo will?”  This has helped us focus on what features are important now, and what features can wait until later.

Another design principle we care a lot about is not letting price be our only deciding factor.  From early on, we realized that ease-of-use and reliability are just as important as price.  We certainly care about how much Pinoccios cost, as we want them as accessible as possible.  But we won’t respond to the trolls on forums that claim “What? I could build one of these in 30 minutes for $7.00.”  By all means Mr. troll, please do so.

Of course, if you’ve been in the hardware world for any length of time at all, you learn that things like manufacturing repeatability, volume purchasing, regulatory certification, and reseller relationships are essential to building a long-term, sustainable business.  Building one in your workshop is one thing.  Building 10,000 of them in an efficient, repeatable manner is something altogether different.

EW: How important is Open Source, both tools and the communities that support them, to Pinoccio?

EJ: Open Source has been a cornerstone of our company’s philosophy.  I would estimate that if we were to list out all of the tools, frameworks, servers, databases, and other software Pinoccio uses on a day-to-day basis, more than half would be open source.  Even things one may take for granted, like the lowly shell script, gives us an advantage we wouldn’t otherwise have.

Pinoccio itself is an open hardware company, meaning we not only publish our bootloader and firmware as open source, but our hardware schematics and board layout files as well.  Some people, after hearing this, think we’re crazy for doing so.  Others nod their head quietly and believe, as we do, that this is actually an advantage to us as a company–not some form of naive altruism.

We’ve closely followed the trajectory of companies like SparkFun, Adafruit, and 3D Robotics, and it’s clear to us that making your hardware open affords you such rapid feedback and design iteration, that you can quickly surpass larger, more traditional hardware companies, even with a tiny team.

There’s a story I like to tell that paints a picture of this.  There’s an individual who lives in Switzerland who reached out to us about 6 months ago.  He had heard of the Pinoccio project and was interested in learning more.  He started by sending me emails of simple suggestions he had after reviewing our schematics.  As we got to know each other better, I learned he was a retired medical device technology design engineer.  He had recently retired and purchased a 700 year old house in the Swiss Alps, and now has sheep and chickens in what could be argued the most beautiful country in the world.  Yet he said he loved electronics too much to leave it altogether.  He wanted Pinoccios to help monitor and manage his small farm.

Through collaboration, his contributions have increased our battery life 10x, and have given us the ability to control power handling on Pinoccio boards in a very fine-grained, very flexible manner–much more advanced than I had even initially considered. He and I continue to bounce emails back and forth, haggling over how to get the quiescent current of Pinoccio boards even lower.  He also designed an energy harvester shield for Pinoccio that can charge the Lipo battery with as little as 80mV, and we’ll be offering this shield for sale this summer.

Now imagine that for a moment.  Here’s an individual who is an expert at low-power systems.  He wouldn’t have found out about the details of our design if we were not open source.  And we would have never even known he existed.  Even if we did know of him, we wouldn’t have been able to hire him, because he’s retired, and it’s assumed he is not motivated by career advancement anymore.  This is extremely powerful, and our products evolve faster and better for everyone because of this openness.

EW: What sets Pinoccio apart from other products that offer similar functionality?

EJ: There are a lot of devices available today that offer subsets of functionality of what Pinoccios offer.  I would even argue that some of them do their particular subset better than we do.

But what sets us apart from them all is that we’ve built everything needed to get physical hardware talking to the web, seamlessly, and in an open manner.  Some companies come close to this, but may perhaps stop at the “open” part.  Others may have the openness down, but don’t get you all the way back to the hardware itself, with example firmware scripts.  We’re planning on each board having its own web URL where you can query or send commands to it.  That’s powerful for the tens of thousands of software and web developers out there who understand REST endpoints and web sockets, but are new to hardware.

Going back to personas, one of the requirements we have is that once you receive a Pinoccio starter kit, you should be affecting hardware–such as making its LED turn on or off–from a web browser in less than 5 minutes.  You should also be able to push data from the hardware to the web–such as temperature–in the same 5 minutes.  Back when I was hacking on Arduinos, I would spend all weekend trying to get a network stack working with the WiFi shield I had bought, and it would still drop connection unexpectedly.  And I’d have to spin up a Heroku virtual server instance to act as a web location for my project. So frustrating.

EW: What part of the design process with Pinoccio surprised you?

EJ: The most surprising part of the design process was how high-level we needed to start at in order to design this new product well.  Had we jumped straight into designing the hardware around things that I was preferential to, or around price, we would have an inferior product today.  Focusing instead on “what is it this device should solve for our personas” has really helped in focusing on what’s important.

It was surprising to me just how important this aspect of the design process is.  It sounds somewhat cliché, but products must be designed from the human back to the hardware, not the other way around.  I’m sure there are industrial designers reading this, thinking “of course”, but to formalize it in a new hardware startup from such an early point was a surprising yet important move for us.

EW: What part of the design process with Pinoccio challenged you, or was the most challenging, and how did you overcome that challenge?

EJ: Two major components have challenged us the most.  The expected one is building out the RF section of Pinoccios.  To non-RF engineers, RF is black magic.  It works, but exhibits behavior that isn’t always intuitive, and sometimes downright mystifying.  Add to this the general unavailability of knowledge and the expense of tools around how to tune RF front-ends, and it’s no wonder it still feels like black magic to most hardware engineers.

We tried to mitigate most of this challenge by following datasheet board layout recommendations to the letter, in addition to choosing RF front-end components designed specifically for the Atmel microcontroller radio we had chosen.  We went through seven revisions of the board before we found an RF layout that worked well.  However, this still wasn’t enough, as we had no idea if our antenna trace characteristic impedance was indeed correct.

I don’t like flying blind like that for production hardware, so we recently employed the help of an RF consultant in Portland, OR who is going to help us through final tuning and FCC certification.  It’s important, we’ve learned, to ask for help when you need it.  Nobody knows everything, and it benefits everyone when many people contribute their best knowledge to a problem domain.

The other component that challenged us the most was completely unexpected and very unsexy.  It was the header sockets we chose.  Pinoccios, like Arduinos, have the concept of a shield–a board with particular sensors or components that you can plug into header sockets on the main Pinoccio board–to extend its functionality.  Due to Pinoccio’s small form factor, the header sockets we chose are 2mm, but it turns out that nobody makes header sockets with this pitch, but low-profile and long tails.

We contacted all of the major header manufacturers (and several lesser known ones) and nobody has these.  So we’ve resorted to higher-profile header sockets for the time being.  It bugs us from the “how does it feel when you hold it” aspect, because the shield headers are taller than they need to be, but it’s something we’ve had to accept for now.  Once we get our first manufacturing run out, I wouldn’t rule out us biting the bullet and getting custom headers developed.  It’s extremely expensive to do so, but it’s important from the human interface aspect.

But who knew header sockets would be a major design challenge?

EW: You have recently finished a successful crowd-funding campaign. Congratulations! What will you focus on next?

EJ: Thank you!  Yes, the campaign exceeded our expectations completely.  We set a fairly high goal so that we would have plenty of room in case something went wrong with the FCC certification, or if we messed up costs or availability of various components.  However, we were delighted to see the community not only help Pinoccio hit its goal, but pretty much blew it out of the water by 75%.

Now we’re singularly focused on converting the momentum we received during the campaign into a sustainable, viable company.  First and foremost, this means getting the tools and equipment in place to deliver the first run of boards that the campaign pledges have reserved.  But it also means building out our e-commerce site for ongoing sales, building the web API portion of our platform, and beginning to hire people to help us in this work.

It sounds strange. The campaign was extremely fun and exciting, but now the real work begins in getting Pinoccios into peoples’ hands.

EW: It looks like you have many extensions planned for Pinoccio. What are some of the ways in which Pinoccio can be extended?

EJ: We currently have around 8 shields under development.  Everything from 3-axis accelerometer/3-axis gyro, to GPS, to environmental sensing, to motion and noise sensing, to 16 channel PWM LED driving, to energy harvesting.  We have a very active community forum where lots of the detailed technical discussion happens around what shields to build next.

We have arranged manufacturing where it costs us very little to introduce new shields, so we’re quite open to new shield ideas.

But even without shields, Pinoccios can be extended very easily.  The boards themselves break out almost all of the microcontroller pins to the header sockets.  So you have access to I2C, SPI, two UARTs, several GPIOs and 8 ADCs.  So anything you want to breadboard up, or build on a perfboard would work fine.  We also offer proto boards that let you solder in whatever design you want, and have it in a nice shield format, for a more permanent custom build.

EW: Now that the crowd-funding campaign is over, how can people just discovering Pinoccio order one (or more) for themselves?

EJ: We are finishing up some details for the e-commerce portion of our site.  There people can continue to pre-order Pinoccios even if they missed our crowdfunding campaign.  We’ll also offer several shields for sale as well as accessories like spare Lipo batteries, jumper wires, and other things you may want for prototyping.

We’re also talking with several well-known Maker/DIY resellers who have reached out to us, interested in carrying Pinoccios on their sites.  We can’t name names quite yet, but we expect you’ll be able to buy Pinoccios at many of your favorite online stores.

New Hardware Kits for Evaluating and Prototyping with Flash Microcontrollers

You now have a new tool available to evaluate, prototype and develop with Atmel® Flash microcontrollers. The new Atmel Xplained Pro hardware kits are easy to use, extensible and low in cost. With an Xplained Pro kit it only takes minutes to run your first program on the microcontroller. Just connect the kit to your PC with a USB cable and the Atmel Studio 6.1 integrated development platform immediately recognizes the boards. , Click a button to program the MCU with a ready-made application example based on Atmel Software Framework and you are set to execute and single step through the first lines of C code.

Need additional software tools?  Just download extensions for the Studio 6 IDP from the Atmel Gallery online apps store.

Need additional hardware?  The Xplained Pro boards are standardized designs of microcontroller boards, with extension boards providing additional capabilities like displays or breadboarding. With this combination, you can create a system to evaluate new Atmel AVR® and ARM® processor-based devices in the context of your targeted applications.

The following boards are now available:

  • SAM4L Xplained Pro
    • Cortex-M4 based Atmel SAM4L4 MCU with 256kB Flash
    • SAM4S Xplained Pro
      • Cortex-M4 based Atmel SAM4SD32 MCU with 2MB Flash
      • ATMEGA256RFR2 Xplained Pro
        • With AVR based ATMEGA256RFR2 MCU WITH LOW POWER 2.4GHZ TRANSCEIVER FOR IEEE 802.15.4
        • Segment LCD1 Xplained Pro extension board
        • OLED1 Xplained Pro extension board
        • IO1 Xplained Pro extension board
        • PROTO1 Xplained Pro extension board

These boards are available in the following kits:

  • Evaluation kits, providing the MCU boards, priced at $39
  • Starter kits, providing a bundle of a MCU board and extension boards, priced at $99 and up
  • Extension kits, providing single extension boards

You can buy Xplained Pro kits through your Atmel distributor or online at store.atmel.com.

When you want to decide if the Atmel MCU is the right fit for your design, Xplained Pro kits are the fastest and easiest way for evaluation, prototyping and development.

Imagining the Future — DIY Style

By Eric Weddington

It’s the beginning of February already. The New Year has started with a bang, with barely enough time to reflect on the past year. However, there have been some exciting things in 2012 that I can’t wait to see continue on in 2013…

Engineers can be a funny group. On one hand they’re the makers of a wide range of technology. But because engineers are, in general, interested in getting the details right, sometimes they can get caught up in the details, with a focus on what should be the “right” way of doing something. One of the privileges of being involved in the open source community has been attending the Maker Faires, put on by Make: magazine, in the Bay Area in May, and in New York in September. The Arduino microcontroller board is a big part of  these Maker Faires, powering all sorts of projects. It’s become popular because it enables people who are not engineers to get involved in making stuff with electronics, allowing them to add smarts to all sorts of things.

What I’ve discovered is that it doesn’t magically turn these people into engineers. They see the Arduino as a tool that they can use to turn their ideas into reality. They don’t get caught up in the details of what is the “right” way, or the “wrong” way, to implement a solution according to their engineering training. They keep their eyes firmly on their goal. They’re too busy creating! During the last year, I have been amazed at all the cool, weird, wonderful ideas that have been thought up and implemented by many in this Maker community. I wouldn’t have thought up half the stuff that I have seen done with an Arduino and our AVR processors. A DIY X-ray CT scanner controlled by an Arduino. FireHero, which has an Arduino controlled propane “puffer” interfaced to a GuitarHero controller. A winner of the California Science Fair used an Arduino to measure foot pressure for diabetics. All manner of quadcopters and UAVs. Desktop 3D printers. Clothing design. And the list goes on. It’s exhilarating to see what’s been done and to think about what people will imagine next! Yes, it’s going to be a fun 2013!

A Pocket-Sized, Low-Power Ecosystem Makes Wi-Fi Easy

By Ingolf Leidert

Sensor networks are nothing brand new and even terms like “smart dust” have been around for a while. Many have envisioned a future where every technical entity around us will be “smart” in some way and is permanently connected to a huge network consisting of small sensors that help monitor and control our world. Usually, the large step into such a future vision is divided into several smaller steps. Obviously, one parameter seems to be essential for the small and smart sensors vision: the power consumption of such an entity. With the ATmegaRF SoC family, Atmel has introduced one of the lowest power IEEE 802.15.4 systems in the world. Its low power consumption combined with the full AVR microcontroller (MCU) capabilities makes networks built with lots of compact, low-power wireless sensors look more realistic now. One project that shows this perfectly is the Pinoccio.

Pinoccio is an open-source, crowd-funded solution that provides a complete ecosystem for building products supporting The Internet of Things. These small “scout” boards, compatible with the Arduino platform, come with everything a “smart, wireless, connected entity” would need:

  • LiPo battery (chargeable over USB)
  • LED
  • Temperature sensor
  • Antenna
  • Several I/Os for connecting DIY hardware (like more sensors)
  • And, as its “heart”, the Atmel ATmega128RFA1 with its excellent power consumption of less than 17mA when actively transmitting. The ATmega128RFA1 is pin-compatible with the new ATmegaRFR2 family…so perhaps we’ll see future “scout” boards in 64kB or 256kB versions. 

The developers have chosen that MCU explicitly for its low power and RF capabilities. And, as you can see from the estimated power specs, a sleeping scout board should be able to run for more than a year from one battery charge. Because the whole Pinoccio ecosystem includes a Wi-Fi board that finally connects all the tiny “scout” boards to an existing Wi-Fi infrastructure and even offers SD card data storage, this whole system looks like a wonderful first step into The Internet of  Things.

New ARM Cortex-M4 Flash MCU: Advanced Connectivity, Floating Point Unit

Industrial applications–from home and building control to machine-to-machine (M2M) communications to energy management–call for underlying technology with abundant connectivity peripherals, processing power and analog capabilities. Atmel’s newest ARM Cortex-M4 processor-based Flash microcontroller, the SAM4E, delivers on all of these fronts.

  • 10/100Mbps Ethernet MAC supporting IEEE 1588, full-speed USB 2.0 device and dual CAN
  • More processing power with a maximum operating frequency of 120MHz
  • Floating point unit
  • Two independent 16-bit ADCs with dual sample and hold, offset and gain error correction, programmable gain amplifier

As with Atmel’s other ARM Cortex-M as well as AVR microcontrollers, the SAM4E devices are supported by the Atmel Studio 6 integrated development platform. A free download, Atmel Studio 6 comes with more than 1,600 project examples that minimize much of the low-level coding for designs. With its integrated Atmel Gallery apps store, you can access a variety of Atmel and third-party embedded software, tools and extensions to support your design process.

Learn how SAM4E microcontrollers can support your next design.

New Dev Kit for Creating and Sharing Embedded Design Extensions

It’s the life of an embedded design engineer: design is becoming increasingly complex, while resources and budgets are as tight as ever. What’s more, design teams are often distributed across different locations, and the pressure to get to market remains constant. Good, easy-to-use software and tools can help, especially if they foster collaboration.

Do you create software, tools and other design resources that help engineers meet their challenges? Read this application note to learn about a new developer’s kit for creating and uploading extensions to the new Atmel Gallery online apps store, a part of the free Atmel Studio 6 integrated development platform for AVR and ARM processor-based microcontrollers. The Atmel Studio Extension Developer’s Kit (XDK) gives you resources to easily develop extensions that integrate with Atmel Studio and are available to design engineers on Atmel Gallery.

Easing Design Process with AUTOSAR Standard Support

By Eric Tinlot

Today’s vehicles have up to 70 electronic control units (ECUs) supporting many of their in-vehicle functionalities—a result of tougher constraints in areas including security, environment, comfort and safety. All of these functionalities call for simultaneous interactions by sensors, actuators and control units. But with the complexity of signal interactions among ECUs, this can be a challenging prospect. What’s more, these complex interactions and the increasing number of ECU nodes are increasing the amount and complexity of software required.

The Automotive Software Platform and Architecture (AUTOSAR) is an open and standardized automotive software platform and architecture jointly developed by automotive manufacturers, suppliers and tools developers. Because it provides an abstraction layer between hardware and application, the standard allows hardware-independent development and testing of the application software.

Atmel has worked with Vector Informatik to fully support the Atmel 32-bit AVR automotive family devices in AUTOSAR through the MICROSAR bundle from Vector. We have developed a microcontroller abstraction layer (MCAL) for our automotive-qualified AVR devices. These MCAL modules and Vector’s LIN/CAN communication layers are integrated into Vector’s complete MICROSAR environment. This AUTOSAR bundle for the 32-bit AVR family is available from Vector.

The AUTOSAR bundle consists of a microcontroller abstraction layer for AVR automotive-qualified MCUs and Vector Informatik’s LIN/CAN communication layers.

To learn more, including which MCALs we’ve developed, read the full article, Atmel Eases Automotive Design Process Through Support of AUTOSAR Standard.