Show Posts
Pages: 1 [2] 3 4 ... 18
16  International / Generale / Re: pinMode IN/OUT on: April 14, 2014, 03:49:22 am
Proprio per quelle direttive di source/sink dei pin delle MCU in generale, io personalmente preferisco mantenermi ben al di sotto di essi, ed è per questo, che preferisco l'utilizzo di componenti extra come transistor / FET / MOSFET / Darlington / LCD Drivers / ecc magari aggiungo dei componenti che potrei benissimo fare a meno, ma do una maggiore sicurezza al sistema, anche considerando che spesso, la presenza di questi componenti, crea un'ulteriore barriera contro eventuali disturbi / guai esterni come le correnti di flyback dei carichi induttivi...  o anche usare dei filtri RC per gli ingressi analogici per sensori dal monto esterno, non si sa mai, magari una sovratensione, due fili che si toccano et voilà! pin ADC bruciato se non peggio, Micro bruciato!! (ne ho fatti di errori a mie spese in questo argomento!!) Come dire, prevenire e meglio che curare!!
17  International / Generale / Re: Arduino UNO R3 contraffatta? on: April 14, 2014, 03:27:33 am
Ma allora se la nuova UNO R3 ha la grafica della parte posteriore bianca con la zona centrale scura ed i pin serigrafati sui header, perché la mia UNO R3 appena arrivata (presa da Mouser) in scatola sigillata, ha i pin serigrafati sui headers e la grafica tutta bianca sul posteriore?  sarà per caso che la versione con la striscia scura al centro è una versione speciale? una versione ancora più evoluta della mia, magari più vecchia di mesi, o è che i ragazzi del Team stanno pasticciando e non si decidono per un layout standard? Magari hanno pensato bene di "rinfrescare" periodicamente le grafiche?  ma se così fosse, credo si debba tenere aggiornato anche le descrizioni e foto del sito ufficiale, altrimenti la confusione aumenta!

Io adesso, come credo, tanti altri utenti, sono confuso, ho un'originale o un crontraffatto perfetto o quasi?  per fortuna, ci sono altri dettagli che indicano la genuinità, come il polyfuse dorato che quelli del "team" dicono sia stato fatto fare custom, i font delle parole "UNO" e "Arduino" custom, il colore tendente al verdino (anche se qui, la mia prima UNO R3 SMD comprata a natale 2012 è più blu a differenza di questa attuale, che è PDIP da rivenditore ufficiale, è più blu).

Lo so che stiamo parlando di hardware Open Source, ma come detto in altre occasioni, i loghi e diciture originali le possono avere solo quelli originali o licenziati (come quelli fatti con/da sparkfun, giusto?)  se voglio prendere un compatibile voglio riconoscerlo a primo colpo d'occhio e dire, a me piace il "CinCiunCian Cinaino!"  almeno sapro che è un clone open sorce, e magari se gli avranno messo qualche upgrade, ne sarò anche lieto!  è come andare a comprare i ricambi per la propria auto, quelli di "concorrenza" spesso costano meno, ma valgono anche meno, ma esistono belle eccezione che valgono anche di più degli originali anche costando meno!  quindi non è che sia contro i compatibili, sono contro i contraffatti !! (ultimamente un'utente del forum si è fatto fregare da un annuncio ebay ed ha comprato uno di questi quasi allo stesso prezzo dell'originale, per fortuna che almeno funziona bene! , purtroppo, non sono serviti a nulla i consigli per fargli fare un acquisto sicuro, ha voluto fare di testa sua, e questo è il risultato! ... la fretta e brutta consigliera!!!)
18  International / Generale / Re: pinMode IN/OUT on: April 13, 2014, 12:05:43 pm
ok adesso ho capito.   Quindi adesso stai alimentando la scheda relè mediante il +5V di arduino, giusto?  mmm, non conosco l'assorbimento della scheda relè, ma penso che effettivamente, l'alimentatore di arduino non è proprio indicato a fornire tanta corrente, specie se lo fai da USB che se non ricordo male, riesce a fornire fino a 500mA, quindi hai fatto bene a prendere un nuovo alimentatore, quando lo alimenterai, non dimenticare di mettere la massa comune tra arduino e tutti i componenti, scheda relè e pulsanti capacitivi.

