[C] muduli che non modulano!!!

[lefermops]

ciao a tutti!! ^^
ho diviso un programma lunghetto in moduli, in modo che nel modulo principale ci sia il main principale con tutte le sue funzioni, e due moduli opzionali.
nel primo ho messo tutto quello che serve per il bootstrap della mia CPU (i settaggi dei parametri, inizializzazioni,...) e che si setta solo la prima volta che la accendo; questo perchè il bootstrap sia indipendente (e funziona!! anche perchè o setto i parametri del bootstrap oppure ho il funzionamento normale).
forte di questo mio successo, sono partita tutta giuliva per fare il secondo modulo, che dovrebbe contenere le impostazioni scelte dall'utente. durante il funzionamento normale, posso entrare nel sottoprogramma del modulo, fare delle scelte e vorrei poter tornare al main principale.
ci ho messo un bel return. ma invece di tornare al main, la mia CPU pare addormentarsi e resta bloccata in un metastato da cui non riesco a farla uscire.


modulo principale:

#include variabili.h
void main(void)
{
bootstrap();
[....]
printf("entro in opzioni utente")
scanf("%", &car);
ik (premo==s)  opzioni_utente();
[....]
}

modulo bootstrap:

#include variabili.h
int scelte_utente(void)				
{timer = 500;                            // carico timer a 5 SECONDI
switch(stato)	                     //scelta
  {case 1:                                 // stato iniziale  
   clr_disp();		       //spegne i display
   if (premo==1)      stato=2;
   if (premo==2)      stato=3;
   if (premo==3)      stato=4;
   break;

   case 2:      inizializza_converter();
   break;

   case 3:      carica_temperaturaOK();
   break;

   case 4:      carica_risoluzione();
   break;

    }
}

modulo opzioni utente:

#include variabili.h

int scelte_utente(void)				
{timer = 500;                            // carico timer a 5 SECONDI
switch(stato)	                     //scelta
  {case 1:                                 // stato iniziale  
   clr_disp();		       //spegne i display
   if (premo==1)      stato=2;
   if (premo==2)      stato=3;
   if (premo==3)      stato=4;
   if (premo==4)      stato=5;
   if (premo==esc)   return 0;
   break;

   case 2:      setta_risoluzione();
   break;

   case 3:      setta_temperaturaOK();
   break;

   case 4:      setta_datario();
   break;

   case 5       setta_password();
   break;
  }
}

la libreria variabili.h contiene la dichiarazione delle variabili globali in modo che siano visibili da tutto il programma.

sapete dirmi dove ho sbagliato?
grazie mille per l'attenzione!!!^^

[cionci]

Gli include si usano così:

#include "variabili.h"

Per ogni variabile globale che usi un programmatore piange... Inoltre così non potrà mai funzionare perché lavorerai su variabili globali ma ridefinite in ogni modulo ogni volta che includi variabili.h.

