MECCANICA e DINTORNI http://meccanicaedintorni.morpel.it/phpbb/ |
|
nuovo controller Mc Raban basato su STM32 Nucleo http://meccanicaedintorni.morpel.it/phpbb/viewtopic.php?f=76&t=17646 |
Pagina 6 di 10 |
Autore: | AlBi [ lun mar 06, 2017 21:11 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Come vanno le cose McMax? chiedo perché è parecchio tempo che non ci sono aggiornamenti... Naturalmente non voglio fare pressioni, capisco le difficoltà e la carenza di tempo, ma dato che il progetto è parecchio interessante e tiene col fiato sospeso parecchia gente, sarebbe carino ogni tanto avere un feedback anche di piccoli progressi giusto per tenere vive le aspettative... |
Autore: | McMax [ mar mar 07, 2017 09:05 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Io sto lavorando al software mentre raban alla nuova versione del trasformatore. Ho i file pronti per fare gli stampati della primary driver e della parte di potenza, ma prima di farle stampare volevo fare le prove con il software e il nuovo trasformatore. Al momento sto avendo qualche difficoltà con l'implementazione delle funzioni che permettono di utilizzare parte della flash del STM32 per salvare i dati... funzione necessaria per poter salvare i parametri di configurazione per i vari profili di saldatura. |
Autore: | AlBi [ mar mar 07, 2017 12:31 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
La prima volta che ho fatto un progetto con l'STM32 ho anch'io fatto l'errore di pensare che la flash fosse sufficientemete e facilmente adoperabile per salvare un po' di dati di configurazione per poi accorgermi che invece era una grossa rogna. Lo feci, ma le routines in questione sono veramente rigide e male riutilizzabili poi in altri progetti perché sono fortemente vincolate alla struttura dei dati da memorizzare. Da allora metto sempre una eeprom esterna (in alcuni modelli come l' L0 hanno messo la eeprom interna) Ti consiglio di filarne una all'esterno, tanto non credo che questo pcb sia definitivo.. sono giusto 4 filetti wire-wrap da connettere... e ti levi il pensiero. Per il trasformatore (se ho capito bene il problema principale è la finestra di contenimento del filo troppo piccola) butto lì un'idea... (è un idea che mi è venuta adesso mentre scrivevo, non ho fatto verifiche, magari ha qualche inconveniente che su due piedi non riesco a vedere...) Provate a valutare se ci sono vantaggi usando due trasformatori su nucleo più piccolo. I primari saranno collegati in serie mentre i secondari (cambia il rapporto spire P:S) ma metà sezione del rame saranno collegati in parallelo oppure a due gruppi raddrizzatori separati e poi uniti a valle di questi parallelando i nodi in continua. Tra i nuclei con dimensioni inferiori probabile che si trovi qualcosa con un rapporto tra sezione nucleo e area avvolgimento più favorevole. Poi dato che i primari sono in serie sei sicuro che la corrente nei due trafi è sempre la stessa e anche se ci sono un po' di tolleranze di traferro dovrebbero essere poco influenti. Il costo sarebbe forse più alto (comunque le ferriti costano poco) ma se poi quello singolo diventa troppo difficile da avvolgere potrebbe comunque valere la pena. Se trovate dei nuclei in Kool-mu https://www.mag-inc.com/Products/Powder-Cores/Kool-Mu-Cores/Large-Kool-Mu-Core-Shapes sarebbe un materiale migliore della ferrite per questa applicazione, soprattutto per l'induttore di filtro in uscita. |
Autore: | McMax [ gio mar 09, 2017 22:27 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Il PCB del micro è definitivo (ne ho stampati 10) quindi non se ne parla proprio di mettere una eeprom esterna! Di flash ne avanza una cifra e gestita bene non ha problemi.. certo non è facile come una eeprom ma direi che si fa lo stesso. Per il trasformatore raban sta assemblando una sorta di planare utilizzando core standard EE e piattine di rame sagomate a misura. Sulla carta viene spettacolare con anche la possibilità di cambiare configurazione per fare prove a diversi rapporti spire... Per le induttanze di uscita ho fato le prove sia con core in ferrite "gappati" che con tiroide in polvere di ferro a gap distribuito. Più o meno siamo li. La difficoltà del progetto sta anche nel cercare di adoperare materiali facile reperibilità. Per questo livello di potenza l'ideale sarebbe stato quello di usare un più buck in parallelo che lavorano sfasati... in questo modo avrei ridotto notevolmente anche le emissioni.... ma da costruire sarebbe stato molto più complicato e oneroso. |
Autore: | AlBi [ ven mar 10, 2017 12:25 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Ho dato un' occhiata ai miei firmware sviluppati su STM32 e ho visto che l' emulazione eeprom su flash l'ho usata in due occasioni. Il problema principale, fondamentalmente è quello dell'estrema rigidità applicativa; con le routines che mette a diposizione stm si possono gestire solo dati a lughezza fissa di 16 bit. Avevo cercato di fare qualcosa di più flessibile, cioè gestire dati di lunghezza arbitraria tipo una struttura, ma non mi ricordo più se poi arrivai in fondo a questa cosa oppure no. Se sei in difficoltà e pensi ti possa dare una mano sull'argomento chiedi pure, un contributo, se posso, lo do volentieri. Il trasformatore a 'sorta di planare' mi/ci incuriosisce avete qualche foto o disegno? |
Autore: | McMax [ ven mar 17, 2017 19:32 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Io ho trovato una libreria che gestisce invece solo char (8 bit). Il problema sta nella conversione di una struttura complessa in un array di char e successiva riconversione. Funziona tutto tranne in una condizione che sto cerando di isolare.... No del trasformatore non ho disegni dovrebbe averli Raban ma ultimamente è incasinatissimo. |
Autore: | AlBi [ ven mar 17, 2017 21:13 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
mmm... la gestione a bytes d'istinto non mi suona bene... verifica di non aver problemi di allineamento con i dati della struttura. nei 32 bit le strutture sono allneate alla word se le smonti e le rimonti potresti disallinearla. c'è una pragma per gestire l'allineamento delle strutture, mi sembra "#pragma pack(1)" o qualcosa di equivalente. |
Autore: | McMax [ ven mar 17, 2017 21:48 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
la libreria l'ho trovata così. E' QUESTA Per convertire da struttura a byte e vice-versa uso la funzione memcpy() Da struttura a array di byte: Codice: char s[sizeof(FLASH_SAVE)]; memcpy(s, &weld_current_save, sizeof(weld_current_save)); Da array di byte a struttura: Codice: char R[sizeof(FLASH_SAVE)];
memcpy(&weld_current_save,R , strlen(R)); |
Autore: | McMax [ ven mar 17, 2017 21:54 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
"weld_current_save" è la struttura che contiene tutti i parametri di saldatura impostati... "s" viene salvato in flash nella funzione di scrittura "R" viene letto dalla flash nella funzione di lettura "FLASH_SAVE" è la struttura: Codice: typedef struct {
char current; //AMPS for the current welding cycle in AMPS ==> read from values[0].value char polarity; //POLARITA' - 0:DC; 1:DC INVERTITA; 2:AC ==> read from values[1].value char process; //PROCESSO - 0:TIG-HF; 1:TIG-LIFT; 2:STICK ==> read from values[6].value char output; //USCITA - 0:TIG 4T; 1:TIG 2T; 2:OUTPUT ON ==> read from values[11].value short pulse; //Pulse value (DC:1-5000; AC:1-500) ==> read from values[17].value for DC or values[18].value for AC float pulse_dutycycle; //Duty Cycle of the pulse ==> read from values[19].value char pulse_base_current; //base current for the pulse ==> read from values[20].value char start_current; //start current for the welding sequence ==> read from values[23].value char end_current; //end current for the welding sequence ==> read from values[24].value char start_ramp; //start ramp in sec. for the welding seqeunce ==> read from values[25].value char end_ramp; //end ramp in sec. for the welding seqeunce ==> read from values[26].value char pre_gas; //pre-gas duration in sec. for the welding sequence ==> read from values[29].value char post_gas; //post-gas duration in sec. for the welding sequence ==> read from values[30].value float arc_force; //arc force percentage value for the welding sequence ==> read from values[31].value char wave_neg_current; //current on the negative qudrant of the AC ==> read from values[35].value char wave_pos_current; //current on the positive qudrant of the AC ==> read from values[34].value float wave_balance; //balance of the AC waveform ==> read from values[36].value short wave_frequency; //frequency of the AC waveform ==> read from values[37].value char waveform; //AC waveform 0:QUADRA; 1:SMOOTH; 2:SINUS; 3:TRIANG ==> read from values[38].value } FLASH_SAVE; FLASH_SAVE weld_current_save; |
Autore: | AlBi [ ven mar 17, 2017 23:20 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Non mi hai detto qual'è il problema... Quella cosa dell'allinemento è un ipotesi a distanza... io proverei così : Codice: #pragma pack(1) <==== oppure __packed, ma è lo stesso, Impacchetta la struttura in modo continuo, senza allineamenti
typedef struct { char current; //AMPS for the current welding cycle in AMPS ==> read from values[0].value char polarity; //POLARITA' - 0:DC; 1:DC INVERTITA; 2:AC ==> read from values[1].value char process; //PROCESSO - 0:TIG-HF; 1:TIG-LIFT; 2:STICK ==> read from values[6].value char output; //USCITA - 0:TIG 4T; 1:TIG 2T; 2:OUTPUT ON ==> read from values[11].value short pulse; //Pulse value (DC:1-5000; AC:1-500) ==> read from values[17].value for DC or values[18].value for AC float pulse_dutycycle; //Duty Cycle of the pulse ==> read from values[19].value char pulse_base_current; //base current for the pulse ==> read from values[20].value char start_current; //start current for the welding sequence ==> read from values[23].value char end_current; //end current for the welding sequence ==> read from values[24].value char start_ramp; //start ramp in sec. for the welding seqeunce ==> read from values[25].value char end_ramp; //end ramp in sec. for the welding seqeunce ==> read from values[26].value char pre_gas; //pre-gas duration in sec. for the welding sequence ==> read from values[29].value char post_gas; //post-gas duration in sec. for the welding sequence ==> read from values[30].value float arc_force; //arc force percentage value for the welding sequence ==> read from values[31].value char wave_neg_current; //current on the negative qudrant of the AC ==> read from values[35].value char wave_pos_current; //current on the positive qudrant of the AC ==> read from values[34].value float wave_balance; //balance of the AC waveform ==> read from values[36].value short wave_frequency; //frequency of the AC waveform ==> read from values[37].value char waveform; //AC waveform 0:QUADRA; 1:SMOOTH; 2:SINUS; 3:TRIANG ==> read from values[38].value } FLASH_SAVE; FLASH_SAVE weld_current_save; ===> Non c'è bisogno di copiare la struttura in un array basta passare l'indirizzo della struttura stessa tramite un puntatore con un cast writer.write_data((uint8_t*)&weld_current_save, sizeof(weld_current_save)); ... reader.read_data((uint8_t *)&weld_current_save, sizeof(weld_current_save)); |
Autore: | AlBi [ ven mar 17, 2017 23:41 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Inoltre in memcpy(&weld_current_save,R , strlen(R)); la strlen() conta fino al primo byte che trova a zero '\0', che identifica come fine stringa, per cui ti darà sicuramente valori sballati |
Autore: | McMax [ sab mar 25, 2017 20:24 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
AlBi scusa ero in viaggio son rientrato ora. In settimana mi rimetto a lavorarci chissà mai che questa sia la volta buona che lo sistemo. Proverò per prima la modifica che hai suggerito; io il C l'ho studiato quasi trent'anni fa quindi tutte le nuove direttive mi mancano. Grazie per l'aiuto! |
Autore: | AlBi [ sab mar 25, 2017 21:03 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Figurati... speriamo piuttosto di aver azzeccato qualcosa.... Le direttive tipo pragma purtroppo non sono standardizzate, ogni compilatore ha le sue, anche se, tra i produttori di compilatori, c'è una forte tendenza a convergere verso le stesse clausole. Buon lavoro e speriamo di vedere presto la luce in fondo al tunnell |
Autore: | McMax [ dom mar 26, 2017 15:29 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
La questione dell'array è per un altro tipo di salvataggio. In pratica avevo deciso di strutturare la memoria così: Sector 5 (128KB) ==> salvataggio della configurazione istantanea, ovvero i parametri coerentemente impostati. In questo modo ad ogni accensione si ritrova la stessa situazione che si è lasciata allo spegnimento precedente. Poiché non volevo prevedere un'opzione di salvataggio, questo settore dovrà essere scritto ogni volta che si cambia un parametro della flash. In questo caso utilizzerei la variabile "weld_current_save". Sector 6 (128KB) ==> salvataggio di 10 blocchi di parametri pre-configurabili per esecuzione di saldature specifiche. In pratica si possono impostare 10 configurazioni definite dall'utente che possono essere richiamate dal menù. L'array di 10 valori è stato creato per questo salvataggio. Poiché non è possibile modificare un solo record per volta sulla flash, la modifica di anche un solo campo all'interno di uno dei record dell'array prevede il salvataggio di tutto l'array. |
Autore: | AlBi [ mar mar 28, 2017 11:54 ] |
Oggetto del messaggio: | Re: nuovo controller Mc Raban basato su STM32 Nucleo |
Ok, ma in ogni caso la copia nell'array di char temporaneo è inutile, e comunque usare le funzioni per la manipolazione delle stringhe come la strlen è sbagliato. Nel secondo caso userei un array di strutture in questo modo. Codice: #include <stdio.h> #include <stdint.h> // dummy interface functions void write_data(uint8_t* datap, size_t data_len); void read_data(uint8_t* datap, size_t data_len); #pragma pack(1) //<==== oppure __packed, ma è lo stesso, Impacchetta la struttura in modo continuo, senza allineamenti typedef struct { char current; //AMPS for the current welding cycle in AMPS ==> read from values[0].value char polarity; //POLARITA' - 0:DC; 1:DC INVERTITA; 2:AC ==> read from values[1].value char process; //PROCESSO - 0:TIG-HF; 1:TIG-LIFT; 2:STICK ==> read from values[6].value char output; //USCITA - 0:TIG 4T; 1:TIG 2T; 2:OUTPUT ON ==> read from values[11].value short pulse; //Pulse value (DC:1-5000; AC:1-500) ==> read from values[17].value for DC or values[18].value for AC float pulse_dutycycle; //Duty Cycle of the pulse ==> read from values[19].value char pulse_base_current; //base current for the pulse ==> read from values[20].value char start_current; //start current for the welding sequence ==> read from values[23].value char end_current; //end current for the welding sequence ==> read from values[24].value char start_ramp; //start ramp in sec. for the welding seqeunce ==> read from values[25].value char end_ramp; //end ramp in sec. for the welding seqeunce ==> read from values[26].value char pre_gas; //pre-gas duration in sec. for the welding sequence ==> read from values[29].value char post_gas; //post-gas duration in sec. for the welding sequence ==> read from values[30].value float arc_force; //arc force percentage value for the welding sequence ==> read from values[31].value char wave_neg_current; //current on the negative qudrant of the AC ==> read from values[35].value char wave_pos_current; //current on the positive qudrant of the AC ==> read from values[34].value float wave_balance; //balance of the AC waveform ==> read from values[36].value short wave_frequency; //frequency of the AC waveform ==> read from values[37].value char waveform; //AC waveform 0:QUADRA; 1:SMOOTH; 2:SINUS; 3:TRIANG ==> read from values[38].value } FLASH_SAVE; FLASH_SAVE weld_current_save; //===> array di strutture per la selezione di n programmi predefiniti #define PREDEF_ARRAY_SIZE 10 FLASH_SAVE weld_current_predef[PREDEF_ARRAY_SIZE]; main() { //===> Non c'è bisogno di copiare la struttura in un array basta passare l'indirizzo della struttura stessa tramite un puntatore con un cast // !!! Nota che ho usato la sizeof con il type, che, secondo me, è formalmente più corretto. write_data((uint8_t*)&weld_current_save, sizeof(FLASH_SAVE)); read_data((uint8_t*)&weld_current_save, sizeof(FLASH_SAVE)); //===> in questo caso passo un puntatore all'array e la dimensione totale dell'array write_data((uint8_t*)&weld_current_predef, sizeof(FLASH_SAVE) * PREDEF_ARRAY_SIZE); read_data((uint8_t*)&weld_current_predef, sizeof(FLASH_SAVE) * PREDEF_ARRAY_SIZE); //===> in questo esempio passo un puntatore esplicito alla prima locazione dell'array ma è esattamente // equivalente a sopra. Quale forma usare è una questione di gusti write_data((uint8_t*)&weld_current_predef[0], sizeof(FLASH_SAVE) * PREDEF_ARRAY_SIZE); read_data((uint8_t*)&weld_current_predef[0], sizeof(FLASH_SAVE) * PREDEF_ARRAY_SIZE); } /********************************************************************************/ // dummy interface functions void write_data(uint8_t * datap, size_t data_len) { return; } void read_data(uint8_t* datap, size_t data_len) { return; } Inoltre sarebbe meglio se per gli interi usassi le definizioni della stdint.h (uint8_t, int32_t ecc.) al posto delle classiche char int... che ad oggi sono da considerare quasi 'deprecabili' . Questo per migliorare la portatilità e la comprensione. (per esempio l' int è minimo 16 bit ma la dimensione effettiva dipende dall'hadware) |
Pagina 6 di 10 | Tutti gli orari sono UTC +1 ora |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |