next topic »

[Reply #15 on:]

Scusate rileggendo la discussione, Leo solleva la questione di "p"
Un 328p e uno 328 (senza p) non sono identici?
Fede

Non sono identici.
La "P" nel codice identificativo sta ad indicare il core PicoPower che offre un miglior risparmio energetico. Anche le signature dei micro sono differenti.
Se ti ricordi, tempo fa Michele ed un suo amico, Daniele se non mi sbaglio, aprirono una discussione per integrare il supporto dell'Atmega328 "non P" nell'IDE di Arduino.

[Reply #16 on:]

ragazzi scusate la resurrezione del topic 

oggi finalmente mi è arrivato il atmega 328p-pu da questo rivenditore...
ho notato che nella descrizione ha sritto che il chip lavora a 20 mhz. è giusto? perche su arduino il quarzo è 16 mhz e non 20 anke se seono uguali?

Sull'Arduino è stato scelto un clock da 16 MHz probabilmente per via del fatto che il numero 16 è una potenza di 2 e permette di muoversi meglio con alcuni timing interni senza ritrovarsi con contatori che abbisognerebbero di decimali per archiviare il valore voluto (vedi funzioni delay/millis ecc).
Dico questo perché ho avuto lo stesso problema con la swRTC in cui ho implementato il supporto solo a clock di 1/8/16 MHz lasciando fuori i 20 MHz perché non mi "tornavano" i calcoli.

[Reply #17 on:]

Scusate rileggendo la discussione, Leo solleva la questione di "p"
Un 328p e uno 328 (senza p) non sono identici?
Fede

Non sono identici.
La "P" nel codice identificativo sta ad indicare il core PicoPower che offre un miglior risparmio energetico. Anche le signature dei micro sono differenti.
Se ti ricordi, tempo fa Michele ed un suo amico, Daniele se non mi sbaglio, aprirono una discussione per integrare il supporto dell'Atmega328 "non P" nell'IDE di Arduino.

Quindi il NON p attualmente è supportato nell'ide ufficiale di arduino o no ? (Non riesco a verificare)

[Reply #18 on:]

Senza modifiche: No.

[Reply #19 on:]

La scelta dei 16MHz e' dettata dalla retrocompatibilita', infatti ArduinoNG usava il mai dimenticato Atmega8, che al massimo supportava i 16MHz.

[Reply #20 on:]

Credo potesse essere vero tempo fa, ma non credo che oggi si preoccupino della retrocompatibilità con l'ArduinoNG 

[Reply #21 on:]

visto come si sono comportati con ide1.0, non posso che darti ragione 

[Reply #22 on:]

visto come si sono comportati con ide1.0, non posso che darti ragione 

Ah ah ah 

[Reply #23 on:]

Ha anche l'Atmel AVR Dragon per programmare jtag HV

eccellente

[Reply #24 on:]

Leo72

16Mhz arriva dai tempi dell'atmega8 che abbiamo usato all'inizio che arrivava al massimo a 16MHz e abbiamo mantenuto quella velocità (senza passare a 20MHz) per compatibilità con il codice esistente.

Con la 1.0 abbiamo annunciato con 2 anni di anticipo che avremmo cambiato delle cose per non cambiarle più nel futuro. Ora la 1.0 diventa la API matura e viene mantenuta ma non più "arricchita".

Poi certo con gli Italiani anche se uno vi avverte 10 anni prima tutti iniziano ad adeguarsi dall'anno successivo alla scadenza...

m

[Reply #25 on:]

grazie della chiarificazione, il discorso 16MHz era quindi inteso proprio come io lo avevo inteso

approfitto per una domanda, ma perche' arduinoisp inserito nella 1.0 non funziona ?
Vedi mia guida in firma per chiarimenti, se necessari

[Reply #26 on:]

Inoltre resta sempre il problema, ormai chiaro, della NON compilazione di sketch >64K; forse, senza polemica, tanto matura non è....

[Reply #27 on:]

forse, senza polemica, tanto matura non è....

Una versione 1.0 non si può certo definire matura 
Non scordiamoci che l'IDE di Arduino fino a poco fa era una 0.23, cioè quello che normalmente viene definito una beta, la 1.0 la vedo come un consolidamento dell'IDE e di wiring ed è normale che passando da una beta ad una definitiva ci possono essere dei cambiamenti.

[Reply #28 on:]

Uhm... a me pare che l'IDE sia stata fatta saltare dalla 0023 alla 1.0 solo perché in arrivo l'Arduino DUE che, magari potrebbe avere un'IDE tutta sua chiamata 2.0.... 
Quindi, a mio parere, una mossa più commerciale che tecnica.

Senza critiche per nessuno.

[Reply #29 on:]

Inoltre resta sempre il problema, ormai chiaro, della NON compilazione di sketch >64K

Pero' come ci siamo detti li e' colpa di gcc.