Rabbit (Progetto on-line)

[walterword]

se fosse cosi ma funzionasse ok , il bello che non funziona

ho scaricato e letto miliardi di articoli ma niente di chiaro e semplice e funzionante

non lo so , mi sembra una cosa troppo assurda

cioe spedire 5 byte lo faccio e li ricevo anche , utilizzando i rispettivi interrupt di trasmissione e ricezione

ma ripeto deve premere il tasto per un buon mezzo secondo , e quando l'operazione dovra essere

eseguita dalla logica invece che dalle miei dita cosa faccio , sto ad aspettare mezzo secondo con un

delay_ms(500) ????

dai non e' possibile , ci siamo vicini comunque

ciao

walter

[dlgcom]

Qando sei dentro la routina di interrupt , lo stesso viene disabilitato , quindi fara' tutta la routine e alla fine riattivera' il master interrupt.

Ma e' preopio quello che voglio , ovvero avendo solo un buffer di tre byte , non posso fare altro che scaricare la seriale, nel pic poi i flag di interruzzione si alzano e rimangono fino alla loro gestione .

Quindi se si scatena un altro int , alla fine della gestione di quello attuale , saranno processati anche gli altri.

se fosse cosi ma funzionasse ok , il bello che non funziona

E questo che e' strano , qui va....

Modificato: 17 agosto 2004 da dlgcom

[Livio Orsini]

Ciao Walter, stai perdendo i capelli su quelle routines?

Senti il consiglio di un vecchio: quando le cose non vanno e non si capisce il perchè la cosa migliore è fare un po' di pausa, svagarsi qualche orettta pensando ad altro (magari alla gnocca), poi fare un bel reset ed uniziare da una pagina bianca.

TU dici che la Tx sembra funzionare, e che è la Rx che non riceve.

Ricorda quello che ti ho detto ieri sera.

Tira via il max485 ed esci in 232, vai nella seriale di un PC (ne hai almeno due perchè li ho visti) in modo hiperterminal. Verifica che ad ogni trasmissione escano i dati che hai programmato, tutti e nell'esatta sequenza. il "/r" ed il "/n" li vedi perchè il cursore va a capo.

Se è tutto OK controlla che il pin dell'enable Tx venga settato al livello giusto quando trasmetti.

Se tutto funziona allora i problemi sono veramente sullo Rx.

A questo punto concentrati sull'uso dell'ICD, perchè senza la possibilità di andare in debug con break point diventa molto, ma molto, difficile trovare l'inghippo.

Io non so come è il tuo ICD. Nel mio si procede così:

Nella schermata di MPLAB si entra nel menù tools e si sceglie MPLAB-ICD Debugger, Scegli il processore PIC16F876 e poi OK ti appare una finestra che ti informa di quello che necessiti. Dovrai caricare il programma completo di debugging. Per fare questo quando scarichi il programma nel micro devi spuntare la voce Enable Debug Mode (almeno nel mio ICD).

X DLGCOM

Il mio compilatore è CCS una versione del 2001.

[walterword]

x Livio

da tempo mi rado barba e capelli in un round

son d'accordo con quello che mi dici e l'ho gia fatto , solo che sono da piu di 1 settimana su sta cosa e mi sta angosciando , il master e lo slave riportati piu sopra funzionano .Nel pc ho fatto un'applicazione per seriale

dove posso vedere anche '\n' e '\r' che sono praticamente il casting di (char)10 e (char)13 in VC#

X Luca

di la verita che per far funzionare i PIC hai acceso lo stereo a palla con musica SAMBA

qua a milano lo stesso software non va Luca .

Provero stasera a portare le basette in un locale sudamericano , magari un po di salsa (di pomodoro)

magari funziona

Ascolta ho fatto anche oggi pomeriggio un centinaio di prove , e mi sa che tra poco

la Flash del micro si rifiutera di essere programmata .

La tua prova funziona , cioe resettando ogni volta il pic master c'e' la trasmissione

e lo slave riceve , il problema e' che pero se si analizza il buffer ricevuto con l'accensione di led

anche collegati direttamente al PIC , ...succede che non c'e' un riscontro

Cioe' ogni volta che si scatena l'interrupt di ricezione , col getc() si prende l'ultimo byte arrivato nella Uart

se poi col ciclo for , come abbiamo fatto , lo copiamo su tutti gli elementi del buffer

for(r=0; r<lu; r++)

ric[r]=getc();

