Salto multiplo

[TardoFreak]

Domani verificherò

[fairyvilje]

Lo switch salta direttamente alla unica condizione senza controllare tutte le condizioni.

Perdonami ma cosa usa, arte divinatoria?
Ci sarà un momento nel quale le condizioni andranno verificate. Salvo usare tecniche "sporche" come codice automodificante non mi vengono in mente altre possibilità.

Allego i due listati di esempio

Codice: Seleziona tutto

int fn(int i);
int fn(int i){return i;}

int main(){
   int a,c;
   a=100;
   switch(a){
      case 0:
      c=1;
      break;
      
      case 1:
      c=2;
      break;
      
      case 2:
      c=4;
      break;
      
      case 3:
      c=8;
      break;
      
      default:
      c=0;
      
   }
   fn(c);
   return 0;   
}

Codice: Seleziona tutto

int fn(int i);
int fn(int i){return i;}

int main(){
int a,c;
a=100;
if(a==0){c=1;}
else if(a==1){c=2;}
else if(a==2){c=4;}
else if(a==3){c=8;}
else c=0;
fn(c);
return 0;   
}


E i rispettivi codici ottenuti con

Codice: Seleziona tutto

gcc -S file.cpp

.

Codice: Seleziona tutto

   .file   "main.cpp"
   .text
   .globl   _Z2fni
   .type   _Z2fni, @function
_Z2fni:
.LFB0:
   .cfi_startproc
   pushq   %rbp
   .cfi_def_cfa_offset 16
   .cfi_offset 6, -16
   movq   %rsp, %rbp
   .cfi_def_cfa_register 6
   movl   %edi, -4(%rbp)
   movl   -4(%rbp), %eax
   popq   %rbp
   .cfi_def_cfa 7, 8
   ret
   .cfi_endproc
.LFE0:
   .size   _Z2fni, .-_Z2fni
   .globl   main
   .type   main, @function
main:
.LFB1:
   .cfi_startproc
   pushq   %rbp
   .cfi_def_cfa_offset 16
   .cfi_offset 6, -16
   movq   %rsp, %rbp
   .cfi_def_cfa_register 6
   subq   $16, %rsp
   movl   $100, -4(%rbp)
   movl   -4(%rbp), %eax
   cmpl   $1, %eax
   je   .L5
   cmpl   $1, %eax
   jg   .L6
   testl   %eax, %eax
   je   .L7
   jmp   .L4
.L6:
   cmpl   $2, %eax
   je   .L8
   cmpl   $3, %eax
   je   .L9
   jmp   .L4
.L7:
   movl   $1, -8(%rbp)
   jmp   .L10
.L5:
   movl   $2, -8(%rbp)
   jmp   .L10
.L8:
   movl   $4, -8(%rbp)
   jmp   .L10
.L9:
   movl   $8, -8(%rbp)
   jmp   .L10
.L4:
   movl   $0, -8(%rbp)
.L10:
   movl   -8(%rbp), %eax
   movl   %eax, %edi
   call   _Z2fni
   movl   $0, %eax
   leave
   .cfi_def_cfa 7, 8
   ret
   .cfi_endproc
.LFE1:
   .size   main, .-main
   .ident   "GCC: (Ubuntu 4.9.2-10ubuntu13) 4.9.2"
   .section   .note.GNU-stack,"",@progbits

Codice: Seleziona tutto

      .file   "main2.cpp"
   .text
   .globl   _Z2fni
   .type   _Z2fni, @function
_Z2fni:
.LFB0:
   .cfi_startproc
   pushq   %rbp
   .cfi_def_cfa_offset 16
   .cfi_offset 6, -16
   movq   %rsp, %rbp
   .cfi_def_cfa_register 6
   movl   %edi, -4(%rbp)
   movl   -4(%rbp), %eax
   popq   %rbp
   .cfi_def_cfa 7, 8
   ret
   .cfi_endproc
.LFE0:
   .size   _Z2fni, .-_Z2fni
   .globl   main
   .type   main, @function