Quindi se misuri sui pin di attivazione della board relè, ti trovi un +5V giusto?  ci dovrebbe essere un pull-up per funzionare correttamente, ma immagino di si, si vedono 2 resistenze ed un LED per relè oltre a quel grosso componente DIL che ritengo sia un optoaccoppiatore e quel piccolo transistor...

19  International / Generale / Re: Dovete guardare assolutamente questo coso... on: April 13, 2014, 11:25:13 am
... comunque sono già a oltre 500.000 dollari , ho sbagliato lavoro!

... abbiamo, Icio, abbiamo sbagliato lavoro ...  smiley-cry smiley-cry smiley-cry

Guglielmo

P.S. : della serie "mal comune, mezzo gaudio"

Quotone, e siamo in 3 allora! o almeno io di sicuro, voi avete almeno le conoscenze tecniche del settore, io ho sbagliato proprio settore (Automotive, e continuo a sbagliare aggiungerei, ma che ci possiamo fare, al cuor non si comanda!!)  Sono sicuro che a voi le buone idee nel cassetto non mancano, vi manca (vi manca?) la motivazione a voler anche voi presentarlo alle masse su codeste nuove piattaforme di promozione e raccolta fondi, si promozione, prima del raccogliere fondi, servono a raccogliere consensi, se dopo una campagna (ben fatta ovviamente) non raggiungiamo l'obbiettivo finale, è segno che la nostra idea non ha colto nel punto giusto o il mercato è troppo ristretto per un settore come quello bazzicato dai bakers/crowfunders.   

Anch'io ho tante idee nel cassetto che mi piacerebbe tirar fuori, ma purtroppo sono per il mio settore che è di nicchia, dubito di arrivare a prendere un euro, ma non è detto che non ci proverei più in la!!

Andiamo!! Tirate fuori le idee!!! Crowfundiamo!!! O almeno, ci proviamo!!

 
20  International / Generale / Re: pinMode IN/OUT on: April 13, 2014, 11:00:59 am
Usa solo quelli con logica 5V TTL, gli altri lasciali stare.  Anche perchè io vado in base alla massa, ovvero, se ci sono 100 progetti basati su ULN2803/2003 e magari 2-3 sugli altri, è per qualcosa no?  Basicamente la differenza sostanziale tra i due 2803/2003 è la quantità di darlington, 8 per il 2803 e 7 per il 2003.  

Ma ancora non ho capito, alla fine, per eccitare i relè, che segnale gli devi dare con arduino, un LOW o un HIGH ?  e a questo che mi riferivo prima io.

Comunque, recapitolando,  se dai un segnale di 5V su uno dei pin del darlington (1 a 7 se ULN2003, 1 a 8 se ULN2803) si attiverà il pin opposto, quindi per il pin 1 si attiverà il pin 16 (del ULN2003) o il pin 18 (del UNL2803)  dando un GND al Relè o carico a lui collegato.  Al disattivarsi il segnale, il relè o altro carico induttivo, creerà una corrente/tensione di ritorno detta di flyback che tenterà di tornare indietro verso il darlington, esso mediante i diodi interni, scaricherà queste tensioni sul circuito di alimentazione o COM e proteggendo sia il darlington che l'arduino da spiacevoli conseguenze.

Un'ultima domanda, ma le alimentazioni, sia di arduino che della scheda relè è in comune?  immagino hai messo il GND in comune tra loro no?  se non lo hai fatto, specie se usi due alimentazioni separate (del tipo l'arduino da USB e la scheda relè da alimentatore) devi avere la massa in comune tra i due o non funzionerà o funzionerà male.

Di questo lascio la parola a membri del forum più autorevoli per chiarimenti, come ti ho detto in post precedenti, io sono nubbio come te, ma con qualche kilometro in più  smiley-wink


21  International / Generale / Re: idee per velocizzare ricerca dati in array? on: April 13, 2014, 10:25:00 am
Ok, ho capito!! Grazie Paolo e Guglielmo, mi era venuto questo dubbio vedendo che comunque per fare sta ricerca binaria doveva fare diverse operazioni... 

Meglio così !  sono più tranquillo, di ricerche del genere, l'array più lungo ha 16 elementi, il problema è che ne sono svariate array, ma troverò un modo di salvare capra e cavoli!! smiley-mr-green   per fortuna, gli array che hanno molti elementi, quelli delle mappe vere e proprie e che sono multidimensionali, vengono usate con gia  il valore index precedentemente trovato, quindi in queste, che ne sono varie  da 8x16 (almeno 2) 10x10 (almeno 2) e 8x8 (circa 3) in realtà i dati in esse sono indicizzati già, e non mi resta che fare:

Code:

     Val_11= Mappa[ Bkp_Load_inf ][ Bkp_RPM_inf ];
     Val_12= Mappa[ Bkp_Load_inf ][ Bkp_RPM_sup ];
     Val_21= Mappa[ Bkp_Load_sup ][ Bkp_RPM_inf ];
     Val_22= Mappa[ Bkp_Load_sup ][ Bkp_RPM_sup ];


Da notare che mi servono 4 valori per realizzare una interpolazione lineare in una mappa 2D dove gli assi X sono i giri, asse Y sono il carico (Load) e i singoli valori in essa sono l'asse Z.   Più sono distanti i breakpoint tra di loro, e più diventa importante l'uso di questa formula di interpolazione a 4 punti.

Beh, Vi Ringrazio dei Vostri preziosi consigli,  Grazie!!! smiley-mr-green

Antonio
22  International / Generale / Re: pinMode IN/OUT on: April 13, 2014, 06:30:13 am
Per l'analisi del codice, lascio il posto a gente più esperta di me, ma analizzando quello che hai detto, ovvero che senza la board relè collegata il problema non si presenta, mi fa pensare che sia veramente una questione di disturbi hardware da parte dei relè,  e a questo punto, devo pensare che forse la stessa scheda non sia del tutto ok, magari gli manca qualcosa o si sono dimenticati di dire che ci devi mettere tu qualcos'altro.

Comunque,  per prima cosa tenta di implementare un diodo come quelli presenti nei link che ti ho messo.  già questo dovrebbe ridurre di un bel po le interferenze che il relè potrebbe far rientrare quando viene diseccitato.

Per il ULN2803 o anche il ULN2003,  si, credo che sarebbe un bel passo avanti nella direzione della protezione di Arduino e poi, ti consentirebbe di pilotare carichi maggiori (se non ricordo male, ogni piedino di un ULN2003 può fornire fino a 500mA e se ne possono anche mettere diversi pin collegati tra loro in parallelo ed aumentare la corrente gestibile).   
Sarebbe interessante vedere meglio la scheda interessata e vedere che componenti ha montati su, i diodi mi sembravano più dei zener che diodi tradizionali, non sono esperto, ma credo che se fossero zener, forse non sono utilizzati per cui sono utili, ma dalla foto non riesco a captare altro, magari una più ravvicinata e ad alta risuluzione chiarirebbe i miei dubbi.

Se non vado errato, tu attivi i relè con un comando HIGH, giusto?  quindi in uscita sul piedino dell'arduino verso la board relè in presenza di attivazione sara a +5V, quindi credo che ti convenga provare con un ULN2003 (che conosco, il 2803 non me lo ricordo molto ma dovrebbe essere una versione a 8 darlingtong invece dei 7 del 2003, al massimo, verifica i datasheet e segui uno dei progetti indicati nei link)  in questo caso, funzionerebbe senza fare modifiche importanti, metti l'ULN2003 in una braeadboard al centro dove c'è il canale doppio, e collega i fili restanti, se ricordo bene, il pin 8 è GND e 9 è +5V/+12V, gli altri pin vanno collegati da 1 a 7 verso arduino, ed i loro pin attivati saranno quello giusto di fronte (quindi per attivare il pin 16, dovrai eccitare il pin 1 con arduino e così via per gli altri 6 pin).   quindi i relè, andranno messi dal pin 10 al 16.

Comunque, dai un'occhiata ai link che ti ho postato, le info qui su sono a memoria, e la mia avvolte mi gioca brutti scherzi, e poi, ci ho giocato con loro 3-4 anni fa, quindi potrei essere confuso, verifica..

A questo punto, l'uso di mosfet si complica perche quelli che conosco io, pilotano GND mentre i tuoi relè vengono pilotati da +5V (VCC quindi) esistono anche con pilotaggio positivo, ma non ci ho avuto a che fare, per questi, ti conviene attendere indicazioni dai bravi elettronici che popolano questo forum.
23  International / Generale / Re: idee per velocizzare ricerca dati in array? on: April 13, 2014, 06:01:28 am
Ieri sera mi sono messo a cercare un po per vedere di capire come funziona ed applicare la ricerca binaria, ho tentato per primo di capire quella spiegata nel libro "Corso completi di Programmazione C" dei fratelli Deitel,  ma onestamente, sarà stata l'ora, ma il fatto è che non ci ho capito un bel niente, ho capito al primo colpo più quello che ha detto Guglielmo che l'esempio del libro, poi ricercando sul web, ho trovato un bell'esempio in C, ma spiegato pochino e nemmeno qui, ho potuto capire come fare per applicarlo al mio caso, ma almeno qui, ho capito di più come funziona, ma non abbastanza da poterlo implementare, mi potete dare un'indizio?  

