PICs overklokken

Wordt hij dan niet warm bij zo een hoge klokfrequentie?

Volgens mij heb je voor overklokken "noodzakelijk" wordt al heel erg veel fout gedaan. Het overklokken zelf is dan de zoveelste fout op rij. Niet iets waar we graag mee lopen te pronken dus.

nee, na 15 minuten op 66 MHz niks van warm worden gemerkt, maarja, de chip zelf is erg klein en zit in een DIP-8 behuizing, dus kan zijn warmte wel kwijt. Zal eens wat uitgebreider meten vanavond, opgenomen stroom enzo.

edit:
@GJ: gaat er niet om of ik moet overklokken, 't ging me er gewoon om eens wat uit te proberen. Zeg maar uit nieuwsgierigheid. 't is voor de hobby, niet voor de baas, als't voor de baas is, dan nemen we gewoon een zwaardere PIC die het wel aankan.

Waar ik aan denk bij problemen met overklokken is dat een A/D omzetter, of een UART, ofzo niet meer meekomt.

overigens, 66MHz klokfrequentie betekent 66/4 MHz instructiecycle bij de PIC.

[Bericht gewijzigd door DC2PCC op woensdag 6 september 2006 09:29:49 ]

Stap gewoon over op een AVR controller, een AVR geklokt op 20MHz loopt minstens net zo snel als een PIC op 80MHz

[offtopic]hier ergens begint de AMD - intelstrijd? [/offtopic]

@xeno:

inderdaad, een 20 MHz ATMEL zou zo net zo snel zijn als een 80 MHz PIC. Maar daar gaat het me niet om, overigens, doet die atmel het ook nog bij 80 MHz ??

@erminJ: Nee, da's niet de bedoeling om weer een AVR-PIC strijd uit te gaan vechten hier.

[Bericht gewijzigd door DC2PCC op woensdag 6 september 2006 09:31:33 ]

wel intresant topic,
ik kan aleen aan gj's post geen touw aan vast knopen wat ie daar mee bedoelt .

te maken met het proberen van buiten specificaties niet iets om mee te pronken ? "veel fout gedaan" ?

:s snap nie ik , jij bedoel wat ?
terug in bed niks doen vooral niet ademen ?

ik vind het wel intresant om te weten bij welke snelheden een pic bv nog werkt en meschien keer uitbereiden met iets wat kan kijken of ie al fouten gaat maken ofzo 66 mhz is wel leuk maar als ie dan helft van de tijd fouten genereert heb je er nog niet zoveel aan

Jup, ik heb wel eens een pic op een hogere clock "misbruikt", omdat anders de tijd voor de beeldopbouw van een scope clock te lang zou duren.

Ik is een groot woord hierin, de code en het idee kamen van iemand anders

[Bericht gewijzigd door Sine op woensdag 6 september 2006 10:33:09 ]

Post is verhuisd naar:
http://www.circuitsonline.net/forum/view/38466

@DC2PCC
Overclocken heeft volgens mij weinig zin. Net als computers, mag het lijken of alles goed gaat, maar de kans blijft dat ie flipt. En dat gebeurt meestal waneer je dat niet wil. Werken buite de specs maakt je controller instabiel, ook al lijkt hij prima te funktioneren.

[Bericht gewijzigd door chipje op donderdag 7 september 2006 11:34:53 ]

Op 6 september 2006 09:25:25 schreef GJ_:
Volgens mij heb je voor overklokken "noodzakelijk" wordt al heel erg veel fout gedaan. Het overklokken zelf is dan de zoveelste fout op rij. Niet iets waar we graag mee lopen te pronken dus.

GJ,
doel je daarmee op de wijze van (inefficient) programeren ?

Zelf heb ik nooit CPU's boven de voorgeschreven snelheid laten rammelen.
maar ik zag laats dat iemand een DDS had gemaakt met een PIC
Wil je daar echt lol van hebben heb je wel een heel snelle pic nodig anders schiet het nog niet op.

Op 6 september 2006 11:19:07 schreef chipje:
Alleen zie ik in een datasheet dat een (RISC!) avr 100+ instructies heeft, tegenover maar 35 bij een PIC. Klopt dat? Maakt asm programmeren ook niet makkelijker.

Het programmeren gaat heel gemakkelijk vind ik, en als je er een beetje mee overweg kunt, kun je zelfs BASIC-commands maken in asm.

