Io pensavo che i chip che progetta rf ,come tutte le sue cose, andassero a gettone.
Io pensavo che i chip che progetta rf ,come tutte le sue cose, andassero a gettone.
sisi ovviamente vabbè alla fine lo schema non l'ho disegnato io e non certo lo correggo..però lo so e cmq funziona questa configurazione!
Quando Chuck commenta , lui che è altissimo, è perche' ha la conoscienza intrinseca
io credo che su phat dare tensione al pin 7 sia inutile visto che viene data già una tensione a questo pin pari a 1,8v-0,6V della soglia del diodo
nel post che ho scritto prima quando leggi "VA COLLEGATO" significa che quel pin non va lasciato floating. Se tu colleghi l'anodo del diodo a una tensione di 1,8V ed il catodo al pin del CPLD, su quel pin ci sarà una tensione pari a 1,8V meno la caduta di tensione del diodo (che con le correnti in gioco non arriva a 0,6V ma è di circa 0,4V)... hai fornito comunque un'alimentazione al pin = non lo hai lasciato floating = l'hai collegato.
perchè sulle fat va messo il diodo tra il pin 15 (1,8V) ed il pin 7, mentre sulle slim vanno collegati direttamente? perchè sulle fat tutti i pin di I/O del banco1 devono lavorare a circa 1,5V, mentre sulle slim devono lavorare a 1,8V... potete controllare questa cosa aprendo i file .ucf con un editor di testo
Solo per la cronaca volevo informarvi che ho montato il glitchip autocostruito (con tanto di led di debug blu sul frontalino, grazie Raiden per la guida) al posto di un TX CoolRunner revB. L'unico fix usato è il classico condensatore da 270pF in parallelo su CPU_RST e punto alternativo FT3N2 per il STBY_CLK (utilizzato per entrambi i glitchip). Inizialmente (a freddo) c'ha messo un po' a glitchare. Ma poi gli avvii successivi mi sembravano tutti fulminei. Stranamente mi sembra che si sia velocizzata dopo la chiusura, cosa alquanto inusuale perché di solito molti utenti riferiscono che dopo la chiusura della console i tempi di boot si allungano di un po'. Comunque ancora non ho avuto tempo per un calcolo del tempo medio di boot. Appena posso, faccio delle prove. Il tempo medio di boot del TX Coolrunner revB, sempre sulla stessa console, era di 28s.
Ci tenevo a ringraziare tutti quelli che hanno partecipato a questo thread, grazie!
Niente, speravo che con il glitchip light migliorasse nei tempi di avvio, invece siamo sempre là. Ora il tempo medio è di 31s, pressapoco il medesimo di prima (3s in più rispetto a prima). Preciso che è una Trinity. Potrei provare a sistemare meglio il filo del CPU_RST, però non ho tanta voglia, penso che la lascerò così o al limite proverò più avanti, quando avrò del tempo libero.
Una domanda di carattere tecnico: il glitchip, dopo che la console ha bootato, non serve a nulla o continua sempre a svolgere il suo lavoro finché non viene spenta?
Dopo che ha glitchato il glitchip si mette in pausa a girarsi i pollici (non scherzo, dopo il gitch si disattiva, in attesa che la console venga accesa di nuovo o venga riavviata).
Grazie della risposta ilario. Ma perché allora alcune volte a qualcuno che aveva problemi di freeze qui sul forum è stato detto di controllare le saldature? Se il cpld si disattiva non dovrebbe dipendere da quello, giusto?
Inviato dal mio GT-I8150 usando Tapatalk
rf ha cominciato ad andare "a gettoni" quando ha visto che la gente se ne approfittava spudoratamente..
Tornando IT: non è sempre detto che una versione "Light" funzioni meglio di una più articolata.. i segnali in gioco devono essere più precisi possibile..
A volte, un condensatore (o una resistenza) nel posto giusto fa la differenza. A me, per esempio, riesce meglio con 220pF su RST..
Inviato dal mio Galaxy Nexus con Tapatalk 2
"... quando il domani verrà, il tuo domani sarà!"
Lungi da me offendere qualcuno, generare flame o andare OT!
Non so a cosa alludi, ma se è a quello che penso non credo comunque che sia bello (e corretto) etichettarlo come una "cabina telefonica" solo per aver intrapreso una strada anziché un'altra. In fondo, chi di noi (chi più, chi meno) non va un pó a gettoni??
Inviato dal mio Galaxy Nexus con Tapatalk 2
"... quando il domani verrà, il tuo domani sarà!"
Ma che, tranquillo, qua puoi esprimere le tue idee senza remora no navendo paura di offendere ne di flammare una cosa che nasce nella trasparenza con il diretto interessato,volevo solo farti presente la differenza fra chi incula a soldi e chi ritiene giusto essere remunerato per quella conoscienza che ha.
Io penso di essere corretto e poter dire quel che cazzo mi pare (nel rispetto e senza offendere nessuno beninteso) proprio per la trasparenza che penso di aver avuto.
Se ti interessa, RF sa come la penso, non lo ho offeso , e non penso nel fondo del suo cuore e del suo cervello, sia stato felice della "strada intrapresa" a suo tempo. Magari ha riparato un po' il tetto.... ma dall'altra parte sono sicuro sarebbe stato piu' felice se avesse continuato a fare scrivere i post in staff alla sua bambina mentre lui gli dettava le parole, come ai bei tempi. Ma è un parere mio....
Purtroppo ci son ferite che si rimarginano male, e lentamente.....
Ci può anche stare (e non ho detto che condivido in toto!).. ma fa tutto un altro effetto rispetto alla frase di chuck, specie agli occhi di chi non lo conosce!
i freeze si creano perché ti ritrovi cmq con fili "volanti" saldati a certi punti della console e da quì la console può captare interferenze e rumori. difatti la maggior parte delle volte i freeze si presentavano sulle fat senza condesatore da 100nF sul pll_bypass. il condensatore (come ben noto) tende a smorzare le variazioni di segnale quindi ha l'effetto di abbattere il rumore captato dal filo "volante". Anche i punti di saldature se fatti male generano rumore.
purtroppo si formano circuiti rlc parassiti ovunque
Segnalibri