The Blink sketch reported that it was writing 632 bytes. That's a lot more than if you coded it using avr-gcc directly, but still leaves a lot of space for additional code.
All this took about an hour. I think it was time well spent and hopefully someone else can use it too.
I happened to have purchased several of the 25's a few years ago and never got around to using them, so I thought I would see if this worked. Now I can utilize my existing stock of these using the same IDE.
if you excange "ATtiny25" with the name of the chip, "2048" with the maximum size of the the memory, "attiny25" with the name of the chip but without caps and "attiny45_85" with the name of the folder there you have saved "WProgram.h" etc? If yes, what do you need to change in that folder (attiny45_85 in this case)? I've read about that you need to change the both files "WProgram" and "pins_arduino". Is that right?
if you excange "ATtiny25" with the name of the chip, "2048" with the maximum size of the the memory, "attiny25" with the name of the chip but without caps and "attiny45_85" with the name of the folder there you have saved "WProgram.h" etc?
Yes. It can be helpful to include fuse settings as well.
If yes, what do you need to change in that folder (attiny45_85 in this case)?
The minimum to change is "pins_arduino.c". Sometimes the timers are different which requires changes to other files. Sometimes the analog input is different requiring changes to other files.
I've read about that you need to change the both files "WProgram" and "pins_arduino". Is that right?
I can't remember having change anything in "WProgram.h". But different processor families require a different "pins_arduino.c".
The current Arduino core is a good example and includes support for at least one tiny processor.
I just realized that my boards.txt file specified the CPU at 1mHz instead of 8.
attiny25.build.f_cpu=1000000L
That could explain why I am having so much trouble trying to tune the OSCCAL value.
If you are going to set the low fuse bit for 8mHz the correct value for this would be:
I was tuning it manually with a sketch that sets OSCCAL then turns an i/o port on and off every second and measuring that with an oscilloscope. Then modify the value being written to OSCCAL, redownload the sketch, remeasure, repeat. Kind of the brute force way to go about it. I'll have to look into AVR053.
Yes, f_cpu is the speed in Hz. If you look in the Arduino code (don't recall which file) it is actually using f_cpu in some calculations for the timing routines.
I had not seen that specific post, but had thought about timing serial data in order to calibrate. I will look that post over in detail.
I have been playing around a bit more. I set the clock to 8mHz in the boards.txt file as shown above (and set the lfuse appropriately), and was able to run the program below with the factory calibration. This program outputs the alphabet to a serial LCD at 9600 baud. I haven't tried a serial receive, but don't see why it wouldn't work.
#include <SoftwareSerial.h>
#define RXPIN 255
#define TXPIN 0
// set up a new serial port
SoftwareSerial mySerial = SoftwareSerial(RXPIN, TXPIN);
void setup()
{
pinMode(TXPIN, OUTPUT);
mySerial.begin(9600);
// Let the LCD get booted up
delay(5000);
// Home the cursor
mySerial.print("?f");
}
void loop()
{
for( char c='A'; c<'Z'; c++)
{
mySerial.print(c);
}
delay(5000);
}
In my testing, 9600 baud has worked consistently with "uncalibrated" processors. But I've only tested about a dozen.
Oh, and SoftwareSerial is a bit flaky. I think the bit timing is not quite right. I had all sorts of problems at baud rates above 19200. Even on "calibrated" processors. NewSoftSerial (which won't compile without changes on an 25 / 45 / 85 processor) works much better.
I wish the Arduino team would really make the ATTiny natively compatible. It's a great chip for small home-built Arduinos that don't need a kazillion I/O pins and need to save space.
They probably don't have interest because an ATMega2560 SMD chip is practically smaller than an DIP ATTiny85 so what would be the point I guess.
Oh, and SoftwareSerial is a bit flaky. I think the bit timing is not quite right. I had all sorts of problems at baud rates above 19200. Even on "calibrated" processors. NewSoftSerial (which won't compile without changes on an 25 / 45 / 85 processor) works much better.
That is exactly why I used SoftwareSerial, it didn't need any changes to run. I've looked at the NewSoftSerial code and IMO it would need extensive changes as it makes much heavier use of interrupts. It's a great library for a regular Arduino, but way beyond my abilities to modify for a Tiny25. I don't need anything beyond 9600 anyway, so I'll wait for someone else to port NewSoftSerial.
I also meant to mention that the program I used to write to an LCD used a little over 1100 bytes, so there is still quite a bit of room for other code even on the Tiny25.
For this one I also had to modify the boards.txt file to include entries for the Tiny25 which I created by copying the Tiny45 section and changing the relevant bits to Tiny25.
I was able to download the above LCD write sketch and also did tests of analogRead, analogWrite, tone, noTone, etc.
That is exactly why I used SoftwareSerial, it didn't need any changes to run
The latest version of the Arduino Tiny core includes "Tiny Debug Serial". If you only transmit, it should make a very nice replacement for SoftwareSerial. I beleive it's smaller and the timing should be dead-on. Some details are here... http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1285218245/25#25
For this one I also had to modify the boards.txt file to include entries for the Tiny25 which I created by copying the Tiny45 section and changing the relevant bits to Tiny25.
Please post your changes. I'll add them to the Arduino Tiny core.
I was able to download the above LCD write sketch and also did tests of analogRead, analogWrite, tone, noTone, etc.