sostanzialmente avremo tutti i byte del buffer uguali , e quindi come facciamo a vedere se il pacchetto e' giusto ?

ti pare?

poi al prossimo interrupt cambia il byte e lo copiamo su tutto il buffer ancora

alla fine , se pero disattiviamo l'interrupt , possiamo trovarci tutto il buffer riempito dell 'ultimo byte che abbiamo spedito

Correggimi se sbaglio

ciao

Modificato: 17 agosto 2004 da walterword

[walterword]

ho provato con la serial de PC , col mio programmino butto fuori il valore decimale del carattere

ogni 5 byte che ricevo , quindi

dal PIC master scrivo

buff[0]='1';

buff[1]='A';

buff[2]='B';

buff[3]='\n';

buff[4]='\r';

nel pc ricevo

49 - 65 - 66 - 10 - 49

49=1

65=A

66=B

10=\n

49=A

quindi il 5° byte invece di essere il return carriage e' un altro '1'

se invece di usare il putc() uso il printf(buffer) come ho fatto , allora i byte arrivano giusti e cioe

49=1

65=A

66=B

10=\n

13=\r

ALLORA COME LA METTIAMO ????????? TRA PUTC() E PRINTF() COSA SUCCEDE????????

BACHI ?????????????????????

a parte che tutto questo non implica sul ricevitore , perche al massimo ho solo controllato il 1° ed il 2° byte

del buffer ricevuto

pero leggete quello che scrivo ognitanto , grazie

[walterword]

GRANDEEEEEEEEEEEEEEEEEEEEE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

FRATELLIIIIIIIIIIIIIIIIIII (e sorelle )

ho migliorato il master e lo slave come avevo scritto ieri

e poi ..............................

ho utilizzato all'interno dei tasti , invece dell'interrupt econ il buffer indicizzato ect ect

la funzione

string[0]='1'

string[1]='A'

string[2]='B'

string[3]='\n'

string[4]='\r'

outpu_high(Driver485)

printf(string) ;

dall'altra parte veloce come un lampo riceve , calcola e scrive in I2C sul PCf8574

per buffer un po grandi si puo utlizzare l'interrupt con putc() , seno anche printf(string)

e se la smazza il compilatore

Bene , adesso iniziero a torturavi col Rabbit che ho gia tolto dalla scatola

Colpo di scena , adesso entra il Coniglio

[Livio Orsini]

Sarà la contentezza ma si caposce solo che funziona. In pratica nel modulo in cui riconosci la pressione del tasto carichi il buffer e metti in ordine i puntatori. Poi usi la printf invece dela putc e tutto sembra funzionare. Ma probabilmente con la putc fai qualche casino con il buffer.

Comunque oggi ho fatto giu la polvere al cniglio e all'ICD. Se mi gira magari domani, visto che si prevede pioggia, mi metto a rivedere un po' le cose che avevo fatto. Poi ci sentiamo.

Ora smetto perchè mi sono stufato

[walterword]

ok nel PIC slave arrivano tutti i byte giusti

dal 1° al 4° li ho testati tutti

l'ultimo e' return carriage e va bene cosi

adesso siiiiiiiiiiiiiiiii che premo una volta sola i tasti e tutto procede come doveva

[dlgcom]

Cioe' ogni volta che si scatena l'interrupt di ricezione , col getc() si prende l'ultimo byte arrivato nella Uart

se poi col ciclo for , come abbiamo fatto , lo copiamo su tutti gli elementi del buffer

for(r=0; r<lu; r++)

ric[r]=getc();

sostanzialmente avremo tutti i byte del buffer uguali , e quindi come facciamo a vedere se il pacchetto e' giusto ?

Non e' vero , quando fai un ciclo for con in getc() se vedi l'assembler , vedrai che il compilatore aspetta che ci sia un nuovo carattere da leggere .

Per sapere quando arriva continua a leggere un bit del regstro , quando e' a 1 vuol dire che e' arrivato un nuovo byte , la lettura del buffer di ricezione cancella automaticamente il bit.

Quindi a ogni loop del for aspetta che il bit si alzi e scarica il buffer.

....................       for(r=0; r<lu; r++)
0040:  CLRF   65
0041:  MOVF   66,W
0042:  SUBWF  65,W
0043:  BTFSC  03.0
0044:  GOTO   04E
....................       ric[r]=getc();
0045:  MOVLW  28
0046:  ADDWF  65,W
0047:  MOVWF  04
0048:  BTFSS  0C.5
0049:  GOTO   048
004A:  MOVF   1A,W
004B:  MOVWF  00
004C:  INCF   65,F
004D:  GOTO   041

