Si parla sempre e solo di frequenze, che cambiano alla velocità desiderata.
Aad esempio da 0 a 100hz massima assistenza, da 100 a 200 media assistenza, oltre i 200 minima assistenza.
In pratica potrebbero bastare due generatori di frequenza ed un sistema di "selezione".
Ora non riesco a scrivere, ma un chip come quello dei led sequenziali, lm2914 se non sbaglio, che alla tensione x attivi l'uscita 1 ed alla tensione y l'uscita 2, collegato alle uscite 2 generatori di segnali...
Giusto per farvi capire...

Sent From My Note3

Personalmente in assenza di un uscita sul cambio o di albero di trasmissione accessibile userei due sensori reed posti sui due assali delle ruote anteriori mediando la velocità.
Onestamente per un applicazione del genere a mio giudizio basta un atmega a 8 bit (tu chiamalo se vuoi, arduino).
Hai due pin con degli interrupts gestibili quindi per calcolare la velocità di rotazione usi direttamente quelli, con i tre timer presenti gestisci i tre segnali di controllo sempre sotto interrupt, col il watchdog gestisci eventuali piantamenti del sistema e con il fuse di brownout problemi di alimentazione. Onestamente poi non vedo neanche il limite del linguaggio, puoi sempre scriverlo in puro C.

Le soluzioni possibili, come detto, sono molte; direi però che i reed per leggere la velocità delle ruote non sono molto indicati su una vettura, per di più da corsa, infatti l'amico parlava di ruota fonica simile a quelle usate per gli ABS che sono sicuramente più adatte.

Concordo ce il linguaggio di programmazione è ragionevolmente ininfluente, purchè il compilatore generi un binario affidabile ed efficiente.

Considerando che stiamo trattando di un sistema di servo assistenza alla sterzata per un auto da corsa e che personalmente opterei per un controllo continuo dell'aiuto scarterei la gestione a scatti in favore di una progressiva, tale scelta comporterebbe la necessità di una discreta capacità di calcolo e filtraggio dei segnali dei sensori, oltre alla necessità di avere una buona risoluzione sul PWM di pilotaggio.

Senza andare agli eccessi vedrei bene un DsPIC33xxxxx che è ben dotato sia come capacità numeriche che di I/O e timer con buona risoluzione, il costo del micro è comunque irrisorio rispetto al resto del progetto.

Voglio chiarire che non ho niente contro Arduino, è ottimo per moltissime applicazioni ed ha l'enorme merito di aver dato la possibilità anche ai non professionisti di avvicinarsi al mondo della programmazione embedded e risolvere in modo facile molti problemi d'automazione. L'importante però è conoscerne ed accettare i limiti intrinsechi sia al micro utilizzato (si stanno evolvendo ora verso i 16/32 bit quando già da tempo altri produttori producono piattaforme di sviluppo user friendly, di basso costo e con sistemi di sviluppo free) che al wire.

:yeah:
.

Il problema è che la ECU dello sterzo ha già delle soglie di intervento. E non sono progressive, nel senso che superata una certa velocità lo sterzo si indurisce. Io non posso cambiare le rampe. Lei ha già delle rampe di intervento, ma l'assistenza cambia superata una certa frequenza...non è a scatti...

Sent From My Note3

Ho scritto tutto mischiato...ci riprovo!

La ECU è già programmata per gestire la modalità di cambio assistenza. Ha già anche le rampe.
Quello che manca sono i segnali, che gli fornirò io!
Poco importa se la frequenza cambia senza una curva, perché la riduzione di assistenza non significa ritrovarsi con lo sterzo di un cacciamali senza idroguida!


Sent From My Note3

Scusa ma il nostro amico si è fermato al Basic. Quanto pensi che impieghi per imparate a programmare i DsPic?

Inoltre hai idea di quanto costi il sistema di sviluppo dei DsPic e il programmatore/debugger?

In passato ho programmato di tutto, Pic a 8bit, MSP430 a 16 bit, Freescale HCS12 a 16bit, ARM7 Philips a 32bit e per finire Arduino. Ho provato ed usato i più svariati IDE, compilatori e debugger hardware, quindi penso di avere una certa esperienza in merito.

