Newsgroup: it.hobby.elettronica.digitale
Titolo: Programmare in C

Salve a tutti.
Avrei intenzione di cominciare a programmare i PIC in C.
Vorrei sapere quale compilatore acquistare premesso che :
- Devo avere necessariamente un compilatore completo di licenza (devo
acquistarlo).
- Il compilatore deve essere il piu' vicino possibile allo standard C.
- Devo creare sorgenti sia per la famiglia 16Fxxx che per la 18Fxxx.
- E' preferibile(ma non indispensabile) che le librerie gia' pronte
non debbano essere modificate troppo per questo compilatore.
Spero di essere stato chiaro.
Ringrazio anticipatamente per i suggerimenti.
Saluti,
Massimo IW0HKG

 non debbano essere modificate troppo per questo compilatore.
Il migliore e' quelo della Hi-Tech Software 
http://www.htsoft.com/

IW0HKG Massimo ha scritto:

Ciao MAssimo,
il mio consiglio č di usare il compilatore ufficiale Microchip,
il C18 (tra l'altro gratis per 60 giorni e poi con alcune limitazioni ma 
sempre funzionante)
Io mi sono trovato sempre bene, allo stesso tempo ti sconsiglio di usare 
il C
per i PIC16, non č un'architettura adatta ad un linguaggio diverso 
dall'assembler.
Infine, il mio giudizio č positivo anche per il CCS (questo lo trovi 
anche per i pic16) anche se alcuni miei amici progettisti lo 
preferiscono (non ha bisogno del file di startup come il C18), io (ci ho 
fatto solo un paio di progetti) rimango sempre legato al C18 che invece 
ho usato largamente
Ho visto che ti hanno gią consigliato l'HI-TECH,
io non l'ho mai usato.
Considerando quindi i pareri contrastanti, il consiglio finale č:
Scaricati una versione demo e scegli quello che ti risulta piu familiare
Emanuele
-- 
YOUR ELECTRONICS OPEN SOURCE * 
http://dev.emcelettronica.com


Grazie ad entrambi,
Ho scaricato la versione student edition del compilatore c18 della
microchip(tanto per capire qual'e' l'ambiente in cui devo muovermi).
Devo dire che l'impatto e' un po' brusco.
Ho scritto il solito sorgente di prova con la funzione main vuota ma
non riesco a compilarlo.
Non riesco a configurare mplab per fargli vedere il tool c18(credo sia
questo il problema).
Credo che passero' le ferie sul manuale di start-up del compilatore.
In pratica :
-ho creato un progetto col wizard.
-ho creato un file main.c e l'ho incluso nel progetto
- sono andato su select language toolsuite ed ho specificato che
voglio usare il c18
- ho cliccato su build-all
ma non compila nulla, mi da' un errore e mi dice "build failed".
Magari il problema e' banale e potete farmi risparmiare un paio d'ore
di lettura del manuale dicendomi qual'e' l'approccio corretto.
Grazie ancora
Massimo IW0HKG

 Massimo IW0HKG

 Massimo IW0HKG


Hai perfettamente ragione. Ecco la schermata che appare :
Debug build of project `C:\PROVACC18\provac18ultima.mcp' started.
Preprocessor symbol `__DEBUG' is defined.
Tue Jul 08 21:21:21 2008
----------------------------------------------------------------------
Make: The target "C:\PROVACC18\main.o" is out of date.
Executing: "C:\PROVACC18\Untitled.c" -p=18F4458 "main.c" -fo="main.o" -
D__DEBUG -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
Could not spawn language tool.  Check command-line options.  (193)
A language-plugin exception occurred and was logged.
----------------------------------------------------------------------
Debug build of project `C:\PROVACC18\provac18ultima.mcp' failed.
Preprocessor symbol `__DEBUG' is defined.
Tue Jul 08 21:21:21 2008
----------------------------------------------------------------------
BUILD FAILED
Grazie

 la lettura del manuale e' COMUNQUE molto consigliata :-)
Certo! infatti ho scritto che probabilmente passero' gran parte delle
ferie sul manuale.
Volevo solo una spintarella.... :)

 A language-plugin exception occurred and was logged.