estratto dall'assembler generato dal CCS

come vedi a linea 48 testa il bit 5 del registro 0Ch che e' esattamente il PIR1,RCIF ovvero il flag di byte nuovo nel buffer .

non si scatena una nuova interrupt perche' all'entrare nella gestione dell'int , vengono disattivati gli interupt , lo fa il pic automaticamente.

Al ritorno dell'int , che avverra' con l'istruzione RETFIE viene abilitata di nuovo l'interruttore generale GIE.

Il mio programma deposita nella stringa ric[] tutti i dati che arrivano dalla seriale , il primo deve essere il numero di byte da ricevere.

Essendo una variabile GLOBAL e' disponibile per tutte le funzioni.

[dlgcom]

Se puo' interessare posto il programma che sta' funzionando.

una Nota sulle matrici , per chi non lo sapesse

In C il passaggio di matrici e' fatto a puntatori , ovvero , quando si passa ad una funzione una matrice , in verita' gli si passa solo l'indirizzo di memoria dell'inizio della matrice.

Quale e' il problema ?

Se passiamo l'indirizzo di una matrice di 5 elementi e cerchiamo di scrivere su sesto elemento , il compilatore non da errore , ma andremo a sporcare un area di memoria che non appartiene alla matrice stessa , con sgradevoli risulati.

#include <16F877.h>
#fuses HS,NOWDT,NOPROTECT
#use delay(clock=4000000)
#use rs232(baud=19200, xmit=PIN_C6, rcv=PIN_C7)  // Jumpers: 8 to 11, 7 to 1

char ric[20];
short int nustr;

#int_rda

   ricevi(){

      int r,lu;
   
   putc(lu);

      output_high(PIN_B0);

      lu=0;
      lu=getc();
      putc(lu);

      for(r=0; (r<lu) && (r<20); r++)
      ric[r]=getc();

  nustr=true;
  

      output_low(PIN_B0);


  


      }







void  trasmetti( int buffer[] , int lung){

       int i;

       output_high(PIN_B1);

       putc(lung);

       for(i=0; i<lung; i++)

       putc(buffer[i]);

       output_low(PIN_B1);

}

void main() {



   char  string[7];

  enable_interrupts(global);
 enable_interrupts(int_rda);


   string[0]='c';
   string[1]='i';
   string[2]='a';
   string[3]='o';
   string[4]='\r';
   string[5]='\n';

    printf("PLCForum ");

   trasmetti(string,6);

    DO{

    

}WHILE(TRUE);

 }

[walterword]

cioe quindi il ciclo for posto nell'interrupt di ricezione e' un ciclo che ad ogni luppata si ferma ad aspettare

che ci sia un nuovo byte ?

questo perche preleva il byte col getc()? e il getc() ci restituisce il byte quando l'hw del micro

alza il flag appropriato nel regitro di ricezione ?

Si in effetti vedendo l'assembly , per quel poco che ne so sembrerebbe che testi il flag

di byte arrivato e poi continua il loop , quindi ogni volta che viene richiamato l'interrupt noi in teoria ci siamo gia dentro , in particolare nel ciclo for che ha gia incrementato l'indice per depositare il nuovo byte

nel posto giusto

dico bene fratello?

ok domani provo il codice , poi posto il mio

non capisco una cosa , nella routine di ricezione fai un putc(lu) senza alzare prima il driver eneble

al max485 , oppure e' una scrittura a vuoto come un trucco per ottenere qualcosa

cosa vuol dire ?

lo provo col pc , cosa dovrebbe arrivarmi ?

"PLCForum "

"ciao"

ciao

walter

[walterword]

qualcuno di voi sa dirmi il significato dell'istruzione

"ioi" , viene usata spesso in funzioni assembly del rabbit

[dlgcom]

non capisco una cosa , nella routine di ricezione fai un putc(lu) senza alzare prima il driver eneble

al max485 , oppure e' una scrittura a vuoto come un trucco per ottenere qualcosa

cosa vuol dire ?

non e' niente , facevo solo un eco della lunghezza quando lo provo con il pc. e' da eliminare.

questo perche preleva il byte col getc()? e il getc() ci restituisce il byte quando l'hw del micro

alza il flag appropriato nel regitro di ricezione ?

