Istruzioni al secondo?

[dadduni]

salve a tutti,
ho un piccolo quesito del quale non mi ero mai preoccupato e adesso ci sono inciampato dentro con tutte le scarpe.
Microprocessore STM32 con clock a 72MHz(13.8ns) . Una sola interrupt a 50kHz (ogni 20us). Mi aspetterei che tra una interrupt e la seguente ci passasero 1449 colpi di clock. Okay che le istruzioni non sono monolitiche, okay che nel main c'è il ciclo while che esegue sempre lo stesso codice. Ma è possibile che se nel while incremento solo una variabile i, questa tra due interrupt consecutive incrementa solo di 64?
Se ho solo 64 operazioni disponibili nel main (e devo togliere il tempo delle interrupt) non ho speranza di fare signal processing a 50kHz, o sbaglio?
Mi permetto di taggare pusillus che so che lavora con questi oggetti
Davide

[EcoTan]

La ISR a sua volta cosa fa, nulla? Vai in release o in debug?
Come saprai ci sono casi che si risolvono meglio senza ISR...

[luxinterior]

Puoi aggiungere info sul modello dell'STM32
Interrupt e main code si dividono il processore hai misurato la durata dell'interrupt
Ovviamente non conosco la tua applicazione ma come dice EcoTan puoi adottare altre strategie ad esempio accumulare un buffer dati in DMA mentre tu elabori un buffer precedentemente acquisito.
ti copio anche un paragrafo di un manuale che spiega come configurare l'accesso alla flash (parla di M3 ma se cerchi nel refernce manual del tuo modello trovi informaizoni su flash buffer di prefetch ecc..)
When we looked at the system architecture of the STM32 we saw that the Cortex-M3 core is connected to the internal FLASH by a dedicated I-Bus. This bus is running at the same frequency as the CPU, so with the PLL enabled the core will be trying to run at the full 72 MHz. Since the Cortex CPU is essentially a single cycle machine, it will be trying to access the FLASH every 1.3ns. When the STM32 starts up it is running from the internal oscillator at 8 MHz, so the access time of the internal FLASH is not an issue. However, once the PLL is enabled and becomes the clock source, the FLASH access time is simply too long (35 ns.) to allow the Cortex CPU to run at maximum performance. In order to allow the Cortex CPU to run at 72 MHz with zero waitstates, the FLASH memory has a prefetch buffer which is made up of two 64-bit buffers. Both of these buffers can do a 64-bit-wide read of the FLASH memory and then pass the individual 16 or 32-bit instructions to the Cortex CPU for execution. This technique works well with the conditional execution features of the Thumb-2 instruction set and the branch prediction of the Cortex pipeline. During normal operation the programmer does not need to take any special precautions because of the FLASH buffer. However you must make sure that it is enabled before switching to the PLL as the main clock source. The FLASH buffer is controlled by the FLASH access control register. As well as enabling the prefetch buffer, you must tune the number of waitstates required for the FLASH prefetch buffer to read the 8 bytes of instructions from the FLASH memory. The latency settings are as follows:
0< SYSCLK <24MHz 0 waitstate
24< SYSCLK <48MHz 1 waitstate
48<SYSCLK <72MHz 2 waitstate
These waitstates are between the prefetch buffer and the FLASH memory and do not impact on the Cortex CPU. As the CPU is executing instructions held in the first half of the buffer, the second half is loading so that the CPU can seamlessly continue execution at its optimum rate.

[dadduni]

Grazie a tutti per le risposte, spero di cuore mi possiate aiutare e consigliare un altro po'
E' un progetto esclusivamente didattico, nessuna richiesta particolare, tutto autogestito tutto auto-modificabile.
STM32F103C6 (blue pill) con DAC SPI a 10bit, TLC5615.

L'idea è di campionare un segnale audio, probabilmente una chitarra, fare "una qualche forma" di Signal Processing, e portarlo all'ampli con il DAC.