Questa e' la linea che ti dice quale e' l'errore.
Non trova il language tool.
Non solo, ma ti indica anche che cosa fare per risolvere...
Check "command line option"
A meno che io non abbia preso un abbaglio colossale, vai in 
MpLab, Project, Select Language ToolSuite e nel menu' che ti 
appare seleziona Microchip C 18
Poi, nelle varie righe sottostanti, seleziona il C18 e fai 
il browse per trovare la directory corrispondente a dove hai 
installato la suite Mcc18.
In pratica tutte le righe del menu' sottostante devono fare 
riferimento alla directory di installazione del C18 ed ai 
vari programmi in essa contenuti.
Ad esempio MpAsmWin fara' riferimento a 
Mcc18\mpasm\mpasmwin.exe se hai installato in Mcc18 che e' 
il default.
A questo punto prova di nuovo la compilazione.
Se ci sono altri problemi, guarda di nuovo quali indicazioni 
hai dalla linea di errore.
ciao
Angelo

 Angelo
Grazie, ho compilato la mia funzione "main" vuota con successo.
Mi vergogno un po' ad avere questo tipo di problemi, ma per me questo
tool e' una cosa completamente sconosciuta.
Non escludo che tornero' a tediarvi con quesiti sempliciotti (prometto
che studiero' sodo )
Grazie * (2^10)
Massimo IW0HKG

 che studiero' sodo )
Quando tornerai, troverai sicuramente qualcuno pronto a 
darti una mano,, quello e' il bello.
Se poi le domande sono semplici, altrettanto semplice sara' 
risponderti, per cui tanta soddisfazione con poco impegno da 
entrambe le parti!
ciao
Angelo


 Volevo solo una spintarella.... :)
noi qui stiamo
a proposito, visto che e' un altro classico:
SE vuoi avere strutture dati piu' grandi di 256 byte ( un banco RAM )
c'e' da modificare il .lkr in modo da creare un segmento di dimensione 
adeguata e di specificare che la struttura si trovi in quel segmento, 
trovi tutto in uno dei vari 'documenti' allegati al compilatore Microchip

 trovi tutto in uno dei vari 'documenti' allegati al compilatore Microchip
Si, ci ho fatto caso questa notte, se ne parla quasi nelle ultime
pagine del manuale in mio possesso nella parte delle FAQ.
Penso che passera' un po' di tempo prima che dovro' scontrarmici.
Comunque grazie per la pre-allerta :)
Non so se e' il caso di aprire un'altra discussione, ma ho notato
un'anomalia nell'uso delle "struct" col c18 (ho sbirciato in un
header).
E' anche vero che sono passati 14 anni da quando ho studiato un po' il
C, ma questa cosa mi sembra illecita per lo standard c:
struct
{
     int pippo;
     int pluto;
};
Non c'e' il nome della struttura e nemmeno un nome dopo la graffa
chiusa che indica una variabile che da sola usa la struttura.
E' lecito per lo standard ansi??? che utilita' puo' avere???
Spero di recuperare il manuale di c che prestai qualche anno fa ad un
amico.
Grazie
Ciao, Massimo IW0HKG

 E' lecito per lo standard ansi??? che utilita' puo' avere???
Sì è lecita, è una struttura anonima. La puoi usare per dichiarare una 
struttura e usarla subito, senza la necessità di dichiarazioni, 
prototipi etc... Il suo uso è molto limitato, ma a volte può fare comodo.
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org

 prototipi etc... Il suo uso è molto limitato, ma a volte può fare comodo.
Se è anonima come fai a farvi riferimento?
Se dopo la graffa  chiusa e prima del puntevvirgola metti un nome di
variabile, siamo d'accordo, ma così com'è come la puoi utilizzare?

 variabile, siamo d'accordo, ma cosě com'č come la puoi utilizzare?
Hai ragione, sono stato criptico, intendevo questo:
struct
{
	int foo;
	int bar;
} foobar;
poi puoi fare:
foobar.foo = 1;
foobar.bar = 2;
etc...


 Hai ragione, sono stato criptico, intendevo questo:
Ok. Già che ci sono, ti contesto anche l'"uso limitato".
Davvero non usi mai array di stutture anomime?


