Newsgroup: it.hobby.elettronica.digitale
Titolo: I2C+PIC16F876A

Ciao a tutti
ho un problema con la trasmissione I2C.
In pratica voglio scrivere su un registro di un sensore (slave) il valore 0x01. Il problema è che mi si accende il LED ERROR che indica il mancato arrivo del segnale di ACK....mi potete dare una mano. Di sguito metto il codice in assembler
	PROCESSOR       16F876A
        RADIX          	 DEC
        INCLUDE         	"P16F876A.INC"
        ;ERRORLEVEL  	 -302
        ;Setup of PIC configuration flags
	;FLASH Program Memory Code Protection Disable
	;In-Circuit Debugger Mode Disabled
	;FLASH Program Memory Write Enable
	;Data EE Memory Code Protection Disable
	;Low Voltage In-Circuit Serial Programming Disable
	;Brown-out Reset Enabled
	;Power-up Timer Enable
	;Watchdog Timer Disable
	;Oscillator Selection XT 
        __CONFIG        0x3FF1	       
#DEFINE 	Bank0		bcf 	STATUS, 5
#DEFINE 	Bank1 		bsf 	STATUS, 5
#DEFINE		END			PORTB, 1
#DEFINE		ERROR			PORTB, 2
#DEFINE 	ACK_control 	btfss 	SSPCON2, 6
#DEFINE		Stop_condition	bsf 	SSPCON2, 2
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;Definizione delle costanti
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Contatore	equ	0x20
Contatore1	equ	0x21
DATO_ACK	equ	0x22
	ORG	0x00
	goto	Main
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
;Inizio del codice
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Delay
		Bank0
	clrf	Contatore
	clrf	Contatore1	
Delay_Loop	
	decfsz	Contatore,1
	goto	Delay_Loop
	decfsz	Contatore1,1
	goto	Delay_Loop
 
return
Led_end
		Bank0
	bsf	END
	goto	$
return
Led_error
		Bank0
	bsf	ERROR
	call 	Delay
	bcf	ERROR
	call	Delay
	return
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;I2C
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
I2C_INIT
	; inizializzazione I2C
 
		Bank1		
	movlw	0x09		;ok
	movwf	SSPADD		
	BCF	SSPSTAT,CKE	;--------------------------------------------------
	movlw	0x00		;--------------------------------------------------
	movwf	SSPCON2
	clrf	TRISB
	movlw	0x18
	movwf	TRISC		; SCL e SDA input
 
		Bank0
		; attraverso il registro SSPCON attivo i pin SCL , SDA e il MASTER MODE
	movlw	0x28		;OK
	movwf	SSPCON
	clrf	PORTB
	clrf	PORTC
 
	return
I2C_transfer
 
;		Bank0		;QUESTO L'HO TOLTA PERCHE SEI GIA SUL BANCK 0
	movwf	SSPBUF		
		Bank1
	btfsc	SSPSTAT, 2
	goto	$-1
		Bank0			;PER CHIAMARE LA PAUSA DEVI TORNARE SUL BANCO 0
	call	waitI2C	
		Bank1			;PER POI RITORNARE SULLA PAGINA 1
;SOSTITUISCI LA ROUTIN DEL ACK CON UNA SIMILE A QUELLA SOTTO
	btfsS	SSPCON2,ACKSTAT		;CONTROLLA ACK
	GOTO	$+6			;SE ACK SALTA
		Bank0
	MOVLW	"1"			;METTI 0 SUL TIPO DI NOACK
	MOVWF	DATO_ACK
	call	Led_error		;ACCENDE LED PER  NO ACK
		Bank0
	RETURN
 
waitI2C
	NOP
	NOP	
	NOP	
	NOP
	NOP
	return
Start
		Bank1
	bsf	SSPCON2, 0
	btfsc	SSPCON2,0
	goto	$-1
		Bank0	;DEVI TORNARE SUL BANCO 0 PRIMA DI TORNARE-------------------------------------
	return
Slave_gain
 
;		Bank1		;QUESTA L'HO TOLTA, NON DEVI PASSARE SUL BANK1--------------------------
	call	Start		; Start condition
	call	waitI2C
	movlw	0xE0		; scrivo l'indirizzo dello slave
	call	I2C_transfer
		Bank0
	movlw	0x01		; indirizzo del registro su cui andrò a scrivere
	call	I2C_transfer
	movlw 	0x01		; Guadagno = 40	
	call	I2C_transfer
 
		Bank1
		Stop_condition
	call	waitI2C
 
	return	
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;MAIN
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Main
 
	bcf	STATUS,6
		Bank0
	call 	I2C_INIT
	call	Slave_gain	; inizializzazione del sensore SRF10
	call	Led_end
 
	end
 
