Rabbit (Progetto on-line)

[ifachsoftware]

Walter , per leggere se un Bit e' ad on c'e' il seuente comando :

if (!BitRdPortI(PGDR, PULS2)) abort; // Controlla se PULS2 e' Premuto

Ciao

[walterword]

ok dopo una settimana nessuno mi ha risposto

mi saro spiegato male

lo trovero da solo il sistema

volevo solo sapere come far partire un interrupt ogni 100

una volta dentro so io cosa devo fare

ciao fratelli

[Dario Valeri]

eeeeeee permaloso!

se vuoi testare un bit all'interno di una word (oppure byte)

utilizzando istruzioni booleiane (molto veloci)

puoi fare cosi':

supponiamo che il bit da testare sia il bit 0 (semplice)

"se (WordDaTestare AND 1) = 1 allora e' a uno"

supponiamo che il bit da testare sia il bit 1:

"se (WordDaTestare AND 2)=2 allora il bit e' a 1"

per l'interrupt non ho capito cosa vuoi fare......puoi spiegarti meglio? come saprai io sono un po' duro

di comprendonio.

dario , moreno

ciao

Modificato: 25 settembre 2004 da Dario Valeri

[Livio Orsini]

...volevo solo sapere come far partire un interrupt ogni 100

Walter ti tolgo dieci punti!!

Se abiliti l'interrupt, ogni qualvolta le condizioni che gerano l'interrupt sono verificate l'interrupt scatta.

Devi per forza fare il test dentro la ruoutine di interrupts!

sub_int()

{

cnt++;

if cnt >=100

{

cnt = 0;

..........

}

}

[walterword]

te tutti risposto a cose mai chieste

...scusate ma e' cosi '

io voglio sapere come ottenere un interrupt a ogni 100 ms

chi ca**o ha mai parlato di bit da testare ????????

siete tremendi , imparate a leggere i post dall'inizio alla fine

ciao

walter

grazie per i punti , 10 me li hanno gia tolti la polizia stradale qualche mese fa , adesso 10 me li togli tu

cosi vado in giro col triciclo

[Livio Orsini]

Messagio iniziale

volevo solo sapere come far partire un interrupt ogni 100

Messagio odierno

io voglio sapere come ottenere un interrupt a ogni 100 ms

Se dimentichi le cose importanti come posso risponderti?

La via più semplice è usare il timer B collegandolo ad un interrupt. Guarda gli esempi che ti danno per il timer B. Basta cambiarli un attimo. Se poi hai problemi fammelo sapere che ti posto l'esempio modificato.

[Dario Valeri]

ciao

non ho capito come testare un bit

int *i;

SET(i,0); // setto il bit 0 dell'intero 16 bit "i" ;

ma poi ..... come faccio a testarlo , cioe ho girato tutta la guida ma niente trovai

boooo chi sara' stato???

comunque' per l'interrupt timer e' come dice livio.

nella configurazione del micro devi fare si che

venga generato un int quando un timer arriva a zero.

il timer si ricarica automativamente e viene chiamata la routine

che tu hai stabilito essere quella di interrupt....

nel mio sito , nella sezione software ho messo qualche abbozzo del software per mitsubishi

ed ho programmato anche 3 int timer . 1 decimo , 1 secondo e 10 millisecondi

ciao

chi avra' scritto ...bo!

dario

[walterword]

col pic ho capito come farlo

vorrei capirlo anche col rabbit

grazie fratello Dario per il tuo aiuto ,ma l'esempio col Mitsubushi non mi dice niente

lo so anche io che l'interrupt avviene dopo che il timer ha raggiunto il suo preset e poi riparte

VOLEVO SOLO CAPIRE COME SCRIVERE 3 RIGHE DI CODICE IN DYNAMIC C DEL RABBIT

[Livio Orsini]

Walter credo che dovrai rassegnarti a scriverle in Assembler, almeno per le istruzioni strettamente legate all'interrupt.

A tal proposito guardati gle esempi: TIMER_B.C, TIMER_B1.C e TINER_B2.C

[walterword]

perfetto fratello cicciolino Livio Sergio

ciao

Walter

[walterword]

