PIC16F88 internal OSC

Ik ben bezig met een PIC16F88. Dit is een PIC die ik nog nooit gebruikt heb, dus ik zit sowieso een beetje te goochelen met configuratiebits.
Nu wil ik dat ie draait op 8MHz intern, maar dat wil maar niet lukken.
In de errata van de datasheet zie ik problemen omtrent deze configuratie voorbij komen, maar het lijkt er op dat dat te maken heeft met een switchen van clockfrequentie tijdens executing.
Maar goed, ik krijg de 8MHz er niet uitgeperst, dus doe wat fout.
Mijn settings mbt de oscillator:


__CONFIG  _CONFIG1, _INTRC_CLKOUT

SwitchToBank1
movlw	b'01110010'	;Internal RC for clock	
movwf	OSCCON		;F = 8MHz

Ik hoop dat iemand mij kan vertellen hoe ik die 8MHz er uit krijg..

Excuses..deze topic was niet nodig.
Na uren van zoeken en lezen kom ik er achter dat ik een label verkeerd had staan, waardoor de instructie mbt OSCCON domweg overgeslagen werd...
Mijn god..daar ben ik dan 7 uur naar op zoek geweest...

De praktijk is een harde leermeester ;)
Dit soort flutproblemen kun je vaak mooi zien in een simulator.

Mijn god..daar ben ik dan 7 uur naar op zoek geweest...

Een voordeel: dit gaat je niet nog een keer overkomen :)

Ik weet het..
Het was ook zo ongelooflijk suf..de simulator had ik reeds gebruikt om m'n code te testen. Dat was in orde.
Toen heb ik die twee regels mbt OSCCON erbij gestopt. Simuleren zou onzin zijn, omdat je dat in de simulator toch niet gesimuleerd krijgt.
Tja..en dan ga je dingen over het hoofd zien...

Op 2 november 2005 11:58:31 schreef gradtje:
Dit soort flutproblemen kun je vaak mooi zien in een simulator.

De meeste flutproblemen zie je trouwens NIET met de simulator (Timing kritische meuk met externe hardware aan je pic, of de configuratiefuses verkeerd instellen)

Op 2 november 2005 12:09:43 schreef Marco69:
[...]Een voordeel: dit gaat je niet nog een keer overkomen :)

Wedden van wel? :)

Op 2 november 2005 12:17:39 schreef JoWi:
[...]
De meeste flutproblemen zie je trouwens NIET met de simulator (Timing kritische meuk met externe hardware aan je pic, of de configuratiefuses verkeerd instellen)

Dat schaar ik niet meer onder flutproblemen, das echte shit ;)

geeft je comp[iler geen warnings als je ongedefinieerde symbolen gebruikt ? of als je dead code hebt ( code die nooit uitgevoerd word ) ? of lees je het compilation rapport niet ?

[Bericht gewijzigd door free_electron op ]

Op 4 november 2005 01:19:39 schreef free_electron:
geeft je comp[iler geen warnings als je ongedefinieerde symbolen gebruikt ? of als je dead code hebt ( code die nooit uitgevoerd word ) ? of lees je het compilation rapport niet ?

Assembler is wat dat aangaat natuurlijk een 'domme' taal, er worden weinig controles uitgevoert. De oorzaak hiervan ligt natuurlijk in het feit dat er niks gecompileerd wordt, de hele preprocessing stap is bij assembler niet aanwezig. Uiteraard wordt dit gebrek weer gecompenseerd door de enorme vrijheid die je hebt in assembler.

Meest voorkomende problemen bij mijn assembler projecten hebben vaak te maken met de simulator. Meestal test ik een deel van de code door in het begin van mijn programma een branch te zetten naar de te testen routine. Als dan blijkt dat de routine helemaal goed werkt, en ik dolenthousiast de microcontroller opnieuw programmeer, blijkt dat het hele ding totaal niet meer functioneert. Na een lange speurtocht en hardware controles (voeding, reset signaal, clock e.d.) blijkt dan altijd weer dat ik vergeten ben om de testbranch aan het begin van mijn programma te verwijderen.

Inline programeren en debuggen zou in zo'n geval geen overbodige luxe zijn... :)
Als er nu iets niet meer functioneert van mijn microcontroller, dan controleer ik eerst altijd de initialisatie met de simulator.

Op 4 november 2005 01:19:39 schreef free_electron:
geeft je comp[iler geen warnings als je ongedefinieerde symbolen gebruikt ? of als je dead code hebt ( code die nooit uitgevoerd word ) ? of lees je het compilation rapport niet ?

Dit heb ik nooit ergens zien staan, maar ik zal eens zien of er dit soort messages gegeven worden.
Natuurlijk kijk ik naar de compilatie output, maar 'dead code' zie ik daar niet staan.
Ik kan me ook voorstellen dat een compiler nooit alle 'dead code' zal vinden. Maar goed, ik zal eens zien..dank je voor de tip.

Op 4 november 2005 01:52:01 schreef KillerB the Supreme:
Assembler is wat dat aangaat natuurlijk een 'domme' taal, er worden weinig controles uitgevoert. De oorzaak hiervan ligt natuurlijk in het feit dat er niks gecompileerd wordt, de hele preprocessing stap is bij assembler niet aanwezig.

Op macro's na dan..

Op 4 november 2005 01:52:01 schreef KillerB the Supreme:
Meest voorkomende problemen bij mijn assembler projecten hebben vaak te maken met de simulator. Meestal test ik een deel van de code door in het begin van mijn programma een branch te zetten naar de te testen routine. Als dan blijkt dat de routine helemaal goed werkt, en ik dolenthousiast de microcontroller opnieuw programmeer, blijkt dat het hele ding totaal niet meer functioneert. Na een lange speurtocht en hardware controles (voeding, reset signaal, clock e.d.) blijkt dan altijd weer dat ik vergeten ben om de testbranch aan het begin van mijn programma te verwijderen.

Tja..da's inderdaad suf, maar is mij ook wel eens overkomen..]

[Bericht gewijzigd door DIY op ]