Code:
//RICERCA BINARIA IN ARRAY  (mia aggiunta)

//--programma e commenti originali------------------------------------------

// lista[]: lista dei valori interi in cui cercare
// n: valore intero contatore di elementi della lista
// x: valore intero da ricercare
 int ricercaBinariaNonRicorsiva(int lista[], int n, int x)
 {
    int p, u, m;
    p = 0;
    u = n - 1;
    if (u < 0)
        return -1;
    while(p <= u) {
        m = (p + u) / 2;
        if(lista[m] == x)
            return m; // valore x trovato alla posizione m
        if(lista[m] < x)
            p = m + 1;
        else
            u = m - 1;
    }
    // se il programma arriva a questo punto vuol dire che
    // il valore x non è presente in lista, ma se ci fosse
    // dovrebbe trovarsi alla posizione p (nota che qui p > u)
    return -1;
 }
 
//--fine codice originale--------------

//--codice aggiunto per testarlo in IDE arduino-----
 void setup(){
  
   Serial.begin(9600);
  
 }
 
 void loop(){
  
  
 }


PS.  forse alla base della mia problematica sta il fatto che ancora non domino il passaggio di variabili tra funzioni, e qui si vede che funziona così...  Devo studiare un pò meglio questo...
24  International / Generale / Re: idee per velocizzare ricerca dati in array? on: April 13, 2014, 04:12:20 am
Altra ragione dell'uso di byte per la memorizzazione dei dati, è che essendo queste organizzate in byte, se dovessi memorizzare un dato "int" o "unsigned int" essi occuperebbero 2 byte giusto? formando una word a 16 bit giusto? un double 4 byte e i float? non me lo ricordo, ma il consiglio che ho visto spesso in giro é:  evitarli come la peste, si mangiano Flash, RAM ed EEPROM come niente e inchiodano le prestazioni. 
 
La Flash è organizzata a 16 bit, quindi word. Difatti se ci fai caso, quando compili uno sketch, non vedrai MAI un'occupazione di Flash data con un numero dispari, sempre pari!  smiley-wink smiley-wink
Uno sketch compilato che occupa 1013 byte prende in Flash 1014 byte, per capirsi.

Grazie Leo per la info, buono a sapersi!! smiley-grin
25  International / Generale / Re: pinMode IN/OUT on: April 13, 2014, 04:10:00 am
Vendendo il filmato e rileggendo il commento messo prima del video, mi viene da pensare a qualche problema di debouncing, hai provato ad usare un tempo maggiore di attesa, magari mentre stai passando il dito,  rileva centinaia di ON/OFF e quindi ti potrebbe dare stati incerti, boh, almeno e quello che penso qui su due piedi, giusto per escludere qualcosa, prova a mettere al posto dei bottoni capacitivi dei comunissimi pulsanti, se il problema scompare allora quasi sicuramente il problema ha ha che vedere con i pulsanti capacitivi ed il debouncing (sono molto grandi?)  anzi, pensandoci su, magari mi viene da pensare, e se li distanziassi maggiormente tra di loro? 
26  International / Generale / Re: pinMode IN/OUT on: April 13, 2014, 04:02:42 am
Con la scheda che stai usando, tutto il discorso dei mosfet/darlington ecc decade! mi sembra di intravedere degli integrati e dei diodi per ogni relè, quindi in questa applicazione non devi aggiungerne perché già dotata o almeno così mi sembra dalla foto.

Per il discorso del pin pull-up ha ragione Leo, anche se non l'ho mai usato per tale scopo, perchè ho sempre preferito mettervi io la resistenza di pull_up quindi non ci mai fatto caso delle altre possibilità, solo ultimamente l'ho vista usare con gli interrupt appunto dove ovviamente, un pin "flottante", "erratico" (stato logico incerto quindi) potrebbe scattare senza ragione apparente.

