CITAZIONE (NonSoloBolleDiAcqua, 25/04/2015 20:31:02 )
Quote:Sto semplicemente dicendo che basta trasformare il tuo vettore in una coda circolare (più o meno già fai una cosa del genere) , fai scorrere un indice su questa coda (il tuo semaforo) 'lokkando' un solo elemento e non metà vettore.
Se l'altro processo necessita di quell'elemento (visto che è sotto semaforo) prendi l'ultimo valore valido che salverai in una apposita variabile.
Tutto questo ti permetterà il dimezzamento della memoria e svincolerai i due processi in modo asincrono:
la coda circolare (cioè la funzione loop) procederà con i tempi di lettura del convertitore a/d,
mentre l'altro processo analizzerà i valori retroazionandoli.
Solo per ragionare, non ti scaldare...
Il primo "
Se l'altro processo necessita di quell'elemento" chi è la funzione loop o l'interrupt ?
Il secondo "
mentre l'altro processo analizzerà i valori retroazionandoli." a chi è riferito ? Non abbiamo mai parlato di retroazione, che vuoi dire ?
Comunque, ipotizziamo di avere una struttura del genere:
Loop {
___Funzione1 (Es. Gestione ADC)
___Funzione2 (Es. Gestione Display)
___Funzione3 (Es. Gestione Protezioni)
___Funzione4 (Es. Gestione Input)
___Funzione5 ...
___Funzione6 ...
___Funzione7 ...
___Funzione8 (Ricalcolo riga matrice, la nostra attuale Calcola_Vet())
}
Interrupt() {
// scorre l'indice da 0 a 319. Indice è una variabile globale, quindi vista dalla funzione Calcola_Vet() che potrebbe rappresentare il semaforo.
}
Calcola_Vet() {
// Supponiamo che vogliamo lavorare su un solo vettore di 160 elementi
// E supponiamo che la variabile Indice sta a 100,
// tale funzione ricalcolerà tutti i valori da da 0 a 99 e poi troverà
// il semaforo rosso (variabile indice) quindi ha 2 possibilità:
Opzione 1:Aspetta che la variabile indice si incrementa e man mano che lo fa ricalcola i restanti valori del vettore fino all'indice 319, quindi termina la funzione.
Da notare che se questa funzione viene eseguita quando l'indice sta a 0 occorrerà aspettare ben 20 ms per uscire dalla funzione, un vero spreco !
Opzione 2:Memorizza il valore 99, alza un flag di ricalcolo incompleto ed esce dalla funzione, quindi il ciclo loop potrà procedere con le Funzione1, Funzione2, etc, fino alla Funzione8 che continuerà il calcolo dal valore 100 fino al valore indice di quell'istante, a meno che il valore indice di quel momento non sia inferiore di 99 (vuol dire che ha ricominciato da 0).
In questo secondo caso, per funzionare correttamente, dobbiamo avere la certezza che la nostra Funzione8 deve essere richiamata entro 20ms, altrimenti ci saranno problemi sui valori ricalcolati.
}
Il secondo metodo è sicuramente quello più performante, tuttavia visto che attualmente la nostra funzione loop ha solo la Funzione8 è prematuro progettare un simile meccanismo, solo per questo dico di rimandare tale ottimizzazione...
CITAZIONE (NonSoloBolleDiAcqua, 25/04/2015 20:31:02 )
Quote:Ok, mi hai convinto...
So benissimo che non è così (e ti ringrazio per l'eleganza con cui mi hai dato la possibilità di andare avanti) ma faccio finta che ci credo e quindi accolgo la tua richiesta e si va avanti !!!
CITAZIONE (kekko.alchemi, 25/04/2015 21:50:37 )
Quote:Dovete partire dall'Hardware, definendo solo a livello filosofico il firmware, definirlo in tutti i suoi componenti, realizzarlo, e solo dopo iniziare a stendere il firmware.
...
Così invece scrivendo tutto da zero senza un riscontro pratico sull'Hardware (carichi applicati sull'inverter, distorsione effettiva, feedback...) si rischia di perdere un sacco di tempo.
E' vero quello che dici, tuttavia stiamo ancora agli albori, stiamo ancora lavorando sui blocchi logici del firmware siamo ancora lontani da tutte quelle ottimizzazioni relative all'hardware...
Inoltre, sicuramente in maniera più limitata, è comunque possibile "simulare" l'hardware con piccoli circuiti (nel mio video, ad esempio, ho simulato la variazione di frequenza con un semplice potenziometro, testando di fatto quella specifica parte di firmware).
In ogni caso ti ringrazio per il "warning", cercherò di tenerne conto adeguatamente...
CITAZIONE (kekko.alchemi, 25/04/2015 21:50:37 )
Quote:Posso aggiungere una cosa, senza scoraggiare nessuno?
Nooooooo !!! Stai zitto !!!
CITAZIONE (ElettroshockNow, 25/04/2015 22:24:56 )
Quote:Per farlo mi sono basato sul lavoro di BellaEli implementando una matrice bidirezionale e quindi mentre il micro lavora sulla matrice 1 viene calcolata la 2 oppure l'opposto.
Ehi, come hai osato senza permesso ?!? Vabbeh, per questa volta chiudo un occhio...
CITAZIONE (ElettroshockNow, 25/04/2015 22:24:56 )
Quote:Sulla carta funziona, ma nella pratica succede qualcosa di imprevisto che crea incroci sui finali !!!
Mmmh... viene da pensare a un piccolo errore o inaccortezza nella stesura del codice, non perchè è una idea mia, ci mancherebbe, ma semplicemente perchè è una operazione che non ha nulla a che vedere con gli incroci...
CITAZIONE (ElettroshockNow, 25/04/2015 22:24:56 )
Quote:A dimenticavo,per aumentare la protezione ho impiegato un pin interrupt che blocca tutto se sente un Fail da uno dei driver ...
Siii... questa è un'ottima idea: utilizzare un Pin da agganciare ad un interrupt con priorità più alta per bloccare istantaneamente l'inverter !
Ne terrò conto per quanto passeremo a gestire le protezioni...
CITAZIONE (ElettroshockNow, 25/04/2015 22:24:56 )
Quote:Si il sincro non può usare un interrupt con priorità più alta del timer1 e 2.
E' vero, l'idea che ci sia qualcosa che ha priorità superiore alla generazione dell'onda non mi piace affatto (a parte la protezione)... Vediamo come andrà a finire...
CITAZIONE (NonSoloBolleDiAcqua, 25/04/2015 22:33:23 )
Quote:Si potrebbe tentare di capire fino a che valori si potrebbe arrivare...un esempio potrebbe essere il 256...ma l'algoritmo dovrebbe essere cambiato, più o meno come avevo anticipato mediante una interpolazione a media pesata.Vediamo cosa ne pensa BellaEli.
Eccolo che riparte... Cos'è sta storia della media pesata ? A cosa ti riferisci ?
CITAZIONE (NonSoloBolleDiAcqua, 25/04/2015 22:33:23 )
Quote:Potrebbe esserci un bug a livello di algoritmo che è sfuggito...una foto potrebbe aiutare...
Quoto...
CITAZIONE (ElettroshockNow, 25/04/2015 22:33:23 )
Quote:Il metodo pwm phase correct è bellissimo perché non obbliga l'inseguimento della forma ,ma come svantaggio ha l'alto rischio di danneggiare il finale inquanto basta che per un attimo i due finali siano entrambi in conduzione e il danno è fatto.
Non ricordo dove ho trovato queste due animazioni:
Per gestire il DeadTime con il Phase Correct è un po' più complicato, potrebbe sfuggire qualche piccolo dettaglio che porta a mandare in conduzione tutti e due i finali quando ci si avvicina a valori alti di PWM...
In ogni caso, come ogni volta, complimenti per la qualità di tutto ciò che fai e condividi !
A presto, Eligio.