Sì, questo è un altro uso interessante, mi è capitato di usarli per 
dichiarare velocemente un array di parametri (configurazioni o 
preset), in modo da poterci accedere per nome.
Però l'uso più comune che ne faccio è quando devo convertire buffer di 
dati grezzi velocemente.
Però deve essere qualcosa di veramente eccezionale e che capita una 
sola volta, se già devi usare la stessa struttura in 2 posti diversi è 
più sicuro (e si fa anche prima) a dichiararla normalmente.
In ogni caso sono eventualità molto limitate, mi ricordo quasi a mente 
tutte le volte che le ho usate :-)


 dati grezzi velocemente.
Immagino tu ti riferisca alle union, non alle struct.

 Immagino tu ti riferisca alle union, non alle struct.
Nono, strutture-
Tipo: devo inviare una serie di parametri tramite un protocollo di 
qualche genere, invece di chiamare 20 volte la funzione di invio, 
istanzio una struttura anonima, la riempio e la invio al volo in una 
botta sola.
Chiaramente deve essere una cosa proprio usa e getta, perché se il 
frame viene usato in più di un posto conviene dichiarare il tipo 
normalmente.


 botta sola.
Ah, ok. Ma allora che c'entra il convertire?


Mii, come sei pignolo! (cit.) :-)
Ho dei dati in memoria sparpagliati e tipizzati in un certo modo, e 
per inviarli li devo *convertire* in un buffer grezzo (o viceversa).


 per inviarli li devo *convertire* in un buffer grezzo (o viceversa).
In altre parole li hai convertiti facendo una porcheria, ovvero dichiarando
una variabile in un modo e poi, complice il passaggio del puntatore per lo
stack e semmai qualche cast od ignoramento di warning del compilatore, la
hai utilizzata in un modo diverso.
K&R, che fessi non sono, avevano previsto le union proprio per effettuare
questa operazione in modo documentato e portabile.
Le hai mai usate in vita tua?
Ora capisco perché la programmazione ad oggetti ha avuto questo
inspiegabile successo: gira certa gente... :D
Tengo a precisare che non solo ti stimo, ma apprezzo anche il tuo costante
impegno ad aiutare gli altri. E' solo che stamattina mi girano un po'.

 impegno ad aiutare gli altri. E' solo che stamattina mi girano un po'.
Anche io ti voglio tanto bene, però allora direi che ti girano spesso :-P


 Le hai mai usate in vita tua?
pero' dal K&R in poi, il C non garantisce l'acesso "promiscuo" alle 
union, e' garantita solo la scrittura e la rilettura dei dati tramite lo 
stesso campo.
quello che rileggi usando un altro campo della union e' lasciata alla 
implementazione ( tipicamente funziona come atteso ma bisogna 
controllare il compilatore come si comporta ), il primo problema che mi 
viene in mente sono gli eventuali pad per garantire gli allineamenti.

 Sě, ma solo per risparmiare spazio, non per convertire dati.
Cosa dicono gli standard ISO, a proposito di una funzione analoga a quella
che hai usato come esempio? Scommetto che prescrivano che devi avere una
funzione per ogni diverso tipo di dato.

 viene in mente sono gli eventuali pad per garantire gli allineamenti.
Guardati il paragrafo 8.7 di K&R.

 per evitare ai programmatori meno astuti di fare delle cazzate.
Oltre a questo servono anche a poter generare compilatori piů 
ottimizzati grazie a regole un po' piů stringenti.


 ottimizzati grazie a regole un po' più stringenti.
Vero.

 Mi pare proprio che sia esattamente ciò che hai fatto nel tuo esempio.
No, nell'esempio ho passato un puntatore ad una struttura (che ha 
un'allineamento ben definito) a qualcosa che invece prende un void * 
(che non ha allineamento), quindi è ok.
Diverso sarebbe stato il caso opposto: ho un buffer di char e lo casto 
ad una struttura.
Esempio:
char *buf;
struct Foo *Bar;
...
buf = (char *)Bar; // Ok, allineamento di char < di quello di struct
Bar = (struct Foo *)buf; // Errore: buf può non essere allineato come 
le strutture richiedono.


 Certo, sono un programmatore, uso algoritmi ricorsivi :-P
A parte gli scherzi, ho trovato il documento ISO del C99:
www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
La frase di interesse è la 6.2.6.1-7 a pagina 50 che recita:
"When a value is stored in a member of an object of union type, the 
bytes of the object representation that do not correspond to that 
member but do correspond to other members take unspecified values."
Ciao!


 member but do correspond to other members take unspecified values."
