Newsgroup: it.hobby.elettronica.digitale
Titolo: ST62xxx Bug o altro???

Ciao!, stò realizzando una centralina elettronica x il controllo e
funzionamento di una macchina industriale, tutto ruota intorna a dei
micro ST62xxx ma ora sono arrivato ad un punto che mi stà facendo
perdere un sacco di tempo sensa capire il xchè!
In pratica un ST62E25 gestisce un LCD 4bit out (data port_c) + 2bit out
(CS e E port_b), 6 bit out (port_b out azionamenti...) port_ a vari:
in/out di cui A1 imput + interrupt, e A2 lettura tastiera seriale NMI
(outA encoder) (outB encoder A3).
Il problema è questo ho utilizzato l'ingresso NMI per poter rilevare con
priorità assoluta, eventuali movimenti dell'encoder... ma ho cmq la
necessetà di gestire la tastiera (a sua volta realizzata con un st62t10)
con ben 42 tasti!. Inizialmente quando non si poneva il problema
dell'encoder, la tastiera veniva gestita semplicemente quando il prg era
libero di gestirla, e la comunicazione dei dati su 2 soli fili avveniva
in RS232 + in bit (semaforo) che sincronizzava l'rx eil tx.
Purtroppo + tardi mi sono reso conto di dover gestire la tastiera
anchessa con un interrupt, e ho dovuto scartare l'invio dei dati in
rs232 (il prg che avevo realizzato utilizzava l'interrupt timer x le
sincronizzazioni) xchè non sono riuscito a gestire all'interno
dell'interrupt A_int anche il l'interrupt timer.... Ho quindi
interfacciato la tastiera e il micro con un sistema del genere: un bit
normalmento alto del tx entra nel pin A1 dell'rx impostato come imput +
interrupt e l'altro bit nel pin A2 dell'rx impostato come imput. Il tx
invia sul pin A1 un clock (basso) dopo aver alzato od abbassato il bit
su A2, l'st6 rileva sul fronte di discesa di A1 l'interrupt event e
salta alla subroutines A_int, legge lo stato della porta A2 e imposta il
bit entrante alto, o basso, quando sono arrivato all'8vo bit imposto una
variabile che letta dal main del prg rileva l'avvenuta formazione del
bits inviato, dopo aver riazzerato la variabile eseguo la funzione
abbinata al tasto.
Tutto funge alla meraviglia, ma basta modificare, aggiungere, o altro al
codice del prg (anche del tutto estranea alla gestione della tastiera)
non ancora completo, che addio lettura... non funge + nulla!!! solo la
lettura dell'encoder (NMI) se tutto và bene viene mal interpretato il
codice del tasto inviato...In + assurdità maggiore se rimuovo un set
x,port_b res x,port_b (porta B abilitata TUTTA come OUT) che non ha
nulla a che vedere con la gestione della tastiera (port_a) il prg non
funge lo stesso (ho verificato alla nausea il sorgente...) Il problema è
mooolto + lungo e complesso di quanto sono in grado di descrivere ora (o
fatto mille tentativi diversi modificando anche radicalmente il codice )
quindi non mi dilungo ulteriormente... se qualcuno ha una idea o pensa
di potermi aiutare... possiamo magari insieme risolvere un'altro dei
misteriosi comportamenti del tanto amato ST62xxx (ho in lista diversi
bug con cui mi sono scontrato...)
                            MI SCUSO X L'ECCESSIVA LUNGHEZZA MA HO DETTO
PRESSO + DI NIENTE
TNX!!!    (PS. sono disponibilissimo a contatti anche telefonici
(naturalmente a mie spese) per la risoluzione del prbl.)

perdere un sacco di tempo sensa capire il xchè!
Non conosco st62 ma st60, ma qualche anno fa ho avuto un problema simile, e la
caosa (dopo diverse settimane di esperimenti) era nel watchdog che a volte
scattava a causa della eccessiva lunghezza del programma in un punto.
La vita, e' una malattia mortale a lungo termine, trasmessa 
per via sessuale !!
   Un ginecologo...
ROTFL!

 scattava a causa della eccessiva lunghezza del programma in un punto.
Purtroppo non è:   :-(
1°) ho controllato ed il wdog viene ricaricato moolto prima del necessario...
2°) se anche così fosse dovrei ottenere un reset del micro evidentissimo dal
display LCD
3°) ho monitorato punti critici del prg aggiungendo dei set e res su pin out della
port_b registrati poi con un oscilloscopio digitale FLUKE ...

Domenico Marsico ha scritto:

Potresti avere uno stack overflow...  è molto difficile da riconoscere nel caso non
disponessi di emulatore.
CIAO, Riccardo.

Ciao!, stň realizzando una centralina elettronica x il controllo e...
Secondo me ti sfora lo Stack delle chiamate. L'ST62 come ben saprai ha
6 livelli di stack, quindi nel caso in cui fai piu' di 6 chiamate
annidate succede un patatrac. Ovviamente e' incluso anche l'NMI e gli
altri possibili Interrupt. Essendo l'NMI sempre attivo i livelli di
Stack a tua disposizione si riducono almeno a 5 in quanto l'NMI ne
occupa 1 (e potendo scattare in qualunque istante non ti puoi
permettere di coprire 6 livelli).
Per altri eventuali problemi puoi fare riferimento alla mia Home Page
in cui ho evidenziato parecchi dei difetti degli ST62xx e diversi
possibili errori da impazzimento (tra i quali c'e' anche quello che ti
ho descritto).
Ciao, Massimo
E-Mail    
max...@libero.it
Visita la pagina dedicata ai microcontrollori ST62
all'indirizzo 
http://digilander.iol.it/max4000

Max4000 ha scritto:

Io lo dissi ieri...forse un po' stringato ma degno di essere notato anche
da Te.
CIAO ! Rik.

Intanto... anche io sto lavorando con la famiglia st62... ed č
complicatissimo debuggare senza Emulatore (sniff... :-( )
Io di tutto quello che hai scritto qui sotto non ci ho capito una mazza...
scusa, ma mi si intrecciano le idee a leggere qua! :-) Se vuoi puoi mandarmi
una spiegazione piů dettagliata in privato! Intanto voglio darti un
consiglio... se il 6225 ha un ADC interno... perché non usi una tastiera
analogica???
Lorenzo p.i. Castricini

CIAO ! Rik.
E con questo ? hai l'esclusiva sulle risposte ?
Quello e' un problema che tempo addietro ha fatto impazzire anche me e
che e' spiegato dettagliatamente da tempo sulla mia HomePage.
Ho ritenuto opportuno spiegare bene cosa accade.


 all'indirizzo 
http://digilander.iol.it/max4000
No scherzo, ma io avrei fatto il reply sul mio msg ...per specificare...per
spirito di gruppo...che so' non so nemmeno xchè ho replicato al tuo...
Ossequi :-)




 Lorenzo p.i. Castricini
Per il semplice motivo che se costruisci una buona routine e se usi partiori
resistivi di precisione o cmq hai dei riferimenti di tensione abbastanza precisi
sei fortunato se riesci a gestire senza troppi rallentamenti circa 18 tasti, e
non 42!!! poi ho notato le il convertitore ADC degli st6 sono piuttosto
"rumorosi" e in alcuni casi creano qualche problema... a mè è capitato in un
caso di ritrovarmi con un st6 che funzionava da sensore di luminosità l'st6 era
di quelli finestrati e in funzione della luce il prg "accendeva" o "spegneva"
alcuni bit delle sue porte A B e C...... vedi tu...

Ossequi :-)
Fa niente, ci sono problemi piu' grossi nella vita


 all'indirizzo 
