Il problema l'ho scovato, non riesco in pratica a gestire il software con l'opzione RISING, visto che prevede il passaggio da LOW ad HIGH, INT0 non si accorge quando resta su HIGH e non riesco a controllare lo stato del pin INT0 (PD2) con un banale digitalRead (2), che evidentemente è disturbato dall'INT0.

Non puoi usare l'opzione rising in sleep, devi usare i valori assoluti HIGH o LOW, la modalità rising /falling richiede che la CPU sia attiva.

a questo punto se il ragionametno è corretto il problema principale è il sw che traduca l'impulso in un tasto funzione (F12 ad esempio).
e de  qui che il buon samaritano entra in azione!!!

Il problema è proprio il sensore, un conto è un pulsante e un conto è un elettrodo per captare le debolissime correnti legate ai movimenti muscolari.
Forse non ti rendi conto di quanto sia complessa e delicata la questione, ecco perché ti ho chiesto se hai già un sensore commerciale, cioè elettrodo e relativo amplificatore, oppure tocca inventarselo, nel secondo caso la realizzazione non è alla portata di tutti, serve perizia e serve la strumentazione per verificare che funzioni correttamente.
Per quanto riguarda la comunicazione tra Arduino e il PC ti ho già spiegato che Arduino non dialoga come emulazione tastiera, dialoga col pc tramite emulazione porta seriale, quindi non preme nessun tasto, può solo inviarti sulla seriale una lettera, o una sequenza di lettere e/o numeri.
Da un punto di vista puramente teorico l'interfaccia USB della UNO può essere riprogrammata per funzionare come emulazione tastiera, però poi non puoi più trasferire i programmi su Arduino e la cosa non è semplice ne da implementare ne da mettere in pratica senza disporre dei giusti strumenti di lavoro.

Ho montato anche io wm+ e nunchuck con il multiwii, però qualche volta non mi legge il nunchuck.. ma basta staccare e riattaccare che funziona tutto..

Nel video che hai postato non vedo le resistenze di pullup e vedo che alimenti il tutto da un pin di Arduino senza nemmeno mettere i diodi in serie.
Così non va bene, alimenta il tutto direttamente dai 3.3V forniti da Arduino e metti due pull up da 1.5k su SCL e SDA del WMP.
Io ho lasciato il WMP in funzione per diverse ore di seguito per sincerarmi se veramente perde la comunicazione come asserisce l'autore del MultiWii, per questo motivo ha previsto l'alimentazione tramite un GPIO con due diodi in serie per poter resettare a comando il WMP, non ho riscontrato nessun problema.
La mia ipotesi è che i problemi lamentati sono dovuti a valori non idonei per le pull up sulla I2C, se non la totale mancanza di queste, con device non originali funziona lo stesso perché le pull up possono incluse sul WMP, però sono di alto valore e sicuramente portano a vari problemi quando si collega tutto il resto.

[ATTENZIONE]

potete inviarmi una foto dei dispositivi collegati?? non ho ancora capito come si collegano.... e in giro non ho trovato foto..

Se vai alla pagina 17, replay 251, ho messo una foto di come ho montato il WMP e l'accelerometro ADXL345 su una breadboard per fare le prove.
Se usi tutti device I2C il montaggio è semplicissimo, devi mettere in parallelo tutti i segnali SCL su una linea e gli SDA su una seconda linea, SCL lo colleghi ad A5 di Arduino e SDA ad A4, metti due resistenze di pull up da 1.5k (valore più che sicuro) su SCL e SDA collegandole al +3.3V.
ATTENZIONE che tutti i device I2C che si collegano al MultiWii DEVONO essere alimentati a 3.3V, assolutamente da evitare l'alimentazione a 5V, chi scrive che si può fare sta dicendo delle cavolate enormi.

Grazie per la risposta ma ormai ho comprato il braccialetto, male non fa.

Il braccialetto deve essere messo a terra, quindi o lo colleghi alla presa di terra dell'impianto elettrico oppure ad un punto conduttivo dell'impianto idraulico, puoi anche allungare il cavo se necessario.

ma per paura di danneggiarli ho acquistato anche un braccialetto antistatico, il problema è che non so come usarlo.

Non crearti problemi che non ci sono, prima di toccare componenti elettronici sensibili alla ESD, e gli ATmega sono decisamente robusti sotto questo profilo, basta che tocchi con le mani un cavo (la parte conduttiva) di messa a terra o una parte conduttiva del termosifone e stai pure tranquillo che non fai danni.
Le situazioni realmente pericolose sono con umidità molto bassa e se indossi indumenti che favoriscono la generazione e l'accumulo di elettricità statica, ovvero quando toccando qualcosa che permette di scaricare prendi la "scossa" o comunque avverti il senso di fastidio legato alla scarica elettrica.
Le varie norme di precauzione con bracciali, tappeti, calzature e abbigliamento particolari si mettono in atto in ambienti dove è facile accumulare cariche statiche, p.e. durante il confezionamento dei componenti elettronici, oppure in laboratori dove si utilizzano componenti particolarmente sensibili.