http://msdn.microsoft.com/en-us/library/y9zewe0d(VS.80).aspx
vedere le note.
-- 
IBM: Incredibly Bloody Minded
News 2002 [v 2.08] / StopDialer / PopDuster - 
http://www.socket2000.com
Akapulce portal: 
http://www.akapulce.net

 Guardati il paragrafo 8.7 di K&R.
dove infatti la union viene usata al solo scopo di allineare 
correttamente in memoria l'header ed i successivi elementi della malloc
leggi a questo proposito il paragrafo 6.8 relativo alle union sempre dal 
K&R ( fine pag. 189 ) :
cit.:
il tipo impiegato dev'essere l'ultimo memorizzato. ....
e
se cio' che e' stato memorizzato e' di tipo diverso da cio' che viene 
estratto, il risultato dell'operazione dipende dall'implementazione.
come vedi K&R "sconsiglia caldamente" l'uso della union per fare 
conversioni volanti  ed estrazioni di pezzi di valore
chiaramente il problema si pone nel passaggio tra un compilatore ed un 
altro, se uno conosce il comportamento del proprio compilatore E 
immagina di non dover fare porting a destra e a manca le union si 
possono usare tranquillamente :-)
sara', ma anche per questo il C mi piace molto !

 sara', ma anche per questo il C mi piace molto !