all'interno della funzione di interrupt delimtiata da

#asm e #endasm si fa cosi '

#asm

....

....

C: miafunzione();

....

....

#endasm

ciao

[Matteo Montanari]

Non sò se il forum è quello giusto, ma piuttosto che aprire un altro argomento mi accodo a questo, anche perchè si parla sempre di Rabbit, ed è leggendo questi Post che mi ha spinto ad intrapprendere questa nuova "impresa" o "avventura" nel campo dell'automazione.

Ho realizzato un circuito, un registratore di pressione con annessa stampante, per farlo ho utilizzato, almeno per il prototipo, una scheda SX01 di AreaSX (Rabbit RCM2250), alla quale ho interfacciato un circuito stampato, con a bordo quattro pulsanti, tre leds, un display LCD ed un convertitore A/D (proposto in un vostro esempio).

mi capita una cosa strana, sembra che il sistema risenta di campi elettromagnetici, o almeno credo.

provo il circuito in ufficio ed esegue tutte le funzioni, senza nessun problema, cambio pagina a comando, visualizzazione dei dati voluti, ciclo di funzionamento solamente a comando, tutte le cose per cui è stato fatto il programma.

inserisco lo stesso circuito in un ambiente industriale, officina meccanica per interderci, e tutto il sistema comincia a dare i numeri, le pagine vengono cambiate senza che nessuno "tocchi" niente, i valori visualizzati variano pur non essendci variazione (all'ingresso del convertitore A/D).

a volte rimane nella pagina iniziale (visualizzata da programma solo per due secondi) in attesa di non sò cosa.

se attivo la funzione di monitor, quindi con cavetto collegato, vengono visualizzati caratteri strani (a volte), oppure non vengono visualizzate variabili, come se saltasse un pezzo di elaborazione...

constatato questo ho tolto il circuito dal banco prova, riportato in ufficio e tutto torna come prima...

io non sò più dove sbattere la testa, realizzare il sistema in altro modo mi è economicamente sconvegniente e come sfida personale vorrei risolvere la cosa.

suggerimenti?

vi è mai capiato qualcosa del genere?

premetto che essendo un prototipo è "in Aria", non racchiuso dentro nessun mobiletto o scatola ne metallica ne in materiale plastico

[ifachsoftware]

Spero che non mi capiti anche a me , visto che sono in fase avanzata con un progetto importante bastato sul RABBIT 3000 , da quello che racconti credo che possano essere problemi di disturbi.

Io incomincerei dall'alimentatore controlando che non entrino disturbi dalla rete elettrica e poi passerei ai cavetti , e allo stampato.

Attualmente sto smadonnando per far eseguire dei test sui bit in tempi decenti , comunque per informazione vi informo che il compilatore C del Rabbit fa molte cose strane (per esempio istruzioni tipo i++ ci mettono quasi il doppio di istruzioni tipo i = i + 1 , alla luce del fatto che il compilatore ha istruzioni assembler di incremento ...)

Comunque buon divertimento e tienici aggiornati

Ciao

[Matteo Montanari]

l'alimentazione avviene tramite una batteria al piombo da 12V, ma le "pazie" del processore avvengono ugualmente, sia se è connessa solamente la batteria ed anche se è collegato l'alimentantore per mantenimento di carica.

per quanto riguarda

(per esempio istruzioni tipo i++ ci mettono quasi il doppio di istruzioni tipo i = i + 1 , alla luce del fatto che il compilatore ha istruzioni assembler di incremento ...)

ho abbandonato le istruzioni "compresse" a favore di quelle più "articolate" nei programmi dei PLC, e quindi ho mantenuto la stessa filosofia anche qui, comunque grazie per le dritte.

i pulsanti sono saldati direttamente su stampato, non hanno nessun circuito di smorzamento (anti rimbalzo, o filtro RC) è tutto affidato a ritardi software, ho cominciato a studiare un nuovo master, con inserimento di ressitenze, induttanza e condensatori per arginare almeno questo problema, si vedrà...

tu, voi, che sistema utilizzate per la gestione degli ingressi?

io utilizzo una funzione del genere:

//;
RES(&Mem0,0);     // Resetto il bit "stato pulsante"
//;
//***********************************
// Controllo pulsante Start
//***********************************
//;
if (BitRdPortI(PEDR, 0)==0) { // Controllo Ingresso
//;
msDelay(250);                      // Attesa per eliminazione disturbi
//;
if (BitRdPortI(PEDR, 0)==0) { // Controllo Ingresso
//;
SET(&Mem0,0);     // Setto il bit "stato pulsante"
//;
}
//;
}
//;
//***********************************
// Attesa rilascio pulsante
//***********************************
//;
if (BIT(&Mem0,0)) {
//;
Sw1On:
//;
if (BitRdPortI(PEDR, 0)) {
//;
msDelay(100);
//;
if (BitRdPortI(PEDR, 0)) {
//;
goto Sw1Off;
//;
} else {
//;
goto Sw1On;
//;
}
//;
} else {
//;
goto Sw1On;
//;
}
//;
Sw1Off:
//;
}
//;

con la sicurezza del pulsante rilasciato, non dovrei avere "condizioni" non volute, ma è quello che mi succede

[Livio Orsini]

Caro Matteo "Keosmm" ti sei imbattuto in un problema di ECM. Non so come è il layout della scheda SX, ne come è il cablaggio. Se hai un convertitore A/D è presumibile che tu debba leggere segnali dal campo, daltro canto affermi che hai fatto un registratore di pressione. DI solito questi disturbi hanno la brutta abitudine dia ccoppiarsi ai cavi di collegamento e da questi entrare nella scheda, dove comunciano a scorrazzare in ogni dove.

Posso solo darti alcuni consigli fondamentali, non offenderti se dico cose ovvie.

Prima di tutto corare schermi e collegamenti di massa. poi disaccoppiare, sulla scheda stessa del micro e sulla scheda di espansione, tutte le alimentazioni usando induttanze e condensatori di buona qualità con reofori di lunghezza prossima allo zero. In questo ogni alimentazione all'ingresso della scheda avrà il suo filtro "pgreco"

Se i problemi persistono togli tutti i collegamenti esterni, verifaca di non avere problemi, poi agiungi i collegamenti uno alla volta per tentare di scoprire la fonte.

Nei laboratori professionali queste prove si eseguono con un apparecchi Shaffner che simula i disturbi dell'ambiente industriale. Per mia esperienza se l'apparecchiatura funziona per 20' con disturbi di 2000Vpp ci sono buone probabilità di non avere problemi

[ifachsoftware]

Tale progetto lo stiamo gestendo io e Livio , per quanto riguarda la gestione degli ingressi vedo che probabilmente fai uso dei costate e poi leggo con i relativi ritardi.

Il nostro progetto per ora ha affrontato la parte algoritmi di gestione dei dati , ma in ogni caso NON utilizzerei i costate ma lavorerei su interrupt e (per la gestione dei segnali veloci) e farei una gestione tipo PLC creandomi dei fronti e facendo un loop generale.

Per i tuoi problemi come ti ha gia' detto Livio sono al 99% problemi EMC , credo che avrai un bel da fare ad eliminarli.

Considera che e' fondamentale lo stampato , se e' fatto male avrai solo problemi.

Per quanto riguarda il nostro progetto al 99% posso dirti che per problemi di prestazioni abbandoneremo il Rabbit (anche l'RCM3200 e' troppo lento per la nostra applicazione nonostante sia un ottimo oggetto) , molto probabilmente passeremo ai dsPIC che per operazioni sui Bit e calcoli e' impressionante.

Ciao

[Matteo Montanari]

per quanto riguarda la gestione degli ingressi vedo che probabilmente fai uso dei costate e poi leggo con i relativi ritardi.

diciamo che ho abbandonato la funzione "constate" in quanto mi attivava il Bit dopo un certo tempo (impostato), per una maggior sicurezza ho voluto attivare le funzioni quando il pulsante venisse rilasciato (premuto, tempo, attivazione del Bit, rilascio, tempo, uscita dal controllo)

lavorerei su interrupt

in questo caso non sarei più esposto a "schifezze" in ingresso?

gli esempi per attivare un interrupt sono nelle cartelle Sample del Rabbit?

dopo vari tentativi mi sono accorto che tutto, sembra derivare dal segnale analogico in ingresso, non posso fare prove, attualmente, e le rimanderò a lunedì, prendendo cavo schermato, collegando calze ecc. ecc.

per quanto riguarda il filtro, ho trovato questo:

http://www.areasx.it/index.php?D=1&page=ar...oli.php&id=8023

pensavo di mettere il filtro sia sull'alimentazione che sugli ingressi "digitali" (pulsanti), posso / devo metterlo anche sui segnali analogici (0..5V) in ingresso al convertitore? io lo metterei ma non vorrei falsare la misura.

Modificato: 15 gennaio 2005 da keosmm

[ifachsoftware]

diciamo che ho abbandonato la funzione "constate" in quanto mi attivava il Bit dopo un certo tempo (impostato), per una maggior sicurezza ho voluto attivare le funzioni quando il pulsante venisse rilasciato (premuto, tempo, attivazione del Bit, rilascio, tempo, uscita dal controllo)

Ottima scelta , visto che a mio giudizio i costate fanno un bel casino al di la' del fatto che non sei mai certo sui tempi e premendo un pulsante se hai dei cicli lunghi rischi che si accende quando vuole lui ...

lavorerei su interrupt 

in questo caso non sarei più esposto a "schifezze" in ingresso?

Il discorso interrupt vale per segnali che non devi perderti , oppure per farti delle operazioni su tempi precisi come con il TimerB.

Un interrupt non e' che ti protegga o aumenti le schifezze

gli esempi per attivare un interrupt sono nelle cartelle Sample del Rabbit?

Si , devi cercare sotto la voce ....\Samples\INTRUPTS

dopo vari tentativi mi sono accorto che tutto, sembra derivare dal segnale analogico in ingresso, non posso fare prove, attualmente, e le rimanderò a lunedì, prendendo cavo schermato, collegando calze ecc. ecc.

Non so la tua applicazione , ma se dialoghi in I2C potresti optoisolare la sezione analogica con 2 optoaccoppiatori ...

per quanto riguarda il filtro, ho trovato questo:

Ciao

[Matteo Montanari]

Non so la tua applicazione , ma se dialoghi in I2C potresti optoisolare la sezione analogica con 2 optoaccoppiatori ...

comunico in I2C con un integrato Philips PCF8561, collegato come riporta un esempio apparso sul sito di AreaSX

tu intendi la comunicazione tra il convertiore ed il rabbit, se ho capito bene, ho i sue segnali:

SLC ed SDA

da quello che ho capito, il segnale SLC è il segnale di Clock, quindi dovrei alimentare il diodo del fotoaccopiatore con il pin del rabbit e mandare l'uscita del fototransistor al convertitore A/D. per quanto riguarda invece SDA (i dati) devo fare l'inverso, il convertitore A/D alimenta il diodo ed il fototransistor è collegato al Rabbit.

Il discorso interrupt vale per segnali che non devi perderti , oppure per farti delle operazioni su tempi precisi come con il TimerB.

Un interrupt non e' che ti protegga o aumenti le schifezze

nel mio caso non ci sono dei dati "importanti" che non devo perdere, ma mi interesserebbe il discorso del TimerB

ho provato a leggere anche i post precedenti ed a vedere i programmi lasciati, e mi rendo conto che secondo me ho utilizzato molta più roba di quella necessaria...

[ifachsoftware]

Hai capito perfettamente , i due optoisolatori vanno utilizzati come hai indicato , l'importante sara' di alimentare separatamente lo stadio analogico (magari tramite un DC/DC converter).

Tale prova potresti anche farla su inizialmente una millefori , cosi' capisci se i problemi arrivano da li.

Come optoisolatori potresti usare i CNY74-4 o CNY74-2 che sono sufficentemente veloci per la tua applicazione.

Ciao

Modificato: 16 gennaio 2005 da ifachsoftware

[Livio Orsini]

keosmm, non voglio sembrarti troppo pessimista, ma ti riporto il frutto di esperienze precedenti di anni di lotte con disturbi e schifezze varie.

La separazione galvanica, con opto o con trasfo, non sempre ti elimina i problemi disturbi introdotti dal campo. Separare galvanicamente il dispostivo I2C può portare vantaggi, ma da solo non è risolutivo. E' importante che i disturbi non si accoppino comunque con il resto delcircuito, quindi occhio al layout. Poi attenzione a tutti i cavi che entrano e escono dalla scheda, curare masse e schermi. Purtroppo non esiste una regola generale per questi problemi. Anzi ni, una c'è: provare, misurare, modificare. Poi sono importantissimi i percorsi dei comuni e masse interne ed esterne.

Io, quando è possibile, uso interfacciare i segnali analogici con topologia ad ingressi differenziali.

Per leggere ingressi tipo pulsanti ti consiglio un semplice pseudo filtro digitale. Ti generi un interrupt a tempo (p.e. timer diciamo 10ms (ma puoi aumentarlo in funzione della velocità di acquisizione dei tuoi ingressi). Ogni 10ms, quando si scatena l'interrupt, abiliti la lttura degli ingressi. I valori letti li metti in una pila, all'ultimo posto libero; le dimensioni della pila vanno da un minimo di 2 ad un massimo di 4. Poi verifichi che per ogni ingresso il valore sia identico su tutti i valori memorizzati. Se è identico usi il valore (0 o 1) altrimenti atendi. In questo modo realizzi un semplice filtraggio che, oltre a lavorare come anti rimbalzo, filtra parte (tanta) dei disturbi.

[Matteo Montanari]

Problema risolto (sembra).

nel circuito stampanto sono sati modificati i pulsanti:

prima cortocircuitavano l'ingresso del Rabbit su di una resistenza da 1K collegata a massa

ora viene prelevato il segnale di ingresso nel nodo tra una resistenza da 10K ed il comune del pulsante, altro capo del pulsante collegato direttamente a massa. in parallelo al pulsante è stato messo un contensatore al poliestere da .1 (100.000 pF).

il cavo collegato al pressostato è stato sostituito con uno scermato, ma già con ancora il cavo "orignale" non si avevano più problemi di "flutuazione" di pagine.

ora è ancora in fase di test, dove rimmarrà per una settimana (più o meno) poi si vedrà.

Per Livio:

Per leggere ingressi tipo pulsanti ti consiglio un semplice pseudo filtro digitale. Ti generi un interrupt a tempo (p.e. timer  diciamo 10ms (ma puoi aumentarlo in funzione della velocità di acquisizione dei tuoi ingressi). Ogni 10ms, quando si scatena l'interrupt, abiliti la lttura degli ingressi. I valori letti li metti in una pila, all'ultimo posto libero; le dimensioni della pila vanno da un minimo di 2 ad un massimo di 4. Poi verifichi che per ogni ingresso il valore sia identico su tutti i valori memorizzati. Se è identico usi il valore (0 o 1) altrimenti atendi. In questo modo realizzi un semplice filtraggio che, oltre a lavorare come anti rimbalzo, filtra parte (tanta) dei disturbi.

ho realizzato su carta quanto espersso nel tuo messaggio, il problema ora è converirlo in linguaggio comprensibile al Rabbit, (e non solo, chiedi a ifachsoftware per fare qualche risata), ma attualmente mi trovo con le mani legate in quanto l'unica basetta su cui fare le prove o test è attualmente impegnata...

non appena, imegni/problemi di lavoro, me lo permettono eseguirò altre prove.

Grazie a tutti per l'aiuto

[ifachsoftware]

Son contento che hai risolto , come hai potuto ben vedere era poi un problema hardware, visto che gli ingressi li avevi gia' discriminati , naturalmente puoi migliorare sempre il codice...

Ciao

[Matteo Montanari]

naturalmente puoi migliorare sempre il codice...

certo, come ti ho detto per me è stato il primo esperimento di programmazione in C, è già molto che il Rabbit non si sia lamentato...

[ifachsoftware]

per me è stato il primo esperimento di programmazione in

Complimenti , perche' un risultato lo hai portato a casa e il problema non era proprio banalissimo.

Ciao