sketch spesso errati...

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

ad ingegneria del software 1 e 2 mi hanno insegnato l'esatto contrario: se si può bisogna sfruttare il già fatto... tutto sommato sbattendosene del come è stato fatto... che dopo la curiosità ti porti al capire come è stato fatto quello è per la ns sete di conoscenza ma non per il fine del progetto.

qsecofr:
ad ingegneria del software 1 e 2 mi hanno insegnato l'esatto contrario: se si può bisogna sfruttare il già fatto... tutto sommato sbattendosene del come è stato fatto... che dopo la curiosità ti porti al capire come è stato fatto quello è per la ns sete di conoscenza ma non per il fine del progetto.

Guarda che il "make or buy" non si applica in questi casi, un conto è comprare un qualcosa che funziona (es. libreria) che richiederebbe mesi di sviluppo perché più conveniente, un conto invece è scaricare dal web a caso del codice che non va che si potrebbe scrivere in poche ore.. :slight_smile:

flz47655:
Guarda che il "make or buy" non si applica in questi casi, un conto è comprare un qualcosa che funziona (es. libreria) che richiederebbe mesi di sviluppo perché più conveniente, un conto invece è scaricare dal web a caso del codice che non va che si potrebbe scrivere in poche ore.. :slight_smile:

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: se c'è già, funziona e fa quello che ci serve non vedo perchè non usarla: qui manca un file alla fine. A me sinceramente gli insegnamenti di ingegneria davano fastidio e li per li ho trovati a volte scontati a volte banali a volte noiosi...del resto da studente... però poi quando l'ho fatto per lavoro ho capito che alcune cose non erano proprio così campate in aria e che alle volte è meglio ad esempio fare un codice chiaro che possa essere corretto piuttosto che risparmiare 1 byte di una variabile e tornando allo sfruttamento del codice fatto da altri in realtà è una prassi che facciamo tutti chi più integralmente chi meno ed obiettivamente più ambizioso è il progetto più devi salire sulle spalle dei giganti che ti hanno preceduto.
forse però sono andato un po' troppo ot con questo argomento...mi scuso: solo un'opinione

@palmirorov:

leo72:

  1. lo sketch usa una o più librerie che non ci sono sul sistema. Soluzione: scaricarle

Non basta prendere uno sketch, ricopiarlo e sperare che funzioni.
Devi intanto anche capirne un po' di programmazione e linguaggio C. Se in cima allo sketch vedi degli #include, questi sono "ordini" dati al compilatore di includere altre porzioni di codice che si chiamano librerie. Una libreria è una specie di "estensione" del tuo programma. E' un codice che mette a disposizione del tuo sketch dei nuovi comandi e delle nuove funzioni. Spesso non sono inclusi con l'IDE perché scritti da terzi. Quindi devi procurartele te, altrimenti il tuo sketch non potrà mai essere compilato.

qsecofr:
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.

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

uwefed:

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.

gingardu:
"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 :astonished:)
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'...

qsecofr:

gingardu:
"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 :astonished:)
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.

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. :wink:
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 :stuck_out_tongue_closed_eyes:

MauroTec:
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.

no vabbe il bravo più bravo era inteso che hai scritto un codice "più rapido ed efficiente della moltiplicazione semplice" quindi diremo "bravo" per aver "ottimizzato il codice" con una soluzione "non scontata".... che diventa "più bravo" quando commenti quello che hai fatto perchè aggiungi all'ottimizzazione del tuo software la "leggibilità e mantenibilità"
ed il discorso del programma di contabilità era per indicare un programma molto grande ma che di solito non contiene necessità di ottimizzazione spinta del codice... in altre parole se devi fare una IRS devi andare veloce e moltiplicare per 4 è più lento dello shift; se invece devi moltiplicare per 4 un listino prezzi di 1000 record per fare un report è meglio che usi la moltiplicazione e lo shift te lo tieni nel cassetto perchè se no nessuno capisce che cacchio hai fatto ne il perchè.... e quindi nonostante il gesto tecnico non sei stato utile... un po' come essere un bravo attaccante che vuole segnare solo in rovesciata ma che non passa mai la palla

grazie ragazzi, molto "agguerriti sul tema", ma la domanda rimane......come imparare in fretta?
a parte i testi "commerciali" esiste di recuperabile qualcosa di un poco serio e attendibile...dopo due settimane di ricerca sono un poco deluso dalla qualità delle info in genere.....alcune sono mascheratamente commerciali altre sono solo banalità.
in due settimane da solo non sono riuscito ad intravedere la via per crescere, questa è la domanda di fondo come e dove ??

please evitate di consigliarmi i testi che si trovano facilmente in giro...ne ho già uno basic (testo "primi passi con arduino"di Simone Maiocchi) . l'ho letto e come prima lettura mi è piaciuta ma adesso che leggo ????
o forse scoprirò che l'elettronica applicata da solo non posso impararla XD XD XD XD

