Ragazzi, più volte sono inciampato sugli Attiny 13 costano poco, possono fare poco e sono ottimi per applicazioni ultra low cost senza troppo grattacapi il problema è il come programmarli senza passare per AVR studio o GCC, spero con la mia scoperta di aver risolto in parte il problema, ho trovato un core compatibile con l'IDE di arduino per programmarli, ne ho ordinati un paio e non appena mi arrivano faccio delle prove, nel frattempo se qualcuno li ha (Pelletta se non ricordo male) potrebbe fare delle prove 
spero di non aver scoperto l'acqua calda con questa cosa.. ecco il link utili:
Io ho gli ATtiny13A pure in package smd, la brutta notizia è che seguendo una discussione nel forum internazionale durante le prove ho messo i fuse sbagliati e ora devo risuscitarli con l'avr dragon. Fortunatamente non li ho schiacciati sulla morsa ma li ho conservati
Ora sono un pò impegnato dietro a un progettino ma appena mi libero faccio un pò di test.
Arriveranno giusti dopo la fine dei miei esami quindi proverò anche io, pensavo foste ancora senza un core adeguato :.
Ma un Attiny25? E' meglio dell'Attiny13, sia per Flash che per Ram. In più basta il core Tiny per programmarlo.
Quello che stanno sviluppando gli amici oltreoceano aveva (ha?) dei problemi, ricordo ad esempio che la funzione delay era del tutto imprecisa (ad esempio se mettevo delay(1000) il codice si bloccava per oltre mezzo minuto). Quando seguivo la discussione uscivano board ogni giorno e ho potuto provare fino a quando non ho incasinato i fuse per vedere se riuscivo a impostare il giusto clock. Non so se lo hanno sistemato, non ho più provato.
Ratto se ti può tornare utile metto il link al topic: http://arduino.cc/forum/index.php/topic,89781.0.html
Perfetto allora ne riparliamo all'arrivo dei micro 
Ratto sono arrivati gli attiny13?
Io ho iniziato
Intanto ho ripristinato i fuse e sto testando un pò il micro.
Come si vede c'è l'attiny13a sulla breadboard montato su quella specie di adattatore mentre a sx c'è l'avr dragon che sta in attesa di ripristinare il micro in caso di fuse sbagliati 
Dalle ultime prove che ho fatto funziona tutto, c'è solo un piccolo problema con la funzione delay: se imposto delay(10000) non ho 10 secondi ma 14.
Ho verificato questa cosa a 9.6 MHz, 1.2MHz e 128 KHz (in pratica lo fa sempre).
Questo è il file wiring.c del core, credo il problema possa essere risolto qua dentro ma lo ammetto senza problemi... non so dove mettere le mani
Sapete dove si può intervenire per poter correggere questa cosa?
/*
*** Core13 ***
Arduino core designed for Attiny13 and similar devices.
NO WARRANTEE OR GUARANTEES!
Written by John "smeezekitty"
You are free to use, redistribute and modify at will EXCEPT IF MARKED OTHERWISE IN A PARTICULAR SOURCE FILE!
Version 0.14
*/
#include "wiring_private.h"
#include <avr/interrupt.h>
volatile unsigned long ovrf=0;
ISR(TIM0_OVF_vect){
ovrf++; //Increment counter every 256 clock cycles
// PORTB = 0x18;
}
unsigned long millis(){
unsigned long x;
asm("cli");
/*Scale number of timer overflows to milliseconds*/
#if F_CPU == 128000
x = ovrf * 2;
#elif F_CPU == 600000
x = ovrf / 2;
#elif F_CPU == 1000000
x = ovrf / 4;
#elif F_CPU == 1200000
x = ovrf / 5;
#elif F_CPU == 4000000
x = ovrf / 16;
#elif F_CPU == 4800000
x = ovrf / 19;
#elif F_CPU == 8000000
x = ovrf / 31;
#elif F_CPU == 9600000
x = ovrf / 37;
#elif F_CPU == 10000000
x = ovrf / 39;
#elif F_CPU == 12000000
x = ovrf / 47;
#elif F_CPU == 16000000
x = ovrf / 63;
#else
#error This CPU frequency is not defined
#endif
asm("sei");
return x;
}
unsigned long micros(){
return millis() * 1000; //To keep it simple and small :) //I will correctly implement this one of these days.......
}
void delay(unsigned ms){
while(ms--){
_delay_ms(1); //Using the libc routine over and over is non-optimal but it works and is close enough
}
//Note, I may have to reimplement this because the avr-libc delay is too slow *todo*
}
void delayMicroseconds(unsigned us){
//*todo* measure actual speed at different clock speeds and try to adjust for closer delays
if(us == 0){return;}
#if F_CPU == 16000000 || F_CPU == 12000000
if(--us == 0){return;}
us <<= 2;
us -= 2; //Underflow possible?
#elif F_CPU == 8000000 || F_CPU == 9600000 || F_CPU == 10000000
if(--us == 0){return;}
if(--us == 0){return;}
us <<= 1;
us--; //underflow possible?
#elif F_CPU == 4000000 || F_CPU == 4800000
if(--us == 0){return;}
if(--us == 0){return;}
//For 4MHz, 4 cycles take a uS. This is good for minimal overhead
#elif F_CPU == 1000000 || F_CPU == 1200000//For slow clocks, us delay is marginal.
if(--us == 0){return;}
if(--us == 0){return;}
us >>= 2;
us--; //Underflow?
#elif F_CPU == 600000
if(--us == 0){return;}
if(--us == 0){return;}
us >>= 3;
#elif F_CPU == 128000
if(--us == 0){return;}
if(--us == 0){return;}
us >>= 5;
#else
#error Invalid F_CPU value
#endif
asm __volatile__("1: sbiw %0,1\n\t"
"brne 1b" : "=w" (us) : "0" (us));
}
void init(){
//Setup timer interrupt and PWM pins
TCCR0B |= _BV(CS00);
TCCR0A |= _BV(WGM00)|_BV(WGM01);
TIMSK0 |= 2;
TCNT0=0; //Causes malfunction?
sei();
//Set up ADC clock depending on F_CPU
#if F_CPU == 128000
ADCSRA |= _BV(ADEN);
#elif F_CPU == 1000000 || F_CPU == 1200000 || F_CPU == 600000
ADCSRA |= _BV(ADEN) | _BV(ADPS1);
#else
ADCSRA |= _BV(ADEN) | _BV(ADPS1) | _BV(ADPS0) | _BV(ADPS2);
#endif
}
Credo che l'unico che possa aiutarti è leo,è lui l'esperto di timer e schedulazione 
Madwriter:
Credo che l'unico che possa aiutarti è leo,è lui l'esperto di timer e schedulazione
solo? è uno dei piu esperti programmatori italiani
Salve, ritorno ora dall'orale, che penitenza, 4 ore fuori ad aspettare ed 1 e mezza dentro a sfamare i prof affamati di sapere 8)
No non mi sono ancora arrivati =(
ratto93:
Salve, ritorno ora dall'orale, che penitenza, 4 ore fuori ad aspettare ed 1 e mezza dentro a sfamare i prof affamati di sapere 8)
No non mi sono ancora arrivati =(
Auguri sai già qualcosa sul voto?sono rimasti contenti i prof del progetto?
Leggendo il codice ( e i commentin dell'autore) forse il problema è proprio la funzione delay!
void delay(unsigned ms){
while(ms--){
_delay_ms(1); //Using the libc routine over and over is non-optimal but it works and is close enough
}
//Note, I may have to reimplement this because the avr-libc delay is too slow *todo*
}
Lui stesso dice che
//Using the libc routine over and over is non-optimal but it works and is close enough
hai la possibiltá di vedere come è implementata la funzione in altri core?
N.
ratto93:
Salve, ritorno ora dall'orale, che penitenza, 4 ore fuori ad aspettare ed 1 e mezza dentro a sfamare i prof affamati di sapere 8)
No non mi sono ancora arrivati =(
giustooo gli orali ] beh ora sei piu libero
Madwriter:
ratto93:
Salve, ritorno ora dall'orale, che penitenza, 4 ore fuori ad aspettare ed 1 e mezza dentro a sfamare i prof affamati di sapere 8)
No non mi sono ancora arrivati =(Auguri
Del voto ho qualche sentore, le prove sono andate ben diversamente da quello ce speravo =(
I prof boh, speravo di sbalordirli ma se portavo il brat forse era meglio....
Madwriter:
Credo che l'unico che possa aiutarti è leo,è lui l'esperto di timer e schedulazione
Non esageriamo, ho solo studiato i datasheet.
Pelletta:
Dalle ultime prove che ho fatto funziona tutto, c'è solo un piccolo problema con la funzione delay: se imposto delay(10000) non ho 10 secondi ma 14.
Ho verificato questa cosa a 9.6 MHz, 1.2MHz e 128 KHz (in pratica lo fa sempre).
Potrebbe essere normale, ossia gli oscillatori interni hanno imprecisioni anche del +-10/20% rispetto al valore nominale. Cioè se metti l'oscillatore a 1 MHz potresti avere anche un clock di 0,9 MHz. Ecco quindi spiegato perché il tuo delay è più "lungo".
Per riprova dovresti provare con un altro Attiny e vedere se hai lo stesso ritardo o se il delay(10000) viene eseguito con un altro tempo.
Ti porto la mia esperienza: Atmega644, Atmega328, Attiny84 e Attiny85, tutti con il Blink caricato e clock ad 1 MHz interno: dopo 4/5 lampeggi già i led sono fuori sincronizzazione.
superp:
Leggendo il codice ( e i commentin dell'autore) forse il problema è proprio la funzione delay!void delay(unsigned ms){
while(ms--){
_delay_ms(1); //Using the libc routine over and over is non-optimal but it works and is close enough
}
//Note, I may have to reimplement this because the avr-libc delay is too slow todo
}
Lui stesso dice che > //Using the libc routine over and over is non-optimal but it works and is close enough hai la possibiltá di vedere come è implementata la funzione in altri core? N.
e sostituirlo con
void delay(unsigned ms){
while(ms--){
delayMicroseconds(1000); //Using the libc routine over and over is non-optimal but it works and is close enough
}
//Note, I may have to reimplement this because the avr-libc delay is too slow *todo*
}
sembra fatta meglio delayMicroseconds però sono completamente ignorante in materia XD
leo72:
...
Per riprova dovresti provare con un altro Attiny e vedere se hai lo stesso ritardo o se il delay(10000) viene eseguito con un altro tempo.
Ok, farò la prova con un altro attiny giusto il tempo di preparare un altro adattatore.
Proverò anche la modifica suggerita da superp.
Per ora grazie ragazzi, farò sapere come è andata
Il problema che ho poi già detto è la quantità di Flash.
In 1 kB solo di Flash non ci metti nulla. Per ridurre il consumo di memoria, l'autore ha deciso di usare la funzione delay_ms della libreria libc che, ammette lui stesso, è imprecisa. Si potrebbe implementare qualcosa di un pochino più preciso ma a discapito dell'occupazione di memoria.
leo72:
Il problema che ho poi già detto è la quantità di Flash.
In 1 kB solo di Flash non ci metti nulla. Per ridurre il consumo di memoria, l'autore ha deciso di usare la funzione delay_ms della libreria libc che, ammette lui stesso, è imprecisa. Si potrebbe implementare qualcosa di un pochino più preciso ma a discapito dell'occupazione di memoria.
ma richiamando una funzione già lì non dovrebbe esserci consumo di memoria, sbaglio? 
Il consumo di memoria dipende dal codice. Per far tornare il delay andrebbe un pochino rivista quella funzione: potrebbe aumentare, come diminuire. Non so di preciso. Non ho mai usato la delay_ms di libc né ho sottomano gli Attiny13 per provare.
Ora ci studio...