Come diceva Dennis (l'ho conosciuto alla SSGRR), il C è solo un assembler
strutturato, nato per scriverci Unix. E' infinitamente più portabile di un
assembler, ma ha troppo rispetto per le risorse per astrarre più di tanto.

 non e' "assai meglio che niente" , e' potenzialmente pericoloso, le 
Anche la vita è potenzialmente pericolosa, ma assai meglio che niente.

 difficile trovare l'inghippo.
Come già detto ho volutamente trascurato la gestione del padding, la 
portabilità non era l'oggetto della discussione.
Usare le union per convertire invece, prima del C99 è implementation 
dependent (quindi non portabile), dal C99 in poi è proprio "undefined 
behaviour".
Questo significa che anche se provi e vedi che funziona, non è detto 
che funzioni in altre parti del codice o addirittura con opzioni di 
compilazione diverse dello stesso compilatore.


Anche la vita è potenzialmente pericolosa, ma assai meglio che niente.
Molto pericolosa, mortale addirittura.
Interessante questa discussione, anche per uno che cordialmente detesta il C.
--
ciao
  Stefano


Concordo pienamente, una curiosita' con che linguaggio scrivi i tuoi 
programmi per piattaforma embedded? 

programmi per piattaforma embedded? 
Io vorrei scriverli tutti in assembler se potessi, ma me lo lasciano fare senza
protestare solo con i piccoli, tipo Tiny2313 perchè dico che il C lavora male.
E per esempio in un' applicazione dove ho usato diversi 2313 in una piccola
sottorete sono stato anche accusato di averlo fatto per non usare il C, anche se
ho potuto dimostrare che l'altra strada, con un solo µC e una FPGA era più
costosa sia come componenti usati che come stampati. (in 2 facce non si faceva)
Il C proprio non mi piace, ma a volte non si riesce proprio a schivarlo e tocca
usarlo per forza, in fondo quante volte capita che si deve comunque fare anche
cose che non ci piacciono, c'est la vie.
--
ciao
  Stefano

 cose che non ci piacciono, c'est la vie.
In effetti chi ha pensato il C qualche problema doveva averlo...
-- 
"#define QUESTION ((bb) || !(bb))  - Shakespeare."



Motivi? 

 Motivi? 
Tanti. A cominciare dalla sintassi...
-- 
Honey, I Formatted the Kid!


 Tanti. A cominciare dalla sintassi...
Quindi lo eviti oppure usi altri linguaggi?

 Quindi lo eviti oppure usi altri linguaggi?
Se posso lo evito ed uso altro. Quando è necessario mi armo di 
pazienza.
-- 
Nymphomania: Illness that you hear about but never encounter 



Usi Assembler, oppure non mi dire il Basic o Pascal 

 cose che non ci piacciono, c'est la vie.
Sull'ultima tua affermazione non posso che convenire, sulla prima
preferisco attribuirla a qualch echoc infantile, perché davvero non riesco
ad immaginare come una persona del tuo calibro possa non apprezzare una
simile splendida leva. Che poi, come tutte le leve, vada talvolta calibrata
ed ottimizzata non ci piove, ma da lì abuttarla...

ed ottimizzata non ci piove, ma da lě abuttarla...
Non la posso buttare, anche perchč obiettivamente non c'č alternativa per fare
certe cose.
Certo che se gli inventori avessero usato una sintassi piů umana...
--
ciao
  Stefano

pazienza.
E' quello che faccio anch'io.
Sono convinto che le cose che richiedono delle storture mentali sarebbe meglio
impararle fin da piccoli, cosě poi magari vengono naturali.
Ma purtoppo oramai č tardi...
--
ciao
  Stefano

> Certo che se gli inventori avessero usato una sintassi più umana...
Non conosco il C, ovvero proprio le prima 50 pagine del Deitel and Deitel.
Ma non posso che dar ragione (dalla mia parte ovviamente) a SB.
Cioè fare una sintassi umana e più leggibile faceva schifo?
saluti
coals 

 Cioè fare una sintassi umana e più leggibile faceva schifo?
Questione soggettiva e di gusto (tralasciando discorsi di carattere 
tecnico e funzinale). Io ad esempio la trovo molto elegante e leggibile, 
quasi artistica.
Marco / iw2nzm

 Certo che se gli inventori avessero usato una sintassi più umana...
E' ben quella la cosa più bella. E' asciutta e necessaria, non per nulla i
compilatiori C sono i più facili da implementare.


Effettivamente leggendo un listato in Basic, Pascal si ha la sensazione 
almeno a prima vista che sia piu' UMANO, pero' se si insiste con il C si 
arriva ad avere lo stesso grado di comprensibilita' con in piu' tutta una 
serie di vantaggi che gli altri linguaggi purtroppo non possono dare oppure 
devono ricorrere a codice in assembler.
Inoltre secondo il mio modesto parere dipende dal codice C che si va a 
leggere, se il programmatore esperto ha avuto fretta ed e' ricorso a tutti i 
trucchi del mestiere "passatemi il termine" sara' difficile per chi si 
avvicina al C capire cosa fa il programma, se invece ilcodice e' scritto 
come si deve ed ha i commenti nelle parti che servono, allora la musica 
cambia.
Qualche giorno fa ho visto un listato in C proposto da una famosa rivista di 
hobby per elettronica che serviva per decifrare un codice per telecomandi 
Motorola, ti assicuro che anche chi non ha mai programmato poteva capirci 
qualcosa, forse non era il massimo dell' efficienza c'era qualche goto di 
troppo ma veramente era notevole la comprensibilita' del codice.
Sarebbe anche bello che gli esperti del forum ogni tanto facciano una buona 
azione mettendo qualche breve listato in modo che chi vuole imparare puo' 
farlo con il loro aiuto, ovviamente chi vuole farlo deve prima studiare le 
cose faondamentali del C, infatti non si puo' pretendere che il primo che 
arrivi vedendo & * chieda cosa e' un puntatore. 

SB:

Mah, io ne dubito.
Prendi per esempio questa struttura con puntatore a funzione, ho fatto il copia
incolla perchè sicuramente mi sarei sbagliato con gli asterischi o con una
parentesi se la scrivevo a memoria.
struct Pls {
    void (*ptrFunc) (int*);
}  Puls[nm] ;
Ia assembler la stessa cosa la fai con un salto indiretto dopo aver preso da una
tabella e un offset la destinazione, una cosa semplicissima.
Ma per riuscira a farla in C bisogna piangere in greco, e di esempi ne avrei
altri.
Ti sembra che una cosa del genere sia stata pensata da una persona non
disturbata?
O forse sono io il matto, chissà...
--
ciao
  Stefano

 O forse sono io il matto, chissà...
No, assolutamente, è davvero questione di gusti.
Quando, dopo qualche anno di basic, pascal ed asm ho scoperto il C ho avuto
una folgorazione uguale e contraria alla tua. Forse quella mattina il tempo
era più bello che dalle tue parti. ;-)