Esatto , era quello che ti dicevo.

il fatto di usare l'interrupt per ogno carattere e' valido , ma considera che ogni volta che entra nella routine di int. deve fare una serie di cose per salvare tutti i registri e ripristinarli ala fine .

Quindi per ogni 2 istruzioni che servono per la trasmissione e sprechi 10 in piu' per il salvataggio.

Stessa cosa in ricezione , se hai una stringa di byte che ti arrivano , calcola che ogni byte a 19200 ci impiega 0,000460 secondi , calcolando che hai un buffer di 2 byte hai al massimo 0,00093 sec per fare altre cose prima di avere un errore do overflow.

Non so' se e' consigliabile uscire dalla routine con il pericolo cheentri un altra int e ti faccia perdere tempo..

Ma questa e' la mia teoria .

[dlgcom]

IOI nel rabbit serve per dire che vuoi acessare ad un registro I/O interno .

Il processore Rabbit ha due aree differenti per accessare alla memoria.

3.3.8 Input/Output Instructions

The Rabbit uses an entirely different scheme for accessing input/output devices. Any

memory access instruction may be prefixed by one of two prefixes, one for internal I/O

space and one for external I/O space. When so prefixed, the memory instruction is turned

into an I/O instruction that accesses that I/O space at the I/O address specified by the 16-

bit memory address used. For example

IOI LD A,(85h) ; loads A register with contents of internal I/O register at location 85h.

LD IY,4000h

IOE LD HL,(IY+5) ; get word from external I/O location 4005h

By using the prefix approach, all the 16-bit memory access instructions are available for

reading and writing I/O locations. The memory mapping is bypassed when I/O operations

are executed.

I/O writes to the internal I/O registers require only two clocks, rather than the minimum of

three clocks required for writes to memory or external I/O devices.

[Livio Orsini]

Come dice DLGCOM nel rabbit, come in altri processori, lo spazio di I/O è separato dallo spazio di memoria. In questo modo si semplifica il lavoro dei progettisti HW e si ottengono sistemi più "puliti". E' importante ricordarsene quando si trattano le perifireche HW. Anche inquasi tutti i PLC separi la lettura scrittura della memoria da quella degli I/O.

[dlgcom]

Ciao Livio ,

Vedi che il progetto Rabbit non e' morto , ma solo cammina lento anche se pensando al coniglio....

Non so li in Italia , ma qui ho parecchi problemi a far passare un progetto con un Rabbit dovuto all'alto costo dei moduli.

Come va la cosa li? sono molto cari? c'e qualche nicchia di mercato?

[walterword]

Be su fattori commerciali non ho le capacita ne conoscenze per poter quantificare il Rabbit .

Sto leggendo a fatica con mezzo occhio , stamattina sono stato al pronto soccorso per una visita ed ho una media congiuntivite .

In sostanza ho voluto qualche settimana fa iniziare coi PIc per infarinarmi un po coi micro , i registri e le comunicazioni .

il Rabbit l'avevo acquistato nel 2003 ad aprile , il primo a farlo nel progetto on line , e adesso vorrei capirne qualcosa di piu , anche se i tempi sono scaduti e devo sbolognare un paio di lavoretti

Certo a confronto dei PIC e' tutto un altro pianeta , e' una vera potenza

e proprio un micro computer e credo che anche commercialmente debba essere piazzato a svolgere compiti

dove un PIC sarebbe irrisorio ,e un pc troppo costoso ed ingombrante .

Paragonandolo ad un plc direi proprio che sia molto piu potente di un S7-300 , vista la memoria ram e flash

Io lo vedrai come modulo "centrale " , visto le sue risorse in comunicazioni , affiancato da moduli

di acquisizione dati digitali ed analogici basati su PIC16F876 e remotati vari .

Cambia solo il tool di programmazione , ma non e' detto che , e qualcuno gia lo fa , che si possa sempre creare un compilatore che permetta di programmarlo con linguaggi meno "professionali " .

Il plc e' sempre piu alla portata ed assorbe la buona parte di mercato , perche la gente e' lazzarona , senza voglia di essere professionale ; il plc costa sempre di piu compresi i sui tranelli di chiavi , run-time , miriadi di pacchetti opzionali addirittura per importare file da excel ect ect .

penso che comunque in applicazioni veloci , e dove lo spazio sia importante , non ci sia posto per i plc

Ci sono un sacco di applicazioni dove si puo usare un rabbit e ce ne saranno sempre piu :