GemPC TWIN USB....

Questo è un vetusto lettore di smartcard, quelle vere e non i "tarocchi" realizzati con un qualche micro, ovvero si aspetta di leggere determinate informazioni a risposta di determinate domande.

ed uno seriale attaccato ad un programmatore JDM

Il JDM pure lui un incubo elettronico, a parte il fatto che per funzionare richiede una vera porta seriale COM1 o COM2, non vanno bene quelle con adattatore USB e nemmeno quelle aggiuntive su bus pci, rimane il fatto che funziona (quando funziona) solo per pochissimi modelli di PIC tra i quali non è incluso il 16F876.

Resta comunque il fatto che un programmatore apposito cè l'ho.... e ho i suoi driver ma manca tutto il resto..

Che programmatore hai ?

Il ludipippo è un semplice PCB che alla fine ha un PIC16F628 nulla più nulla meno

Il ludipipo,  e non pippo, era un programmatore per PIC disegnato da uno che non sapeva una benemerita acca di elettronica e pic, un vero incubo elettronico, poteva funzionare solo con la prima serie dei PIC16F84 per via di una maggiore tolleranza rispetto alle specifiche per la programmazione.
Le varie smartcard nate nel periodo d'oro dello "studio" delle codifiche sat erano basate o su un PIC 16fxxx oppure sugli ATmega90xxx, per poterle utilizzare a fini costruttivi, p.e. una serratura elettronica, è indispensabile sapere quale hardware contengono perché cambia sia la modalità di programmazione hardware sia l'ambiente di sviluppo del software stesso.

... io vorrei programmare questo tipo di schede.. alcune monteno una MCU ed una EEPROM
questa è una:
http://www.telcominstrument.com/p_162_silver-card-smartcard-pic-16f876-e-memoria.html

Questa usa un PIC16F876, se non hai il programmatore specifico per i PIC non ci fai nulla.

altre qui...
http://www.boxsat.com/fun-cards.html

Questa usa l'AT90S8515, non lo puoi programmare tramite lo sketch ISP di Arduino, non puoi nemmeno usarlo con un bootloader, anche in questo caso serve un vero programmatore per AVR.

Inoltre l'ide di arduino zavorra di circa 450 bytes tutti gli sketch.
Provate a compilare uno sketch vuoto solo con setup e loop.

Tutti i compilatori, qualunque linguaggio, aggiungono del codice a quello che viene scritto, serve per gestire i vari servizi che l'utente non vede, ma ci sono, come lo stack, le variabili dinamiche, la ISR, etc, inoltre allocano a loro uso esclusivo della ram per le variabili di sistema, lo stack e l'heap, solitamente è possibile intervenire sulle dimensioni dello stack e dell'heap tramite file di configurazione del compilatore o il file del linker.
Wiring aggiunge ancora più codice di quello che normalmente mette il compilatore perché si sono anche le varie funzionalità di base di Arduino, p.e. la gestione del timer 0 che viene utilizzato come clock di base del sistema e il relativo interrupt, poi ci sono le varie routine di base del core che vengono comunque compilate anche se lo sketch è vuoto, tutte cose che utilizzano memoria flash e ram.
Compilando un programma in C ANSI tramite gcc-avr, cioè il compilatore usato da Arduino, completamente vuoto salvo definire la main() con dentro almeno un'istruzione, altrimenti non è possibile compilare, cioè una cosa come questa:

Code:

int main()
{
 char i;
 i =0x00;
}

Il risultato è che occorrono 138 bytes di flash se compilato per l'ATmega 328, compilato per l'ATmega 2560 servono 292 bytes di flash, se lo compilo per l'ATTiny 85 bastano 58 bytes.

Mi dispiace deludervi ma.. non va bene per l'Attiny perché questo non ha timer a 16 bit ma solo a 8 bit, come ho già scritto più sopra 

Si, ma ho anche detto che la stessa cosa è applicabile a qualunque timer degli ATmega, basta solo cambiare i nomi dei registri.
Per l'esempio ho usato il timer1 solo perché consente una migliore precisione per il problema di Michele, ma potevo benissimo farlo con il timer 2 o il timer 0 che sono a 8 bit.

non vorrei ordinar 2 volte

