Apro questo thread per segnalare il core per Atmega644/1284. Questo core l'ho rielaborato a partire da quello per il Sanguino1284 che a sua volta deriva dall'IDE 0023 di Arduino.
Rispetto a questo però il mio supporta anche il TIMER3, presente solo sul 1284 (basta provare un PWM sui pin D6 e D7) del micro. Inoltre introduce il supporto ai pin analogici che, curiosamente, nel core del Sanguino0023 non c'è!
Relativamente a quest'ultimo punto, devo segnalare una cosa circa la numerazione degli stessi. Stranamente, Atmel ha deciso di adottare una numerazione inversa per i pin analogici: la porta PORTA che li gestisce parte dal pin PA7 collegato al piedino 33 e termina al pin PA0 collegato al piedino 40 del micro, ho deciso di adottare questo criterio:
se i pin sono usati come DIGITALI, la numerazione segue quella classica, quindi con numeri che incrementano di valore, per cui il piedino 33 è il pin digitale D24, il piedino 34 è il pin digitale D25 ecc...
se i pin sono usati come ANALOGICI, la numerazione segue (per facilità di riscontro con la piedinatura del datasheet) quella decisa da Atmel, quindi A7 per il piedino 33 (PA7), A6 per il piedino 34 (PA6), ...., A0 per il piedino 40 (PA0)
Altre indicazioni:
il core supporta i seguenti micro: ATmega644/A, ATmega644P/PA, ATmega1284P
nel core NON è presente un bootloader per il 644 "liscio" perché non sono riuscito a compilarlo
i bootloader presenti NON sono testati, sono quelli del core Sanguino quindi non so come vanno
nel menu dell'IDE di Arduino compariranno le voci "Arduino1284 w/Atmega644", "Arduino1284 w/Atmega644P" e "Arduino1284 w/Atmega1284" per le 3 board. TUTTE le board sono preimpostate a 16 MHz: se volete frequenze differenti, basta editare il file /hardware/arduino1284/boards.txt
il core Sanguino da cui deriva questo è sviluppato sulla base del core Arduino 0023, quindi NIENTE Arduino 1.0 per ora
Siccome gli allegati ai post fanno e non fanno, per sicurezza ho messo l'archivo sul mio sito. Scaricate da qui (nome "Arduino1284") http://www.leonardomiliani.com/?page_id=374
e poi scompattate come al solito per i nuovi core in /arduino-002x/hardware.
Ottimo Leo!
Spero domani di trovare qualche minuto per fare due prove. Come dicevo in precedenza sono riuscito a caricare il bl "Sanguino" sul 644 ma non sul 1284, a causa di un errore.
Ma sul 644, dopo aver caricato il bl, comunque non sono riuscito ad inviare uno skecth via seriale.
Hai fatto prove in tal senso? Come vanno?
Io sto usando la 0022, non sono riuscito ad usare il Sanguino 0023 perché ci sono incompatibilità? Pensavo il problema riguardasse solo l?IDE 1.0.
menniti:
Ottimo Leo!
Spero domani di trovare qualche minuto per fare due prove. Come dicevo in precedenza sono riuscito a caricare il bl "Sanguino" sul 644 ma non sul 1284, a causa di un errore.
Ma sul 644, dopo aver caricato il bl, comunque non sono riuscito ad inviare uno skecth via seriale.
Hai fatto prove in tal senso? Come vanno?
Io sto usando la 0022, non sono riuscito ad usare il Sanguino 0023 perché ci sono incompatibilità? Pensavo il problema riguardasse solo l?IDE 1.0.
Non ho fatto prove al bootloader, anche perché per quest'ultimo dovrebbe lavorarci Astro. Come ha detto, partirà dall'Optiboot per ottenere un prodotto capace di lavorare ad alta velocità. E' inutile che mi metta a lavorare su una cosa che poi tra qualche giorno verrà surclassata da un prodotto ben più performante
leo72:
Apro questo thread per segnalare il core per Atmega644/1284. Questo core l'ho rielaborato a partire da quello per il Sanguino1284 che a sua volta deriva dall'IDE 0023 di Arduino.
Ottimo, dato che ho già cominciato a disegnare lo schema mi sono reso conto che per far quadrare la disposizione standard dei pin sulla UNO con il 644/1284, in particolare i sei canali pwm, tocca fare il giocoliere con i PORT perché su questi micro i vari OCx sono assegnati in modo diverso rispetto al 328.
Il core su cui stai lavorando tiene conto di questa cosa oppure i port sono assegnati in modo lineare con i port del 328 ?
Durante il weekend finisco lo schema e posso darti una tabella esatta di come sono assegnati i vari PORT su i pin, il connettore che sto adottando è quello della UNO r3 con i pin aggiuntivi del 644/1284 riportati sotto forma di estensione connettore in stile MEGA 2560.
Dato che sul 644/1284 la TWI/I2C non è presente su A4 e A5, sono solo pin analogici, questa sarà disponibile sia sul connettore dedicato della r3 e su A4 e A5 tramite dei jumper che isolano i pin analogici e collegano quelli TWI, in questo modo si garantisce la totale compatibilità con tutte le shield vecchio stile che utilizzano la TWI.
Forse è il caso che estendi il titolo del topic anche alla relativa scheda, così teniamo le due cose assieme, tocca dare un nome alla nuova scheda, eviterei il classico duinoqualcosa o qualcosaduino, sono troppo banali e scontati.
astrobeed:
Ottimo, dato che ho già cominciato a disegnare lo schema mi sono reso conto che per far quadrare la disposizione standard dei pin sulla UNO con il 644/1284, in particolare i sei canali pwm, tocca fare il giocoliere con i PORT perché su questi micro i vari OCx sono assegnati in modo diverso rispetto al 328.
Me ne sono accorto. Ogni classe di micro (Tinyx5, Tinyx4, Megaxx8, Megaxx4 ecc..) ha la sua fantasiosa disposizione dei pin...
Il core su cui stai lavorando tiene conto di questa cosa oppure i port sono assegnati in modo lineare con i port del 328 ?
Non ho cambiato la disposizione delle porte per riadattarle a quelle del'Arduino/328. Il problema più grosso sono i pin analogici: il casino nasce dal fatto che Atmel ha scelto una numerazione dei pin INVERTITA rispetto al normale ma anche alle altre porte digitali sullo stesso micro. Mentre PORTB, PORTC e PORTD hanno i pin che seguono lo standard classico (maggiore è il n° di piedino, maggiore è il n° di pin), PORTA è invertita. O si "intrecciano" le piste e si mantiene la disposizione del n° di pin agganciato al n° di bit della porta oppure si inverte questo numero.
Per intendersi, questa è la mappatura attuale dei pin:
Durante il weekend finisco lo schema e posso darti una tabella esatta di come sono assegnati i vari PORT su i pin, il connettore che sto adottando è quello della UNO r3 con i pin aggiuntivi del 644/1284 riportati sotto forma di estensione connettore in stile MEGA 2560.
Dato che sul 644/1284 la TWI/I2C non è presente su A4 e A5, sono solo pin analogici, questa sarà disponibile sia sul connettore dedicato della r3 e su A4 e A5 tramite dei jumper che isolano i pin analogici e collegano quelli TWI, in questo modo si garantisce la totale compatibilità con tutte le shield vecchio stile che utilizzano la TWI.
Mi pare una buona scelta.
Forse è il caso che estendi il titolo del topic anche alla relativa scheda, così teniamo le due cose assieme, tocca dare un nome alla nuova scheda, eviterei il classico duinoqualcosa o qualcosaduino, sono troppo banali e scontati.
Ciao Leo, avevo ricavato una mappatura diversa dalla tua, pur senza aver fatto prove concrete, inoltre un link di BUD mi dava "conforto" in tal senso, può essere che via core siano rimappabili i pin?
@ Astrobeed: il mio consiglio sul nome è "va' dove ti porta il cuore"; a me non piace "proto", ricorda l'errore dell'ISP sulla Luigino "prototype" e poi perché non poensare che sia definitiva? al più metti una version...
Se inizi con i sondaggi sai già come va a finre, già non siamo d'accordo due su due :~
La differenza che noto è sui pin digitali dal 24 al 31.
Come ti ho detto, ho preferito mantenere la numerazione dei pin digitali a salire, com'è sul core Sanguino, mentre ho riallineato la mappatura dei pin analogici con la numerazione delle porte.
Uhm. Riguardandola, mi è venuto un altro dubbio: la posizione di INT0 e INT1.
Effettivamente stanno dove dici tu, ossia sui piedini 16 e 17, però il core Sanguino contiene la mappatura che ho allegato, a cui poi io ho aggiunto solo i PWM sui piedini 7 e 8. Non posso credere che il core Sanguino contenga un errore così macroscopico, ossia i pin di interrupt messi alla hotdog...
Ora ricontrollo il core per capire cos'hanno fatto.
Io intendevo solo dire che se si riescono a fare mappature così diverse probabilmente alla fine puoi arrivare a realizzarla come vuoi, tanto è roba "nostra", mica dobbiamo dare conto a qualcuno se una volta tanto stabiliamo noi lo standard.
La mappatura che ti ho postato segue, sia per analogico che per digitale, la numerazione PD in modo sequenziale, sembrerebbe la cosa più sensata, anche il 328 è così, mi pare; se è fattibile sarebbe la soluzione migliore.
Forse Astrobeed dovrebbe aspettare l'esito del tuo studio prima di mettersi al lavoro.
Guarda, la mappatura è "personalizzabile" fino ad un certo punto. Se non hai mai dato un'occhiata ad uno dei file che mappano i pin logici sui piedini, cerco di spiegarti brevemente. Esistono degli array per ricavare in modo veloce il piedino fisico dal piedino logico. Generalmente quindi si tende a seguire un certo ordine numerico per evitare appunto formule astruse per ricavare i numeri dei piedini. I pin logici sono quindi agganciati sulle linee I/O delle varie porte del micro, le quali a loro volta sono agganciate a livello fisico ai piedini del micro.
Nel caso del 328 la cosa è facilitata dal fatto che la mappatura dei piedini segue un ordine incrementale per tutte e 3 le porte (PORTB, PORTC e PORTD) per cui puoi vedere come PC0 sia sul piedino 23, PC1 sul piedino 24 ecc... Quindi A0 che equivale a D14 viene da sé, se così possiamo dire, è "logico" insomma seguire la numerazione.
Il 644/1284 per non so quale motivo, ha i pin della PORTA, quella che controlla i canali analogici, invertiti. Quindi una delle 2 mappature va invertita: se vuoi che A0 corrisponda a D24 come nel tuo caso, va invertita la sequenza dei pin digitali dato che PA0 è il piedino 40, se vuoi mantenere D24 su PA7, piedino 33, allora va invertita la numerazione dei pin analogici, come nel mio. In ogni caso.... #@$!#¶ all'ingegnere Atmel che quel giorno ha collegato le porte I/O ai bit del registro interno.....
Ho corretto la mappatura nel precedente post, integrandola con i segnali PcInt. Il simbolo "~" indica i pin PWM, agganciati ai vari TIMER segnati sui pin con "OCRnX".
Sentiamo poi il parere di Astro sulla mappatura dei pin analogici.
Intanto aggiorno anche lo zip scaricabile dal mio sito.
Leo, scusa, lo sai che sono un capoccione calabrese; non ho letto nulla se non datasheet e qualche info cercata un mese fa sulla rete, mi era sembrato facile come 1+1.
La mappatura che ho postato io dice che PA0 -->ADC0 -->D24 ........... PA7 -->ADC7 -->D31.
Ora ho trovato anche il link di BUD, che mi pare avesse citato anche Daniela, qui se non erro hanno lavorato con l'IDE 1.0, ma io ho trovato riscontro della mia mappatura, credo al 99-100%. Allora mi permetto di insistere, lascia stare me che ho fatto solo un lavoro cartaceo, ma se questi ti pubblicano tanto di lavoro hw/sw con quella mappatura significa che si può fare o che stanno bluffando?
Forse, con tutto il tuo tempo ovviamente, potresti dare un'occhiata alle loro risorse per capire cos'hanno fatto, se l'acqua calda c'è mica dobbiamo rinventarla a tutti i costi!
leo72:
Sentiamo poi il parere di Astro sulla mappatura dei pin analogici.
Intanto aggiorno anche lo zip scaricabile dal mio sito.
Il problema non sono i pin analogici, e poco importa come sono assegnati fisicamente sul case, semmai questo è un problema di sbroglio, a livello software devi solo fare riferimento ai relativi registri, rispetto al 328 ne abbiamo due in più, A6 e A7, che avranno la loro estensione dedicata.
Il problema sono i pin digitali e non per le funzioni primarie che sono praticamente identiche a quelle del 328, ma per le funzioni secondarie e terziarie che sono diverse sia come corrispondenza pin che come distribuzione, il che rende impossibile ottenere una perfetta compatibilità pin to pin di tutte le funzioni.
Il mio obbiettivo è ottenere la compatibilità come pin digitali, analogici, TWI, PWM, le altre funzionalità non è detto che coincideranno alla perfezione.
Prima di fare altre modifiche al core aspetta che sforno la tabella pin - funzioni così hai una cosa univoca su cui lavorare, dovrei dartela definitiva entro dopodomani.
Non ho detto che la mia via è la migliore né che la tua/loro sia meglio della mia, o ancora che il tuo lavoro è sbagliato (ora mi intreccio...) Ho solo detto che la mappatura che sto usando è la stessa presente nel core Sanguino0023 che sto usando e che "a me" pare logica (pare logica perché mantiene un ordine numerico: dopo D23 viene D24 nella sequenza dei pin). Per far tornare questa cosa ho però invertito la numerazione analogica, perché per far corrispondere A0 con PA0 e D31 devi necessariamente invertire una delle due. Ma tutto rispetto al core che sto usando.
Considera poi che astro non so che problematiche deve affrontare per le piste: con la numerazione tenuta con PA0=A0=D24 la numerazione dei pin da D24 a D31 sulla scheda viene invertita a meno di non intrecciare le piste. Per questo ho detto anche che era bene aspettare anche il parere di astro, perché è lui che deve tracciare le piste.
Cmq se pensate che PA0=A0=D24 sia più logico, cambio tutto. Ci vuole poco. Basta mettersi d'accordo, a me va bene in un modo come in un altro. L'importante è che quanto si decide poi non venga più cambiato: considerate che una volta masterizzata la scheda, le piste rimangono quelle.
Brrrr Leo, ma io non sto contestando nulla, nemmeno io parlo di migliori/giuste e peggiori/sbagliate.
Tu hai scritto:
Non ho cambiato la disposizione delle porte per riadattarle a quelle del'Arduino/328. Il problema più grosso sono i pin analogici: il casino nasce dal fatto che Atmel ha scelto una numerazione dei pin INVERTITA rispetto al normale ma anche alle altre porte digitali sullo stesso micro. Mentre PORTB, PORTC e PORTD hanno i pin che seguono lo standard classico (maggiore è il n° di piedino, maggiore è il n° di pin), PORTA è invertita. O si "intrecciano" le piste e si mantiene la disposizione del n° di pin agganciato al n° di bit della porta oppure si inverte questo numero.
e io nella mia ignoranza sul discorso pensavo che cercassi un modo per risolvere una cosa che credevi non fattibile, e ti ho postato queste informazioni, tutto qui. Ovvio che alla fine si fa ciò che si decide, se anche sono da intrecciare le piste, in fondo sono 8 mica 800.
Comunque sto buono buono e non parlo più finché non fornite una soluzione che ritenete definitiva e chiedete un parere
Io odio il forum perché non ci vediamo in faccia... e tutto quello che scriviamo viene sempre interpretato male.
Lo so che non mi stai contestando nulla. Stai esprimendo dei dubbi sulla scelta che ho fatto, dubbi avvalorati dal fatto che vedi altri sistemi con una numerazione diversa da questa. Ho premesso che la scelta di indicare i pin digitali proseguendo dal 24 in poi per i piedini fisici 33 è insita nel core Sanguino, però ho deciso di mantenerla perché mi pareva logica.
Sul fatto che tu sia ignorante ("io nella mia ignoranza..:"), avrei dei dubbi Sono sempre pronto ad ascoltarti ma amo anche spiegare le mie idee. Poi se non sono esatte, non sono "de coccio", le cambio.
Sul fatto che tu non ti esprima non è bello, non voglio mettere bavagli a nessuno. Solo, sto lavorando su una cosa non mia per cui ho anch'io diversi dubbi ma anche diversi problemi a capire come sono state fatte le cose. Rispetto ai precedenti core che ho esaminato, questo del Sanguino è molto più ingarbugliato perché l'autore, non ne capisco il motivo, ha inserito il supporto ai 1280/2560 così come ai 328 (e qualche volta si legge di commenti riferiti ad altri micro ancora) per cui per cambiare determinate cose devo muovermi con i piedi di piombo, non è facile come sembra.
Se i singoli pin fisici del 644/1284 sono collegati agli header in modo fedele alla 2009/UNO
come li mappi via software si ripercuote solo sulle librerie che usano quei pin, alla fine per la porta
Analogica non importa l'ordine perchè PA0 PA1 ecc. svlogono tutte la stessa funzione.
In pratica è impossibile essere fedeli alla 2009/UNO o in genere al 328, perchè come ha detto astro ci sono pin che hanno doppia/tripla funzione, es MOSI/MISO/SCK che si trovano in PB3/PB4/PB5 (328) e PB5/PB6/PB7 nel 644.
PB6, PB7 nel 328 sono Xtal0-1 e quindi non sono presenti nell'header, mentre devono esserlo nella board con 644 assegnati all'header supplementare. Quindi tocca rivede la spiegazione per arduinoISP.
Insomma è un bel casotto, forse abbiamo un po sottovalutato la cosa, cioè non è semplice e poco impegnativo, specie se consideri che ci sono shield che neanche conosci l'uso che fanno dei pin. Poi anche la mega non ha compatibilità shield con la 2009/UNO o sbaglio?
Il problema di TWI è una gran rottura di P.. ti obliga a fare jumper selectable, per scegliere la compatibilita con la shield, con quale? Quella che usa il TWI e usa i pin A4/A5 o quella che usa A4/A5 come analogico.
Lo so che non è per niente facile, ecco perché sto zitto, siccome non faccio prove dirette posso solo fare parole, mentre a te servono suggerimenti utili, quindi non è autocensura, parola! XD