main:
.LFB1:
   .cfi_startproc
   pushq   %rbp
   .cfi_def_cfa_offset 16
   .cfi_offset 6, -16
   movq   %rsp, %rbp
   .cfi_def_cfa_register 6
   subq   $16, %rsp
   movl   $100, -4(%rbp)
   cmpl   $0, -4(%rbp)
   jne   .L4
   movl   $1, -8(%rbp)
   jmp   .L5
.L4:
   cmpl   $1, -4(%rbp)
   jne   .L6
   movl   $2, -8(%rbp)
   jmp   .L5
.L6:
   cmpl   $2, -4(%rbp)
   jne   .L7
   movl   $4, -8(%rbp)
   jmp   .L5
.L7:
   cmpl   $3, -4(%rbp)
   jne   .L8
   movl   $8, -8(%rbp)
   jmp   .L5
.L8:
   movl   $0, -8(%rbp)
.L5:
   movl   -8(%rbp), %eax
   movl   %eax, %edi
   call   _Z2fni
   movl   $0, %eax
   leave
   .cfi_def_cfa 7, 8
   ret
   .cfi_endproc
.LFE1:
   .size   main, .-main
   .ident   "GCC: (Ubuntu 4.9.2-10ubuntu13) 4.9.2"
   .section   .note.GNU-stack,"",@progbits

[DirtyDeeds]

GOTO
Orrore, abominio, maledizione!

Un linguaggio di programmazione è come il maiale, non si butta via niente!

Ci sono casi in cui il goto va evitato, altri in cui va bene. In un caso come questo potrebbe velocizzare la selezione rispetto alle altre soluzioni, e se la velocità di esecuzione è importante lo terrei in considerazione. Il problema maggiore di questa soluzione è che non è portabile.

Il povero Dijkstra urla vendetta!

