Newsgroup: it.hobby.elettronica.digitale
Titolo: veri programmi in C

Salve!
e' da un po che cerco di imparare qualche cosa usando il C (compilatore ccs) 
mi domando ma in rete si trovano veri programmi e non idee e piccole parti 
di programma? secondo me studiando un programma completo e modificandolo, si 
impara veramente a programmare. 

 programma completo e modificandolo, si impara veramente a programmare.
Mmhh filosofia sbagliata. Si impara ***VERAMENTE*** a programmare senza 
neanche mai mettersi alla tastiera. Altrimenti non impari a programmare, ma 
a giocare con un linguaggio, che è un po' diverso :-)

 ha
scritto:

Mah, in quel caso farai programmi che funzionano solo sulla carta, mentre la
gente paga solo per programmi che funzionano in pratica.
Io l'unico linguaggio che ho imparato in quel modo è stato il Fortran, e se
dovessi scriverci qualcosa adesso, a parte gli anni trascorsi, credo che avrei
dei seri problemi a combinare qualcosa.
Viceversa non ho problemi ad usare il Basic, Visual Basic e riesco anche col
VB.NET
, posso programmare uno Z80 o un AVR in assembler senza avere vicino il
manuale perchè conosco tutto il set di istruzioni a memoria, e ho imparato quei
linguaggi 'giocandoci', come diresati tu.
C'è da dire che il C è forse una cosa un pò troppo ostica per impararla
giocando, ma se Enzo vuole partire da qualcosa di funzionante per cercare di
capire come lavora un programma, può essere una strada valida anche quella.
Tanto dovrà comunque studiare la sintassi del linguaggio e seguirà una sua
strada che lo porterà alla fine a sapere usare lo strumento.
Io personalmente imparo più in fretta se vedo il risultato di quello che sto
facendo.
Per esempio adesso sto cercando di capire spulciando tra le decine di proprietà
incasinate di un Qpainter come usarlo, ma debbo vedere subito a video se mi
disegna un cerchio o mi da una sequela di errori. 
--
ciao
  Stefano

Luca ha scritto:

Sono princiaplemnte un programmatore e secondo me il tuo metodo è del 
tutto sbagliato. O per lo meno "vecchio". E' vero quello che dici che se 
uno vuole puo' tranquillamente programmare su carta. Ma così secondo me 
non impari molto e non vedi i risultati e quindi il tutto ti riamane più 
ostico.
Io ho imparato un sacco di linguaggi ( una lista in questa sede sarebbe 
inutile ) e ho sempre imparato con il manuale ( un buon manuale/tutorial 
è sempre necessario ) affianco e facendo mini esempi. Aggiungendo piano 
piano robba e ampliando i set delle mie istruzioni.
io inizio dal
void main ( void ) {
   printf( "hello world\n");
}
per arrivare agli oggetti ( nel caso del c++ ) alla allocazione di 
memoria e tutto il resto.
Non vorrei che questo discroso ti sembri troppo arrogante, ma ti 
assicuro che per me è così. Non riuscirei a imparare "bene" un 
linguaggio solo studiando sul libro e carta.
Secondo me il tuo modo di raggionare è figlio del tempo quando la 
potenza di calcolo erano basse e i pc non erano così diffusi come oggi. 
Prima si doveva fare un programma, magari debuarlo su carta e poi andare 
al calcolatore per non sovracaricarlo di lavoro inutile e togliere tempo 
agli altri. Aveva senso all'epoca ma oggi non credo che questo approccio 
può aver senso.
-- 
Il Razziatore,
"Lo sviluppo di una nazione si misura anche dallo stato della sua rete 
ferroviaria". Camillo Benso Conte di Cavour
"Per tutto quanto non previsto nel presente regolamento il capostazione 
deve usare senno e ponderatezza." Regolamento d'esercizio FS
-----------------------------------------------
MSN   : 
IlRazz...@netscape.net
ICQ   : 67552596
Yhaoo : Razziatore82
-----------------------------------------------
Founder of MediaPlayer Project
http://mpp.iwebland.com

Enzo ha scritto:

Il C forse è il linguaggio più diffuso al mondo. Trovi programmi per 
fare di tutto. Se vuoi puoi anche leggerti i sorgenti di un sistema 
operativo ( 
www.kernel.org
, anche sete lo sconsiglio se non vuoi un gran 
mal di testa ).
Un altro discorso è se vuoi un firmware per mC o comunque per soluzioni 
embaded. Ma secondo me con quelli impari poco.
Ti consiglio prima di imparare il C come linguaggio e poi di programmare 
per PIC ( questo passaggio è immediato, l'inverso non proprio ).
Quello che ti serve è un buon libro di C/C++ ( libri di solo C non so se 
li fanno ) e impararti le strutture basi su un compilatore C normale ( 
tipo il borland C++ che è free, oppure meglio ancora il gcc ) e imparare 
la sintassi magari attraverso degli esempi.


 la sintassi magari attraverso degli esempi.
Tuttora, dopo tutti questi anni, trovo sempre utile il
Kernighan&Ritchie "The C programming language", che si trovava anche
in italiano.
Avevo studiato il C++ sulla seconda edizione del libro di Stroustrup
(quindi, quella pre-standard), ma quando ho poi preso in mano la terza
edizione, l'ho trovata molto più pesante.

 ostico.
Secondo me la programmazione va studiata a parte, mi sembra che Luca 
confonda "programmare" con "conoscere il C" perché spesso lo studio di 
un linguaggio "applicato" porta con sé anche concetti che dal linguaggio 
stesso sono separati.
Secondo me però la programmazione è molto più articolata, mi capita di 
leggere di approcci che spesso mi sorprendono, un esempio è l'approccio 
funzionale che ho scoperto solo recentemente. 
L'approccio "vecchio" cui si fa riferimento ha un sapore di 
programmazione procedurale, di basic sul televisore, di un algoritmo 
attraversato in verticale. Non che sia sbagliato ma non è certo tutto lì.
 
Una volta che i meccanismi dei vari paradigmi di programmazione sono 
noti imparare ad applicarli ad un linguaggio od ad un altro è davvero 
banale, anzi spesso è divertente.
Per questo io suggerisco di procedere top-down, cerchi qual'è il 
paradigma che ti è più utile per risolvere il tuo problema (in genere 
c'è un'esigenza a monte di un programma) e ti cerchi un libro o 
documentazione online che affronti quel paradigma, poi l'implementazione 
in una maniera o nell'altra

 linguaggio solo studiando sul libro e carta.
Cutto tutto e ti fermo qua: 
Io non ho scritto "Imparare bene un linguaggio" ma "imparare a 
programmare". C'č una bella differenza...
Se sai "programmare" il linguaggio diventa un mero mezzo, io oggi scrivo 
in C, domani in VB, dopodomani in java, e se il cliente mi chiede cobol o 
lisp, no problem (oddio, il lisp lo odio con tutte le mie forze, ma 
questo non centra ;-) )
Se invece impari a programmare direttamente in un linguaggio, nel momento 
in cui ti cambiano le carte sotto le mani ti ritroverai spiazzato. L'ho 
visto succedere piů di una volta...

 programmare". C'è una bella differenza...
[cut]
Sotto certi aspetti posso concordare, ma imparare a programmare senza 
affidarsi a un linguaggio è utopia, IMHO.
Le due cose possono benissimo (e devono a mio parere) essere apprese 
assieme, avendo l'accortezza di separare mentalmente la sintassi dalla 
semantica. Chiarito questo punto sono d'accordo con te che in generale 
cambiare linguaggio implica quasi solo imparare nuove sintassi e costrutti.
Ciao e buona domenica!
Marco / iw2nzm

 che sto facendo.
Beh anche io. Il motto "prima la pratica e poi la grammatica" funziona 
spesso. 
Solo che alla fine potresti scoprire che se avessi studiato prima la 
grammatica, adesso sapresti tre lingue invece che una :-) 

 questo non centra ;-) )