qsecofr:

MauroTec:
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.

no vabbe il bravo più bravo era inteso che hai scritto un codice "più rapido ed efficiente della moltiplicazione semplice" quindi diremo "bravo" per aver "ottimizzato il codice" con una soluzione "non scontata".... che diventa "più bravo" quando commenti quello che hai fatto perchè aggiungi all'ottimizzazione del tuo software la "leggibilità e mantenibilità"
ed il discorso del programma di contabilità era per indicare un programma molto grande ma che di solito non contiene necessità di ottimizzazione spinta del codice... in altre parole se devi fare una IRS devi andare veloce e moltiplicare per 4 è più lento dello shift; se invece devi moltiplicare per 4 un listino prezzi di 1000 record per fare un report è meglio che usi la moltiplicazione e lo shift te lo tieni nel cassetto perchè se no nessuno capisce che cacchio hai fatto ne il perchè.... e quindi nonostante il gesto tecnico non sei stato utile... un po' come essere un bravo attaccante che vuole segnare solo in rovesciata ma che non passa mai la palla

Ero quasi sicuro che il significato di bravo e più bravo che volevi lasciare intendere era quello che io considero corretto, purtroppo non siamo tutti coscienti e magari può passare il messagio che io che ho scritto una ISR sono da considerare più bravo di chi ha scritto un qualunque programma di contabilità, programma che io allo stato attuale non saprei neanche progettare, dico di più questo tipo di programmi va sviluppato in gruppo perchè è difficile trovare un solo individuo con tutte le competenze necessarie.

In gioventù ho scritto un programma di gestione veterinaria che prevedeva anche la stampa del registro bollato, di cui non sapevo nulla, è ho dovuto acquisire le dovute competenze, ora non ricordo con precisione ma c'è una procedura precisa da seguire nel caso si blocchi la stampante, si inceppi la carta ecc, mi sembra di ricordare che la pagina stampata a metà deve essere annullata e si deve riprendere la stampa dalla pagina di interruzione.

Non dimentichiamo che in ambito obbistico è richiesto uno sforzo maggiore al singolo individuo, infatti esso deve, analizzare, acquisire le competenze mancanti e poi sviluppare il codice. Mancano ancora la fase di test e debug che anche in questo caso è portata avanti da un singolo individuo, però se il codice viene rilasciato ed è interessante si può contare su un discreto numero di tester e debugger umani.

gingardu:

uwefed:

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.

Da anni c'è una ricerca incessante al fine di ottenere degli strumenti che permettano ad un programmatore di comprendere ed usare codice scritto da altri programmatori, uno degli strumenti nati con quell'intento è proprio il linguaggio C++, seguito da tutti gli altri linguaggi orientati agli oggetti, java, c#, D ecc. Già, c'è anche il D oltre al C, ma ancora non è maturo. Il problema principale è legato al codice non flessibile, guarda caso più il codice è flessibile più si riduce la performace potenziale, cioè ancora adesso un codice rigido usa meno ram ed è più rapido in esecuzione di un codice flessibile e cioè facilmente adattabile.

Il compilatore gioca un ruolo fondamentale, perchè permette allo sviluppatore di scrivere codice flessibile senza preoccuparsi delle prestazioni pure, ma questo compilatore non è ancora nato, anche se gcc fa tante cose mirabolanti.

E allora come ci si deve comportare?

Non pensare alle prestazioni, c'è sempre tempo per rimediare.
Scrivi codice auto-documentante: 128 è un mumero, buffer_zise è un parametro auto-documentante, 128 no, e rx_buffer_size documenta in dettaglio il codice.
Buona la prima, accade nell'arte: es gli scultori non hanno una seconda possibilità, perchè non deve accadere anche in programmazione?
E infatti, se il codice lavora correttamente consideralo buono e vai avanti (buono non vuol dire non migliorabile).
Non ti fissare. Più facile a dirsi che a farsi.
Testa piccole porzioni di codice: se il test è positivo il prossimo compito deve essere quello di scrivere la documatazione, se rimandi confondi codice testato con codice da testare.
E per ultimo, cerca anche di divertirti mentre sviluppi.

PS: sapere come comportarsi non vuole dire essere capaci di comportarsi come si sa, ma quanto meno ci si può lavorare su.

Ciao.

palmirorov:
grazie ragazzi, molto "agguerriti sul tema", ma la domanda rimane......come imparare in fretta?

