Newsgroup: it.hobby.elettronica.digitale
Titolo: Limiti principali di Arduino

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.

 prezzo per la rapidità di sviluppo?
 
Premessa: di elettronica non capisco niente e ho usato
(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.
 

  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
 

 Per chi è già avezzo a questi sviluppi, quale è il limite importante che si incontra?
 
La "forza" di Arduino (intesa principalmente come semplicita`di 
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.
 
 

Il 29/06/2015 14:45, Piccio 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.
 
..

 addirittura nulli, margini di ottimizzazione.
 
E riguardo la gestione degli interrupt come è messo?
Intanto grazie a tutti.  ;)
 
Piccio.

> 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

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
 
 

 formare i tecnici o gli ingegneri del domani.
 
 
Epppero`... se la gente non studia piu` non e` mica colpa di Arduino ;)
 
 
 
 

 Comunque Arduino usa il compilatore C AVRGCC 
 
Questo può essere vantaggioso.  :)
 
Piccio.

 parlare se si vuole scrivere un intero byte parallelo.
 
A tal proposito...
https://www.youtube.com/watch?v=1MQI1D0rUwI
 
 
-- 
Forget RTFM...Phone the Author at home! 


 
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 non certo da imperfezioni del micro.
 
Piccio.

 non certo da imperfezioni del micro.
 
Ma qui stiamo parlando del modulo arduino non del suo 
microcontroller...
 
-- 
 

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

 formare i tecnici o gli ingegneri del domani.
 
Ma si , ritorniamo alle ottime schede perforate e ai pannelli ad interruttori, li si si poteva "toccare"
l'hardware!!
 
Giulia
 
 

 l'hardware!!
 
Ogni lungo viaggio comincia da un passo.
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.

 
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.

 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 
linguaggi di alto livello ;)
 
 


a me questa filosofia piace molto.
Molti di più sono quelli che "fanno" e molto di meno sono quelli che
"sanno fare".
Le leggi del mercato poi stabiliscono i compensi.
 
..


Noi, qui dove lavoro, ci occupiamo di sw. Io sono sempre stato appassionato di elettronica, ci lavoravo fino a che moltianni fa ho deciso di fare "il salto" e dedicarmi al sw.
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.

 Facciamo cosi`, il C e` il linguaggio di livello piu` basso tra i linguaggi di alto livello ;)
 
+1
 
 

 +1
 
Tsk!, tsk!...
E il Forth dove lo inseriamo?
 
Piccio.

 l'hardware!!
 
Vatti a leggere qualche post piu' sotto "Problema con sketch arduino" vedrai 
che cazzo combinano con Arduino e vanno a dare la colpa al C 


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!

 paragonabili ad un Arduino
 
dopo di che la cosa si fa esilarante quando se ne spunta qualcuno che si 
lamenta di non poter avere il controllo di qualcosa di cui non ha il 
controllo e dalla tecnologia si passa all'empirismo.
 
..