[C] Funzione di calcolo della radice quadrata di un intero

[Shockwaver]

E non solo...
La sta testando sul campo davanti ai suoi occhi, funzia alla grande, decide di condividerla con noi e tu che fai?? Gli vai a fare le pulci tirando fuori cose che tra l'altro non stanno in piedi????
Mah... ora capisco perché TardoFreak non voleva più essere un moderatore di questa sezione del forum. Mi auguro solo che riesca a farsi scivolar tutto di dosso e gli ritorni la voglia di condividere codice e realizzazioni... Perché io credo non riuscirei..

[eimiar]

Minchia se ti sei arrabbiato!
Caro Shockwaver, io le stesse tue considerazioni le ho fatte quando ho scritto il mio post
So benissimo che il mio benchmark non va bene, soprattutto sulla mia macchina che è quad core a più di 3 GHz e quant'altro, ma se permetti vorrei fare due considerazioni:

Anche se il sistema non è in real-time ed è pieno di threads e processi in esecuzione il mio benchmark non è proprio da buttare, perché è molto probabile che l'esecuzione di un programma piccolo come quello che ho scritto venga eseguito senza interruzioni di thread.
Quindi l'indicazione che si può estrarre da quel benchmark, l'unica utile, è che alcune funzioni sono veloci il doppio delle altre... Su un'architettura x86!

Poi hai totalmente ragione sul fatto che non c'è il minimo paragone tra queste due architetture perché una è MOLTO più ottimizzata dell'altra nello svolgere FLOPs.

Ma io non ho mai lavorato su microcontrollori! né ho mai detto di averlo fatto!
È per questo che sono interessato a sapere come performa la mia funzione su un microcontrollore. È sbagliato essere interessati?

Ho chiesto per cortesia se TardoFreak possa fare questo test non appena ha tempo così che io potessi capire, lo farei io stesso il test come tu mi consigli, ma ti ripeto: non possiedo un micro, tantomeno un oscilloscopio.

[Shockwaver]

Mi sono arrabbiato per via della tua insistenza nonostante tu stesso avessi detto che il tuo bench è fuori luogo e per via del fatto che l'unica risposta veramente elegante nei confronti di qualcuno che condivide del PROPRIO CODICE VALIDO è quella in [2].
E comunque hai ragione il tuo bench non è proprio da buttare, lo è proprio del tutto! Cercando di dimenticarsene il più in fretta possibile tra l'altro e dopo le 16.30 appena rimetto le mani sul computer ti faccio vedere perché senza bisogno di un benchmark.

[Shockwaver]

Eccoci qua.
Da premettere innanzitutto che ho dovuto prendere in considerazione una MCU paragonabile a quella di TardoFreak un PIC32 famiglia MX3.
A parte il fatto che a quanto sembra quell'algoritmo tanto caro agli sviluppatori di Q3A in collaborazione con quelli dell' id Tech 3 non è portabile sui microntrollori (credo abbia a che fare col "magic number" e la rappresentazione IEEE-754 ma non ho né il tempo né la voglia di controllare/approfondire), anche riadattando l'algoritmo per farlo funzionare, è evidente una differenza di 18 cicli tra un'implementazione e l'altra.
La limitazione dell'algoritmo sugli interi che può operare solo su... interi non ha alcuna influenza se chi la usa non ha bisogno di lavorare sui virgola mobile.

Over and out.

[Shockwaver]

Uff lo so che avevo detto passo e chiudo.. ma non riesco a smettere, per favore fermatemiiiii
Dimenticavo di far notare che ovviamente i cicli di istruzione nell'algoritmo sugli interi sono direttamente proporzionali alla dimensione dell'operando (a "scaglioni"), mentre nell'altro sono (quasi) fissi, quello di prima era il worst case... Guardare per credere.

Over and, I hope, out.

[TardoFreak]

E per concludere (magari a qualcuno che paciocca con gli stepper potrebbe interessare) questa è la routine per la gestione del movimento dello stepper con rampe di accelerazione e decelerazione con a=cost. dove uso la funzione oggetto della discussione.

Codice: Seleziona tutto