[Ikon O'Cluster]

[fero86]

volete capirlo che le donne vanno tenute lontane da qualunque forma di tecnologia?

[fero86]

onde evitare il ban do il mio contributo utile al thread

le variabili nell'header vanno dichiarate extern e poi devono essere ridichiarate all'interno di uno solo dei... "moduli"

[Ikon O'Cluster]

Non è bello discriminare le donne programmatrici, sebbene a livello empirico non mi sia mai riuscito di smentire alcuna forma di discriminazione in tal senso. In ogni caso faccio notare che la figlia di Lord Byron è stata la prima programmatrice della storia. Programmò l'algoritmo di Bernoulli per una macchina meccanica. Ahimè non so per quale motivo (spero non per via dell'implementazione) il progetto non venne mai realizzato praticamente........

[lefermops]

premetto che sto cercando di "tradurre" un mio programma assembler in C causa obsoletamento del vecchio micro. e come ho già detto non pensavo che questo passaggio fosse così difficile!!!!

si, ho dimenticato le virgolette, ma nell'oroginale ci sono^^ (#include "Variabili.h" dove le variabili sono ext) infatti il modulo del bootstrap da cui ritorno spegnendo e riaccendendo la cpu, funziona.
ma è il return del modulo utente che non funge!!! non riesco a tornare al main. ormai sono ai tentativi, visto che da libri e manuali non ho trovato soluzioni. ho provato a cambiare il tipo di dato del return (int, char, long,...) e vorrei evitare il goto (il mio insegnate diceva che lo usano solo i programmatori inesperti...) in assembler ci piazzavo un bel RET e tornava da chi chiamava, ma in C sembra non richiudersi. non riesco a trovare l'errore in cui incappo.... qualcuno che ci è già passato sa darmi una soluzione? grazie mille per la vostra attenzione!!^^


Discriminazioni ne subiamo a iosa..... perfino al supermercato, quando sono andata col mio fidanzato per acquistare un hard disk esterno. e l'impagabile espressione di sorpresa del commesso, quando il mio topolone gli ha detto "parli con lei che io non ci capisco niente!!" mi considero comunque una buona utilizzatrice di pc (tanto che a volte mi è capitato di sistemare quello del capo (ometto^^), che non ha testa per pulizie, deframmentazioni, aggiornamenti...^^)
Se ricordo bene, Ada Byron e Babbage sono del 1850 circa.... e la macchina non sono riusciti a terminarla perchè credo che siano morti prematuramente entrambi.
vi siete mai chiesti se fossimo noi a tentare di implementarla, con le tecniche dell'epoca, senza i microprocessori cui siamo abiutati, senza pc, senza video.... senza diodi o transistor!!!....brrrrr!!!! il solo pensiero fa rizzare i capelli in testa......^^

[Ikon O'Cluster]

lefermops malgrado sia un uomo, odio i maschilismi gratuiti... fanno troppo talebano e nel 2009 non è possibile permetterlo! Cmq al di là di questo appena ho un attimo di tempo cerco di guardare meglio. Come tesi triennale sviluppai un bootloader, quindi con i salti tra ASM e C ci sono abituato. Però non riesco proprio a capire niente. Cerca di essere più precisa. Cerca di scrivere meglio il codice e prova a dirci dov'è la return che non ritorna!

[lefermops]

il main se si premono due tasto insieme, nel mio caso 1 e 9(perchè sono abbastanza lontani e quindi è intenzionale!!!^^), richiamano il modulo scelte_utente.
in questo modulo ho provato a mettere il retun subito nel primo case schiacciando un tasto, oppure creando un case tutto suo, ma è inutile! si spegne il display, non so più dov'è o cosa stia facendo la cpu....... non ho ancora provato il goto su una label nel main, perchè temo di scompaginare il program counter..... non capisco perchè questo registro non riesca a tenersi l'indirizzo a cui tornare.....

[#include "variabili.h"

int scelte_utente(void)				
{
switch(stato)	                     //scelta
  {case 1:                                 // stato iniziale  
   clr_disp();		       //spegne i display
   if (premo==1)      stato=2;
   if (premo==2)      stato=3;
   if (premo==3)      stato=4;
   if (premo==4)      stato=5;
   if (premo==0)      stato=0; 
//avevo persino provato if premo==0) return......ma non funziona...   
   break;

   case 2:      setta_risoluzione();
   break;

   case 3:      setta_temperaturaOK();
   break;

   case 4:      setta_datario();
   break;

   case 5:       setta_password();
   break;
   
   case 0:       RETURN;  <----- è questo!!!!
  }
}

[Ikon O'Cluster]

Continuo a non capire cosa vuoi dire... per come hai usa tu il codice mi sembra che l'esecuzione abbia questo ordine:

1) Si entra in seclta_utente
2) Si valuta stato all'inizio dello switch

A questo punto quanto vale stato??? Supponiamo 1:

3) Si sceglie case 1
4) Spegne i display
5) Modifichi lo stato (potrebbe non succedere)
6) Break (esce dallo switch)
7) Il compilatore ti dà errore perchè non ritorni un intero all'uscita dello switch... cmq supponiamo che ci metti "return N;" ritorni al chiamante.

Adesso mi domando: il chiamante è in assembly??? Se sì e non hai un ritorno corretto, tutto mi fa pensare che in precedenza hai caricato male la pila e quindi non ritorna a dovere. Se è in C il problema è altrove.

In tal caso scrivi il codice con maggior completezza, tipo introducendo anche quello relativo al chiamante, e mostraci dettagliatamente una specie di esecuzione di debug ipotizzando i valori che supponi in ingresso e quelli che ti attendi in uscita.

[lefermops]

grazie per l'aiuto, Ikon!!^^
il main è scritto in C.
prima di entrare in scelta_utente pongo, ancora nel main, stato =1 in modo che lo switch passi direttamente al case1. premendo i tasti, modifico stato in modo da accedere ai diversi case che compongono il modulo (e questa parte funziona....) arrivo nel case scelto, faccio quello che devo fare, poi premo il tasto "C", metto stato=1) e torno al case 1. ma se premo per tornare al main, il display si spegne e non so dove sono..... è come se il program counter non sapesse dove tornare....