Quello che a mio parere è necessario tenere in considerazione è:
1. La bassa esperienza che Fabry WRX3 sembra avere nel campo embedded
2. I costi di sviluppo (difficilmente potrà spendere 2000euro per comprare un IDE, un debugger e un compilatore), senza contare che poi bisogna come minimo aggiungere il costo di strumentazione da laboratorio come ad esempio l'oscilloscopio
3. Il tempo che potrà impiegare per arrivare al risultato finale (non penso che abbia a disposizione 8 ore al giorno per diverse settimane/mesi, per studiare come funzionano i DSP), ovvero il Time-To-Market
4. La disponibilità di piattaforme hardware low-cost preassemblate
5. Disponibilità di esempi e community di supporto

Leggendo l'ultimo intervento dell'amico mi pare che il problema sia risolto alla base visto che non servono algoritmi evoluti ed ha questo punto potrebbe risolvere con solo hw senza scrivere una riga di codice, comunque essendo un'applicazione critica credo che dovrebbe essere affrontata disponendo di conoscenze, budget e strumentazione adeguate, poi se al pilota del mezzo va di rischiare... .

Per puro scopo divulgativo mi permetto di confutare alcune tue affermazioni:
- l' IDE della Microchip MPLAB una volta ed oggi MPLAB-X è sempre stato gratuito, come pure la versione base dei compilatori MC8 MC16 o XC8,XC16 che si differenziano dalle versioni PRO solo per alcune ottimizzazioni del codice prodotto.
- i programmatore/debugger Microchip costano pochissimo (PICkit 3 e ICD 3 sono quotati 45€ e 185€ si trovano anche a meno o cloni economicissimi)
- per i PIC esistono centinaia di librerie, forum, risore in rete e milioni di programmatori validi.
- Esistono per i PIC un infinità di (mini) schede assemblate a basso costo (Olimex per citarne una).

Quanto sopra vale anche anche per i micro delle famiglie ST, TI, NXP, Cypress e con qualche limitazione anche per le altre marche.

La conoscenza del linguaggio C classico credo sia un must per ogni interessato a giocare seriamente con i microprocessori embedded ed essendo 'trasversale' a mio avviso vale la pena di investirci un po di tempo per studiarlo ed è meglio partire con il piede giusto piuttosto che scegliere la via più facile al momento.

Se il time to market è determinante e non si hanno le competenze adeguate per fornire la soluzione è meglio non accettare l'incarico od appoggiarsi a terzi più esperti.

Penso di conoscere il settore visto che mi ci guadagno la pagnotta da 45 anni, i primi programmi li ho scritti nel 1972..'74 su schede perforate ed i primi microprocessori con cui ho giocato erano a 4 bit. :wink:

:yeah:

Scusate.
Il sistema originale legge il sensore abs, o il sensore velocità del cambio.
Non c'è nessun microprocessore super mega figo a generare una frequenza, ne un algoritmo da NASA.
Non capisco per quale motivo pensate a cose complicatissime quando il sistema originale è la cosa più stupida che esista...
Non si sta parlando del sistema che comanda la farfalla elettronica, (che tra l'altro tutte le farfalle elettroniche hanno ingranaggi in plastica...) che se il sistema non funziona ti rimane aperta la farfalla e ti schianti (non a caso dopo i problemi avuti con toyota hanno inserito un sistema che nel caso si prema acceleratore e freno contemporaneamente viene tagliata l'alimentazione per farti
frenare).
Non la vedo così complicata o pericolosa.
Certo, questo non vuol dire che la cosa deve essere fatta alla carlona...ma se per assurdo riuscissi a replicare il sistema originale, con sensore abs...non ci sarebbero problemi.


Sent From My Note3

Diciamo che non era chiarissimo che lo sterzo era già dotato di una sua 'intelligenza'.

Facci sapere se hai eseguito le misure suggerite che così possiamo studiare come pilotare in tensione l'accrocchio.

:yeah:

Uhm...no dai, l'ho scritto più volte che lo sterzo ha una sua centralina che lo gestisce a livello di assistenza.
Quello che mancava erano i segnali, che ora invece ci sono. O perlomeno il segnale principale, RPM, c'è ed infatti lo sterzo finziona a meraviglia!
Manca da scegliere come comandare la variazione di assistenza, se mettere una fonica o cambiare assistenza in base alla marcia usando il pot che "vede" quale marcia è inserita.

Per le misurazioni...serve una frequenza tra 20 e 130 hz per attivarlo, il duty non è fattore importante, tensione 12v: tutto questo risolto, per ora, col 555.
Segnale a 12v con ritardo in On: fatto con 555.
Altro 12v sotto chiave
12v diretto.
Segnale velocità per cambio assistenza.

Ad oggi sevo solo decidere se affidarmi al 555 per gli RPM, e decidere come e se gestire l'assistenza...

Sent From My Note3