Be' la posizione di Dijkstra è stata criticata da molti. Qui c'è un documento che mi sembra interessante a riguardo (non l'ho letto tutto).

Amico mio, da te proprio non me lo sarei mai aspettato.

Da me bisogna aspettarsi di tutto

[EcoTan]

perché lo hai fatto...

Intanto chiarisco questo, poi cercherò di capire il metodo dei puntatori perché a orecchio mi pare che risolva.
Desidero rifare in bella copia un robottino che usa 2 accelerometri e 1 giroscopio analogici, e poiché non si trovano più i giroscopi analogici mi sono dovuto studiacchiare il protocollo I2C. Per lasciare alquanto inalterato il precedente SW, che è monolitico, desidero che i valori letti dai sensori vengano sempre aggiornati automaticamente in tempo reale, come meglio si può, in rispettive variabili nella memoria common, poi il main girerà indipendentemente e li userà quando crede; in pratica si occuperà di regolazione di attuatori perseguendo determinati scopi fissi o variabili.
L'aggiornamento dei valori, se deve essere automatico e non intralciare o condizionare il main, penso che debba avvenire a livello ISR.
La MCU è dsPic33 e il suo modulo I2C prevede diverse circostanze in cui fa interrupt, praticamente per una lettura da master abbiamo una catena di ben 10 interrupt, fra comandi, address, sub-address, dati e riscontri, se poi vogliamo leggere 2 accelerometri coi 2 giroscopi abbiamo una catena di 40 interrupt dalla stessa sorgente in condizioni diverse con compiti diversi, ma oltre a leggere dobbiamo anche scrivere qualcosa per configurare 'sti dannatissimi sensori altrimenti non fungono, e la stessa ISR deve saper fare anche quello una volta all'inizio, per poi leggere e rileggere a ripetizione. Potrebbe darsi che ho trascurato qualcosa di grosso ma di sicuro funziona. Può darsi però che l'aggiornamento automatico risulterà troppo lento per le esigenze finali, coi vecchi sensori analogici questo problema non l'ho avuto e debbo completare il lavoro per poter sapere questo.
Adesso cercherò di capire come usare i puntatori, o le altre soluzioni proposte per cui ringrazio infinitamente ma penso che chiederò ancora.

P.S. simo85 ti andrebbe di farmi un esempio commentato?
Se scrivo "if" mi cambia colore ma se scrivo "write" non cambia e poi ovviamente mi dà errore di compilazione e ciò mi blocca, questo è il mio livello..

[simo85]

Se scrivo "if" mi cambia colore ma se scrivo "write" non cambia e poi ovviamente mi dà errore di compilazione e ciò mi blocca..

Il fatto che cambi colore a seconda del flusso di controllo usato non ha nulla a che vedere con il compilatore.
È una proprietà dell' editore di testi di riconoscere le parole chiave del linguaggio di programmazione usato.

La funzione write:

Codice: Seleziona tutto

#include <unistd.h>

ssize_t write(int fd, const void *buf, size_t count);

È una chiamata di sistema in C in Linux, ma suppongo anche su altri sistemi Unix-like. Non me li conosco tutti.

Tornando al caso del microcontrollore, ti scrivo un piccolo esempio, poi devo studiare.

Tu hai scritto che hai una variabile (chiamiamola n) che può assumere valori da 0 a 50, e che quando entri nella Interrupt Service Routine (ISR), in funzione del valore di n chiami una delle 51 funzioni (da 0 a 50 sono 51).

Supponendo che in ciascuna delle tue 51 funzioni cambi solo il valore del PORTC, in questo caso il tuo codide dovrebbe essere qualcosa del genere:

Codice: Seleziona tutto

/* index for function reference */
unsigned char n;

void func0(void)
{
  /* write 0x00 on PORTC */
  PORTC = 0x00;
}

void func1(void)
{
  /* write 0x01 on PORTC */
  PORTC = 0x01;
}

void func2(void)
{
  /* write 0x02 on PORTC */
  PORTC = 0x02;
}

/* ... func3 to func49 ... */

void func50(void)
{
  PORTC = 0x32;
}

/* declare array of function pointers */
void (*functions[])() = {func0, func1, func2, ... , func50};

void main(void)
{
  /* ... */
  while(1)
  {
    /* infinite loop */
  } 
}

void interrupt ISR(void)
{ 
  if(condition)
  {
    /* call function depending on n */
    functions[n]();
  }
}

Come vedi la chiamata ad una delle 51 funzioni si riduce ad una sola istruzione.
Per delle prove potresti anche usare un approccio come questo: restituisci su una porta, in output, il valore binario di n.

[Candy]

...

Ho capito poco o nulla, ma mi sembra di intravedere una concezione e gestione di eventi interrupt parecchio sbagliata.

[TardoFreak]

Un linguaggio di programmazione è come il maiale, non si butta via niente!
Ci sono casi in cui il goto va evitato, altri in cui va bene.

Oibò, io ho visto ragazzi non passare un esame per un return messo non alla fine di una funzione!
Nessuno però ha provato neanche lontanamente ad infilarci un break.
Se qualcuno avesse utilizzato un goto sarebbe stato crocefisso ed il suo cadavere sarebbe ancora esposto in pubblica aula.

[simo85]

io ho visto ragazzi non passare un esame per un return messo non alla fine di una funzione!

Ma dove l'ha messo il return ? All'inizio ?

[EcoTan]

ti scrivo un piccolo esempio

OK, ti ringrazio molto. Debbo dire che anche il tuo post 4 era abbastanza chiaro ed è anzi prezioso, solo ho visto una funzione write che non ho mai usato e non mi sono reso conto subito che era lì solo perché faceva parte dell'esempio ma non era nulla di essenziale per lo scopo in questione.
Non so se all'interno della ISR posso usare le chiamate a funzione.
Se abbandonassi I2C e passassi a SPI avrei meno interrupt?

[EcoTan]

Non so se all'interno della ISR posso usare le chiamate a funzione

OOPS.. il tuo esempio è fatto appunto con una ISR quindi deduco che si può fare.