[Ikon O'Cluster]

Ho troppi pochi elementi il codice è molto grande??? Potresti fare un copia e incolla preciso di tutti i sorgenti, specificando il nome del file su ognuno di essi? Xkè così non riesco proprio a vedere il problema dove sia...

[Volutomitra]

Non è che "premo" possa assumere un valore diverso da 0, 1, 2, 3 o 4?

[Ikon O'Cluster]

uscirebbe dallo switch causando il termine della funzione... a norma è sempre bene prevedere un caso default...

[Ikon O'Cluster]

Cmq vorrei far presente che al di là dell'uso da abolire delle variabili globali... cosa di per sè oscena ed inutile... Ci sono tanti accorgimenti di buona programmazione. Ad esempio riscrivo la funzione:

#define RET_OK 0
#define RET_ERR 1

int scelte_utente(void) {
	switch(stato) {
		case 1: clr_disp(); if(premo >= 1 && premo <= 4) stato = premo+1;
		case 2: setta_risoluzione(); break;
   		case 3: setta_temperaturaOK(); break;
		case 4: setta_datario(); break;
		case 5: setta_password(); break;
		case 0; return RET_OK;
		default: fprintf(stderr, "ERROR: Unknown Command!"); return RET_ERR;
	}

	// Never reached...
	fprintf(stderr, "ERROR: Code execution!");
	return RET_ERR;
}

Vediamo cosa c'è di buono:

1) Ho definito delle costanti di errore/successo che mi permettono di definire dei valori di ritorno in modo che il chiamante sappia cosa è successo. Ad esempio al posto di RET_ERR posso definire più tipi di errori con vari valori in modo da permettere di capire al chiamante anche quale errore si è verificato. In realtà esistono modi standard per gestire queste situazioni, ma alla buona senza stare troppo ad applicarsi, questo lo definirei un metodo di buon senso.

2) Quando si scrivono troppi if incascata o si mette uno switch (per aumentare la legibilità del codice) oppure si trova un metodo alternativo. Ti faccio notare che la mia scelta valuta 1 sola condizione rispetto ai tuoi 5 confronti. E' una banalità, ma è altrettanto banale ridursi ad un solo if. Devi considerare che riducendo le righe di codice, statisticamente si riduce anche il numero assoluto di errori contenuti.

3) Nel case va previsto sempre un caso default. Non si sa mai, ma un utente può sbagliare l'input, o tu puoi sbagliare codice, magari era corretto, ma magari fai una modifica e non lo è più.

4) Come nella nota 3 c'è un punto del codice mai raggiunto... e se modifico il codice e x sbaglio ci arrivo? Quanto tempo dovrà passare prima di accorgermene???

5) Stampare sempre sul stderr (e non sullo stdout) i messaggi di errore e strutturarli in maniera tale che siano facilmente individuabili, in modo da poter risolvere.

Non vorrei entrare nel filosofico, primo perchè non è il topic e secondo perchè sono ingegnere e come tale disprezzo la filosofia, però la programmazione ha una certa percentuale di arte, scrivere codice non è una cosa facile. Io non lo so fare bene, ma se c'è una cosa che mi sforzo di fare e di scriverlo pensando poche sacrosante cose:

1) Chi legge lo capisce? O parafrasando Einstein lo capirebbe anche la nonna? Quindi giù con i commenti... non dico uno ogni riga, ma anche se fosse non farebbe male. Mi raccomando istruzioni che racchiudano una logica, che non siano fuorvianti. Definite una variabili in più se questo aiuta a scrivere istruzioni più leggibili, tanto è probabile che il compilatore ottimizzi cmq e la elimini...

2) Se da qualche parte posso fare un errore allora devo programmare in modo da poterlo rilevare facilmente. E se posso fare un errore allora la legge di Murphy insegna che sarà il peggiore possibile. E per il corollario alla legge di Murphy si verificherà anche nel momento meno opportuno!

3) (Non è questo il caso, ma in generale...) I nomi delle variabili devono sempre esprimere con precisione il loro significato... non facciamo brutti riciclaggi di variabili, pur di rispermiare 4 byte!

Già con queste 3 regole, la musica comincia a cambiare. Il fondamento di ciò sta nel fatto che programmare è soprattutto un lavoro e farlo bene aumenta la produttività.

Scusa lefermops per questo post che alla fine sembra una lezione di buona programmazione, ma non era rivolto a te personalmente, credo che possa risultare utile a tanti lettori... Vedo miei colleghi che malgrado prossimi alla laurea programmano molto ma molto male, questo è grave... programmare è anche una responsabilità. Il software è pervasivo: c'è la possibilità che un giorno se lo ritrovi in mano qualcuno e se non è fatto bene può produrre danni. Era una affermazione seria malgrado alcuni leggendo si saranno fatti un sorriso: se io scrivo un algoritmo semmai un algoritmo genetico e poi qualcuno lo usa in medicina e semmai qualcun'altro muore x un bug di chi è la colpa? O di chi è la colpa quando due treni si scontrano perchè c'è un bug nel software? Intanto la gente muore...

[lefermops]

grazie della lezione!!^^
io ho ancora il "brutto vizio" dell'assembler....
una riga ->una istruzione..... e sviluppo il codice in verticale!!!
invece vedo che tu tendi all'orrizzontale.... proverò a "girare" il codice...^^
appena ho un attimo per tirare il fiato posto il main.....
(qui stamane, si sono alzati tutti dalla parte sbagliata del letto!!??^^)

[Ikon O'Cluster]

No no niente lezione, sembra ma non lo vuole essere... diciamo qualche consiglio...

[fero86]

scusate l'OT...

Originariamente inviato da Ikon O'Cluster

Non vorrei entrare nel filosofico, primo perchè non è il topic e secondo perchè sono ingegnere e come tale disprezzo la filosofia,

io invece non sono un ingegnere ma ugualmente AMO chi scrive una cosa simile!

[Ikon O'Cluster]

Originariamente inviato da fero86

ma ugualmente AMO

Spero che tu sia donna!

[fero86]

Originariamente inviato da Ikon O'Cluster

Spero che tu sia donna!

no, ma sporadicamente per certe perle di saggezza posso diventare omosessuale
sporadicamente eh, non facciamoci l'abitudine.