definizione porte di I/O

Sezione dedicata al sistema di sviluppo BASCOM-AVR per i micro AVR
At90s, Attiny, Atmega e Xmega

definizione porte di I/O

Postby mario59 » 06 Jun 2014, 22:52

salve,
chiedo scusa a tutti del mio "tempestare" di domande, ma la mia ignoranza ancora mi "morde" su questo sistema... :oops:
Ho un arduino 2009 che programmo con il BASCOM
ho un problema semplice: definire i pins di I/O (PC0...PC5), attivando i pull-up interni solo per alcuni pins.
Più esattamente voglio definire:
PC.0 = è in input e deve essere a "1" logico, perchè deve essere attivo il pull-up interno.
PC.1 idem
PC.2 idem
PC.3 idem
PC.4 è un OUTPUT e deve essere normalmente a "0" logico
PC.5 uguale a PC.4

nell'header di definizione ho scritto:

Ddrc = &B11110000 'definizione direzione pins porta C: 0=IN, 1=OUT
Portc = &B00001111 'attiva pullup PORTC

dopo aver programmato correttamente il micro, mi trovo i seguenti stati logici alle uscite:
PC.0 = "0" logico
PC.1 = "0" logico
PC.2 = "1" logico
PC.3 = "1" logico
PC.4 = "0" logico
PC.5 = "0" logico.

inutile dire che ho controllato molte volte il tutto. Non ci sono corti.
Nel simulatore, invece, funza tutto bene.
qualcuno sa dirmi perchè? :roll:
Mario59
User avatar
mario59
 
Posts: 43
Joined: 27 Mar 2013, 17:33
Location: Napoli

Re: definizione porte di I/O

Postby einstein » 06 Jun 2014, 23:05

ciao mario
la configurazione mi sembra giusta e vedo che il problema sussiste solo per i pin pc0 e pc1 che dovrebbero essere anche loro a 1, dico bene?
User avatar
einstein
 
Posts: 88
Joined: 01 Mar 2014, 15:10
Location: Siracusa

Re: definizione porte di I/O

Postby pier » 07 Jun 2014, 09:22

Anche a me sembra che la configurazione sia corretta ed il fatto che gli altri pin si comportano correttamente di fatto lo confermano senza contare la simulazione ok.
Hai cose collegate a PC.0 e PC.1? Tieni presente che il valore delle pull up dichiarato da Atmel per l'ATmega128 è compreso tra 20 e 50K.
Visto che parli di livelli 0 e 1, cosa usi per misurare i livelli fisicamente?
Inoltre più che un controllo visivo consiglio di staccare il micro dalla scheda e misurare la resistenza verso GND dei pin 1 e 2 di J1 (corrispondenti ai pin 23 e 24 del micro ovvero a PC.0 e PC.1).
Se tutto ok non escluderei un problema al micro.
Tutto questo ovviamente vale nel caso in cui il codice caricato sul micro sia esattamente e SOLO quello postato altrimenti bisogna vedere che altro gli fai fare...
pier
 
Posts: 115
Joined: 11 Aug 2013, 22:05

Re: definizione porte di I/O

Postby mario59 » 07 Jun 2014, 15:06

Ciao Pier e einstein ( :o :D )
grazie molte per l'attenzione al mio problemino
Da PC.0 a PC.3 ho collegati 4 pulsanti verso massa -IDENTICI-
Oggi ho provato a ricompilare e flashare il micro più volte.
diciamo una decina.
Su tutte queste volte IN DUE CASI il pin PC.1 si è comportato come PC.2 e PC.3
Mentre PC.0 è rimasto invariato.
in allegato trovate la copia dello schema elettrico.
Giusto per chiarezza allego lo schema elettrico
Image
c'è qualcosa che mi sfugge? :roll:
M
Mario59
User avatar
mario59
 
Posts: 43
Joined: 27 Mar 2013, 17:33
Location: Napoli

Re: definizione porte di I/O

Postby mario59 » 07 Jun 2014, 15:08

Ah, dimenticavo di dire che i pull-up sulla piastra ci sono fisicamente, indipendentemente da quello interno dell' ATMEL... :geek:
e lo "0" logico lo trovo anche staccando i pulsanti.
boh! :? :? :?
Mario59
User avatar
mario59
 
Posts: 43
Joined: 27 Mar 2013, 17:33
Location: Napoli

Re: definizione porte di I/O

Postby pier » 07 Jun 2014, 16:52

Beh, questa instabilità nei risultati esclude quindi definitivamente il codice. Tra l'altro avendo tu pullup fisici non ti servirebbe neppure programmarli.
Gli imputati restano quindi il micro e la programmazione.
Fai ancora un tentativo: stacca il micro e controlla i livelli a micro staccato (qualora avessi problemi hw intermittenti)
pier
 
Posts: 115
Joined: 11 Aug 2013, 22:05

Re: definizione porte di I/O

Postby deluca » 07 Jun 2014, 18:38

Salve a tutti,
@mario, hai provato a vedere se i pin in questione funzionano bene se configurati come out?
Ho letto il topic e come già detto da pier escluderei assolutamente il codice.

Sicuramente Il prb è da ricercarsi altrove.
Ciao
Il mio sito: http://www.delucagiovanni.com ......e la chat: chat/
User avatar
deluca
Site Admin
 
Posts: 1104
Joined: 19 Jun 2011, 10:44
Location: 95123 - Catania (Italy)

Re: definizione porte di I/O

Postby pier » 07 Jun 2014, 19:46

Ma la verifica dopo la programmazione va sempre a buon fine?
Questo ti direbbe qualche cosa sulla stessa.
Se va sempre a buon fine non resta che un problema Hw (saldature fredde, crepe nelle piste, etc) oltre che qualche dubbio sul micro
pier
 
Posts: 115
Joined: 11 Aug 2013, 22:05

Re: definizione porte di I/O

Postby mario59 » 07 Jun 2014, 20:04

ciao a tutti!
sono veramente contento di poter discutere con qualcuno di questi problemi !!! :D :D :D
grazie a tutti per le idee. Posso dire che questo problema è risolto, grazie a voi!
IL problema risiedeva nell'alimentazione dell'arduino. Con l'oscilloscopio ho potuto vedere che i 5v in piastra erano 4,3v o giù di lì quando era alimentato da USB.
La cosa curiosa è che il programmatore interno del BASCOM mi dava SEMPRE programmazione OK!!!
ho cambiato il regolatore e il "bestio" ha ripreso a funzare regolarmente :D :D :D
Ma non finisce qui, ragazzi: ho un nuovo quesito da postare e questo lo farò prossimamente in un altro topic.
grazie ancora a tutti! :mrgreen: :mrgreen: :mrgreen:
Mario59
User avatar
mario59
 
Posts: 43
Joined: 27 Mar 2013, 17:33
Location: Napoli

Re: definizione porte di I/O

Postby pier » 07 Jun 2014, 20:07

Complimenti a te. Non era facile da beccare!
Per la risposta "curiosa" del programmatore non mi stupirei più di tanto. Probabilmente la programmazione andava veramente a buon fine; era il funzionamento dopo che "scalchignava". 4,3 (misurati un po' a spanne) non erano poi tanto lontano dai 4,5 minimi previsti dal ATmega128....
pier
 
Posts: 115
Joined: 11 Aug 2013, 22:05


Return to BASCOM-AVR

Who is online

Users browsing this forum: No registered users and 3 guests

cron