Comunque, fai qualche prova su quel pin, se ti serve il pull down, metticelo esterno, magari una resistenza da 4,7-10K e ri testa il tutto.  Se nemmeno cos' dovesse funzionare a dovere, ti suggerirei di controllare le schede comprate separatamente, per accertare che siano apposto.
27  International / Generale / Re: idee per velocizzare ricerca dati in array? on: April 12, 2014, 07:21:55 pm
Ciao, in risposta alla domanda del perchè l'uso di byte per le array...

Diciamo che principalmente perché avendo la necessità di avere in SRAM tante array (mappe) caricate per velocità di calcolo, e per poter usufruire della UNO l'ho impostato fin dall'inizio sulla riduzione di memoria occupata.  Non vorrei memorizzare i dati delle mappe in flash, quindi preferisco siano memorizzati in EEPROM,  diciamo che allo stato attuale, dal conteggio che ho, sommariamente, mettendo tutti i dati byte che ho in arrays e singoli dati variabile/costanti, sto già sulla soglia del limite della EEPROM della UNO, ma se non dovessi apportare ulteriori aggiunte o ampliazioni, mi avanzerebbero circa 70-90 bytes su 1024 disponibili.  Comunque adesso questo non è un problema, presto passerò il progetto su Atmega1284P che di flash ne ha 128Kb, di EEPROM ne la bel 4Kb e di SRAM ben 16Kb. 

Per ora, con la SRAM, considerando che non ho ancora tutto funzionante e quindi tutto quello che ho in teoria inizializzato come variabili, costanti e arrays non utilizzate da nessuna parte, il compilatore semplicemente le esclude, ma una buona parte è già funzionante, usando "freeRam" messo sparso un po dappertutto a fine funzioni, ottengo che ho ancora circa 1400-1450 bytes di SRAM,  non male, ma ovviamente, credo che a fine progetto, ne resteranno si e no 400-500 liberi e non so fino a che punto siano sufficienti per fare cose che non posso misurare dove stanno messe.  Per fortuna il passaggio alla 1284p risolverà indirettamente, anche questo ipotetico eventuale problema che potenzialmente potrò incontrare.

In realtà la scelta della 1284p è stata dettata per vari fattori:

1-ha 2 timers 16 bit, mi servono assolutamente.
2-ha 2 timers 8 bit, necessari per alcune funzioni da implementare in secondo momento.
3-funziona a 20 MHz (anche la UNO potrebbe farlo, la MEGA da datasheet NO) quindi un buon 25% di potenza in più.
4-Ha 128Kb di Flash (anche se per ora, non uso tanta flash da saturare la UNO).
5-Ha 4 Kb di EEPROM, mi darebbe respiro e consentirebbe anche l'implementazione di multi mappe, feature molto richiesta nel motorsport, e mi piacerebbe inserirla se possibile.
6-Ha 16 kb di SRAM e questo non può che giovare al progetto.
7-il formato TQFP44 è perfetto per un progetto stand alone, lo posso saldare agevolmente quello della MEGA non tanto.
8-il chip 1284P costa meno della metà di quello della MEGA.

della Mega invidio solo i 4 timers a 16 bit, adesso che ho visto cosa si può fare sfruttando i timers con OCRnX, più ce ne sono meglio è.