http://digilander.iol.it/max4000
Sono davvero gratificato dal constatare una tua risposta, xchè avevo già
tempo fà trovato la tua home page e l'ho trovata ottima, e un
vero punto di riferimento per gli "utenti" italiani degli MCU della
famiglia ST6. Purtroppo però conosco già il problema delle chiamate
call e del limite dei 6 livelli di annidamento (che scendono a 5 con l'NMI
sempre presente) ho già controllato anche il set di istruzioni tipo
set res jrs etcc. che operano sulla porta A che purtroppo è settata come
out e come imput con e senza interrupt (A1) ho utilizzato una
var tipo park_a su cui eseguo le operazioni sui singoli bit e poi con un
bel LD a,park_a poi seguito da un LD port_a,a. per ogni
subroutines vengono salvati accumulatore e registri se utilizzati, il wdog
è ricaricato alla nausea, non esistono cambi di impostazioni delle
porte...
Molto sinteticamente il programma è così:
Bit 1 port_a settato come imput con iterrupt
A_int
            ( inc nbit )
            (rilevazione bit 1 o 0 su 0,port_a)
            (impostazione del bit nbit 1 o 0  )
            ( nbit = 8 (sì bits=1) / (nò bits rimane 0)
            reti
NMI_int
               (lettura signal A encoder)
                (lettura su 3,port_a signal B encoder)
                (esegui incrementi o decrementi su valore dell'encoder e
restituisce i nuovi dati)
               reti
Main
           (azzeramento variabili)
            (inizializzazione display LCD, epot, motori etc..etc..)
           set 4,ior  (abilitazione interrupt generale)
loop    ldi    wdog,254
           (aggiorna display)
           ( i dati sul diplay vengono aggiornati dai valori restituiti
dalla NMI interrupt)
           (bits = 0) (sì jp loop ) / (nò jp ctrlkey)
ctrlkey    (bits = 0)
                (esegui controllo dato ricevuto dalla tastiera...)
                (e salta la routines corrispondente)
                jp loop
così com'è il prg non ne vuole di leggere o interpretare bene la tastiera,
ma la lettura dell'encoder e di tutte le funzioni legate
sono ok, se aggiungo subito dopo il label NMI_int l'istruzione ldi ior,0 e
all'uscita set 4,ior la tastiera funge fino a quando non avviene
una chiamata alla nmi_int (mentre prima nò, anche se la nmi_int non veniva
MAI chiamata!!!) (tra l'altro la routines nmi viene sempre
eseguita correttamente). Un'altra stranezza ??? la porta B è settata TUTTA
come out e non ha niente a che vedere nè con la tastiera nè
con interrupt nè con le linee di programma eseguite prima delle
incriminate, ma se dopo il label loop inserisco una bella set 1,port_b e
subito dopo ctrlkey res 1,port_b il programma funziona correttamente a
patto che nella routine di NMI non controllo il numero dei step
effettuati dall'encoder prima di incrementare o decrementare l'unità e
quindi ad ogni lettura dell'encoder automento  o diminuisco il
valore, senza quei inutili set e res della porta B! non funge proprio.
Mi sono dilungato oltre misura e quindi interrompo momentaneamente quì se
hai altri suggerimenti domande o che altro te ne sarei grato.
                                Bye e complimenti per il sito.... ;-)
PS naturalmente un ringraziamento và a TUTTI coloro che hanno replicato...

                                Bye e complimenti per il sito.... ;-)
ancora grazie


 all'indirizzo 
http://digilander.iol.it/max4000
Ho provato a gestire la tastiera senza disturbare l'interrupt sulla porta A,
gestendo meglio e ottimizzando un pò il
main program in modo tale che se anche la lettura della key fosse
"serializzata" (cioè le gestione della tastiera avviene solo
quando il loop nel main program lo consente) non ci fossero tempi di attesa
troppo lunghi, ma anche in questo semplicissimo caso ho diversi problemi che
non riesco a capire (e il primo prg in assoluto che mi ha dato questo tipo di
problematiche...).
Ora ho una domanda, l'editor e l'assembler di cui dispongo, sono quelli forniti
nel kit di NE (il primo) e ultimamente danno questo problema:
                    l'editor nel momento in cui vado a salvare un file sorgente
.ASM se è + lungo (di non ho ancora calcolato quanto), blocca il computer (a
volte compore un msg d'errore del dos) ed è possibbile solamente resettare il
comp. stesso...
per risolvere stò utilizzando il semplice comando edit del dos poi lo carico
sul prg di NE SENZA salvare, e da lì assemblo e programmo...
PS il file *.asm che si è tentato di salvare diventa o lungo 0 bytes oppure
viene alterato in parte (parecchie linee mancanti, caratteri sparsi x il prg
etc.. etc..) Grazie a questo bel sistema ho perso diversi lavori di settimane
(è facile una volta assemblato il tutto farsi scappare un save di
sicurezza....). ho notato che se il sorgente trattato così anche se a video
viene ripristinato (ricomponendo il prg) quando si prgmma l'mcu ci sono
comportamenti strani... non sò se questo può essere la causa del prb come
sopra, perchè ho importato diverse subroutines da vari prg che avevo realizzato
precedentemente (chissà magari qualcuna ha subito un "restauro") ma il prg
complessivamente è troppo lungo e noioso da riscrivere x intero senza rompersi
troppo le OO.
Di nuovo un saluto Bye!

Di nuovo un saluto Bye!
Ciao, Massimo
