Progettazione software per cubo led 4x4x4

[Galaxi93]

Allora:

In quanto alla random pensavo che forse si potrebbe fare in modo che ritorni un numero casuale tra 0 e 63 che rappresenta il led da accendere/spegnere, quindi trasformare quel numero nelle coordinate x, y e z. In sostanza una sola chiamata e non tre chiamata per avere numeri tra 0 e 3.

Anche io ci avevo pensato e ci stavo lavorando.

citazione cancellata

Sto testando su 20 led, perché i led definitivi non mi sono ancora arrivati, appena mi arrivano assemblo il tutto.

[Galaxi93]

Ho elaborato una formula, come dire, strana per ottenere le coordinate da un numero compreso tra 0 e 63.
Molto probabilmente c'è una via più semplice per fare ciò, ma io ho trovato questa.
Ora metto solo i calcoli:

Codice: Seleziona tutto

z=random_64/16;
xy=random_16 % 16;
y=xy/4;
x=xy % 4;

Io l'ho provato (con exel) e il calcolo mi viene, ditemi voi se è giusto e se può andar bene per il programma.

[c1b8]

Correggerei solamente questa

Codice: Seleziona tutto

xy=random_16 % 16;

in questa

Codice: Seleziona tutto

xy=random_64 % 16;

[Galaxi93]

In realtà è così come hai detto tu, ho solo sbagliato a scriverla qua. Ora la provo.

[Galaxi93]

Provato! Notevole differenza! Ora il lampeggio è quasi scomparso (dico quasi perché c'è ancora qualcosa).
Ora direi che il giochino è finito. Ora si può passare alla fase di ottimizzazione. Io intanto vedo di riadattare i giochi di luce che c'erano all'inizio.

[Galaxi93]

Per ottimizzare il programma e renderlo più efficiente, cosa potrei fare? Si parlava di utilizzare i #define e di togliere tutti gli if, switch da acc_led. Come posso fare?

[Galaxi93]

Oggi ho provato a ottimizzare il programma, ma per la funzione acc_led, non so che fare...
Mentre ho trovato una via differente per memorizzare lo stato dei led. Non so se funziona praticamente, so solo che teoricamente dovrebbe essere giusto. Ora, io non so se è più performante questa rispetto l'altra.
Eccola qui:

Codice: Seleziona tutto

//Date le coordinate x, y e z, restituisce index e il bit in forma decimale.
char get_index_bit(char x, char y, char z)
     {
     char n, index, bit;
     n=z*16+y*4+x;         //Trasforma le coordinate in un numero compreso tra
                           //0 e 63.
     index=n/8;            //Divide il numero per 8 ottenendo l'index.
     bit=2^(n%8); //Qua non so se è giusto: in pratica vorrei elevare il due, per
                 //il risultato di quello che c'è nella parentesi. (il compilatore me lo accetta).
     return(index, bit);        //ritorna i due valori.
     }

//Dale le coodinate, cambia lo stato dei led.
void cambia_Stato(char x, char y, char z, char stato)
     {
     char index, bit;
     get_index_bit(x,y,z);
     if (stato)                         //se deve accendere (stato=1)
        {
        map[index]=map[index]+ bit;     //aggiunde all'idex corrispondente,
        }                               //il bit.
     else                               //altrimenti,
         {
         map[index]=map[index]- bit;    //lo sottrae.
         }
     }
//ottiene lo stato dei led, date le coordinate.
char get_stato(char x, char y, char z)
     {
     char index, bit;
     get_index_bit(x,y,z);
     return (map[index] & bit);
     }

Magari è una grande cavolata, ma volevo sapere un vostro parere.
Rispetto al codice di Posta10100 c'è qualche calcolo in più e qualche if di meno. Come spazio occupato, il mio ne occupa meno, ma non è questo che a me interessa.

[phylum]

^ almeno in C classico nn significa elevato a bensi' XOR per quello si usa Pow(base,esponente)
quindi: bit=2^(n%8); con p.es n=16 ---> bit=2

comunque personalmente trovo piu' semplice incollare tutto il codice da controllare ad ogni release in un pastebin e poi usare il diff - nel tuo caso potresti fare Galaxy93.pastebin.com
almeno le differenze sono evidenziate in modo "certo", si evita cioe' che "dimentichi" di dirci altro
nota sulle prestazioni: come avrai notato ti e' stato suggerito p.es di usare << invece di * perche' il pic16 non conosce la moltiplicazione (il 18 si...) (e mikroC "inventa" una soluzione ogni volta)

[Galaxi93]

Lo farò, questa volta non mi interessava postare tutto il codice per intero, dato che ho modificato solo queste funzioni.

nota sulle prestazioni: come avrai notato ti e' stato suggerito p.es di usato << invece di * perche' il pic16 non conosce la moltiplicazione (il 18 si...) (e mikroC "inventa" una soluzione ogni volta)

Dove mi è stato suggerito? Non ho capito.

[phylum]

quando ti e' stato detto potresti fare *2 ma e' piu' lento ma era una noticina cosi per dire nn ti voglio complicare la vita facendoti riscrivere tutte le moltiplicazioni per risparmiare 10ns alla fine

nota:confermo anche in mikroC ^ è XOR