ATtiny13A programming

[IvoS]

OK. So far I was playing with Arduino UNO because it was easy to get and came with bootloader so I could use Arduino software right away. I want to use ATtiny13A in my design but... how to program it? Can I use Arduino UNO as ISP programmer perhaps? or  Is there a way to write the program in Arduino software and create a HEX file, then export the HEX file into my MiniPro and program this way? Or use a FTDI friend from Adafruit which I have and go from Arduino software through that? I am lost.

[Tac Eht Xilef]

You can use your Uno as an ICSP, by loading a sketch into it in the usual way & placing a 10uF capacitor between RESET & GND. Google "ArduinoISP" for details.

You can use the Arduino software to create a hex file for your ATiny13 by installing some additional core files & modifing boards.txt so you can choose ATtiny13 as a target. Google "Arduino ATtiny13" for details.

You can then compile your sketch, dig the .hex file out of the bowels of your Arduino installation, and load it into your ATtiny using your Uno as an ICSP. Google "Arduino without bootloader".

[SirNick]

The ATtiny13A is pretty small though - 1K flash, 64B RAM.  That'll go quick.  You might want to give Atmel Studio a try.  Once you start hacking the Arduino environment to support non-standard hardware, you're already putting in more effort than it takes to learn straight AVR.  (Remember:  Arduino C is AVR C with a few custom libraries and an awful IDE.)

You can also import those Arduino libraries into an Atmel Studio C++ project and use any AVR MCU you want.  (Of course, some of it scales to different ICs and clock frequencies, and some requires some fudging.  Same goes with third-party libraries.)

Try it.  You'll probably soon find out that you can write small AVR C programs with less trouble than trying to shoe-horn Arduino into all your projects.  (Every tool has its job.)

[IvoS]

I might give that Atmel Studio a try, once again. I have had it once already but the program itself is big and requires so much external crap to be installed with it, so I went back with Arduino. I first wanted  ATtiny13A but I may end up getting ATtiny85 instead. More space indeed. I just wanted something small in DIP package with just few pins, that's all I need for my project. But I would like to be able to use my MiniPro programmer to upload the program this way. I am totally new in this, so any info helps.  Thanks.

[dannyf]

but the program itself is big

That's why I always recommend AVR Studio 5 - it doesn't have the support for their ARM chips.

Alternatively, you can develop C code (Arduino-less) in the Arduino environment.

If that's what you want to do - with so limited sources, I think it is your own option - I would switch to gcc + Code::Blocks, for a "proper" IDE.

[westfw]

I always recommend AVR Studio 5

Opinion over on AVR freaks is that AS5 was a buggy nightmare.
For tiny13-sized projects, the arduino IDE or the WinAVR command-line tools should be sufficient.
(your arduino install already includes WinAVR; you just have to put the appropriate directories in your path.)

When I'm actually writing code, as opposed to making minor changes, I like to put the Arduino IDE in "use external editor" mode, and use a real editor (EMACS for me, but ... whatever.)  This works surprisingly well.

Arduino 1.5.7 now includes a very recent version of avr-gcc (4.8.1, I think), BTW.

[Tac Eht Xilef]

When I'm actually writing code, as opposed to making minor changes, I like to put the Arduino IDE in "use external editor" mode, and use a real editor (EMACS for me, but ... whatever.)  This works surprisingly well.

You almost have to, don't you? For what's supposed to be a kind & gentle intro to uCs & programming, the Arduino's so-called "IDE" is a shocker.

Myself, I use Xcode with AVR-Crosspack or embedXcode.

[SirNick]

Opinion over on AVR freaks is that AS5 was a buggy nightmare.

And I would agree.  I really only ran into a few bugs, but they were annoying enough that I wouldn't consider going back just to save some disk space.

AS is big, but even the Arduino install isn't exactly small.  Development environments just kinda aren't compact by nature.  If that's important to you, you can technically do all your code editing on your own, and just use the CLI tools from the Arduino installation to compile.  Not exactly a user-friendly method if you're used to the Arduino IDE, but if you cut your teeth on 'Nix or DOS systems, it might be comfortable enough.