Automotive ,DOMOTICA, apparecchiature mediche , microcomputer per rilevamneti dati , elaborazione ect .

Anche nel settore industriale c'e' chi sta gia iniziando a pensare che forse sarebbe meglio sviluppare qualcosa di piu appropriato , potente e flessibile tenendo in considerazione semrpe piu "la comunicazione " col resto del mondo o comunque di un area interna , interfacciando sempre piu dispositivi tra loro

il futuro , e presente , e' la telecomunicazione e la trasmissione dati .

Ce ne' da fare , bisognerebbe solo che i parassiti che ci governano inizino a rubare meno , stare un po a casa loro e lanciare compagne ed incentivi a chi avra il coraggio di rimanere in italia a continuare a produrre nel futuro .

Il problema non mi spetta personalmente perche ho gia deciso prima o poi di allontanarmi da lmio paese

per vivere una vita altrove

.... chissa magari proprio in Brasile

ciao

walter

Modificato: 18 agosto 2004 da walterword

[Livio Orsini]

X DLGCOM

Hai mai sentito quella canzone di Rinaldo in campo? Sai quella che fa: "Siamo solo in tre, tre briganti e tre somari sulla strada di Girgenti....." Qui forse siamo in quattro anche se, inteoria, siamo partiti in 15-20. Bhè speriamo pochi ma buoni.

