Go Down

Topic: sketch spesso errati... (Read 2 times) previous topic - next topic

uwefed


questa è una libreria che nella fattispecie muove un servo... gioca con registri ed interrupt per settare timer eccetera...non è proprio una banalità ed è molto più facile sbagliarla che farla giusta:

C'é oltre anche un po di codice assembler in mezzo che peggiora da difficoltá di capire/scrivere un codice del genere.
Code: [Select]
if (us>1) 
      { 
      us <<= 2; // Translate us to the 4 cyles loop (1/4 us) 
      __asm__ __volatile__ (  // 4 cycles loop = 1/4 us  (taken from delayMicroSeconds function) 
        "1: sbiw %0,1" "\n\t"            // 2 cycles 
        "brne 1b" : "=w" (us) : "0" (us) // 2 cycles 
        ); 
      } 

Cioa Uwe

gingardu



e poi la strada più giusta   e quella di farsi da soli lo sketch su "misura"

gingardu hai letto il Sketch? Ti sfido a scriverne uno simile.
Ciao Uwe


tutto dipende......
da cosa serve lo sketch  
certo che se alla fine muove dei servo per l'irrigazione temporizzata del prato   non vedo perche non puoi
farti tu il programmino,

poi raramente uno sketch è bello  che pronto e giusto per quello che vuoi fare, a meno che non si tratta di un progetto tutto completo e ti va bene cosi,

"alla lunga"  dopo che si ha un po di pratica , e meglio scriversi le cose di sana pianta.
le cose funzionanti  fatte con la propria testa   sono sempre capite e modificabili/migliorabili   all'istante

la penso così  poi ....  magari mi sbaglio non so.
Le cose si possono considerare facili in due casi: quando le si conosce bene o quando non le si conosce affatto...

qsecofr



"alla lunga"  dopo che si ha un po di pratica , e meglio scriversi le cose di sana pianta.
le cose funzionanti  fatte con la propria testa   sono sempre capite e modificabili/migliorabili   all'istante

la penso così  poi ....  magari mi sbaglio non so.