era più bello che dalle tue parti. ;-)
Sarà per quello, ma io ci metto sempre un sacco di tempo e mi viene il mal di
fegato, col C del c...    ;-)
--
ciao
  Stefano

 

Esatto.
-- 
Trojan:  Storage device for replicating codes...


 fegato, col C del c...    ;-)
LOL. Credo, correggimi se sbaglio, che tu prediliga l'hardware al software,
mentre io sono (per i casi della vita, che mi hanno dato un impiego
piuttosto che un altro) più softwarista che hardwarista.

 }  Puls[nm] ;
In effetti per certe cose il C è poco comprensibile, ma di contro ha 
una grande compattezza.
Hai scritto tutto in 3 righe, se volevi renderlo più chiaro avresti 
potuto usare qualche typedef e inserire qualche commento, tipo così:
/**
  * Tipo per puntatori a funzione usati come handler dei pulsanti.
  * La funzione prende un int * e non ritorna nulla
  */
typedef void (*pbtn_handler_t)(int *);
/**
  * Struttura che descrive un pulsante
  */
typedef struct Pushbutton
{
     pbtn_handler_t handler; ///< callback per la gestione del pulsante
     ...// altri campi
} Pushbutton;
/* Ecco i pulsanti */
Pushbutton puls[nm];
Anche avere un coding standard aiuta la lettura: il nostro (che ho 
usato sopra) prevede:
- il nome dei tipi semplici sempre minuscolo con "_t" alla fine
- I nomi degli oggetti (strutture) maiuscolo
- I nomi delle variabili sempre minuscolo
etc...


piuttosto che un altro) più softwarista che hardwarista.
Io sono uno che da giovane studente di fisica voleva andare al Cern, poi ho
girato un pò per il mondo e alla mi sono trovato quasi per caso a fare questo
mestiere, avrei potuto fare altre cose.
L'elettronica per molti anni è stato solo un hobby, costruivo amplificatori,
casse e radio già mentre facevo il liceo.
Poi gradualmente la passione mi ha tirato dentro e dai primi anni 80 faccio
questo mestiere, ma mentre per l'elettronica ho anche seguito corsi specifici,
per l'informatica la cosa si limitava all'uso del Fortran su schede e qualche
discorso teorico, tanto che il Basic e l'Assembler li ho imparati da solo su un
TRS80.
Quindi sicuramente mi sento più hardwarista che softwarista, ma bisogna
adeguarsi ai tempi e oggigiorno bisogna saper fare tutto, e non basta ancora.
Ma il C mi fa venire il mal di fegato lo stesso...
--
ciao
  Stefano

 mestiere, avrei potuto fare altre cose.
Sei Fisico?
:)
coals 

 typedef void (*pbtn_handler_t)(int *);
Bene, bravo, bis! :-)

Sei Fisico?
Si, ma per campare faccio l'elettronico.
--
ciao
  Stefano

 Ma il C mi fa venire il mal di fegato lo stesso...