The nice thing about moving to plain C/C++ though, is that you get access to the whole product portfolio.  Need small and cheap?  Use the 13A.  Need UARTs?  ATtiny2313.  Need the kitchen sink?  ATmega1284P.  SMD OK?  ATmega2560.  No worrying about "cores" and translating pin assignments and all that, although you do need to know the peripheral registers a little better.  That's something you'll need to come to grips with to move beyond AVR though, so it's time well spent.

As far as hardware tools:  To this day, I still don't own a proper programmer.  I just use an Uno with the ISP sketch on it, along with AVRdude -- it works fine.

[IvoS]

Thank you all. I think going with pure C++ is the way. I would like to have the door opened with all the options right away.  I know I will have to grasp a lot of things around it befeore I even begin. I don't know how to configure fuses for example and where to get that info from. I think that Arduino doesn't even have an option for fuses config.. ?
Anyway, a good literature will be a start. I am not new to electronics, I designed some stuff but I am totally green to programming.

[westfw]

I think that Arduino doesn't even have an option for fuses config

That's correct.  Nor does the bootloader (which is the usual method of programming an arduino) allow the fuses to be changed (which would be a bad idea if you wanted the bootloader to continue working!)

I use http://www.engbedded.com/fusecalc

I think going with pure C++
  :
a good literature will be a start.

The Atmel full-length data sheet, and the avr-libc documentation, is where you should start.
Unfortunately for C/C++ programers, the AVR datasheets are NOT very C-oriented.