no non è che sbagli: è normale che un programmatore capisce meglio quello che fa lui che quello che fanno gli altri ma non è un approccio "ingegneristico" al software... è un po' come stuccare un muro o costruire un condominio: se devi stuccare il muro prendi lo stucco e la spatola e fai, se devi fare un palazzo devi fare un progetto ed usare i mattoni, malte premiscelate e ferro prodotti dagli altri e tu "architetto" devi "solo" conoscere cosa puoi fare con questi componenti.... e a tal fine un'altra cosa che spesso il programmatore fa (sbagliando) è quello di spingersi in codici magari molto ottimizzati ma poco chiari invece il ciclo del software è molto lungo e non si ferma alla prima stesura e quindi è prioritario che il programmatore si "abbassi" a scrivere commenti e precisare cosa fa di modo che lui stesso e gli altri possano metterci mano o correggere senza impazzire...
esempio (citando il codice immesso da uwe  :smiley-eek:)
us <<= 2; ... bel metodo per moltiplicare per 4 in modo molto rapido... ottimo metodo per non far capire a nessuno quello che stai scrivendo... (infatti l'autore consapevole ha accennato un commento).... se stai facendo un driver o una ISR sei bravo, se lo commenti sei ancora più bravo, se stai scrivendo un programma di contabilità (o accendere un led ogni morte di papa) pensi tu di essere bravo ma in realtà stai sbagliando tutto.
IN MIA UMILE OPINIONE SEMPRE COMUNQUE E'...

MauroTec




"alla lunga"  dopo che si ha un po di pratica , e meglio scriversi le cose di sana pianta.
le cose funzionanti  fatte con la propria testa   sono sempre capite e modificabili/migliorabili   all'istante

la penso così  poi ....  magari mi sbaglio non so.


no non è che sbagli: è normale che un programmatore capisce meglio quello che fa lui che quello che fanno gli altri ma non è un approccio "ingegneristico" al software... è un po' come stuccare un muro o costruire un condominio: se devi stuccare il muro prendi lo stucco e la spatola e fai, se devi fare un palazzo devi fare un progetto ed usare i mattoni, malte premiscelate e ferro prodotti dagli altri e tu "architetto" devi "solo" conoscere cosa puoi fare con questi componenti.... e a tal fine un'altra cosa che spesso il programmatore fa (sbagliando) è quello di spingersi in codici magari molto ottimizzati ma poco chiari invece il ciclo del software è molto lungo e non si ferma alla prima stesura e quindi è prioritario che il programmatore si "abbassi" a scrivere commenti e precisare cosa fa di modo che lui stesso e gli altri possano metterci mano o correggere senza impazzire...
esempio (citando il codice immesso da uwe  :smiley-eek:)
us <<= 2; ... bel metodo per moltiplicare per 4 in modo molto rapido... ottimo metodo per non far capire a nessuno quello che stai scrivendo... (infatti l'autore consapevole ha accennato un commento).... se stai facendo un driver o una ISR sei bravo, se lo commenti sei ancora più bravo, se stai scrivendo un programma di contabilità (o accendere un led ogni morte di papa) pensi tu di essere bravo ma in realtà stai sbagliando tutto.
IN MIA UMILE OPINIONE SEMPRE COMUNQUE E'...



In buona sostanza condivido, tranne per il giudizio; bravo, più bravo ecc. Non ho capito l'ultima parte riguardo al programma di contabilità, mi sembra di capire che chi scrive un programma di contabilità sia meno "bravo" di chi scrive una ISR. Ovviamente non è così, perchè sono lavori complessi entrambe e richiedono competenze diverse.

Riguardo ai commenti sul codice, posso dire evitando di usare la parola "bravo" che se è intesa in modo corretto ci può stare.
Se sei in grado di scrivere codice e contemporaneamente commentarlo mantenendo in sincro il codice con la documentazione hai sicuramente una capacità in più, capacità che si può acquisire con il tempo. Mi prendo come esempio da non seguire: io non ho la capacità di scrivere codice e commentarlo, forse mi lascio prendere dal piacere di scrivere codice di getto, e questa la mia natura.

Purtroppo poi ci sbatti il muso, e con il tempo visioni tanto codice altrui e si viene a creare la situazione assurda in cui risulta più comprensibile il codice altrui che quello scritto di proprio pugno, se questo accade bisogna impegnarsi a scrivere imitando gli altri fino ad acquisire le capacità mancanti.

Così io penso che ci vuole tempo per superare le varie fasi, però chi ha studiato progettazione software ha acquisito anche delle tecniche che lo aiutano ad essere produttivo a 360 gradi, per cui è cosciente che l'analisi va fatta in gruppo, e che dopo una settimana ci deve essere del codice su cui lavorare, su cui effetuare test, questa coscienza fa di lui un programmatore dotato degli strumenti del mestiere, strumenti che un programmatore come me non ha, ma con il tempo e lo studio può rimediare.

Tutta sta tiritera per dire che scrivere codice commentato è buona cosa ed è utile in futuro, ma sbatterci il muso prima possibile è una strada percorribile che da i suoi frutti, quindi scrivete codice su codice non importa se commentato, prima possibile ci sbatterete il muso accorgendovi che dovete trovare una soluzione.

La cosa che può accadere e che con il tempo avete acquisito nuove capacità legate alla programmazione e rivedendo il vostro codice vecchio di 6 mesi noterete mille cose da modifcare perchè non efficienti, perchè errate e questa cosa la noterete sempre magari in misura minore, ma accadrà sempre fino alla completa maturazione che avverà nei dintorni dell'ottantesimo compleanno.  XD

Ciao e buone feste.
AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

leo72

Concordo in pieno con Mauro.
Sempre commentare il codice.

Non siamo nell'epoca dei computer anni '80 dove la RAM era poca ed i commenti in BASIC erano salvati carattere per carattere insieme al listato per cui ogni commento erano byte tolti al programma.  ;)
Anche a me capitava all'inizio di non commentare, poi ho iniziato a mettere qualche commentino, ora sono arrivato alla condizione in cui nei passaggi critici metto anche un commento per riga (vedi leOS o swRTC) altrimenti se riprendo in mano il codice dopo qualche mese non ci capisco più nulla  :smiley-yell:

Go Up