poort als output?

ldi temp, 0b11111111
out ddrb, temp

for temp = 5 to 128
...
next?

ldi temp, 5

teller:
inc temp
out portb, temp
sbrs temp, 128
rjmp teller

En veel instructies lijken sterk op elkaar

-sbr, cbr dienen om bits te setten/clearen in een register.
-sbi, cbi dienen om bits te setten/clearen voor de poorten.

[Bericht gewijzigd door Ununoctium op woensdag 6 september 2006 11:45:11 ]

Op 6 september 2006 10:32:36 schreef Sine:
Jup, ik heb wel eens een pic op een hogere clock "misbruikt", omdat anders de tijd voor de beeldopbouw van een scope clock te lang zou duren.

Ik is een groot woord hierin, de code en het idee kamen van iemand anders

kijk, dat soort dingen bedoel ik dus, sine, vraagje, welke PIC was dat en hoe snel liep die na overklokken ??

@_GJ: 't gaat niet om het programmeren, dat gaat zowiezo in ASM, omdat voor die kleine PICs geen fatsoenlijke C-krompiler bestaat. Ik ben gisteravond een beetje aan het klooien gegaan, omdat ik in zo'n klein picje een testbeeldgenerator voor TV-signalen wil proppen, en voor een 1MHz pixel clock de pic toch wel ietsje sneller moet lopen, om de patronen te berekenen.
bij 66 MHz werkt die pic12F509 nog steeds.

Op 6 september 2006 11:19:07 schreef chipje:
[... geblaat over atmel vs. PIC ...]
@DC2PCC
Overclocken heeft volgens mij weinig zin. Net als computers, mag het lijken of alles goed gaat, maar de kans blijft dat ie flipt. En dat gebeurt meestal waneer je dat niet wil. Werken buite de specs maakt je controller instabiel, ook al lijkt hij prima te funktioneren.

Dat wil ik dus uitvissen, misschien doet een A/D omzetter (zit niet in de 12F509 en 16F505) het niet meer goed dan, of de uart (hebben de 12F509 en 16F505 ook niet).
en voordat ik daar zelf het wiel ga uitvinden, misschien eens hier vragen, je weet maar nooit. Er zullen best meer mensen op dat idee gekomen zijn (en idd. zie post Sine)

Op 6 september 2006 09:25:25 schreef GJ_:
Volgens mij heb je voor overklokken "noodzakelijk" wordt al heel erg veel fout gedaan...

Het begin van een projekt is het vastleggen van het doel van het projekt. Tijdens de engineering moet duidelijk worden of de ingeslagen weg er toe zal leiden dat het doel ook werkelijk bereikt gaat worden. Als een projekt daar al fout loopt door bijvoorbeeld een verkeerde componentkeuze of door de taken verkeerd over de diverse componenten te verdelen heb je toch nogal wat over het hoofd gezien dacht ik zo.
De problemen die in een eerder stadium zijn ontstaan later "oplappen" maakt dat je de problemen eigenlijk voor je uitschuift. Dikke kans dat je ze later toch weer op je bordje krijgt, in dit geval door bv kapotte of slecht functionerende PIC's.
De enige manier is denk ik terug naar de tekentafel en een goede oplossing bedenken.

Maar, een beetje klooien en hobbien met het overklokken van een PIC van 2,50 kan natuurlijk ook best leerzaam en/of leuk zijn. Als dat het oorspronkelijk doel was heb ik natuurlijk niks gezegd.

Op 6 september 2006 13:40:24 schreef GJ_:
[...]

Maar, een beetje klooien en hobbien met het overklokken van een PIC van 2,50 kan natuurlijk ook best leerzaam en/of leuk zijn. Als dat het oorspronkelijk doel was heb ik natuurlijk niks gezegd.

't is inderdaad om te hobbyen, en niet voor de baas, daar gebruiken we nu de PIC24 serie en dsPIC33.

Daarnaast nog beesten als de 80C166 en TMS320 nogwat.
Die beide zijn industriestandaard.

Voor het 'kleinere werk' zoeken we nu een goedkopere controllerfamilie. Daar de PICs ook aardig volwassen beginnen te worden (pic24 serie) hebben we die erbij genomen, en daar wordt inderdaad wel gekeken naar de specs. (en natuurlijk de prijs, die wezenlijk gunstiger ligt als van die 80166 of TMS320 beesten.)