Basta che entri nel tuo acconto e sotto la voce ordini trovi tutto lo storico, se non è presente vuol dire che non è stato concluso, se è presente hai pure il numero di riferimento e basta che telefoni per avere tutte le informazioni del caso.

Senti, non esplodere, mi dai quella piccola dritta sul tiny, così posso fare le prove su entrambi i micro? 

Semplicemente prova ad inizializzare il PWM tramite analogWrite, però usa i pin abbinati al timer 1, e poi prova a variare il contenuto di OCR1C per vedere se cambia la frequenza.

per la dimostrazione che hai dato di quanto ancora possano produrre questi piccoli scarafaggi, rispetto alle già ottime potenzialità di Arduino.

Sicuramente mi crocifiggeranno in sala mensa per quello che sto per dire, però wiring è una bella palla al piede per l'ATmega sia come risorse utilizzate sia come impiego del tempo cpu, ovviamente la semplicità d'uso ha un prezzo e chi ne risente sono proprio le prestazioni.
Un esempio banale, per settare un pin wiring usa la digitalWrite, tradotta in assembler sono circa una quindicina di istruzioni e ci mette circa due microsecondi per essere eseguita.
In C per cambiare lo stato di un pin scrivo direttamente sul registo macchina del port, p.e. se voglio accendere il led di Arduino, pin 13, scrivo 1 sul quinto bit di portB, ovvero PORTB = 0b10000; una sola word di memoria e solo 62.5 ns per l'esecuzione.
Se voglio scrivere solo il quinto bit senza alterare gli altri, o doverli riscrivere tutti, uso una mascheratura AND o OR, p.e. per settare solo il bit 5, lasciando gli altri inalterati, scrivo  PORTB != 0b10000; due word di memoria e 125 ns per l'esecuzione.

Ed ecco la soluzione 2:

Code:

#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))

unsigned char out_bit = 0, c_puls = 0, riarma;

void setup()
{
  pinMode(11, OUTPUT);    
  pinMode(13, OUTPUT);  

  TCCR1A = 0b00000011;     // mode 15, fast pwm
  TCCR1B = 0b00011001;

  sbi (TIMSK1,TOIE1);      // enable Timer1 Interrupt
}

void loop()
{
  digitalWrite(13, HIGH);
  delay(1);
  digitalWrite(13, LOW);
  delay(1);
  riarma = 10;
  c_puls = 0;
  out_bit = 0;
}

ISR(TIMER1_OVF_vect)
{
  if (c_puls < riarma)  
  {
    out_bit ^= 1;
    digitalWrite(11,out_bit);
    OCR1A = 209;
    c_puls++;
  }
}

In questo caso usiamo il timer 1 perché è quello a 16 bit e offre maggiore  risoluzione, ma il tutto è applicabile a qualunque timer cambiando il nome dei registri, selezioniamo il modo 15, fast pwm, scollegando il timer dai pin di uscita in modo da poter usare il registro a 16 bit OCR1A come preset per il conteggio.
Attivando l'interrupt del timer 1, sbi (TIMSK1,TOIE1), ogni volta che questo arriva a 0 chiama la relativa ISR, ovvero la funzione ISR(TIMER1_OVF_vect) (timer 1 overflow), dove cambiamo lo stato di un pin a nostro piacere ogni volta che viene chiamato l'interrupt.
Introducendo due variabili di controllo, c_puls e riarma, per contare il numero di impulsi emessi è possibile far commutare il pin un numero predeterminato di volte in base ad un evento prestabilito, nel nostro caso un delay di 2 ms all'interno della loop.
Purtroppo questo metodo presenta uno svantaggio utilizzato all'interno di wiring, dato che sono attivi in simultanea altri interrupt su cui non abbiamo nessun controllo, la ISR(TIMER1_OVF_vect) è solo una porzione della ISR complessiva, ad alte frequenze è presente un leggero jitter, si verifica solo ogni tot us su alcuni impulsi e in modo aperiodico, se si genera un'onda quadra costantemente.
Nel caso dei 38 kHz per il diodo IR il jitter non è un problema, anche se viene perso un impulso perché va fuori periodo ogni qualche centinaio non è certo un problema, idem per il ping degli ultrasuoni, in questo caso il jitter è praticamente inesistente, mentre può essere un reale problema per altre applicazioni.

Per la serie non finisce qui tra poco arriva la soluzione numero 2.
Utilizzo del timer come contatore di tempo e dell'interrupt per ricaricarlo, soluzione che richiede un minimo impegno cpu, mentre quella tramite pwm no, che però consente un migliore controllo delle cose, sopratutto una precisione migliore, e permette anche di emettere un numero preciso di impulsi, utile per il Sonar.