scusa tu invece: da un se vogliamo banale problema di compilazione ci siamo ritrovati (e mi assumo una buona fetta della colpa) a parlare di ingegneria del software. In ogni caso non so se esistono vie rapide per imparare... alla fine c'è tanta tanta pratica da fare... è imprescindibile... ma io quello che non ho capito è "cosa" ti interessa e dove eventualmente ti senti lacunoso... in altri termini se ti mancano dei rudimenti di c++ oppure se ti mancano dei rudimenti di programmazione generale, se arduino, se elettronica digitale, se elettronica "analogica". Per esempio dal listato precedente che aveva una libreria mancante io intuisco (correggi se sbaglio) che ti manca un po' di pratica con il c++: arduino non è il miglior strumento per imparare il c... meglio a tal fine un pc ed un modesto compilatore e mettersi a fare "esercizi".

....vero vero non ho verificato che le librerie interesate siano caricate, davo per scontato che nel programma pc già fossero caricate quasi tutte.....beh allora bisogna che mi dia da fare....

uwe la luce mi ha abbagliato !!!! sulla via di damasco !!! thanks

MauroTec:
In gioventù ho scritto un programma di gestione veterinaria che prevedeva anche la stampa del registro bollato, di cui non sapevo nulla, è ho dovuto acquisire le dovute competenze, ora non ricordo con precisione ma c'è una procedura precisa da seguire nel caso si blocchi la stampante, si inceppi la carta ecc, mi sembra di ricordare che la pagina stampata a metà deve essere annullata e si deve riprendere la stampa dalla pagina di interruzione.

per fortuna molti "formalismi" sono stati parzialmente rimossi dalle contabilità. Io invece dopo gli studi facevo proprio software per applicazioni contabili e vedevo diremo con una certa "invidia" quelli che scrivevano su microcontrollori o su tematiche diverse perchè mi parevano temi più stimolanti... poi lavoro è lavoro e sicuramente anche chi scrive driver per i sensori del cern avrà i suoi momenti di sbattimento ma a me pareva che fare stampe fosse la cosa più pallosa del mondo... in particolare quando mi arrivavano tracciati e moduli fiscali tipo 730-740... una noia mortale di somme ridondanti... vabbè scusa le chiacchere...
Ottimi i consigli che hai dato sulla scrittura del codice: spesso lo spirito ribelle si oppone ma sarebbero da applicare alla lettera ed effettivamente nei software che sopra citavo di contabilità erano un must anche perchè si lavorava in team sotto degli analisti

...io adoro i temi di estetica ed è stato bello leggere queste pagine di commenti...in fin dei conti devo conoscervi e quale modo migliore se non dissertare sull'acqua calda :smiley: :smiley:
allora faccio un passo indietro e mi oriento ai rudimenti di c++.
il mio prgetto sarebbe un rov, telecomandato con ricevente e tele da 40 mhz, 4 motori,videocamera e altri gingilli.
il progetto in versione filoguidata potrebbe essere già quasi finito (in attesa delle due motor shield).....ma io mi vorrei proiettare ad usare arduino nel vasto mondo del modellismo. è stata la sua flessibilità estrema insieme all'economicità (le stesse funzioni a quasi 50% del costo) rispetto ai prodotti da modellismo a spingermi all'acquisto.

maurotec quale compilatore consiglieresti ?

maurotec quale compilatore consiglieresti ?

Non hai molte alternative, gcc e avr-gcc. Ma alla fine qualunque compilatore C va bene per imparare. Su windows sarai sicuramente tentato da visual C, che molti usano, ma di cui nulla so. Molto dipende anche dai soldi che vuoi spendere, se non ne vuoi spendere c'è l'imbarazzo della scelta. Ambiente di sviluppo eclipse, netbeans, ecc ( cerca IDE C++ sul web ).

Arduino usa il compilatore avr-gcc, che è usato anche AVR Studio di atmel, ma arduino preferisce il subset C++ al C standard, questo grazie al compilatore GCC che compila per C (tutti gli standard e no) e C++ (tutti gli standard e no).

Confermo, e meglio usare il pc per apprendere il C/C++, e poi di tanto in tanto usare l'ide Arduino e seguire gli esempi di codice che si trovano nell'IDE, raggiungibili da menù.

Io penso che al momento non ti serve studiare il C/C++, penso sia più produttivo studiare in superficie così da farti una idea di cosa hai davanti.

Cosa è un microcontroller?
Cosa è un linguaggio?
Cosa è un compilatore?
Cosa è la logica booleana?
Cosa è la corrente elettrica?
Cosa è la tensione?
Cosa è la periferica seriale?
Cosa è I2c?
Cosa è il PWM?
Cosa è ecc.

Ciao.

roger ora si che sono gaio :smiley: :smiley: :smiley:
un bel listone da digerire..........grazie
gli argomenti sono tanti.....e la maggiorparte li conosco più che altro per i suo aspetti pratico applicativi nel mondo modellismo e fai da te....ma qui sono richieste competenze ben più profonde.
quindi sotto con lo studio !
a presto per gli sviluppi e grazie ancora

mauro tec cosa ne pensi di questo compilatore ?

http://www.cs.virginia.edu/~lcc-win32/