Sono in parte d'accordo ma in parte no.
E' vero che si si sa programmare il linguaggio è solo un mezzo, ma è 
anche vero che ogni linguaggio ha i suoi punti forti e deboli, e si 
devono conoscere bene prima di essere davvero produttivi.
Nella mia (breve) esperienza ho visto tante persone fare il tuo 
ragionamento (se si sa programmare, il linguaggio è solo un mezzo), 
salvo poi metterci *mesi* o *anni* prima di raggiungere un livello di 
produttività ed efficienza adeguati.
Io credo che in definitiva servano entrambe le cose: magari si inizia 
spippolando un po' per farsi venire l'appetito, poi ci si documenta e 
si studia, e poi si può ritornare alla tastiera.
A parte la prima fase di incuriosimento iniziale, la seconda e la 
terza sono per me ugualmente fondamentali: se si salta o l'una o 
l'altra si rischia di diventare o troppo astratti, quindi incapaci di 
risolvere *efficientemente* problemi *reali* in tempi e modi *reali*, 
o troppo praticoni e quindi con scarse capacità di astrazione e con 
soluzioni troppo limitate per mancanza di un'adeguata pianificazione.
Ciao


Ragazzi ho apprezzato che il mio post abbia aperto un confronto, ma quello 
che chiedevo cioe' veri programmi gia' funzionanti si trovano in giro? 

 che chiedevo cioe' veri programmi gia' funzionanti si trovano in giro? 
Credo che qui ci sia parecchio materiale:
http://www.microchipc.com/
Comunque di siti con applicazioni complete open source ce ne sono 
parecchi. Bisogna solo avere la pazienza di spulciarli :)
Ciao!
Marco / iw2nzm

 visto succedere più di una volta...
Mah dipende molto da quele linguaggio impari e da come lo impari. Io ho 
imparato a programmare in Pascal. Dal pascal poi sono passato al C e al 
C++ poi sono passato al Java, nel contempo ho imparato prima ASP e poi 
PHP, tralasciando accenni di JavaScript.
Poi dipende anche "come" impari. Voglio dire se tu diventi un automa. 
Devo fare X prendo il codice $codice["X"] e lo incollo così com'è senza 
neache capire cosa fa il codice ( e ne ho visti tanti che fanno così ) 
cioè sensa farlo tuo... beh vai poco lontano...
Probabilmente se avessi imparato prima il Java ora sarei bloccato. Java 
per me non è un linguaggio da cui si impara a preparare ( poi se lo 
insegni come lo insegnano all'università da me ... ) però con un 
linguaggio come il C la cosa è diversa. L'importante è imparare le 
strategie ( il top->down ecc ) ed estrarre i concetti poi il linguaggio 
è semplicemente un insieme di sintassi per tradurre i concetti. Io 
potrei imparare un nuovo linguaggio con poco tempo ( e l'ho fatto ).
Ormai programmo da quasi una vita ( ho inziato a programmare a 12/13 
anni e ora ne ho 25 ) i linguaggi che conosco me li rigiro praticamente 
tutti.
Il lisp non è troppo male comunque, ho visto alcuni programmi e si 
capivano, ma poi parla uno che ha programmato anche in un OCmel


 cambiare linguaggio implica quasi solo imparare nuove sintassi e costrutti.
Mah per me neache piů quelli. Ormai ogni nuovo linguaggio che imparo 
riesco a farlo rientrare in qualche marco famiglia. Poi i linguaggi 
C-Like hanno conquistato il mondo e aiuta parecchio.
Comunque concordo sul fatto che una cosa č saper imparare e una cosa č 
saper copiare pezzi di codice in C. Ma proprio per questo secondo me se 
sai programmare, e ripeto saper programmare, in C a quel punto sai 
programmare.
Non si puo' mica imparare a programmare con un meta linguaggio creato da 
qualcuno a scopo didattico solo per farti capire il concetto di 
"Funzione" o di parametri passati per valore e per riferimento....


 
Il problema, in termini di produttivita, secondo me non ï¿œ tanto la 
consocenza del linguaggio ( Quanto ci vuole a conoscere i vari costrutti 
del linguaggio? ) ma piï¿œ che altro la consocenza a buon livello delle 
librerie che il linguaggio ( o piï¿œ spesso il compilatore ) ti regala. Un 
linguaggio senza librerie ci fai veramente poco. E' anche per questo che 
il Java ha avuto molto successo ha una libreria quasi sterminata che ti 
permette di fare di tutto e di piï¿œ.
Ti porto un mio esempio personale. Io ho inizato in Pascal. Poi sono 
pasato per varie ragioni al C. Io a livello sintattico li conosco 
entrambi, ma le librerie del PAscal le so tutte, praticamente, a memoria 
mentre il C ho molta meno esperienza ma questo non vuol dire che con un 
paio di minuti in google non trovo quello di cui ho bisogno.


 
Anch'io ho la terza edizione ma lo uso più che altro come reference... 
cioè non mi ricordo come si fa X e vado a vedere come si fa X


 permette di fare di tutto e di più.
Hai ragione, quando io intendo conoscenza del linguaggio mi riferisco 
anche alle librerie standard collegate. Tutti i linguaggi che conosco 
ne hanno in quantità diverse. Ma ogni linguaggio ha anche delle 
particolarità non solo a livello di sintassi, ma di semantica.
Per esempio non tutti i linguaggi hanno i puntatori, altri hanno le 
liste built-in e altri come libreria e così via.
Usare la soluzione più efficiente con un dato linguaggio non è solo 
una questione di "come si fanno i loop" ma anche di quale filosofia si 
adatta meglio, quale è più sicura, etc...
Questo secondo me si impara solo con l'esperienza, perchè anche se lo 
studi su un libro, ci vuole un po' perché il cervello interiorizzi la 
cosa ed abbia la prontezza di fornirti la soluzione giusta al momento 
giusto.
Ciao

Enzo ha scritto:

Enzo, te lo dico in tutta sincerità e senza offesa, ma è già 3 o 4 
volte che posti una domanda simile a questa, quindi non è che ci stai 
prendendo un po' per... in giro?
A me sembra impossibile che non tu riesca a trovare nulla, il sistema 
da cui scrivo questa mail è scritto al 95% in C e, oltre ad essere 
ovviamente funzionante, è completamente disponibile anche il suo 
codice sorgente.
Forse (se non sei un troll) non fai ricerche nel modo adeguato?
Se vuoi imparare il C non è necessario che tu cerchi programmi fatti a 
posta per la tua piattaforma, va bene qualsiasi programma C per 
qualunque piattaforma.
Poi potresti leggere qualche buon libro, come il Kernighan & Ritchie 
consigliato da Darwin.
Prendere un programma già fatto e dargli martellate fino a fargli fare 
quello che vuoi tu *non* significa saper programmare.
Ciao

 quello che vuoi tu *non* significa saper programmare.
Come fai a dare martellate ad un programma? :-) quello che vorrei fare e 
studiarmelo per capirlo e farlo mio cosi' da poter essere autonomo e fare 
dei miei pogrammi, il mio e' un hobby, nella vita lavorativa faccio altro, 
per me e' pura soddisfazione fare certe cose, fare il copia e incolla non mi 
da niente. 

 Come fai a dare martellate ad un programma? :-) 
