- This topic has 8 replies, 2 voices, and was last updated 8 years, 7 months ago by
.
-
Posts
-
Ciao Carmine, a pag. 212 proponi un esercizio che tratta la gestione degli interrupts, a tal proposito volevo chiederti come faccio materialmente a mettere in stato “low” PB2 affinche’ EXTI2_IRQHandler() possa far partire una richiesta di interrupt e portare blink a 0? Ho individuato sul Morpho Headers la posizione di PB2 della mia board (Nucleo F401RE) ma non so come mandare un input a questo pin.
Grazie come sempre.
Ciao
DavideCiao Davide,
ho scelto il PB2 nell’esercizio perché se vedi è adiacente a un pin connesso alla GND, quindi ti basta un qualcosa che faccia da corto (puoi anche usare un jumper con spaziatura da 2.54mm).
Carmine
Carmine ho provato a cortocircuitare i pin corripondenti alla PB2 e al Ground (pin 22 e 20 per la scheda nucleo F401RE, in pratica i pin esterni 9 e 10 contati dal basso) come consgiliavi tu ma di fatto non accade nulla e il led ld2 continua a lampeggiare. Invece, cosa strana, se provo a cortocircuitare i pin 20 e 18 (ground e NC, quest’ultimo non so cosa sia) il led smette di lampeggiare.
Secondo cosa succede?Grazie
DavideCarmine ho provato a sostituire nella riga 83 (sempre dello stesso codice a pag 211) la dicitura GPIO_PIN_4 con GPIO_PIN_2 pensando che ci fosse un errore di stampa nel codice (spero di aver fatto bene…) ma anche dopo questa correzione non accade nulla, quando metto in corto i pin relativi a PB2 ed a GND il led continua a lampeggiare.
Help me.Grazie
DavideEccomi.
Hai ragione, il codice nel libro è sbagliato!!! Fai riferimento agli esempi del libro per il codice corretto (https://github.com/cnoviello/mastering-stm32/blob/master/nucleo-f401RE/src/ch7/main-ex3.c).
In pratica, è sbagliato alla line 83: non è il 4 ma il 2!
Ciao Carmine, come ti scrivevo ieri mi era venuto il dubbio che ci fosse un errore di stampa e cosi’ avevo corretto la linea 83 ma comunque le gestione degli interrupt non andava, quando mettevo a 0 il PB2 il led continuava a blinkare. Poi mi sono accorto (ed il codice che mi hai inviato me lo ha confermato) che c’era un altro errore nell’impostazione dei preemption priority levels che erano settati a 0x8 e 0x4 per un set di HAL_NVIC_SetPriorityGrouping = NVIC_PRIORITYGROUP_1. Quindi guardando anche il codice che mi hai girato ho cambiato i preemption priority levels rispettivamente a 0x1 e 0x0 ed adesso sembra funzionare tutto bene. L’unica perplessita’ che mi resta e’ che di fatto non ho bisogno cortocircuitare i pin corripondenti alla PB2 e al Ground mi basta solo toccare con un filo di rame il pin corrispondente alla PB2 ed il led smette di lampeggiare. Secondo te perche’?
Grazie Carmine
Davide
Si hai ragione, anche quello è un errore. Purtroppo all’epoca ci fu un problema con i sorgenti degli esempi (gli esempi nel testo del libro sono generati automaticamente dagli esempi, non sto qui a spiegare come….). Nella prossima release si sistemerà tutto.
Venendo alla tua domanda, ci sono due motivi per cui ciò succede:
- Tutti i più recenti STM32 hanno un forte indirizzo verso il “low-power”, anche quelli non della serie “L”. Le resistenze di pull-up/down interne sono molto alte, per ridurre i leak, e quindi gli I/O sono “poco tirati” (lasciami passare il termine) verso massa/VDD e basta poco per far “fluttuare” lo stato logico della porta.
- Il codice non applica alcuna politica di debouncing, e quindi una transitoria fluttuazione dell’I/O (indotta dal fatto che ti basta toccare il pin) non viene adeguatamente gestita e “ignorata”. Ci sono vari modi per fare questo: o tramite hardware (un trigger di schmitt in genere fa il suo lavoro) o software (ad esempio, usando come pin di input un canale di un timer in modalità input capture sui cui è stato anche definito un filtro adeguato (vedi capitolo 11).
- You must be logged in to reply to this topic.