-- 
Questo articolo e` stato inviato dal sito web 
http://www.nonsolonews.it

 In pratica voglio scrivere su un registro di un sensore (slave) il valore 0x01.....
Posso darti una risposta alternativa non molto pertinente ?
Se ti interessa bene, se no ignorala:
Sai che tutta quella pappardella in PicBasic si scriverebbe + o -
così:
I2CWRITE, I2C_SCL, I2C_SDA, Control, Address, Value
Una volta ero sfegatato dell'assembler, poi ho scoperto l'esistenza del
PicBasic e ho smesso di perderci la testa.
Certo ci sono dei limiti e svariati motivi per cui in certi casi sia
necessario rimanere in assembler, non apriamo un thread su questo, lo
dico solo perchè magari nemmeno tu, come io allora, conosci il
PicBasic.
Quando l'ho visto per la prima volta e ho visto che per dire pippo=3 si
scrive "pippo=3" e non set_bankvattelapesca, movlw3,movwf pippo,
rimettiilbankdov'era ....
Ciao
Marco

 necessario rimanere in assembler, non apriamo un thread su questo
[...]
Ho paura di sì, invece. Ho lavorato su un paio di progetti e la scelta
del PicBasic mi è stata imposta dall'alto. La prossima volta perderò
il lavoro ma mi rifiuterò di continuare a lavorare con quella sottospecie
di linguaggio di programmazione.
Certo, se devi far lampeggiare un led il PicBasic va benissimo... ma anche
l'assembler. Se devi fare qualcosa di più complesso il PicBasic è un suicidio,
a partire dalla gestione degli interrupt. Avere il coraggio di definire
gestione dell'interrupt quella fatta via software (in pratica, dopo ogni
istruzione viene controllato il flag dell'interrupt ed eseguita la ISR)
è da pazzi. Quella cosa non è gestione dell'interrupt, piuttosto una
mezza ciofeca che fa perdere *tutti* i vantaggi dell'interrupt.
A quel punto, meglio non usarli.
Puoi usare gli "interrupt hardware" ma era molto complicato.
Inoltre, da quello che ho capito, ma potrei sbagliarmi, non esiste la
possibilità di creare subroutine con parametri locali. Del tipo, non posso
creare la funzione somma(a,b) che mi somma i due registri a e b (ovviamente
è un esempio semplicissimo).
Le uniche routine che puoi usare tranquillamente sono quelle che il
"compilatore" PicBasic gestisce internamente.
Con questo non voglio esaltare l'assembler, anche io sono per linguaggi ad
alto livello. Visto che il nostro amico usa il PIC16F876A, potrebbe buttarsi
tranquillamente sul C.
Ovviamente può usare le innumerevoli librerie già scritte, tra cui quelle
per l'I2C, che si trovano liberamente in rete.

 per l'I2C, che si trovano liberamente in rete.
Quoto tutto. Anche se a prima vista si può rimanere affascinati dal PicBasic 
(sono tra coloro...), basta leggersi il manuale per capire che è del tutto 
inutilizzabile per scrivere firmware di una complessità anche minima.
-- 
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking 
at it (Robert A. Pease)
zsimone...@zliberoz.it
 (Rimuovere i caratteri di zorro per rispondere 
via mail)

 possibilità di creare subroutine con parametri locali. .....
Con il Basic bisogna affrontare il tutto con un'altra filosofia. Inizi
a dotarti di micro con una memoria quadrupla di quella che sei abituato
ad usare in assembler e poi te ne freghi di quello che fa. E non andare
mai a guardare il listato ....
 
Marco

 mai a guardare il listato ....
Ok, questo è un altro motivo per non usare il PicBasic, ma la tua osservazione
non risponde alla mia domanda: perché mai in PicBasic non posso usare
parametri locali di subroutine? Penso che il Basic "classico" lo preveda.
Oltre ad essere un Basic, il PicBasic è pure non standard...


Io non sono un grande esperto pero' vedendo i listati che si trovano in rete 
dalla stessa Melabs (casa che produce il pic basic) oppure quelli di 
Elettronica in la quale piu' volte con questo tipo di compilatore ha 
presentato diversi progetti tipo gps-gsm che non sembrano poi cosi' semplici 
da realizzare, forse qualcuno di voi si rende conto che con questi tipi di 
compilatori quasi tutti possono far funzionare un microcontrollore? 

 di linguaggio di programmazione.
Puoi dire solo se si tratta di qualche rivista del settore che ti ha imposto 
di usare questo compilatore? 

 il Basic come l'assembler.
Allora, l'esempio all'inizio del post non è proprio un accendere un
led, sono 50 e 100 righe di assembler equivalenti a una singola
istruzione PicBasic.
Non devo convincere nessuno, ho solo suggerito di considerare questa
alternativa casomai non fosse nota.
Ciaooooo
Marco

 compilatori quasi tutti possono far funzionare un microcontrollore? 
Diciamo subito che se fai una ricerca di routine e programmi scritti per i PIC
in C o in assembler, ne troverai sicuramente molti di più rispetto a quelli
scritti per il PicBasic (fatti un giro, solo per citare il più famoso, a
www.piclist.com
).
La semplicità del Picbasic risiede nelle numerose librerie che la Melabs ha
messo a disposizione e che mascherano la complessità dell'hardware. Tieni
presente che si tratta di librerie che potresti scrivere tu (o copiare) in
C con maggiore efficienza.
Facciamo un esempio... il programma che scrive il risultato di 3 conversioni
A/D su un display:
---
mainloop:
	Lcdout	$fe, 1		' Clear the LCD
	Adcin	0, adval	' Read the first ADC channel
	Lcdout	"0=", #adval	' Send it to the LCD
	Adcin	1, adval	' Read the second ADC channel
	Lcdout	" 1=", #adval	' Send it to the LCD
	Adcin	3, adval	' Read the third ADC channel
	Lcdout	" 3=", #adval	' Send it to the LCD
         Pause   200             ' Delay for time to read the display
         Goto    mainloop        ' Do it forever
---
A questo punto, in C, il programma potrebbe essere scritto:
---
while(1) {
	lcd_clear();
	adval = adcin(0);
	lcd_print( adval );
	adval = adcin(1);
	lcd_print( adval );
	adval = adcin(3);
	lcd_print( adval );
	pause( 200 );
}
---
Come vedi, la complessità del linguaggio C è paragonabile a quella del Basic.
Il grande *apparente* vantaggio del Picbasic sono solo le librerie che la Melabs
ha messo a disposizione insieme al compilatore. Routine che fanno molte cose,
tra cui la scrittura su un LCD o la conversione di un segnale analogico.
Ma queste routine possono essere scritte, con un minimo di sforzo, o possono
essere anche copiate dai numerosi esempi che si trovano in rete.
Certo, con la tua frase
---
   forse qualcuno di voi si rende conto che con questi tipi di
   compilatori quasi tutti possono far funzionare un microcontrollore?
---
si capisce che ti riferisci a gente che vuole far funzionare in breve tempo
un microcontrollore senza perderci molto tempo. Sono d'accordo che il Picbasic
può venire incontro a queste persone, ma se la complessità del software aumenta
leggermente, il Picbasic è più d'intralcio.
Quando parlo di complessità, non intendo il numero di compiti che il micro
deve svolegere, ma il tipo di periferiche da gestire.
Per esempio, cosa succede se dovete usare un LCD grafico? Oppure comunicare
con una smartcard?
Ovvio che il Picbasic non potrà avere tutte le librerie di cui l'utente può
avere bisogno, ci mancherebbe. Ma qui nasce la difficoltà di usare il Picbasic,
perché la creazione di librerie diventa, secondo me, praticamente impossibile
se non si hanno a disposizione caratteristiche fondamentali di un qualsiasi
linguaggio di programmazione (degno di questo meno), come le subroutine e
le variabili locali.
No, Picbasic... se lo conosci lo eviti.

enzo ha scritto:

Cosa c'entrano le riviste?
No, era un committente che aveva già scritto un mezzo programma in Picbasic, ma,
guarda caso, non riusciva a terminarlo, così mi ha chiesto una mano. Ovviamente
non potevo riscrivere tutto quanto il software (anche se avrei perso meno tempo)
e così decisi di completarlo. Che pena... non me lo far ricordare.
Anche le cose più banali diventavano complicatissime con il Picbasic.

 alternativa casomai non fosse nota.
Ah certo, neanche io devo convincere nessuno. Sto solo parlando del mio
punto di visto. Magari la discussione può essere interessante per altri.


Capisco, potresti spiegarmi magari con un banale esempio cosa intendi per 
subroutine con parametri locali?
Puoi consigliare come fare per iniziare con il C per i pic? magari esiste 
qualche buon manuale in italiano per incominciare? tu consigli il mikroC? 
qualcuno dice ceh non e' neanche ansi compatibile, non se se leggi Fare 
Elettronica stanno facendo a puntate un corso sul MikroC che ne pensi? 


Faresti un esempio per farmi capire quale e' il limite del Pic-Basic 
rispetto ad un qualunque altro compilatore C? 

 Elettronica stanno facendo a puntate un corso sul MikroC che ne pensi? 
Quei tutorial vanno bene per i principianti. Però, spesso, ti spiegano come
installare il software e come fare per caricarlo. Tutte informazioni che si
possono avere leggendo il file di Help del programma, con un po' di buona
volontà.

 tipo di applicazioni intendi fare, ecc. ecc.
Riprendiamo un attimo il discorso dei compilatori C freeware. Cosa c'è in
giro che supporti tutte le famiglie (12F/16F/18F/dsPIC) e che sia
sufficientemente "stabile" da poterlo usare non solo per hobby?
Io mi trovo benissimo con il (pay) CCS di cui ho regolare licenza ma
purtroppo lo aggiornano spessissimo e se non compri gli aggiornamenti non è
più compatibile con le ultime versioni di MPLAB.
Vorrei valutare un compilatore o ancora meglio un IDE che giri anche sotto
linux. Le librerie non sono indispensabili... se ci sono tanto di
guadagnato, altrimenti me le scrivo :-)
Ho cercato con zio google ma ho trovato più che altro semplici compilatori
per pochi modelli di PIC e dalle funzionalità "caserecce"....
Marco / iw2nzm

 comunicazione con un modulo GSM, ecc.
Ma anche il PicBasic della Melabs puo' fare queste cose, comunque stavo 
incominciando a leggere un libro sul linguaggio Ansi C, mi ha incuriosito un 
parte del libro relativa agli interrupt dove viene riportato che ANSI C non 
prevede interrupt come funzioni native o di libreria pertanto viene 
consigliato di usare delle estensioni (quindi non ansi compatibili) che sono 
proprietarie e fornite insieme al compilatore, quindi per i Micro anche con 
il C conviene usare assembler per gli interrupt?


il C non e' nato per gestire questi livelli cosi bassi e poiche' il 
comitato di standardizzazione non e' particolrmente interessato ( forse 
non sa neanche che esiste :-) ) all'ambiente embedded l'evoluzione ansi 
non ne ha tenuto conto.
per cui le eventuali funzioni di interrupt vanno dichiarate sfruttando 
estensioni, non standard e sopratutto non unificate , dei vari 
compilatori, altre estensioni , sopratutte relative ai tipi di dati , 
sono spesso necessarie per poter sfruttare a pieno peculiarita' 
dell'architettura nel caso dei micro di piccola taglia ( PIC , 8051 , AVR ).
anche la libreria standard diventa un' utopia dove l'implementazione 
della sola printf ( minima ) o delle 4 operazioni in virgola mobile 
occupano da sole tutta la memoria codice disponibile.
l'eventuale portabilita' del codice diventa piu' un protocollo per il 
programmatore che il seguire le regole di un compilatore ansi.
il C ha pero' il grande vantaggio di essere un linguaggio molto piu' 
astratto rispetto al basic, dove la sintassi fondamentale si riduce a 
poche e semplici regole e dove almeno il nucleo fundamentale e' 
portabile tra architetture e compilatori differenti.
nota bene: io lavoro indistintamente in assembler ( 8051 ),  in c, in 
basic, in fortran ( ognuno sulla piattaforma corrispondente )

 per pochi modelli di PIC e dalle funzionalità "caserecce"....
Immaginavo. Purtroppo questi software specifici in ambito professionale sono
tutti sotto Windows.

 il C conviene usare assembler per gli interrupt?
Come ti hanno già detto, l'Ansi C è pensato per architetture molto più complesse
rispetto a quelle di un PIC. Per questo motivo non trovano posto, nello
standard, cose come la gestione degli interrupt che sono compiti in genere
svolti dal sistema operativo (il problema è quando scrivi un tuo sistema
operativo :) ).
Quindi, giustamente, devi utilizzare delle estensioni all'Ansi. Ma sono
estensioni veramente limitate che dipendono dal compilatore. In genere si
utilizzano delle direttive #pragma o qualcosa del genere.
Però attento... il fatto di utilizzare estensioni all'Ansi *non* vuol dire che
"conviene usare l'assembler per gli interrupt". In genere i compilatori C
lavorano molto più a basso livello del Basic (almeno del Picbasic), quindi
l'efficienza della gestione degli interrupt in C è comunque molto vicina a
quella dell'assembler.

 portabile tra architetture e compilatori differenti.
Quoto tutto.

 sono tutti sotto Windows.
Rischiamo di andare OT, ma secondo te perchè questa scelta? Sono tutti sul
libro paga di MS?
Ciao!
Marco / iw2nzm

 quella dell'assembler.
Sicuramente io non ho la tua esperienza pero' da quando ho iniziato a 
giocare (questo e' il termine che mi viene visto che non ho grandipretese al 
momento) con il picbasic pro, mi chiedo dove sia la notevole convenienza ad 
usare il c, visto le poche risorse che ha un sistema embedded alla fine 
credo che che almeno in campo pic i due linguaggi si equivalgono, il 
picbasic come credo anche il c puo' ricorrere a routine direttamente in 
assembler. 

 direttamente in assembler.
Dico la mia: anche ammesso che per progetti semplicissimi il basic è
sufficiente non vedo io l'avversità verso il C: se scrivi codici semplici,
lo saranno sia in basic sia in C. La differenza sta nel fatto che con il
secondo ti puoi spingere ben oltre... tanto vale prenderlo in
considerazione.
Mi permetto di aggiungere che nel campo dei microcontrollori nella
stragrande maggioranza dei casi le differenze sostanziali tra C e basic
sono la sintassi e i tipi di dati (vettori e stringhe in particolare). Solo
se sfrutti funzionalità avanzate allora si richiede uno studio più
approfondito del linguaggio.
Ciao!
Marco / iw2nzm

 approfondito del linguaggio.
Quindi concordi con me? cioe' il fine si raggiunge sia con il C che con il 
Basic almeno nell'ambito dei microcontrollori Pic. 

 Basic almeno nell'ambito dei microcontrollori Pic.
No, intendevo il contrario :)
Visto che non è poi così difficile usare il C su un'architettura come quella
dei PIC, IMHO è più produttivo imparare subito il C. Questo perché ti
permette di arrivare dove il basic arranca ma soprattutto di gestire meglio
le risorse.
Marco / iw2nzm

 istruzione PicBasic.
Non ha senso confrontare il PicBasic con l'assembler.
Devi confrontralo con un linguaggio di alto livello come il C.
Per scrivere il firmware hai 2 opzioni:
- usare l'assembler
- usare un linguaggio di alto livello (C, PicBasic, ...)
Si sceglie l'assembler al posto di un linguaggio di alto livello se ad
esempio è necessario ottimizzare al massimo l'utilizzo del micro in termini
di memoria (RAM e ROM) utilizzata, di velocità di elaborazione, ...
Se non ci sono grossi vincoli in tal senso puoi eventualmente passare ad un
linguaggio di alto livello (C, PicBasic, ...) che danno il vantaggio
rispetto all'assembler di scrivere il firmware in un tempo minore (oltre ad
un maggiore facilità di porting in caso di necessità in tal senso).

 libro paga di MS?
Secondo me ci sono due fasce di prodotti professionali. Quelli low-cost, come
i PIC e tutto quello che ci ronza attorno, in cui Windows la fa da padrone per
ovvi motivi: la maggior parte degli utenti preferisce Windows.
Poi ci sono i prodotti high-end, tipo i vari cad per schemi elettrici e sbrogli,
simulatori termici e di campi elettromagnetici. Qui hai la possibilità di
scegliere spesso la versione sotto Unix e sotto Windows, o solo la prima.
Almeno questo è quello che succedeva un po' di tempo fa, in cui le workstation
Unix erano le bestie che facevano il lavoro duro. Con i computer moderni, i
normali PC con Windows sulla nostra scrivania sono già dei mostri e i software
professionali girano già che è una bellezza.

 assembler. 
E' esattamente il contrario. Sul PC hai notevoli risorse, quindi anche se
utilizzi un linguaggio poco efficiente (il Java è un classico esempio) nessuno
si accorge di nulla. Se una routine è fatta di 100 istruzioni oppure di 1000
istruzioni (è un fattore 10), il tempo impiegato è comunque risibile.
In altre parole, puoi permetterti il lusso, su macchine prestanti, di preferirei
linguaggi ad altissimo livello di astrazione (Java, Python, Visual Basic, ecc.) 
tanto non se ne accorge nessuno. Certo, non puoi comunque pretendere di scrivere
un sistema operativo con questi linguaggi.
Un'altra considerazione è sui compilatori. La loro storia, nel mondo dei PC,
è decennale. Ormai sono arrivati a un grado di raffinatezza enorme. Anche se
utilizzi linguaggi ad alto livello ed anche se il programma la scritto un
novizio, il compilatore riesce ad ottimizzare il codice.
Diverso è il discorso quando utilizzi un sistema poco performante. Qui *devi*
stare *molto* attento alle risorse che usi. Facciamo un esempio concreto.
Se utilizzi un 16F84A hai a disposizione 1024 istruzioni assembler.
Come forse saprai, i PIC hanno una RAM banchizzata, cioè devi prima selezionare
il banco di memoria e poi utilizzare il registro. Questo vuol dire (chi
programma in assembler lo sa bene) che devi "sprecare" molte istruzioni
assembler solo per cambiare il banco di RAM.
Supponiamo di voler mettere a 0 tutte le uscite delle porte PORTA e PORTB.
Se scrivi, in C:
   PORTA = 0x00;
   PORTB = 0x00;
un compilatore pivello potrebbe convertire in:
   BCF   STATUS, RP0
   CLRF  PORTA
   BCF   STATUS, RP0
   CLRF  PORTB
Ovvio che la terza istruzione è inutile perché siamo già nel primo banco e
quindi può essere risparmiata. Ma un compilatore pivello potrebbe non essere
in grado di capire ciò e, per sicurezza, antepone *sempre* le istruzioni per
cambiare banco prima di utilizzare il registro. Questo, come puoi ben capire,
in sistemi con poche risorse (memoria programma) è da evitare.
Questo è solo un esempio per farti capire come i compilatori possono fare
spesso la differenza se sono fatti bene ed hanno molte ottimizzazioni.
Se, per esempio, utilizzi gli interrupt "software" (che orrore) del Picbasic
Pro, il "compilatore" inserisce un sacco di istruzioni assembler in più
prima di ogni istruzioni Basic per controllare se l'interrupt è scattato.
Oltre ad avere una notevole latenza, questo sistema ti "spreca" un sacco
di spazio nella tua preziosa memoria programma.
Una soluzione, ovviamente, è quella di raddoppiare le risorse, come spesso
accade. Utilizzare, cioè, un PIC con il doppio della memoria quando ne serve
uno che ne ha la metà... e che costa anche la metà.

 uno che ne ha la metà... e che costa anche la metà.
Ma tu ovviamente hai fatto dei confronti? cioe' a parita' di hardware e di 
funzioni che deve fare il firmware ha visto delle notevoli differenze nella 
lunghezza del codice?
ad esempio ho visto che se scrivo:
Led1 = high
che dovrebbe essere lo stesso di
Led1 = 1
il compilatore genera piu' codice nel primo caso.

 il compilatore genera piu' codice nel primo caso.
Questo è ancora un altro discorso. E' lo stesso compilatore che si comporta in
modo diverso a seconda di quello che scrivi. Nel primo caso, si assicura che
quel pin sia impostato come uscita, nel secondo caso, invece, no, limitandosi
a impostare ad 1 quel bit.
Ti lascio immaginare cosa succede quando utilizzi quelle varie routine di
libreria messe a disposizione nel Picbasic.

Ciao!
Devo essere sincero, dopo quello che hai scritto, avevo un libro che ha 
scritto lo stesso autore che ora sta facendo il corso MikroC su Fare 
Elettronica, ho incominciato a leggerlo e devo essere sincero la sintassi 
del C e' piu' complicata rispetto al Basic pero' analizzando qualche listato 
sembra effettivamente piu' concreto