Tranquillo che si può fare :)
Taaanti anni fa, quando andavo ancora alle elementari e non sapevo usare 
i poke, i peek e l'istruzione data sul basic del Commodore 64 e 128, 
prendevo un programma e lo smantellavo fino a farne un altro, mantenendo 
e modificando le istruzioni che non riuscivo a capire.
Riuscii a trasformare tra gli altri, un gioco di moto in una piccola 
agenda quotidiana ^___^
Ero ancora piccino però, e a quell'età è permesso ^___^
Ciao!
Marco / iw2nzm

 Marco / iw2nzm
Forse io non avendolo fatto da piccolo  cerco di farlo ora :-) 

 giusto.
Concordo in pieno :)


 da niente. 
Bene, questo spirito è molto positivo, cerca solo di essere più 
specifico e porre domande più mirate, sapremo certamente aiutarti di più.
Ciao


HSEROUT ["AT+CREG?",13]
HSERIN 2000,accensione,[WAIT ("+CREG: "),TMP,TMP1,TMP2]  'attendi una 
risposta entro 2 secondi altrimenti vai ad accensione
questa e' una delle cose che mi piacewrebbe fare in modo semplice con il c
oppure questa altra:
Hserin 1000,prova1,[wait (",128,"),skip 3,B0]
cioe' come fare in C senza usare buffer e quindi memorizzare l'intera 
stringa, ma dicendo semplicementemetti il valore nella variabile B0, 
aspettando che arrivi 128 poi non considerare i 3 caratteri successivi a 128 
? 

 
Non esiste un API standarda per fare quello che vuoi in maniera standard 
devi andare un po' sullo specifico. Ma dipende molto dalla piattaforma 
che usi.


 ? 