Thuis ben ik dan nog af en toe bezig met kleine picjes, zeg maar het andere uiteinde van de familie.
(overigens betaal ik voor een 12F509 minder dan een euro hoor)

als gj doelt op het feit dat overclockte programma's niet echt een betraubaare functie hebben naast dat "het kan"
heeft ie er natuurlijk gewoon 100% gelijk .
eveneens als ie zegt dat je waarschijnlijk constant dingen moet oplossen die specifiek aleen door dit probleem zullen komen.

ikzelf heb ook eens gekeken naar die video signialen generen maar kwam zelf tot de conclusie dat 20 mhz pic's daar niet veel te bieden heeft naast het gewoone expirimenteer werk

meschien dat de 40mhz pics al betere oplossingen zijn
en als je een van de weinige pic en video tutorials heb gelezen was je er ook vast wel achter dat je erg snel gelimiteerd gaat worden met wat je tevoorschijn kan toveren

neemt niet weg dat mocht je een nieuwe specifiekere topic aan gaan wijden icm pics ik het zeker met intresse zal gaan volgen.

Op 6 september 2006 13:55:04 schreef sould3mon:
als gj doelt op het feit dat overclockte programma's niet echt een betraubaare functie hebben naast dat "het kan"
heeft ie er natuurlijk gewoon 100% gelijk .
eveneens als ie zegt dat je waarschijnlijk constant dingen moet oplossen die specifiek aleen door dit probleem zullen komen.

Zoals ik al zei, het gaat me er niet om om zo een officiele toepassing te programmeren voor de baas, maar meer om te experimenteren met pics op hogere klokfrequenties, voor de hobby.

ikzelf heb ook eens gekeken naar die video signialen generen maar kwam zelf tot de conclusie dat 20 mhz pic's daar niet veel te bieden heeft naast het gewoone expirimenteer werk

hmm, het kan ook met discrete poortjes, maar bouw zo eens een compleet composiet-synchroon-signaal op, met alle egalisatiepulsen erbij, dan ben je blij als een picje dat voor je doet (en daarvoor kan-ie gewoon op 4 MHz lopen hoor. ok, de timings kloppen dan niet 100% meer, maar het id. alleen al de syncpulsen met discrete logica te gaan opwekken) en kom niet met FPGA, want dat is naar mijn mening overkill.

meschien dat de 40mhz pics al betere oplossingen zijn
en als je een van de weinige pic en video tutorials heb gelezen was je er ook vast wel achter dat je erg snel gelimiteerd gaat worden met wat je tevoorschijn kan toveren

neemt niet weg dat mocht je een nieuwe specifiekere topic aan gaan wijden icm pics ik het zeker met intresse zal gaan volgen.

Precies daarmee wil ik eens gaan experimenteren, met een pic geklokt op 40MHz een videosignaaltje genereren.
specifiek topic, hmm, weet niet, eens zien wat de experimenten opleveren.

@_GJ: Als ik alles altijd exact volgens specificaties maak dan is dat voor mij geen experimenteren meer. Als iedereen dat zou doen dan werd er veel minder ontdekt volgens mij, het leuke van ontdekken is juist dat je je niet aan de specs houdt en kijkt wat er gebeurt, ik mag dan ook graag aan Free_electron referen met de spreuk/formule:
Experience*KnowHow=Destroyed Components + Time.
Als we alles maar zo gebruiken als gespecd is, dan is Destroyed components gelijk 0, en de tijd die je daaraan besteed hebt ook gelijk 0

Toen columbus via het westen naar india wilde varen heeft-ie ook de specificaties van de toen geldende landkaarten niet aangehouden, en amerika ontdekt.

Je zult best een eind komen qua frequenties... maar steeds meer kans dat het niet meer werkt over het hele temp/voltagebereik.

Ik denk trouwens dat het ding eerder flipt dan echt stuk gaat, dus vrij safe om ff te testen.

[Bericht gewijzigd door Ben_ op woensdag 6 september 2006 14:08:20 ]

Ik heb regelmatig een PIC overgeklokt, bijv. een 18F252 op 48 Mhz. Daarmee nooit problemen ondervonden, maar meer dan 25% ben ik niet over de limiet gegaan (ook al ken ik enkelen die rustig 2X de maximale klok gebruiken), maar af en toe (zoals bij een software DDS) kwam ik net niet uit met de grens uit het datasheet en loste een iets hogere klok het probleem op.
Bij mij was de voedingspanning wel altijd netjes 5 Volt. Als je ook de grenzen van de temperatuur en spanning gaat opzoeken zou het wat minder betrouwbaar kunnen worden.