: (((

: (((
Non è un problema, vivo bene lo stesso, un software in C++ l'ho fatto finire ad
un esterno perchè non mi andava più e poi ci stavo mettendo troppo, in autunno
dovrei fare qualcosa con un Cortex e credo che avrò un problema simile.
--
ciao
  Stefano

 Non è un problema, vivo bene lo stesso, un software in C++
Bleah! Non farmi la cattiveria di confondere il C col C++, col quale la
somiglianza è in realtà minima e fuorviante.

somiglianza è in realtà minima e fuorviante.
Perchè?
Io sinceramente non ho notato una gran differenza, almeno a livello di sintassi
sono ambedue brutti.
--
ciao
  Stefano

 sono ambedue brutti.
LOL. E' il paradigma di programmazione ad essere completamente diverso.
Detta così sembra il solito parolone grosso e vuoto, ma non è così.
Che poi uno possa usare un compliatore C++ per compilarci programmi scritti
in C è verissimo, ma non può certo dire di aver usato il C++.
Per inciso, penso che Stroustroup sia partito dal C perché gli veniva bene
partire da un compilatore più semplice possibile e con una sintassi pulita
ed ortogonale come quella del C.

in C è verissimo, ma non può certo dire di aver usato il C++.
Mah, io ho cercato di usare la sintassi C, poi ho usato QT e le sue funzioni, ma
non so dirti la differenza in fino, facevo abbastanza fatica così.
--
ciao
  Stefano

 non so dirti la differenza in fino, facevo abbastanza fatica così.
LOL. Comunque ti assicuro che non è una differenza in fino e che, con tutta
probabilità, non hai scritto una sola riga in C++. Non che sia un male, su
di un sistema embedded...

di un sistema embedded...
Ques'ultima frase è arabo per me, davvero.
--
ciao
  Stefano

 Ques'ultima frase è arabo per me, davvero.
Bah, non ti perdi granché. Come ho già scritto, nell'ultima lezione di
Programming Languages, il professore riassunse il corso (dove ci aveva
fatto studiare cose ben ben astruse) dicendo che, dopo assembler, fortran
ed algol, la sola cosa che aveva avuto un reale impatto sulla
programmazione sono stati gli IDE.

ed altrettanti operatori, nella maggior parte di uso comune.
Già, ma in asm per esempio ho una sintassi che al massimo mi obbliga a mettere
una virgola, poi si ci sono gli opcode che però stanno tutti in due o tre
paginette al massimo.
Io consulto la lista soprattutto per controllare l'effetto delle istruzioni sui
flags, e ho programmato in asm di tutto,  Z80,  COP, 68HC05, PIC, AVR, ecc.
Dopo poco tempo gli opcode mi vengono da soli, e li ricordo perchè mi basta
leggere un listato per capire chi è e cosa fa.
In C invece hai  () [] {} ;  *  &  -> %c %s %d  e magari dimentico qualcosa.
Tutti da mettere secondo una logica astrusa con indentazioni varie e contorsioni
mentali, contro una virgola solamente.
Che è poi quello che non mi piace del C.
(So che alcuni assembler usano anche caratteri come # o @, ma sono casi rari.)
Comunque mi sento sempre come Don Chisciotte contro i mulini a vento    :-)
--
ciao
  Stefano

 Comunque mi sento sempre come Don Chisciotte contro i mulini a vento    :-)
Non direi. Il risultato finale è sempre migliore, con l'assembler, anche se
la manutenibilità ed i costi di sviluppo sono assai peggiori.
Come dicono in ammerica "there's no such thing as a free lunch"...

Come dicono in ammerica "there's no such thing as a free lunch"...
"My lunch is more tasty"     ;-)
--
ciao
  Stefano

 "My lunch is more tasty"     ;-)
E chi dice di no? :-)

Ehm...
Dipende ovviamente dai punti di vista e anche dall'allenamento all'uso, però ti
assicuro che di fronte ad una situazione di segnalazione di bug, spesso in
condizioni critiche magari con la macchina in collaudo, in genere in 1/2 minuto
riesco a capire dove può essere il problema e inizio ad operare, non credo che
in C ci metterei molto di meno.
Davvero, la voglia di usare il C non è un bisogno che sento spontaneamente, ma
che mi viene continuamente istigato dall'esterno, con frasi del tipo:
  "ormai sei anacronistico con l'assembler"
  "ci sono passati in tanti ma poi si sono trovati bene"
e invece io mi C trovo male.
Oramai mi sento come quello che guarda fisso le sbarre e dice
  "ma il manicomio è dentro o  fuori da qui?"
e non ho ancora la risposta  :-)
--
ciao
  Stefano

 e invece io mi C trovo male.
La verità è che puoi permetterti questo ed altri lussi. Anch'io, quando ero
dipendente, potevo permettermi di arrivare all'ora che volevo e fare un po'
quello che mi pareva. Quando hai un datore di lavoro che sappia fare due
conti, sei la persona più libera del mondo... :-)

conti, sei la persona più libera del mondo... :-)
Ehm, la verità è che per fortuna non sono un dipendente, altrimenti mi avrebbero
già imposto di lavorare in C e questi non li considero lussi.
Il problema è che ho a che fare con gente che mi considera retrogrado, e se
voglio affidare parti di programma ad altri sono costretto a turarmi il naso e
ad usare le graffe, purtroppo.
Come ti dicevo in autunno dovrò fare qualcosa con un Cortex, e nonostante abbia
già fatto qualche prova con l'assembler ARM che è molto potente, sarò costretto
mio malgrado ad usare il C o a fare tutto da solo.
--
ciao
  Stefano