Si può fare anche senza buffer temporaneo, snocciolando un carattere 
dopo l'altro dalla seriale, ma io non lo farei almeno che non ci sia 
assoluta carenza di memoria. Quanto sono lunghe le righe inviate?
Ciao

 (o almeno io, scrivo la seriale in modo che lo faccia ;-) )
Visto che sto scrivendo anche io una funzione simile... tu cosa fai? 
Dedichi un timer solo per la seriale?
Io avevo pensato a un timer come "base dei tempi" condiviso tra più 
servizi. Ognuno avrà la sua variabile che viene incrementata (se attiva) 
nell'interrupt del timer. Così posso avere tutti i timeout che voglio a 
costo (qausi) zero.
Che ne dici?
Marco / iw2nzm


io seguo questa seconda strada:
un timer come base dei tempi ( tip. 50 mS 20 interrupt al secondo ) e 4 
timer software : 4 variabili di conteggio e 4 flag da testare come se 
fossero flag d'interrupt
li uso pero' a decrementare ci carico il valore di timeout e quando si 
azzerano setto il flag e non decremento piu'
il programma principale vive testando quei flag ( ricordarsi, in C di 
usare "volatile" nella dichiarazione dei flag )


 usare "volatile" nella dichiarazione dei flag )
Vero. Confesso che a volte devo ancora pensarci su quando usare 
variabili volatili, ma prima o poi ci arrivo :)
Ciao!
Marco / iw2nzm

Marco Trapanese ha scritto:

Questa soluzione funziona, però è poco generica e non scala molto bene.
Il timer per me *è* il servizio base che ogni applicazione deve avere, 
quindi fossi in te ci perderei un pochino di tempo per fare qualcosa 
di riusabile, altrimenti riscrivi tutto per ogni nuova applicazione.
Per darti un'idea noi abbiamo un solo contatore unico, che di solito 
viene incrementato alla frequenza di 1000 Hz (ma è configurabile).
Se nella tua applicazione vuoi eseguire dei task periodici (senza 
avere il kernel) possiamo fare in 2 modi:
Modo 1: polling, esecuzione sincrona
Nel main loop la prima volta ci salviamo il clock, e le successive 
conforntiamo il clock attuale con quello salvato, se è passato il 
tempo eseguiamo il task e risalviamo il clock.
Modo 2: irq, asincrono
Il timer ti permette di definire anche degli eventi e di dire fra 
quanto scadranno. Alla scadenza verrà chiamata una callback.
Questi eventi vengono messi in una lista ordinata per scadenza (gli 
eventi che scadono prima sono i primi). Dentro l'ISR del timer, oltre 
ad incrementare il clock, si scorre la lista e si chiamano le callback 
degli eventi scadute. Detto così può sembrare complicato ma sono 
davvero solo poche righe di codice e viene usata pochissima memoria.
Quale modo usare?
Nel modo 2 viene fatto tutto sotto IRQ, quindi di solito uso quello se 
le cose da fare sono veloci (tipo settare un pin o roba simile). Per 
fare un esempio ci ho fatto il driver per TRIAC in parzializzazione di 
fase, ho generato segnali a bassa frequenza, controllo i rimbalzi 
della tastiera, etc...
Ciao

Francesco Sacchi ha scritto:

Grazie dei suggerimenti, molto interessanti!
Ancora non riesco a ragionare in termini di processi ed eventi nei 
microcontroller. Lo faccio in .NET senza problemi, ma con i micro ancora 
non mi viene spontaneo.
Devo riuscire a iniziare a fare qualcosa in questa direzione, le 
potenzialità sono molto grandi!
Ciao!
Marco / iw2nzm

 potenzialità sono molto grandi!
Sì, come ti dicevo  è più difficile a dirlo che non a farlo, se guardi 
la nostra implementazione vedrai che sono davvero 10 righe di codice.
E' da un po' che penso di scrivere magari un qualche articolo 
divulgativo per queste cose, ma non trovo mai il tempo :-(
Ciao