The 4313 has landed.

By on

ATtiny4313-PU

One of our all-time favorite chips is the ATtiny2313.

It’s a little 20-pin AVR microcontroller that we’ve used in dozens of projects, including our high tech holiday decorations, some of our coolest pumpkins, our (digital) Larson Scanner, and some wacky papercraft— to name a few. It’s one of those few chips that we used often enough to justify a custom breakout board.

But… if there’s one thing that the ‘2313 is short on, it’s memory. With 2 kB of flash (program) memory and 128 bytes of RAM, it’s perfect for tiny single-purpose projects. But, it’s oh-so-easy to run up against that memory limit. And, that’s why we were so excited when Atmel began to announce their then-forthcoming ATtiny4313 in late 2009.

Unfortunately, it’s often a long delay between when a chip is announced and when it’s actually available through distribution. Sample quantities have been floating around for half a year or so, but– and finally— a big box showed up in the mail, and so here they are.

4313 - 3

Now, programming it. There are very few changes between the ‘2313 and ‘4313. Mainly, it’s what you’d expect: memory sizes (Flash, SRAM, EEPROM are all doubled), and the device signature is different.

Recent versions of AVR-GCC already support the ‘4313, and so it’s relatively straightforward to recompile an existing program (say, the Larson scanner firmware) to run on the ‘4313. There are some minor inconsistencies between the “io.h” header files for the two chips, and those inconsistencies can cause compiling to fail. For example, the register name “WDTCSR” (for watchdog control register) works on the ‘2313, but the ‘4313 io.h file lists that same register name as “WDTCR.” So, if you run into a place where AVR-GCC is confused after switching chips, you might be able to solve the issue by comparing that register name in the “io.h” files for the two chips.

Now, for programming the chip with avrdude, things are slightly more complicated. Avrdude does not yet natively support the ‘4313, but fortunately, you can add the new chip definition by editing the avrdude.conf file on your system. (On my Mac, where I use Crosspack as the AVR toolchain, I found that file at /usr/local/CrossPack-AVR/etc/avrdude.conf ) The ‘4313 code block can be added right below the ‘2313 code block, and you can download that code block here (via this mailing list post). So, a couple of steps, but works like a charm.

There aren’t a whole lot of these to go around right now, but we’ve put some of our ‘4313 chips into little dev kits that you can pick up at our store. Let’s see how long they last. ;)

This entry was posted in EMSL Projects, Microcontrollers and tagged . Bookmark the Permalink.

15 thoughts on “The 4313 has landed.”

  1. Or, if you want code that will compile easily on either a ‘2313 or a ‘4313, just do:
    #ifndef WDTCSR
    #define WDTCSR WDTCR
    #endif

  2. Considering some of the shortcuts and feature cuts I had to make with some of my Larson Scanner redevelopment projects, this is AWESOME news!

    Granted, it’s nice to be forced by memory limits to write clean code sometimes, but it will also be nice to be able to make some more feature-rich programs for ‘2313-based projetcs, too! :)

  3. I guess it won’t make much sense to have one in a 2313 project unless you need to expand it beyond its memory sizes :)

  4. Don’t get too discouraged by 128 bytes of RAM. You’d be surprised what you can get done in that. I did a cordless telephone handset in 2k rom, 96 bytes ram (68HC05) and a 4k part for the base. Bit-banged data over the RF channel, keyboards, audio path control, dtmf generation (simple d/a with a ladder and filter), piezo, battery charger. Shipped millions of these.

  5. Have you seen the ATTiny*61 devices? Same number of pins as the 2313, comes in 2k, 4k, and 8k versions, has an internal PLL for 16MHz speeds off the internal resonator. I just wish it were pin compatible.

  6. Hi,

    I obtained two t4313 from EMSL last week.
    I implemented USB-MIDI <> Serial-MIDI converter with one of t4313. The original software uses t2313. Because of V-USB stack I used, 2KB was not sufficient to implement both directions. I must choose one direction.
    Thanks to t4313, I can build bidirectional devices.

    USB-MIDI converter MOCO:

    http://bit.ly/hFHh26

    http://bit.ly/hBf865

    -Yoshi

  7. Would there be a non ATtiny4313 agnostic version of avr-gcc for linux as well?

    Everything I can find / compile doesn’t work…

    at best I get: "…attiny4313 … only supported for assembler…"

    1. My impression was that current versions of AVR-GCC for linux are *much* more up to date than the packages for mac and windows, which is a reason not to mention it. Have you run updates on your AVR-GCC/avr-libc?

      —
      Windell H. Oskay
      drwho(at)evilmadscientist.com
      http://www.evilmadscientist.com/

      1. Oh yes. I have the latest packages available for openSUSE 11.3

        I even went to avrfreaks.net and investigated how to compile my own version of the binutils/gcc/avr-libc. I also used their download/compile/install script.

        End of story: it doesn’t work. There seems to be one essential patch missing that enables device-support for the ATtiny4313. There is one patch out there on a freebsd page that should do it, but it doesn’t seem to work with any of the gcc source code versions I got hold of. Even the latest 4.5.2 doesn’t support this chip out of the box, which sucks.

        The latest WinAVR version works though… but I desire native apps on my machine. Seems like Atmel doesn’t feel like giving back information to the community.

        1. >The latest WinAVR version works though… but I desire native apps on my machine.
          >Seems like Atmel doesn’t feel like giving back information to the community.

          You seem to be misplacing your blame. WinAVR is based on AVR-libc, and is no longer updated. So the open source tools *do* support this, and have for quite some time. I don’t know how you can blame Atmel here.

          The problem, rather, is with your linux distribution and its maintainers. "Oh yes. I have the latest packages available for openSUSE 11.3"

          Have you actually checked what version those are? A quick search shows that AVR-libc is no longer being updated for openSUSE, so you’re apparently running an old (pre 1.7.0) version, even though it is the "latest" offered.

          Maybe see here, instead: https://build.opensuse.org/package/show?package=avr-libc&project=CrossToolchain%3Aavr

          —
          Windell H. Oskay
          drwho(at)evilmadscientist.com
          http://www.evilmadscientist.com/

            1. Despite all that, the basic problem is that you seem to be running an old version of AVR-GCC. I’m not sure if that’s because your sources were old or if you had an older version that was (and still is) installed.

              Regardless, your basic premise here– that the ‘4313 isn’t supported by linux –does not seem to be true. If you’d like additional help with this, please move this to the forum, as it’s heading towards tech support, not an actual comment on the blog entry.

              —
              Windell H. Oskay
              drwho(at)evilmadscientist.com
              http://www.evilmadscientist.com/

              1. No I didn’t.

                As a matter of fact, it was (up to a few days ago) not widely known which patches Atmel used to compile ‘their’ version of avr-gcc that is shipped with AVR-Studio. Downloading the latest versions of GNU gcc and applying the patches indicated on the avr-libc website did not produce a working compiler. As a user of a MAC, this may not have been affecting you.

                Fortunately this has changed !

                http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=104134

                This script will download and build a working version of avr-gcc/avr-libc/binutils on linux. You still have to apply the avrdude.conf patch as shown in this post though. You might also need udev rules to allow access to programmers (e.g. avrdude).

                Have fun.

Comments are closed.