//-----------------------------------------------------------------------------------------------
// Spostamento di n passi con rampa di accelerazione e decelerazione
// n può essere sia positivo che negativo
void muovi(int32_t passi)
{
  int8_t direzione;
  uint32_t passiAcc, passiDec, passiCost;
  uint32_t i;
  uint32_t v;
 
  if (passi ==0) return;
 
  direzione = 1;
  if (passi < 0) { direzione = -1; passi = -passi; }
 
  // Calcola i passi di accelerazione, velocità costante e decelerazione
  if (passi > (lungRampa * 2))
  {
    passiAcc = passiDec = lungRampa;
    passiCost = passi - passiAcc - passiDec;
  }
  else
  {
    passiAcc = passi /2;
    passiDec = passi - passiAcc;
    passiCost = 0;
  }
 
  // Rampa di accelerazione
  for (i=0; i<passiAcc; i++)
  {
    // Calcola la velocità
    v = uintSqrt(2*accelerazione*i + velMin*velMin);
    // Muove il motore
    passoMotore(direzione);
    // genera ritardo
    setTimer1(10000/v);
    while(getTimer1() != 0) os_tsk_pass();
  }
   
  // Movimento a velocità costante
  for (i=1; i<(passiCost+1); i++)
  {
    passoMotore(direzione);
    // genera ritardo
    setTimer1(10000/velMax);
    while(getTimer1() != 0) os_tsk_pass();
  }
 
  // Rampa di decelerazione
  for(i=passiDec; i>0; i--)
  {
    // Calcola la velocità
    v = uintSqrt(2*accelerazione*i + velMin*velMin);
    // Muove il motore
    passoMotore(direzione);
    // genera ritardo
    setTimer1(10000/v);
    while(getTimer1() != 0) os_tsk_pass();
  }
 
  // Ritardo finale per stabilizzazione
  setTimer1(10000/velMin);
  while(getTimer1() != 0) os_tsk_pass();
}

//-----------------------------------------------------------------------------------------------
// Inizializzazione motore
static void initMotore(void)
{
  posMotore = 0;
  statoMotore = 0;
  setStatoMotore();
  // Calcola i parametri
 
  #ifdef FULL_STEP
  velMin = 50;           // step al secondo
  velMax = 800;          // step al secondo
  accelerazione = 4000;  // step al secondo quadrato
  #endif
  #ifdef HALF_STEP
  velMin = 100;           // step al secondo
  velMax = 1600;          // step al secondo
  accelerazione = 8000;   // step al secondo quadrato
  #endif
  lungRampa = (velMax*velMax - velMin*velMin) / (accelerazione * 2);
}

Le velocità sono espresse in
L' accelerazione in
La risoluzione del timer è
L' istruzione

Codice: Seleziona tutto

os_tsk_pass();

è utilizzata per rilasciare il controllo allo scheduler.


Le prove sono state fatte in questo modo:

Codice: Seleziona tutto

for(;;)
  {
    MOSPA_SX_PORT->BRR = MOSPA_SX_PIN;
    //i=sqrt(4281346624);
    i = uintSqrt(4281346624);
    //i = pow(4281346624, 0.5);
    MOSPA_SX_PORT->BSRR = MOSPA_SX_PIN;
    //i=sqrt(4281346624);
    i = uintSqrt(4281346624);
    //i = pow(4281346624, 0.5);
  }

Togliendo dai commenti e vedendo il periodo dell' onda quadra visualizzata sull' oscilloscopio (delle balle).

[eimiar]

Apprezzo lo sforzo, era tutto ciò che chiedevo.
Perdonatemi se non v'è piaciuto il mio atteggiamento ma non pensavo di provocare questo casino.
La mia insistenza era causata dalla mia ignoranza per non aver mai praticato con un microcontrollore, abbiate pazienza.
Spero che non ci siano rancori e ad ogni modo vi ringrazio per il tempo dedicatomi.

[TardoFreak]

Siamo in un forum tecnico,
Quindi nessun rancore ma attenzione e pignoleria per evitare di dare informazioni imprecise e/o fuorvianti.