Per il prezzo, se consideri solo il core module, non è per niente caro, almeno per le prestazioni. Da noi il problema principale sono le marcature CEE e le omologazioni. Sta caz2o di europa (volutamente minuscolo) sta strangolando tutto e tutti. Certe regole sono state fatte apposta (dichiarazione del presidente dell'unione aziende di automazione francesi nel 1999) per mettere in difficoltà i piccoli produttori italiani perchè molto fastidiosi (sic!)

Comunque il rabbit è per applicazioni diverse dal PIC. A mio giudizio la forza prrincipale è costituita dagli strumenti di programmazione low cost per una simile macchina, dalle prestazioni velocistiche e dalla quantità di memoria.

[walterword]

stando al manuale Rabbit che sto cercando di consultare

sembrerebbe che ci sia una sorta di multitasking (virtuale) utilizzando i Costate {....}

In effetti potrebbe venir utile per le comunicazioni , cioe senza interrupt

mi piazzo li in un costate e aspetto una connessione tcp\ip , piuttosto che un pacchetto in Rs485 che dovrebbe ritornare dai pic magari

Nel frattempo eseguo altre routine

poi magari non sarebbe male il compilatore dynamic c premier con micro-OS ||

be adesso iniziamo a fare qualcosa , poi si vedra

Modificato: 19 agosto 2004 da walterword

[dlgcom]

Pensando a quello che dice Livio, devo dargi ragione.

Ho fatto mente locale ed in effetti avendo a disposizione tutta quella memoria , la potenza di calcolo e le periferiche , non e' troppo caro .

Lo diventa qui per il fatto che sia importato e la moneta qui non e' forte.

Per le normative , qui per fortuna non si parla molto di questo , quindi ho strada libera per progettare e vendrere quello che voglio.

In piu' esiste un organo che qui si chiama SEBRAE che aiuta le piccole aziende ad avere successo.

Hanno contatti con IMMETRO che e' quella che da l'ok per le apparecchiature ... stile CE in italia.

La mi possono aiutare a certificare le mie schede...

Ma bando alle ciance , iniziamo lo scambio.

X Walter ,

Costate , non si riferisce alla carne ai ferri ma e propio un semi multitask.

Se scrivi un programma dove c'e' un ciclo for di attesa per accendere un led ed un altro per aspettare un carattere da una tastiera , con il COSTATE possono dividere il tempo CPU e fare le due cose " contemporaneamente" dividendosi le risorse.

Molto potente come istruzione.

Adesso faccio io una domanda.

Nei pic ho la possibilita' usare i timer interni come contatori di impulsi esterni.

Bene , Esiste la setssa possibilita' nel Rabbit? come posso fare?

Oppur si possono usare solo le entrate per gli encoder ?

[walterword]

per l'encoder so che c'e' un qualcosa di predisposto , ti parlo della board prototipo che ho io

con il rabbit 3000

per i timer non posso darti una risposta in questo momento

ho appena ritolto la polvere e sto provando tutti gli esercizi primari , in prativca quelli che dici tu

del costate , ledfalsh1.c ledflash2.c ect .

spero di riuscire a combiare qualcosa , intanto i 2 PIC sono che si scambiano i soliti pacchetti , in attesa

di un master degno , cioe il Coniglio .

Adesso faccio ancora qualche esercizio , e domani se gli occhi melo permettono vorrei iniziare a studiarmi qualche registro importante ed i mnemonici , PADDR , Shadow ect

non ho ancora afferrato il significato dei registri "ombra" , sono forse una copia in ram dei registri veri e propri

che vengono tirati in ballo per raggiungere una sicurezza forse ?

[Livio Orsini]

I timer usano contatori interni (non vedo come è possibile usarli da segnale esterno).

Attenzione alla programmazione del timer: non è così come potrebbe sembrare a prima vista, specie il prescaler del timerB. L'anno scorso, quando ero immobilizzato dal gesso, ho speso qualche giorno per analizzare bene il sistema; ho ancora i listati delle prove e ne avete necessità li posso mettere on line.

Per l'encoder: ci sono due canali encoder bidirezionale, sono disponibili anche le librerie.

Avevo pubblicato uno schema di simulatore encoder (dovrebbe esserci il linck su un post precedente). Con in ingresso 0-10v hai in uscita un frequenza (con due canali in quadratura) che varia da 3Hz a 30kHz. Caso mai lo rimentto in line.

Ueri sera ho ripreso ad usare il coniglio, tempo di togliere le ragnatele dal cervello e poi sarò operativo.

[dlgcom]

Infatti anche io stavo leggendo la storia die timer per vedere se c'era qualche analogia con pic... purtroppo no , ma ci si arrangia.

I moduli RCM3000 3010 hanno le entrate encoder che quindi si possono usare come contatori esterni, ma per esempio una nuova famiglia la 3700 se non sbaglio non ha queste entrate .. quindi ero curioso di sapere come si potava fare .

Anche io ho eseguito tutti i prg base anche tcp/ip e funziona , ora e' solo iniziare a fare qualche cosa di serio.

Il problema e' che la documentazione non e' molto completa ... oppure le info sono sparse in piu' manuali ...

Ma niente paura ... spero..

X Walter

non ho ancora afferrato il significato dei registri "ombra"

I registri shadow sono un appoggio a dei registri di sola lettura , nel manuale giustifica l'esistenza di registri write only per un fattore di costi .

Quando scrivi in questi registri , non hai la possibilita' in seguito di sapere cosa c'e' srcitto, quindi copy il valore del registro nel suo corrispondente "ombra" che potrai consultare quando ti fara' comodo.

Hanno predisposto anche un opzione per evitare che un interrupt si scateni tra la scrittura del reg . W/O e il suo Shadow , per evitare problemi di discrepanze..

... ovvero , il facile reso difficile mediante l'inutile .... :ph34r:

Spero di essere stato chiaro.

[walterword]

chiarissimo fratello

oggi ho iniziato il montaggio fisso sulla demoboard del Rabbit

- 1 dip switch a 8 posizioni

- 1 PCF8574 per gli 8 ingressi con relative resistenze al +5 V

- 1 PCF8574 per le 8 uscite con i relativi 8 led di uscita senza resistenza perche il Pcf butta fuori 1.75 V giusto giusto per un led , in futuro applichero dei chip driver per pilotare dei rele ma adesso non mi interessa

-1 Max485 con relativi morsetti per collegarci il cavetto telelfonico twistato del quale ho fatto buona scorta

- Ho collegato il bus I2C per i PCFxxx alle porte PD4 e PD5

-Per la seriale mi son collegato a quei pirlunini che si sono sulla demoboard , che dovrebbero essere gia coperti

dal driver max232 , colegati rispettivamente sulle porte seriali B e C

Pero forse e' meglio che mi collego ad una seriale senza uscirta rs232 , tanto poi ho il max485

cosa ne dite ???

aspetto vs. considerazioni per finire di pelarmi le mani col saldatore marcio che ho e provare il sw

ciao

walter

[dlgcom]

Per le seriali se devi collegare un max485 , ti converrebbe usare una porta seriale diretta , senza passare per J5 la tensione deve essare sicuramente superiore.

Una domanda , perche' usi i PCF , non ti bastano le entrate uscite gia del modulo?

Io invece usero' un UDN2981 come driver di uscita e foto accoppiatori come entrate .

Ricordando che le uscite sono a 3,3v quindi in alcuni casi sono da adattare a 5v o piu'.