Op 6 september 2006 13:21:36 schreef DC2PCC:
[...]
@_GJ: 't gaat niet om het programmeren, dat gaat zowiezo in ASM, omdat voor die kleine PICs geen fatsoenlijke C-krompiler bestaat.
[...]

Al microC (gratis tot 2k code) bekeken? Ik ken alleen maar mikroBasic, maar vind em erg goed.

Op 7 september 2006 10:16:08 schreef Videomodulator:
[...]Al microC (gratis tot 2k code) bekeken? Ik ken alleen maar mikroBasic, maar vind em erg goed.

Hmm, ik ben zowiezo niet zo'n liefhebber van C op microcontrollers, daar gaat eigenlijk niks boven plain assembly. Ik hoef in mijn applicaties geen drijvende komma getallen te bewerken, en de rest, pinnetjes hoog en laag maken, bitjes schuiven etc. gaat net zo goed in assembler als in C. Volgende probleem is dat ik vaan controllers inzet die helemaal niet zo veel geheugen aan boord hebben (0,5K of 1K) en dat optimaal te benutten betekent meestal dan toch gebruik maken van assembler, om hier en daar optimaal te coderen.

De kleine PICs (pic12/16) hebben geen hardware vermenigvuldiger aan boord, dat betekent dat je dan een schuif- en optel routine moet schrijven. In assembler, waar ik ze zelf schrijf kan ik ze zo aanpassen dat het mij 'past' (code-geoptimaliseerd of snelheid-geoptimaliseerd) bij een C-krompiler moet ik altijd maar afwachten wat de krompiler er van maakt.

en een ander nadeel is dat ik geen boekhouder ben, en C-programmeren gelijk staat met boekhouden, je moet overal een puntkomma achter zetten en je accolades moeten kloppen.
Vergeet je op regel 3 een puntkomma, dan krijg je op regel 10 een foutmelding terug van de krompiler dat er iets niet klopt in regel 10, de eigenlijke fout zit echter in regel 3 (puntkomma vergeten). Daar zoek ik me altijd wezenloos naar.

Ik ben juist weer erg gek op C, ook voor de wat kleinere uC. Mijn keuze is behalve historiesch ook praktisch:
Ik heb geen zin om al die verschillende assembler talen te leren. Ik gebruik o.a. PIC's, 8052, ARM uC. Als ik deze allemaal in assembler moet programmeren zou ik helemaal gek worden. Ik hou het liever bij 1 taal (C dus). Zo kan ik ook code (algoritmes) ook makkelijker porten naar andere uC's. B.v. het aansturen van een I2C LCD'tje. De bovenlaag is voor alle uC gelijk (lcd_init(), lcd_send_string() etc.), alleen de implementatie van de 'driver' is anders.
En ja, een in C geschreven prog heeft meer geheugen nodig dan een ASM progje, maar dan koop ik gewoon een grotere controller, een PIC16F648 i.p.v. PIC16F628. Het prijsverschil is meestal niet zo groot.
Oja en op de PC programeer ik ook veel C(++), ook beroepsmatig, dus de keus voor C is voor mij erg logies.

Op 7 september 2006 11:51:25 schreef Lexy:
Ik ben juist weer erg gek op C, ook voor de wat kleinere uC. Mijn keuze is behalve historiesch ook praktisch:
Ik heb geen zin om al die verschillende assembler talen te leren. Ik gebruik o.a. PIC's, 8052, ARM uC. Als ik deze allemaal in assembler moet programmeren zou ik helemaal gek worden.

Dat vind ik nou juist weer leuk, de verschillende dialecten van de verschillende controllers.
en je weet ook beter wat er in de controller zelf zit.

Maar het topic ging eigenlijk over overklokken van PICs

misschien ook mensen die wat over overklokken van AVRs willen vertellen

http://www.epemag.wimborne.co.uk/0406.htm
in dit nummer stonden er een paar goed uitgewerkte voorbeeldjes met grafiekjes over het "overclocken" van pic's, temperatuur t.o.v. tijd enz.
helemaal vanonder op de webpagina staat he "PIC n MIX: experimenting with overclocking PICs"
stonden wel wat leuke resultaten.