BTW, the ATtiny13 is a pretty old chip.  Unless you got a really good deal on hundreds of them, you should think seriously about using a newer chip like the ATtiny85 instead.  (Beware pricing "strangeness" with these small chips.  At digikey, the ATtiny45 is cheaper than the ATtiny25, even though it has twice as much flash...

[SirNick]

The fuses are stored in the boards.txt (or whatever it's called) that defines the Arduino IDE's known target hardware.  You can pull the defaults from that file for a starting point, but remember they're device-specific.  I.e., you can't just use the ATmega328P fuses for a Tiny.  The Engbedded link that westfw posted is the de-facto resource for setting fuses (along with the datasheets, of course.)  Bookmark it, you'll use it a lot.  Know whether you need a 1 or 0 for each fuse, and understand that some devices are masked, so the value read back won't necessarily match the value you wrote.

There's a bit of a learning curve to go from Arduino to AVR, but it's not too bad.  You have to understand the difference between the bootloader code upload method (using the IDE's Upload function to speak to the target via serial) and the Upload with Programmer method (using ISP from a programming device to the target device via SPI.)  Just assume the bootloader is no longer an option, and get used to uploading hex images via a programmer.  It's not hard.  You need to know what fuse settings to use, and how to use the programmer of your choice.  AVRdude is pretty good, but it's very CLI-heavy.  If you go that route, follow a guide (Adafruit has one) to get started, and write down the command line you need.  Unless you do it everyday, you won't remember in a week.  There are plenty of GUI options if you prefer, but AVRdude is used all over the place (e.g., the Arduino IDE) so it helps to know it.

Finally, a good way to ween yourself from Arduino to AVR is to find a guide that shows you how to import the Arduino libs to Atmel Studio.  This will give you a few in-between steps so you're not thrust in a foreign environment.  It'll also make it more clear what's AVR code and what's Arduino code, as well as showing you how to set up projects in the new IDE.

Give it a shot, and don't give up if you hit a wall somewhere.  Help is a post away.

[IvoS]

Thank you. Would you please somebody give me a suggestion on C++ book - source material to learn from, or any start guide book to Atmel family specifically? Thank you. 

[SirNick]

In terms of just C, I liked O'Reily's "Practical C Programming".  There's also "Practical C++ Programming", which I also have -- it uses (nearly) identical text for the chapters where C++ is based on C, but the OO stuff is unique to the latter book.  The C subject matter (the first half of the book) was written very well.  The C++ subject matter feels a little tacked-on, but overall, it's still pretty good.  If you're comfortable with C already, go elsewhere.  If you want to start from the beginning, it's a really good book for that.

There's not much you need to learn, in terms of the language, for Atmel devices specifically.  Bookmark the avrlibc site, you'll reference it a lot.  You do need to be able to read and understand the datasheet sections on the peripherals you're interested in (e.g., timers and UARTS, etc.)  If you can read the datasheet and figure out what code is required to (e.g.) turn off the watchdog timer, you're in good shape.

Learning a programming language (or a new microcontroller) is an exercise in immersion, just like a spoken language.  You need to devise a project that is SIMPLE and ATTAINABLE, and will keep you interested enough to provide the motivation to get through initial hurdles.  Hello World will teach you how your IDE / compiler works, and what a minimal C program looks like.  Then, it's up to you to find your bliss.  For me, it was 1) learning how to open a WAV file and show the metadata; then 2) learning how to open an audio device; and 3) learning how to play the audio data from a file.  That was my intro to C, and I'm still working on that project to this day -- but, obviously, now it does a lot more.

From my example, you can tell I learned how to program on a PC rather than a micro.  If you're just starting out with C, you might want to get your bearings with Linux and GCC, or Windows and Visual Studio Express, or Mac and Xcode.  The write / build / debug cycle is a lot easier when you have a full dev environment.  If you're already used to coding from the Arduino, then you're probably good to go.

[IvoS]

I managed to upload to ATtiny13A chip using Arduino Uno as ISP. Found instruction on https://github.com/tekstop/attiny/tree/Arduino1. I also added "defined(__AVR_ATtiny13__)" into "wiring.c" file.  I uploaded simple blink program and it works. However, I wrote "delay(100);" in Arduino program but the oscilloscope shows 95ms pulse width instead. What is the problem and how can I fix this to be exactly 100ms?

[dannyf]

What is the problem

Too high an expectation: delay() isn't meant to be accurate.

If you do want accurate timing, run it off a crystal and / or use timers.

and how can I fix this to be exactly 100ms?

You may try to change the code to adjust its timing to 100ms.

[IvoS]

Arduino Uno has time delays accurate. 1ms written code is actually 1ms on the scope. Is it because the clock frequency comes from the crystal on the board?

[Tac Eht Xilef]

Arduino Uno has time delays accurate. 1ms written code is actually 1ms on the scope. Is it because the clock frequency comes from the crystal on the board?

Yup. Uncalibrated, the internal RC clock on the ATtiny13 is only accurate to (I think) +-10% e.g. 90-110ms for your example. 95ms is only 5% out, so it's within spec. A typical oscillator or crystal is +-50ppm (i.e. 0.005%) or better, so the Uno will be much more accurate e.g. 99.995-100.005ms.

You can adjust the OSCCAL value to get getter than +-2% (e.g. 98-102ms) from the internal oscillator, or use an external clock for much better accuracy & stability. Note that the ATtiny13 only has a single CLK IN pin so it requires a stand-alone oscillator (not just the typical crystal + 2 caps).

[GiantGnome]

Depending on how accurate you need, it is also possible to calibrate the internal clock, by changing the OSCCAL register. Look on page 27 in the datasheet.

More advanced method (which I have not read), would be to check this app-note.

[IvoS]

Arduino Uno has time delays accurate. 1ms written code is actually 1ms on the scope. Is it because the clock frequency comes from the crystal on the board?

Yup. Uncalibrated,

the internal RC clock on the ATtiny13 is only accurate to (I think) +-10% e.g. 90-110ms for your example. 95ms is only 5% out, so it's within spec.

A typical oscillator or crystal is +-50ppm (i.e. 0.005%) or better, so the Uno will be much more accurate e.g. 99.995-100.005ms.

You can adjust the OSCCAL value to get getter than +-2% (e.g. 98-102ms) from the internal oscillator, or use an external clock for much better accuracy & stability. Note that the ATtiny13 only has a single CLK IN pin so it requires a stand-alone oscillator (not just the typical crystal + 2 caps).

Good to know. And yes. I tried another tiny13A and the internal oscillator is slightly different again. It outputs 97ms this time. Thank you for sharing this info.