Al momento ho, TIM3 che genera una interrupt a 50kHz, triggera automaticamente una lettura di ADC e avvia la srittura del dato dal DAC, così (immaginavo) di tirare fuori un dato ogni 50kHz e a fine trasmissione tornando nel main avere già la successiva lettura dell'ADC da poter manipolare fino alla prossima interrupt.

La comunicazione SPI non l' ho gestita con interrupt, ma in polling e devo aspettare la trasmissione di 16bit.

Il processore ha il clock a 72MHz, tutte le periferiche al massimo del clock possibile, non ho fatto nessun calcolo preliminare, ma speravo (speravo) che 72MHz di processore ce la facesse a gestire 50kHz di campionamento (ci sta un fattore 1000 di rapporto) e qualche piccolo filtraggio/modulazione.

Cosa ne pensate? In questi casi bisogna necessariamente migrare verso l'FPGA o ho ancora speranza di far funzionare il tutto?

[EcoTan]

Quello che ti so dire è che facendo un passaggio all'indietro di parecchi anni verso il dsPic33 troveresti ADC e DAC già a bordo senza bisogno di comunicare in SPI con dispositivi esterni, un compilatore C favoloso, un datasheet chiarissimo (a parte l'accodamento dei dati al DAC che non ho mai capito) ed un mare di code examples gratuiti ma molto sofisticati con uso del DMA.

[dadduni]

Io ho approcciato i microcontrollori da ragazzino con Arduino, poi ad elettronica con gli AVR della Atmel, e ho fatto "il salto" ai 32bit con gli STM32. Anche la ST fa bei micro con tutto a bordo e credo funzionino da paura, solo che a casa avevo questo e non punto ad una soluzione "elegante" o "facile". Ora mi sto solo divertendo a progettare e realizzare qualcosa con quello che ho, senza utilizzare librerie o cose prefatte ma facendo tutto a mano a livello più basso possibile.
Mi sa che il modo più facile per vedere le il micro ce la fa a fare quello che gli chiedo è scrivere il codice e verificare sul campo

[EcoTan]

Sì anch'io faccio così. Col dsPic33 ho fatto un frequency shifter audio che funziona discretamente tutto DIY programmato in C ma se vado a riguardarlo neanche io che l'ho fatto ci capisco granchè...
[youtube]https://www.youtube.com/watch?v=ygAQOkAzAPk[/youtube]
https://www.youtube.com/watch?v=ygAQOkAzAPk

[luxinterior]

Usare le periferiche interne al micro ovviamente aiuterebbe molto ad incrementare la velocità.
Ho visto il reference manual del micro hai la possibilità di definire un buffer circolare che puoi riempire automaticamente in DMA 50KHz a 16Bit sono 100Kbyte al secondo (...se non sbaglio)
Dividi il buffer circoalre in due parti mentre il DMA riempie una parte tu elabori la precedente e poi i ruoli si invertono.
Stima più o meno il tempo necessario all'elaborazione di un blocco
Durante l'eleaborazione il DMA acquisirà X campioni.
Dimensioni il buffer 2Xbytes + qualcosa di margine. (X li elabori X li riempie il DMA)

[pusillus]

Ciao,
Concordo con le considerazioni di Luxunterior. Probabilmente la SPI è il collo di bottiglia.
Scusa ma in questi giorni ho poco tempo libero. Sono uno di quelli che continua a lavorare e con tutti i protocolli di sicurezza da seguire i tempi si allungano.

[dadduni]

Signore e signori, sono lieto di annunciarvi che... CE LA FA.
Ho proprio voluto strafare, utilizzato brutalmente operazioni in floating point senza un briciolo di ottimizzazione né nulla. Si riesce a fare filtraggio passa alto per togliere la continua del centro dinamica dell' ADC, moulazione di ampiezza tipo tremolo, filtraggi di bassi ed alti e forse, spremendolo un po qualche risposta convoluzionale tipo eco (ma di questo non ne ho idea).
Al momento almeno ho la soddisfazione di avere un oggetto suonante e con qualche effetto a bordo. Prossimo passo dispay e pulsanti di selezione.

Grazie a tutti per l'aiuto, mi sono fasciato la testa molto prima di rompermela.

Davide