Altra ragione dell'uso di byte per la memorizzazione dei dati, è che essendo queste organizzate in byte, se dovessi memorizzare un dato "int" o "unsigned int" essi occuperebbero 2 byte giusto? formando una word a 16 bit giusto? un double 4 byte e i float? non me lo ricordo, ma il consiglio che ho visto spesso in giro é:  evitarli come la peste, si mangiano Flash, RAM ed EEPROM come niente e inchiodano le prestazioni.  E qui, le prestazioni sono tutto o quasi, siamo quasi nel "Real Time" e voi mi insegnate...
Quindi anche per mia facilità, memorizzare/leggere un byte è più facile che con una word, dove poi devo andare a decidere di leggere il MSB e LSB, con i quali ancora faccio fatica a ragionarci, e si sa, "make it simple" recita un famoso detto gringo, ed ha ragione.
Consapevole delle mie grandi lacune Tecniche in materia Hardware/programmazione tento di ridurre tutto a codice che per me sia comprensibile, almeno fin tanto non imparo nuove cose, purtroppo questo rende le prestazioni del sistema più lente o addirittura inutilizzabili...
Ho analizzato il codice sorgente di diversi progetti di ECU basati su Arduino/Freescale ecc e ho riscontrato diverse strade per fare le stesse cose, questo mi da da pensare, che la strada non è standarizzata, e quello che per me può essere un'incubo per qualcun'altro sarà normale amministrazione...


 
28  International / Generale / Re: pinMode IN/OUT on: April 12, 2014, 06:02:27 pm
Personalmente non collegherei mai un relè direttamente ad un pin Arduino, essi hanno una piccola capacità di assorbire/dare Corrente di pochi mA ed anche ammettendo che trovassimo un relè con piccolissima corrente di eccitazione, comunque, per il fatto di essere un carico induttivo (come un solenoide, un motore elettrico o una bobina magnetica di un altoparlante per esempio) genera una corrente/tensione di ritorno detta flyback al momento di sospendere la nostra eccitazione al device, queste correnti/tensioni solitamente sono brevissime ma hanno la caratteristica di essere molto superiori a quelle di pilotaggio, avvolte nell'ordine di anche 40-70 volts ma durano pochi ms al massimo.  Per evitare danni ai componenti che attivano carichi induttivi, si usa un diodo. 
In rete troverai un casino di materiale al riguardo di come collegare un relè, il problema è il tipo di relè, vi sono di piccola tensione (5V) media (12V) e alta tensione (oltre 24V secondo me) nonché quelli a corrente AC per pilotare utenze a 220V per esempio.
A prescindere dal relè utilizzato, io lo piloterei con un integrato idoneo, si possono usare transistor, FET, MOSFET, IGBT o Darlington.   Di questi solo i darlington hanno incorporato il diodo di protezione.  Ecco alcune pagine interessanti che dovresti leggere:

http://forum.arduino.cc/index.php?topic=159154.0
http://forum.arduino.cc/index.php?topic=52512.0
http://fritzing.org/projects/controling-8-relay-with-arduino-mega-adk
http://www.danielealberti.it/2013/09/rele-e-arduino.html
http://forum.arduino.cc/index.php?PHPSESSID=1e4a4883d1494c29861a458c565d7b79&topic=36133.msg265830#msg265830
http://blog.elettronicain.it/2013/01/04/le-mie-avventure-con-arduino/
http://www.instructables.com/id/Connecting-a-12V-Relay-to-Arduino/step6/The-Schematic/

Non ti preoccupare per il fatto di essere un "niubbo" in elettronica, anch'io lo sono, solo che con qualche anno di pratica in più, ma alcune cose le ho imparate facendo pratica, vedi?

Per l'osservazione fatta da Brunello:  Come mai metti un pin in input e poi lo metto low?  che io sappia avvolte si mette il pin in Ingresso High per così poter utilizzare il pull-up interno per poter "sentire" segnali LOW, l'ho visto fare specialmente con pin interrupt.

Immagino che il test suggerito sia per verificare che le masse che alimentano i relè ed arduino siano condivise, se non lo sono, possono portare a problematice di disturbi vari come questi da te indicati.
29  International / Generale / Re: pinMode IN/OUT on: April 12, 2014, 02:16:46 pm
ma i relè come li attivi? direttamente da arduino no! meglio farlo attraverso un Mosfet o anche un darlington tipo UNL2003, se usi un Mosfet, devi anche collegare un diodo per eliminare le correnti di flyback del relè quando viene diseccitato.
30  International / Generale / Re: idee per velocizzare ricerca dati in array? on: April 12, 2014, 01:58:09 pm
in realtà ci hai capito abbastanza, è proprio quello il problema nello scegliere i breakpoint giri e carico motore.

Scusa se non sono stato troppo chiaro, è difficile descrivere in poche parole i concetti dietro quello che dovrebbe fare una gestione motore (io da profano in elettronica e programmazione, sto facendo una specie di reverse engineering, dal funzionamento lato utente finale sto risalendo a ritroso su "come" lavora una ECU in firmware... non sono bruscoline...)

Comunque alla base di ciò che affermavo, vi è che sarebbe opportuno poter spaziare i breakpoint RPM in base alla curva di coppia del motore perchè, dove esso si comporta linearmente, io aumento il divario di giri a cui fa il controllo mappa, mentre nelle zone dove il motore è più imprevedibile, per facilitare le cose, spesso sono costretto ad aumentare il numero di breakpoint in quella zona ravvicinando i giri di controllo (ovvero i breakpoint) ti faccio un'esempio:

ho un motore che deve funzionare liscio a filo di gas in citta,  poi il motore sale con una progressione abbastanza lineare fino a 5000 rpm, da li al massimo numero di giri utili (diciamo 6000) del motore diventa poco lineare.   Quindi se la mia mappa ha 16 breakpoint RPM,  affinchè vengano inglobati tutto il range di funzionamento, quindi i miei breakpoint potrebbero essere:
     0 ,        1 ,        2 ,         3,         4,          5,         6,          7,          8,         9,       10,        11,         12,        13,        14,        15,    
     0,    500, 1000, 1500, 2000, 2500, 3000, 3500, 4000, 4500, 5000, 5500, 6000, 6500, 7000, 7500

Questo qui sopra sarebbe uno spreco di breakpoint tutti spaziati ogni 500 giri e partendo da 0 e superando i giri utili.

noi Tuner del settore Racing, dove queste cose sono all'ordine del giorno, in base a questo ipotetico motore faremmo:

       0 ,         1 ,        2 ,         3,         4,          5,          6,         7,          8,          9,       10,        11,        12,       13,        14,       15,    
1000,  1250,  1500, 1750, 2000,  2500, 3000, 3500, 4000, 4500, 5000, 5250, 5500, 5750, 6000, 6250,

come vedi, ho evitato lo 0, quando il motore è fermo la ECU resta in "ascolto" del segnale giri quindi in stand by, appena vede "girare" il motore, attua altre strategie specifiche della partenza (cranking)  superato una certa soglia giri, passa allo stato "running" e qui, entra in funzione la nostra bella mappa. quindi i nostri giri iniziano intorno alla zona di minimo che magari sarà intorno ai 900-1000 giri, per una buona erogazione, si predispongono breakpoint ogni 250 giri poi si passa a 500 giri alla volta (nella zona dove il motore è linare, ed infine, nella zona dove il motore è un po più irregolare e vicino alla potenza massima, si ritorna di nuovo a spaziare ogni 250 giri.  Ovviamente, questo dipende molto dal tipo di centralina che ho per mani e dal motore, ho centraline che hanno solo 16 breakpoint giri disponibili e con motori che fanno tantissimi giri diventa un problema trovare la spaziatura giusta, altre ECu invece, gestiscono fino a 32 breakpoint giri x 24 carico motore a mappa (e consentono i 250 giri dappertutto).

Visto che la mia idea è per un motore specifico e conosco le mappe originali, mi bastano i 16 breakpont giri ed anzi, forse userò anche la spaziatura originale, questo lo deciderò al momento delle fasi finali, se ci arriverò, della messa in moto di un motore cavia, ma per ora, quel momento è lontanuccio, meglio concentrarsi sui problemi uno ad uno separatamente e poi andare ad inglobarli uno alla volta fino ad ottenere il firmware completo e funzionante.

Quindi da qui, la mia preoccupazione per rendere fin da subito, più ottimizzato il codice, magari anche con queste lacune, sarebbe funzionante, ma essendo io profano, preferisco pensare al massimo risparmio di risorse per garantire velocità di riserva in caso di guai non previsti, quindi per esempio, per le funzioni di ricerca breakpoint sensori temperatura vari e relativo calcolo valori ingegneristici (sensore NTC non lineari, richiedono la linearizzazione mediante array, rieccoci !! capite?) l'ho ottimizzato inglobando le ricerche in una unica funzione Universale, che viene invocata da ogni funzione sensore da calcolare invece di fare una funzione per ogni sensore (sono 3 al momento i sensori). così ho risparmiato diversi byte di flash, codice più breve, e qualcosina a livello di uso SRAM (forse il compilatore gia di per se ottimizzava tantissimo prima), adesso sto facendo la stessa cosa con queste altre mappe, se non le ho inglobate in quella "universale" è per la differenza di numero breakpoints, e per quieto vivere, ho preferito farne una specifica per le mappe di gestione, ma una volta capito bene come fare, l'idea è inglobare anche queste ricerche in quella unica funzione "universale" come se fosse una libreria.  Le librerie, per ora, non ne uso nessuna, ma l'idea sarebbe anche verificare se conviene o meno, trasferire queste funzioni universali in librerie in modo da rendere il codice più trasportabile e corto (nello sketch ovviamente).  La strada è lunga.... smiley-sad

PS. sai che la tecnica che descrivi di dividere/moltiplicare per 128 l'ho vista tantissime volte sulle ECU di vecchia generazione? anche loro a corto di risorse e senza FPU.







Pages: 1 [2] 3 4 ... 18