Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Limiti principali di Arduino
381 views
Skip to first unread message
Piccio
Jun 29, 2015, 8:45:51 AM6/29/15
to
Premetto che non ho mai utilizzato Arduino basato su AVR 8 bit ma ne conosco la diffusione e le lodi sperticate.
Un mio amico sistemista si è cimentato nella realizzazione di applicazioni interessanti con tale piattaforma e mi satura gli ultimi neuroni sani rimasti (sbadiglianti) con pregi e lodi a non finire per tale - come lo definisce lui - "standard".
Non nego la comodità d'uso ma mi piacerebbe indicargli i limiti di tale piattaforma per evitargli brutte sorprese tra pochi anni, quando si accorgerà che per far lampeggiare un LED gli occorrerà un ARM.
Per chi è già avezzo a questi sviluppi, quale è il limite importante che si incontra?
Ovvero, a parità di micro, a quanto si deve rinunciare delle risorse come prezzo per la rapidità di sviluppo?
Grazie.
Piccio.
Un mio amico sistemista si è cimentato nella realizzazione di applicazioni interessanti con tale piattaforma e mi satura gli ultimi neuroni sani rimasti (sbadiglianti) con pregi e lodi a non finire per tale - come lo definisce lui - "standard".
Non nego la comodità d'uso ma mi piacerebbe indicargli i limiti di tale piattaforma per evitargli brutte sorprese tra pochi anni, quando si accorgerà che per far lampeggiare un LED gli occorrerà un ARM.
Per chi è già avezzo a questi sviluppi, quale è il limite importante che si incontra?
Ovvero, a parità di micro, a quanto si deve rinunciare delle risorse come prezzo per la rapidità di sviluppo?
Grazie.
Piccio.
Archaeopteryx
Jun 29, 2015, 10:05:22 AM6/29/15
to
> Per chi è già avezzo a questi sviluppi, quale è il
> limite importante che si incontra? Ovvero, a parità di
> micro, a quanto si deve rinunciare delle risorse come
> prezzo per la rapidità di sviluppo?
Premessa: di elettronica non capisco niente e ho usato
> limite importante che si incontra? Ovvero, a parità di
> micro, a quanto si deve rinunciare delle risorse come
> prezzo per la rapidità di sviluppo?
(poco) solo arduino. Quindi appartengo al novero di quelli
che in un certo senso ne stanno decretando il successo
anche se mi chiamo fuori dal gruppo degli integralisti,
degli illusi e dei professionisti improvvisati: riesco a
capire che se il gioco si fa duro non è tanto Arduino che
deve uscire di scena ma quelli non sufficientemente capaci
di usare hardware adatto e che si sono improvvisati
"professionisti" in questo campo. Esattamente come accade
con lo sviluppo dei siti web: mercato inquinato da gente
che trovandosi strumenti di sviluppo estremamente user
friendly hanno portato tutto verso il basso ("perché devo
dare 1000 euro a te quando lo studentello mi fa il sito
per la salumeria a 200 euro?").
Detto tutto questo: ho provato a programmare arduino da
eclipse, non sono un genio ma manco l'ultimo idiota. E'
così intricato anche solo caricare il classico "blink.ino"
che sono tornato all'IDE standard con un sospiro di
sollievo. Credo che se non tutto buona parte del successo
di Arduino (e i problemi conseguenti delineati sopra) si
sia giocato lì: ovvero scrivi, premi un pulsante per
controllare e un altro per caricare.
ciao!
Apx.
Megazone
Jun 29, 2015, 10:41:24 AM6/29/15
to
Conscio delle conseguenze, Piccio <in...@picciatiandrea.it> un bel
dì scrisse:
> Per chi =E8 gi=E0 avezzo a questi sviluppi, quale =E8 il limite importante =
> che si incontra?
> Ovvero, a parit=E0 di micro, a quanto si deve rinunciare delle risorse come=
> prezzo per la rapidit=E0 di sviluppo?
Il successo di Arduino, così come è stato per tanti altri prodotti,
non è certamente dato dalla sua "potenza", dalla sua "scalabilita" o
dalle sue "performance". Il successo l'ha guadagnato grazie alla
semplicità d'uso e di programmazione ma, soprattutto, anche alla
enorme quantità di codice scritto in gro per il web, librerie
comprese. Anche il parco hardware non se la cava male, sulla baia
imperversano i sistemini di sviluppo, i sensori, gli add-on...
Qundi uno che piglia in mano arduino sa che, bene o male, troverà
qualche cosa si sicuramente adatto a ciò che ha in mente di fare.
I Limiti sono quelli tipici di un microcontroller a 8 bit con 32k di
flash... ;-)
A parte le ovvietà si devono poi mettere in conto alcuni contro dopo
i pro...
I limiti soppracitati di memoria che con progetti complessi possono
diventare un problema. Ma parliamo di casi, appunto, complessi. Non
so esattamente quanto sia l'efficienza di compilazione dell'IDE di
arduino ma prima di intasare tutta la memoria ce ne vuole di
codice...
Il non sapere esattamente cos stia "sotto" al programma, ovvero quale
sarà il codice macchina finale può portare ad alcune delusioni (ci si
aspetta che il micro faccia una certa cosa invece ne fa un'altra) ma
sono scogli superabili sia con l'esperienza che si acquisisce
usandolo, sia scrivendo programmi ben fatti, avendo i testa quali
siano i passaggi da evitare.
i pin di I/O, presentati nudi e crudi sul connettore d'uscita,
potrebbero creare problemi con alcuni tipi di sensori, cose tipo
spike, spurie, malfunzionamenti, letture errate, etc... etc... Un
neofita che non sa andare oltre alla mera connessione fisica dei
moduli si troverebbe in un "cul de sac" dal quale non ne uscirebbe
facilmente, ma questo varrebbe perq ualsiasi altro micro.
--
Structured Programming supports the law of the excluded muddle.
News 2002 [v 2.07] / StopDialer / PopDuster - http://www.socket2000.com
Akapulce portal: http://www.akapulce.net
Claudio_F
Jun 29, 2015, 1:26:22 PM6/29/15
to
Il 29/06/2015 14:45, Piccio ha scritto:
> Per chi è già avezzo a questi sviluppi, quale è il limite importante che si incontra?
La "forza" di Arduino (intesa principalmente come semplicita`di
> Per chi è già avezzo a questi sviluppi, quale è il limite importante che si incontra?
sviluppo/utilizzo) e` anche il suo "limite", lo strato software (per
quanto sottile) tra lo sviluppatore e il metallo (e *non* sto parlando
dell'IDE) rappresenta qualcosa di indeterminato/indeterminabile.
Per dire, un segnale generato a software in bit-bang può essere affetto
da glitch, ritardi ecc perche` "sotto" gira qualcos'altro (ISR delle
periferiche, funzioni di libreria ecc). Anche l' on/off dei singoli pin
e` lento rispetto ad un canonoico set/reset scritto in Assembly, per non
parlare se si vuole scrivere un intero byte parallelo.
Arkannen
Jun 29, 2015, 1:34:44 PM6/29/15
to
Il 29/06/2015 14:45, Piccio ha scritto:
del dispositivo.
Per accendere un led va bene, ma se ne devo accendere 2.000?
Non sapendo come verranno allocate le risorse scoprirò se è possibile e
come solo a prototipo realizzato e nel caso avrò anche scarsi, se non
addirittura nulli, margini di ottimizzazione.
..
Piccio
Jun 29, 2015, 4:51:46 PM6/29/15
to
Il giorno lunedì 29 giugno 2015 19:34:44 UTC+2, Arkannen ha scritto:
> Il limite principale di Arduino è che non si ha il controllo completo
> del dispositivo.
> Per accendere un led va bene, ma se ne devo accendere 2.000?
> Non sapendo come verranno allocate le risorse scoprirò se è possibile e
> come solo a prototipo realizzato e nel caso avrò anche scarsi, se non
> addirittura nulli, margini di ottimizzazione.
E riguardo la gestione degli interrupt come è messo?
> Il limite principale di Arduino è che non si ha il controllo completo
> del dispositivo.
> Per accendere un led va bene, ma se ne devo accendere 2.000?
> Non sapendo come verranno allocate le risorse scoprirò se è possibile e
> come solo a prototipo realizzato e nel caso avrò anche scarsi, se non
> addirittura nulli, margini di ottimizzazione.
Intanto grazie a tutti. ;)
Piccio.
Giulia
Jun 30, 2015, 3:03:32 AM6/30/15
to
> Per chi è già avezzo a questi sviluppi, quale è il limite importante che si incontra?
Secondo me il debugging non e' banale sopratutto quando si creano situazioni "intricate",
noi usiamo ICD 3 che e' il minimo per fare un debug serio secondo me (ovviamente su PIC),
ATMel ha i suoi strumenti piu' sofisticati ovviamente.
Giulia
gulp
Jul 2, 2015, 6:01:22 PM7/2/15
to
Arduino ha reso semplice programmare i microcontrollori, questo puo'
sembrare positivo la realta' invece e' diversa, questo fenomeno ha portato
la programmazione verso il basso, nel senso che prima pur usando un
compilatore in C o Basic si doveva sapere cosa fosse un microcontrollore nel
senso hardware del componente per poter sfruttare con cognizione di causa le
sue potenzialita', vai a chiedere ad uno che si crede programmatore perche'
usa Arduino cosa sono i registri del micro che si sta usando e come li
setta.
Spero che questa spazzatura resti fuori dalle scuole dove si dovrebbero
formare i tecnici o gli ingegneri del domani.
Comunque Arduino usa il compilatore C AVRGCC
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
sembrare positivo la realta' invece e' diversa, questo fenomeno ha portato
la programmazione verso il basso, nel senso che prima pur usando un
compilatore in C o Basic si doveva sapere cosa fosse un microcontrollore nel
senso hardware del componente per poter sfruttare con cognizione di causa le
sue potenzialita', vai a chiedere ad uno che si crede programmatore perche'
usa Arduino cosa sono i registri del micro che si sta usando e come li
setta.
Spero che questa spazzatura resti fuori dalle scuole dove si dovrebbero
formare i tecnici o gli ingegneri del domani.
Comunque Arduino usa il compilatore C AVRGCC
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Claudio_F
Jul 3, 2015, 11:14:48 AM7/3/15
to
Il 03/07/2015 00:01, gulp ha scritto:
> Arduino ha reso semplice programmare i microcontrollori, questo puo'
> sembrare positivo la realta' invece e' diversa, questo fenomeno ha portato
> la programmazione verso il basso, nel senso che prima pur usando un
> compilatore in C o Basic si doveva sapere cosa fosse un microcontrollore nel
> senso hardware del componente per poter sfruttare con cognizione di causa le
> sue potenzialita', vai a chiedere ad uno che si crede programmatore perche'
> usa Arduino cosa sono i registri del micro che si sta usando e come li
> setta.
>
> Spero che questa spazzatura resti fuori dalle scuole dove si dovrebbero
> formare i tecnici o gli ingegneri del domani.
Epppero`... se la gente non studia piu` non e` mica colpa di Arduino ;)
> Arduino ha reso semplice programmare i microcontrollori, questo puo'
> sembrare positivo la realta' invece e' diversa, questo fenomeno ha portato
> la programmazione verso il basso, nel senso che prima pur usando un
> compilatore in C o Basic si doveva sapere cosa fosse un microcontrollore nel
> senso hardware del componente per poter sfruttare con cognizione di causa le
> sue potenzialita', vai a chiedere ad uno che si crede programmatore perche'
> usa Arduino cosa sono i registri del micro che si sta usando e come li
> setta.
>
> Spero che questa spazzatura resti fuori dalle scuole dove si dovrebbero
> formare i tecnici o gli ingegneri del domani.
Piccio
Jul 3, 2015, 12:25:32 PM7/3/15
to
Il giorno giovedì 2 luglio 2015 22:01:22 UTC, gulp ha scritto:
> Arduino ha reso semplice programmare i microcontrollori, questo puo'
> sembrare positivo la realta' invece e' diversa, questo fenomeno ha portato
> la programmazione verso il basso...
> Arduino ha reso semplice programmare i microcontrollori, questo puo'
> sembrare positivo la realta' invece e' diversa, questo fenomeno ha portato
Temo anch'io che Arduino stia all'informatica come "Nuova Elettronica" stava all'elettronica "ruspante" ma formale.
> Spero che questa spazzatura resti fuori dalle scuole dove si dovrebbero
> formare i tecnici o gli ingegneri del domani.
> Comunque Arduino usa il compilatore C AVRGCC
Piccio.
Megazone
Jul 7, 2015, 3:34:21 AM7/7/15
to
Conscio delle conseguenze, Claudio_F <clau...@tin.it> un bel dě
scrisse:
> Per dire, un segnale generato a software in bit-bang puň essere affetto
> da glitch, ritardi ecc perche` "sotto" gira qualcos'altro (ISR delle
> periferiche, funzioni di libreria ecc). Anche l' on/off dei singoli pin
> e` lento rispetto ad un canonoico set/reset scritto in Assembly, per non
> parlare se si vuole scrivere un intero byte parallelo.
A tal proposito...
> periferiche, funzioni di libreria ecc). Anche l' on/off dei singoli pin
> e` lento rispetto ad un canonoico set/reset scritto in Assembly, per non
> parlare se si vuole scrivere un intero byte parallelo.
https://www.youtube.com/watch?v=1MQI1D0rUwI
--
Forget RTFM...Phone the Author at home!
Piccio
Jul 7, 2015, 2:20:37 PM7/7/15
to
Il giorno martedì 7 luglio 2015 07:34:21 UTC, Megazone ha scritto:
> A tal proposito...
> https://www.youtube.com/watch?v=1MQI1D0rUwI
E' da prendere con le molle.
> A tal proposito...
> https://www.youtube.com/watch?v=1MQI1D0rUwI
I glitch sono certamente causati dal cablaggio o dallo sbroglio del PCB e non certo da imperfezioni del micro.
Piccio.
Megazone
Jul 7, 2015, 7:26:22 PM7/7/15
to
Piccio ha detto:
> Il giorno martedì 7 luglio 2015 07:34:21 UTC, Megazone ha scritto:
>
>
> > A tal proposito...
> > https://www.youtube.com/watch?v=1MQI1D0rUwI
>
> E' da prendere con le molle.
> I glitch sono certamente causati dal cablaggio o dallo sbroglio del PCB e =
microcontroller...
--
> Il giorno martedì 7 luglio 2015 07:34:21 UTC, Megazone ha scritto:
>
>
> > A tal proposito...
> > https://www.youtube.com/watch?v=1MQI1D0rUwI
>
> E' da prendere con le molle.
> non certo da imperfezioni del micro.
Ma qui stiamo parlando del modulo arduino non del suo
microcontroller...
--
LAB
Jul 15, 2015, 11:11:00 AM7/15/15
to
Io in poco tempo ho realizzato un prova cavi audio veramente come lo
desideravo: dice se è OK, o è controfase, o sbilanciato, se ha
un'interruzione o è in corto circuito.
Appena arrivato a casa il kit, senza aver mai usato Arduino né sapendo
ancora se avrei potuto sfruttarlo per quell'applicazione, ho cominciato a
fare qualche prova accendendo e facendo lampeggiare un LED e il giorno dopo
già avevo raggiunto qualche risultato incoraggiante, dopo aver combattuto
per mesi e mesi con i varii approcci che mi venivano in mente: logiche
AND/OR/XOR, semplici LED collegati in varii modi e segnali continui o
alternati, prove di codifica analogica per ottenere una tensione
univocamente corrispondente allo stato del cavo...
In due giorni cominciava a funzionare, dopo un'altra settimana la prima
versione funzionava. In 5 mesi (ma nel frattempo ho preparato il matrimonio
e mi sono sposato) ho ottimizzato tutto, l'ho montato e ho chiuso il
progetto.
Gli ostacoli principali sono stati:
- Volevo ridurre il consumo. Tanta gente prende il kit con il clock a
16MHz e lo lascia così. Cercando un po', però, si trovano anche informazioni
per usarlo a 1MHz (per cui è impostato un uC vergine di fabbrica, tra
l'altro: 8MHz/8...). Dopo aver messo insieme tutte le informazioni (chi ne
parla qua, chi là...) sono riuscito nel mio intento.
- Mi sono accorto che il "Biip" emesso non è perfettamente continuo.
"Chissà perché"... Credevo che lo facesse solo a me, invece poi ho scoperto
che il tone() di Arduino è così!!! Con il clock a 16MHz, però, si nota un
po' meno (comunque sweepando si sente, eh!); con il clock a 1MHz si nota di
più. Ho provato anche a scrivere uno sketch che poneva a 1 e a 0 il pin a
frequenza audio: stessa cosa!
Insomma, Arduino mette a disposizione comandi molto potenti per fare di
tutto, ma fa le cose a modo suo. Dicono anche che digitalWrite() è lento e
che, si ha bisogno di velocità, bisogna fare uso del "PORT MANIPULATION".
Allora uno si chiede: "Perché non lo hanno fatto loro?"... :-) Probabilmente
hanno voluto mantenere una distanza fra i programmatori improvvisati e
quelli che hanno studiato tanto...
desideravo: dice se è OK, o è controfase, o sbilanciato, se ha
un'interruzione o è in corto circuito.
Appena arrivato a casa il kit, senza aver mai usato Arduino né sapendo
ancora se avrei potuto sfruttarlo per quell'applicazione, ho cominciato a
fare qualche prova accendendo e facendo lampeggiare un LED e il giorno dopo
già avevo raggiunto qualche risultato incoraggiante, dopo aver combattuto
per mesi e mesi con i varii approcci che mi venivano in mente: logiche
AND/OR/XOR, semplici LED collegati in varii modi e segnali continui o
alternati, prove di codifica analogica per ottenere una tensione
univocamente corrispondente allo stato del cavo...
In due giorni cominciava a funzionare, dopo un'altra settimana la prima
versione funzionava. In 5 mesi (ma nel frattempo ho preparato il matrimonio
e mi sono sposato) ho ottimizzato tutto, l'ho montato e ho chiuso il
progetto.
Gli ostacoli principali sono stati:
- Volevo ridurre il consumo. Tanta gente prende il kit con il clock a
16MHz e lo lascia così. Cercando un po', però, si trovano anche informazioni
per usarlo a 1MHz (per cui è impostato un uC vergine di fabbrica, tra
l'altro: 8MHz/8...). Dopo aver messo insieme tutte le informazioni (chi ne
parla qua, chi là...) sono riuscito nel mio intento.
- Mi sono accorto che il "Biip" emesso non è perfettamente continuo.
"Chissà perché"... Credevo che lo facesse solo a me, invece poi ho scoperto
che il tone() di Arduino è così!!! Con il clock a 16MHz, però, si nota un
po' meno (comunque sweepando si sente, eh!); con il clock a 1MHz si nota di
più. Ho provato anche a scrivere uno sketch che poneva a 1 e a 0 il pin a
frequenza audio: stessa cosa!
Insomma, Arduino mette a disposizione comandi molto potenti per fare di
tutto, ma fa le cose a modo suo. Dicono anche che digitalWrite() è lento e
che, si ha bisogno di velocità, bisogna fare uso del "PORT MANIPULATION".
Allora uno si chiede: "Perché non lo hanno fatto loro?"... :-) Probabilmente
hanno voluto mantenere una distanza fra i programmatori improvvisati e
quelli che hanno studiato tanto...
Giulia
Jul 22, 2015, 5:09:09 AM7/22/15
to
> la programmazione verso il basso,
> compilatore in C o Basic si doveva sapere cosa fosse un microcontrollore nel
> senso hardware del componente per poter sfruttare con cognizione di causa le
> usa Arduino cosa sono i registri del micro che si sta usando e come li
> setta.
Veramente a nessuno gli interessa cosa siano i registri finche' fanno quello
> setta.
che gli si chiede sia che si usi una libreria ad alto livello, sia che li si programmi in assembler.
> Spero che questa spazzatura resti fuori dalle scuole dove si dovrebbero
> formare i tecnici o gli ingegneri del domani.
l'hardware!!
Giulia
Piccio
Jul 22, 2015, 7:35:30 AM7/22/15
to
Il giorno mercoledì 22 luglio 2015 09:09:09 UTC, Giulia ha scritto:
...
Se usi il teletrasporto già da subito ti ritrovi che per far lampeggiare un LED ti servirà un ARM a 200MHz.
Comunque volevo capire i vantaggi di un ambiente Arduino paragonato con compilatori decenti quali il CodeVision che dispone di librerie interessanti per vari dispositivi.
Di solito sono prevenuto ma un mio amico che si occupa di sistemi (reti, server, ecc) ha approcciato Arduino e senza troppe basi di programmazione "pura" ha già realizzato un programmino in grado di leggere una temperatura ed inviare delle email via rete.
Ha utilizzato pesantemente i file di esempio corredati nell'IDE ma non ha la minima idea di come funzioni l'hardware che ha sotto.
Questa semplicità mi affascina se penso alla possibilità di realizzare per un mio personale utilizzo vari gadget ma dall'altro mi inquieta perché vedo anche i limiti nel caso di produzione già su scala medio-piccola.
Conoscere l'hardware vuol dire sfruttare al meglio le risorse, gestire correttamente i consumi e l'affidabilità (watchdog) nonché le prestazioni critiche (inseguire un segnale senza interferenze di altre routine).
Piccio.
...
> Ma si , ritorniamo alle ottime schede perforate e ai pannelli ad interruttori, li si si poteva "toccare"
> l'hardware!!
Ogni lungo viaggio comincia da un passo.
> l'hardware!!
Se usi il teletrasporto già da subito ti ritrovi che per far lampeggiare un LED ti servirà un ARM a 200MHz.
Comunque volevo capire i vantaggi di un ambiente Arduino paragonato con compilatori decenti quali il CodeVision che dispone di librerie interessanti per vari dispositivi.
Di solito sono prevenuto ma un mio amico che si occupa di sistemi (reti, server, ecc) ha approcciato Arduino e senza troppe basi di programmazione "pura" ha già realizzato un programmino in grado di leggere una temperatura ed inviare delle email via rete.
Ha utilizzato pesantemente i file di esempio corredati nell'IDE ma non ha la minima idea di come funzioni l'hardware che ha sotto.
Questa semplicità mi affascina se penso alla possibilità di realizzare per un mio personale utilizzo vari gadget ma dall'altro mi inquieta perché vedo anche i limiti nel caso di produzione già su scala medio-piccola.
Conoscere l'hardware vuol dire sfruttare al meglio le risorse, gestire correttamente i consumi e l'affidabilità (watchdog) nonché le prestazioni critiche (inseguire un segnale senza interferenze di altre routine).
Piccio.
Tom Pinara
Jul 22, 2015, 9:19:25 AM7/22/15
to
Il giorno mercoledì 22 luglio 2015 13:35:30 UTC+2, Piccio ha scritto:
[..]
Poi, se ti va ma soprattutto se ti serve, approfondisci. Senno' no, chettiserve.
Na' roba agiail (si pronuncia agile), insomma.
[..]
> Conoscere l'hardware vuol dire sfruttare al meglio le risorse, gestire correttamente i consumi e l'affidabilità (watchdog) nonché le prestazioni critiche (inseguire un segnale senza interferenze di altre routine).
>
Imho la cosa piu' importante e' *fare*, senza tante seghe mentali.
>
Poi, se ti va ma soprattutto se ti serve, approfondisci. Senno' no, chettiserve.
Na' roba agiail (si pronuncia agile), insomma.
Claudio_F
Jul 22, 2015, 11:32:53 AM7/22/15
to
Il 22/07/2015 11:08, Giulia ha scritto:
>
>> la programmazione verso il basso,
>
> Direi alto , visto che il c e' un linguaggio di alto livello.
Facciamo cosi`, il C e` il linguaggio di livello piu` basso tra i
>
>> la programmazione verso il basso,
>
> Direi alto , visto che il c e' un linguaggio di alto livello.
linguaggi di alto livello ;)
Arkannen
Jul 23, 2015, 2:04:56 AM7/23/15
to
Molti di più sono quelli che "fanno" e molto di meno sono quelli che
"sanno fare".
Le leggi del mercato poi stabiliscono i compensi.
..
Tom Pinara
Jul 23, 2015, 5:10:01 AM7/23/15
to
Beh, il mio vicino di banco (un ing. informatico che ha almeno 25anni meno di me; siamo colleghi, ci occupiamo di cose diverse) si e' comprato Arduino e ha cominciato a smanettare. Io gli ho dato anche il mio kit (inutilizzato) ed e' stato veramente divertente, direi anche appassionante, vederlo curioso e fortemente interessato. Tirava fuori la breadboard anche qui, ci smanettava un po', mi ha fatto un sacco di domande banali e meno banali. Sta cosa, son sicero, un po' mi ha colpito.
Non sempre i percorsi mentali, gli schemi/preconcetti che abbiamo (che ho) si realizzano, o sono gli unici, o i piu' corretti. Ci sono mille sfumature, mille modi di approcciare le cose. Io non penso, realisticamente, che i miei siano i piu' giusti. Rispondono alle mie esigenze, quello si', ma ciascuno (e ciascuna situazione) ha le proprie.
GIulia
Jul 23, 2015, 5:01:13 PM7/23/15
to
> Facciamo cosi`, il C e` il linguaggio di livello piu` basso tra i linguaggi di alto livello ;)
Piccio
Jul 23, 2015, 9:47:15 PM7/23/15
to
Il giorno giovedì 23 luglio 2015 23:01:13 UTC+2, GIulia ha scritto:
> > Facciamo cosi`, il C e` il linguaggio di livello piu` basso tra i linguaggi di alto livello ;)
>
> +1
Tsk!, tsk!...
> > Facciamo cosi`, il C e` il linguaggio di livello piu` basso tra i linguaggi di alto livello ;)
>
> +1
E il Forth dove lo inseriamo?
Piccio.
mmm
Jul 24, 2015, 7:13:55 AM7/24/15
to
: Shoot_Yourself_In_the_Foot Foot in yourself shoot. ;
Marco
> Piccio.
>
gulp
Aug 11, 2015, 4:53:09 PM8/11/15
to
"Giulia" <far...@iperbole.bologna.it> ha scritto nel messaggio
news:monmjl$eae$1...@virtdiesel.mng.cu.mi.it...
>
> Ma si , ritorniamo alle ottime schede perforate e ai pannelli ad
> interruttori, li si si poteva "toccare"
> l'hardware!!
Vatti a leggere qualche post piu' sotto "Problema con sketch arduino" vedrai
> Ma si , ritorniamo alle ottime schede perforate e ai pannelli ad
> interruttori, li si si poteva "toccare"
> l'hardware!!
che cazzo combinano con Arduino e vanno a dare la colpa al C
Kokiua
Aug 21, 2015, 1:31:58 AM8/21/15
to
Ragazzi, se volete capire i limiti di un sistema che pretende di sfruttare un hardware a basso livello (come Arduino) iniziamo con lo scegliere una CPU (o MPU che dir si voglia), e con datasheet alla mano gli si prepari l'indispensabile per poter funzionare (alimentazione, eventuale clock esterno, periferiche per l'interfacciamento ecc).
Quindi, utilizzando un linguaggio umanamente comprensibile ma non riduttivo nella gestione dell'hardware (come il C dove possibile, altrimenti ASM!), iniziamo con il configurare TUTTE le funzioni e periferiche interne (memoria, velocità, porte, interrupt, consumi, ecc), e creiamo le convenzioni necessarie a utilizzarne le caratteristiche a livello superiore senza fare "casini" ..
Fatto questo avremo un sistemino pronto con caratteristiche paragonabili ad un Arduino e potremo capire realmente quali possano essere i suoi limiti (che saranno sostanzialmente quelli determinati dalle scelte fatte in fase di realizzazione ;-) )
A chi non comprende quello che ho spiegato consiglio di studiare o fare altro!
Quindi, utilizzando un linguaggio umanamente comprensibile ma non riduttivo nella gestione dell'hardware (come il C dove possibile, altrimenti ASM!), iniziamo con il configurare TUTTE le funzioni e periferiche interne (memoria, velocità, porte, interrupt, consumi, ecc), e creiamo le convenzioni necessarie a utilizzarne le caratteristiche a livello superiore senza fare "casini" ..
Fatto questo avremo un sistemino pronto con caratteristiche paragonabili ad un Arduino e potremo capire realmente quali possano essere i suoi limiti (che saranno sostanzialmente quelli determinati dalle scelte fatte in fase di realizzazione ;-) )
A chi non comprende quello che ho spiegato consiglio di studiare o fare altro!
Arkannen
Aug 21, 2015, 3:50:53 AM8/21/15
to
Il 21/08/2015 07:31, Kokiua ha scritto:
> Ragazzi, se volete capire i limiti di un sistema che pretende di
> sfruttare un hardware a basso livello (come Arduino) iniziamo con lo
> scegliere una CPU (o MPU che dir si voglia), e con datasheet alla
> mano gli si prepari l'indispensabile per poter funzionare
> (alimentazione, eventuale clock esterno, periferiche per
> l'interfacciamento ecc). Quindi, utilizzando un linguaggio umanamente
> comprensibile ma non riduttivo nella gestione dell'hardware (come il
> C dove possibile, altrimenti ASM!), iniziamo con il configurare TUTTE
> le funzioni e periferiche interne (memoria, velocità, porte,
> interrupt, consumi, ecc), e creiamo le convenzioni necessarie a
> utilizzarne le caratteristiche a livello superiore senza fare
> "casini" ..
>
> Fatto questo avremo un sistemino pronto con caratteristiche
> paragonabili ad un Arduino
dopo di che la cosa si fa esilarante quando se ne spunta qualcuno che si
> Ragazzi, se volete capire i limiti di un sistema che pretende di
> sfruttare un hardware a basso livello (come Arduino) iniziamo con lo
> scegliere una CPU (o MPU che dir si voglia), e con datasheet alla
> mano gli si prepari l'indispensabile per poter funzionare
> (alimentazione, eventuale clock esterno, periferiche per
> l'interfacciamento ecc). Quindi, utilizzando un linguaggio umanamente
> comprensibile ma non riduttivo nella gestione dell'hardware (come il
> C dove possibile, altrimenti ASM!), iniziamo con il configurare TUTTE
> le funzioni e periferiche interne (memoria, velocità, porte,
> interrupt, consumi, ecc), e creiamo le convenzioni necessarie a
> utilizzarne le caratteristiche a livello superiore senza fare
> "casini" ..
>
> Fatto questo avremo un sistemino pronto con caratteristiche
> paragonabili ad un Arduino
lamenta di non poter avere il controllo di qualcosa di cui non ha il
controllo e dalla tecnologia si passa all'empirismo.
..
0 new messages