Per quanto riguarda i microcontrollori c'è da dire che oggi sono macchine molto diverse dai personal computers, tablet ed altri prodotti. In effetti si assomigliano, è vero, ma la somiglianza la si può ritrovare più nei linguaggi utilizzati per scrivere i programmi (per fortuna dico io, il C è un dono del Signore ) che nella filosofia e nelle applicazioni che ci stanno dietro.
Il microcontrollore lo trovi dentro lo spazzolino da denti elettrico, nella gettoniera del distributore di bibite, nel riproduttore musicale MP3, nella lavatrice, negli elettrodomestici in genere, nelle centraline dei motori, nel pupazzetto che trovi dentro l' uovo di Pasqua e che ti suona la musichetta e via discorrendo.
E' una macchina a programma ma la somiglianza con un personal computer non va oltre, anche se è vero che molto probabilmente l' evoluzione tecnologica li avvicinerà sempre di più.
Per semplificare: se quando si acquista un personal computer si presta attenzione alle prestazioni, quando si sceglie un micro lo si fa prestando attenzione al prezzo. Se il PC deve funzionare bene il micro non deve costare.
Questo significa avere a che fare con limitazioni in termini di memoria di programma, potenza di calcolo e memoria dati a volte notevoli (gli 8 bit per esempio). Oppure ci si trova con oggetti potenti, discretamente dotati, poco costosi ma tremendamente complicati (come i 32 bit).
Adottare un micro o un altro è sempre il risultato di compromessi ma il fine è sempre uno solo: produrre un oggetto al minor costo possibile, che sia affidabile (o comunque che non dia problemi in produzione) e possibilmente rapidamente. Ma non c'è una regola generale: dipende sempre dall' applicazione.
Prendiamo un caso reale: quello che sto facendo ora.
Uso un micro che costa molto poco, molto potente rispetto al prezzo ma complicato ed oneroso da utilizzare (i sistemi di sviluppo non te li regalano ma li paghi bei soldi). Una sorta di motore da formula 1, complicato come un motore da gara, ma che sviluppa solo un centinaio di cavalli, venduto a meno di un motore da tosaerba.
Non so che tipo di stepper gli dovrò far comandare, se userò un driver apposta o se opterò per una soluzione a componenti discreti per abbattere i costi, non so che carico meccanico dovrà pilotare e dovrò fare parecchie messe a punto. Non ho un team di ingegneri ma sono da solo a lavorare e quindi, visto che il micro me lo permette (fino ad un certo punto) cerco di sfruttare la sua intrinseca potenza per rendermi la vita semplice.
Poi magari succederà che dovrò produrre un solo tipo di apparecchiatura ed allora rifarò il progetto con il preciso scopo di abbattere ulteriormente i costi. Probabilmente non calcolerò più niente ma mi farò le tabelle come indicato da DirtyDeeds da implementare su di un carciofo lento come una mucca con l' artrite.
Magari il programma lo dovrò scrivere in assembly o in un linguaggio che non conosco, o in Java o in Sumatra o in Barbados ... in "bananix" ... chi può dirlo? Prenderò quello che passa il convento.

Ciò detto,

Uno degli scopi di questa sezione è di raccogliere del codice che può essere utile nello sviluppo dei programmi di questi aggeggi quindi, da come la vedo io, qualsiasi contributo sviluppato sul campo, provato e funzionante e messo a disposizione è un qualcosa che potenzialmente può rendere la vita meno complicata.
A volte non sono le soluzioni più eleganti, a volte sono delle vere e proprie manovalate che però risolvono un problema.
Ricordo di aver postato le funzioni per sintetizzare un bus I2C utilizzando dei semplici pin di I/O e facendo tutto tramite programma. A me ha risolto un problema e potrebbe essere la soluzione per un altro utente che è costretto ad utilizzare un micro che non dispone della periferica I2C. Non è il top ma funziona.

In buona sostanza l' idea di scambiarsi del codice funzionante la vedo come un modo per cooperare con il solo fine di riuscire a risparmiare un' oretta da dedicare a gli affetti o alla famiglia per esempio, un modo per non ritrovarsi sempre da soli ad affrontare un problema che altri hanno già risolto.
Per questo motivo (ed altri legati al momentaccio che sto passando) non vedo di buon' occhio il "fare le pulci" ed auspico partecipazione attiva.

[Shockwaver]

Nessun rancore.

[WALTERmwp]

Dopo aver seguito la discussione, arrivato a questo punto, al netto delle considerazioni sulle funzioni, credo che quanto riportato da TardoFreak da qui ...

Per quanto riguarda i microcontrollori

a qui ...

Prenderò quello che passa il convento.

... sia un prezioso compendio d'integrazione, d'affiancare a quelli "tecnici": bello !
La sintesi di una realtà.
Per quello che segue stavo aggiungendo un altro commento ma penso "parli" da sè.
Saluti