Atmel And Arduino Announce Wi-Fi Shield 101 At World Maker Faire

Atmel and Arduino teamed up at World Maker Faire to introduce the Wi-Fi shield 101. [Gary] from Atmel gave us the lowdown on this new shield and its components. The shield is a rather spartan affair, carrying only devices of note: an Atmel WINC1500 WiFi module, and an ATECC108 crypto chip.

The WINC1500 is a nifty little WiFi module in its own right. WINC handles IEEE 802.11 b/g/n at up to 72 Mbps. 72Mbps may not sound like much by today’s standards, but it’s plenty fast for most embedded applications. WINC handles all the heavy lifting of the wireless connection. Connectivity is through SPI, UART or I2C, though on the Arduino shield it will be running in SPI mode.

The ATECC108 is a member of Atmel’s “CryptoAuthentication” family. It comes packaged in an 8-pin SOIC, and is compatible with serial I2C EEPROM specifications. Internally the similarities to serial EEPROMs end. The ‘108 has a 256-bit SHA engine in hardware, as well as a Federal Information Processing Standards (FIPS) level random number generator. Atmel sees this chip as being at the core of secure embedded systems. We think it’s pretty darn good, so long as we don’t hear about it at the next DEFCON.

The Wi-Fi shield 101 and associated libraries should be out in January 2015. We can’t wait to see all the new projects (and new ways to blink an LED) the shield will enable.

25 thoughts on “Atmel And Arduino Announce Wi-Fi Shield 101 At World Maker Faire

  1. I’m so underwhelmed everytime I hear about shields.
    I know they are apparently a thing, but I like my modules loose. An Arduino Pro Micro and a SPI Interface to a Real Time clock and a RF Module. A Arduino Nano and a Sensor-unit + a BT Device.
    I see shields always as a “on your desk” solution and a development eviroment, but in the end I need my Option as flexible as possible and dont want to ne limited by clunky shields.

    Give be Modules. The smaller the better. Make them talk ISP/I²C and you get my money. This way I can stay flexible. Swap Communication Modules if needed on upgrades and enhance the unit over time.

    1. yes/no on that. I agree for long term projects, things I’m going to build and cast in concrete I’m all with you on small modules. Shields are good when you are just dev/testing or doing a quick and dirty one-time temp build like a Halloween display or such. Not much thought needed, just slap a shield or two together, upload the code you had from last Halloween and go. Shields, while costly, also help if you are building several of the same thing. I am most interested in this if the shield is actually of a reasonable price. WiFi on an Arduino has been unreasonably prohibitivly expensive in the past. Im hoping for $20 or less, but I doubt it.

    2. When I’m in hobbyist mode, I’m all for shields…. usually something I’m designing for fun will fit on one ProtoShield (for example, a DTMF decoder chip and associated circuitry to control something I’ve programmed). Most things I do are a one-off, and not worth making a custom board (although it’s cool it’s usually not cost effective) or taking a bunch of specialized modules and point-to-pointing them. Yes, it kind of sucks leaving a whole Arduino board in a final project, but the motherboard-daughtercard idea is nice if you decide to change something or if you have a work-in-progress. Some guys on the Arduino group mentioned the Diavolino (link below) and I discovered you can buy the board itself for under $5, it has power supply area, headers for the FTDI, the irritating Pin 13 LED, and room for the supporting stuff for the ‘328. You can leave out what you don’t want (in my final project I would leave out the LED, the power supply stuff if I have my own source of regulated 5V, and the FTDI header if I never plan on changing anything…

      Of course, if there is ever anything I need to be repeatable, I’d pop into Fritzing and have some boards made. Depends on the application. If I need something to be compact, then hell, I can whip something up with a ‘328, a socket, a resonator, and be done with it…

    3. Standardised, breadboard-able, stack-able, shield modules are what’s needed I think.

      Keep the whole common pins thing, but cut it down to 8 or something. 2 for power, a couple for communications, and the rest for general i/o pin toggling.

      1. I’ve been thinking about making a variety of modules exactly the way you’ve described, with a common serial bus for configuration, etc. I2C is nice because even processors that don’t have the hardware for it can bit-bang I2C if the compiler allows for it.

        The shield concept is nice for prototyping because it allows you to start with “trusted” hardware and eliminates soldering time / wiring or pinout errors.

        But once you get beyond development on a shield stack, you would need to shrink down the size of the modules / base processor to fit in your application.

        Are you guys thinking of something like the Beaglebone Black cape formfactor with multiple PCBs stacked ontop of one another? The formfactor for modules seems kinda large there and not easily reusable on other projects.

        Are you thinking of, let’s say a DTMF decoder for example, that could be mounted onto a shield motherboard for use with Arduino, or mounted onto a breadboard for prototyping, or plugged into a project as-is?

        I have some ideas for a physical interface to do the above.

        What type of module functions would you say are currently not available or too inconvenient to use or too expensive?

  2. As a back of hand formula, what is the maximum data an arduino say, the, Mega can send if its not doing anything else? 72MBPS is an overkill, I think. If this shield is not for Arduino and is generic, then its a different story.

    1. 72Mbps is the PHY speed, at best possible N connection, actual data rate from the avr to the wifi chip would be considerably lower since you don’t transmit all the data that’s in that 72Mbps from the avr, you’re looking at about probably 50% of that speed in actual data transfer + some wifi chip protocol overhead, not packet overhead. even at that, It’s still fast though.

          1. For a 16MHz 8-bit AVR without DMA you would be lucky to buffer a byte of data at every 8 cycles (give or take YMMV) -> 2Mbps. That’s not factoring what you do with the actual data and any I/O, protocol and libraries overhead etc.

            This would be a lot more useful for ARM microcontrollers with DMA and a lot more processing speed.

      1. but you can get by with much lower Tx power as you won’t need high SNR for the lower transmission speeds. If you can drop the Tx power by 20dB, but only take a few times longer to transmit, you still save energy. Power saving might not be as simple as how long you stay on the air and there might be a sweet spot at a lower speed.

        1. That’s probably true. Look at BLE as an example: it uses simpler modulation, simpler protocol, and lower rates to sip power. I’d also be curious to see what the typical power overhead is. Assuming the AP association and DHCP lease are still valid, how much power do you need to expend outside of the actual payload to send a packet?

  3. The price is something that Arduino will announce. Atmel does not have information on that. Yes, 72 Mbps is just a theoretical number and in most cases the bottle neck will be spi, i2c or UART. But it’s also essential to mention the theoretical limits to demonstrate the capabilities of the chip running the TCP/IP stack and more over, running faster data rates means more time in sleep (2 uA mode).

  4. I think the ATECC108 will be a bad surprise for most trying to use it. It is a big pain to use, can only be configured once (and is very easily configured wrong), and you must have an NDA to get a datasheet.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.