Al enige tijd bestudeer ik een programma van een Morse-keyer dat gemaakt is voor de 12C509A, maar aangepast is voor de 16F84A. Ik heb nauwelijks ervaring met PIC's (tutorial wel gelezen natuurlijk) maar spring toch in het diepe zonder te kunnen zwemmen en de overkant ligt 2465 code-regels verder. Omdat ik een wijziging wil aanbrengen probeer ik te analyseren hoe het een en ander werkt.
Nu kom ik op een aantal plaatsen in het programma dit soort instructies tegen: MOVWF TRISB ^ 0x80 In de instructie set van de 16F84 staat echter: MOVWF f (Move W to f en verder niets erachter)
Kan iemand mij vertellen wat de bedoeling van die: ^ 0x80 is?
Jeroen Boere
IF you can't convince them, then confuse them!
mja, dat is het hexadecimale getal dat correspondeerd met je 8-bits I/O op uitgang B.
Binair zit dit er zo uit: 10000000
als je dit getal (80h) naar het I/O register schrijf dan zal je zien dat RB7 hoog word
ps. kan wat onduidelijk zijn uitgelegt, maar ben zelf ook nog maar 2 dagen bezig met PIC'jes 
[Bericht gewijzigd door Jeroen Boere op ]
De TRISB is maar een voorbeeld Jeroen, er zijn ook anderen zoals: MOVWF OPTION_REG ^ 0x80
Waar het mij om gaat is dat MOVWF f, maar één operand heeft en er staan er in het programma twee!
Jeroen Boere
IF you can't convince them, then confuse them!
antwoord op je tweede vraag: ik denk dat het gewoon onderdeel is van dat zelf verzonnen woord. wat voor instructie staat er boven MOVWF TRISB ^ 0x80 ?
staat dat TRISB ^ 0x80 niet bovenaan het programma met de instructie EQU <hexadres> ?
[Bericht gewijzigd door Jeroen Boere op ]
Nee, dat staat er niet. De inhoud van TRISA en TRISB bepalen of RAx en RBx in- of uitgangen zijn.
Hieronder een paar samenhangende regels code ter verduidelijking:
ifdef __16F84A
MOVLW B'11111000' ; Restore Pin 2 as an input
BSF STATUS, RP0 ; to cancel beacon request
MOVWF TRISB ^ 0x80
BCF STATUS, RP0
else
MOVLW B'00101011' ; Restore Pin 2 as an input
TRIS GPIO ; to cancel beacon request
endifIn TRISB komt dus binair 11111000 te staan nadat bank 1 geselecteerd is.
Wouter van Ooijen
Wouter van Ooijen: VOTI webwinkel, docent HvU (Technische Informatica); C++ on mictrocontrollers blog
Op 16 januari 2003 22:51:43 schreef Carel M.:
Kan iemand mij vertellen wat de bedoeling van die: ^ 0x80 is?
voorkomen dat de assembler klaagt over een adres dat niet in bank 0 ligt.
Bastiaan
Bachelor of Engineering -- Microcontrollers AVR, PIC (asm, C), PC applicaties (C, C++), Webpages (HTML, CSS, PHP, SQL), Rail-infra engineer
Ik zal je even wat uitleggen wat je nog niet weet maar waar dit mee heeft te maken.
Er zijn codes die je kunt gebruiken in je programma voor extra functionaliteit. Dit zijn opdrachten die alleen de assembler begrijpt. Zo heb je END bijvoorbeeld. Dit staat niet in de instruction set maar werkt wel. Zodra de assebler deze code tegenkomt weet die dat die klaar is met assembleren vanwege het einde van het programma. EQU is ook zo'n commando. Deze commando's noem je directives. Ze worden als eerste door de assembler behandelt en gebuikr of omgezet en daarna pas word het programma volgens de instructieset geassembleerd.
Zo kun je ook gebruik maken van expressions. Dit zijn kleine expressies (berekeningen) die de assembler eerst zal uitrekenen en die uitkomst gebruikt als enkele operand. Zo is dat ook met je TRIS ^ 0x80 expression. Dit word zodra je assembler begint eerst uitgerekent. ^ is een code voor bitwise XOR, er zal dus een XOR tussen TRISB (0x03) en 0x80 worden uitgevoerd. Het antwoord daarvan is 0x83. De assembler gebruikt dan tijdens de "echte assemblatie" als operand op die regel 0x83. Dus het heeft hetzelfde effect als
MOVWF 0x83
Er zijn nog veel meer mogelijkheden. Je kunt bijvoorbeeld ook + doen en - en maal(*) enz. Ik raad je aan om even deze file te downloaden en daar te kijken naar het hoofdstuk "expressions" waar al deze codes in een tabel staan.
http://www.microchip.com/download/tools/picmicro/code/mpasm/33014g.pdf
Mag ik dat ongeveer vergelijken met het werk dat een preprocessor doet in bv. een C-compiler?
Toch nog even dit Bastiaan.
TRISB staat toch op adres 0x86, het lijkt mij dan dat de XOR hier de waarde 0x03 moet opleveren. Juist andersom dus.
Even los van het selecteren van de juiste bank moet er, als ik die gedachtegang doorzet, hetvolgende gebeuren:
- stop b11111000 in W
- zet de inhoud van W weg op plaats 0x03 (wat het Statusregister is !!!)
Bovenstaand kan ik echter niet rijmen met de verklarende tekst achter de code. Daar staat, in geval een 16F84A wordt gebruikt helaas een onjuiste tekst. Pen 2 is poort GP5 bij de 12C509A, daarvoor is bij de 16F84A poort RB3 gekozen.
Voor zover ik weet, is het de bedoeling van het programma dat RB3 een input moet worden ipv een output en dat doe je toch door in TRISB bit3 te 'setten'?
Een van beide of wellicht allebei mijn redenaties kloppen niet.
Bastiaan
Bachelor of Engineering -- Microcontrollers AVR, PIC (asm, C), PC applicaties (C, C++), Webpages (HTML, CSS, PHP, SQL), Rail-infra engineer
Op 17 januari 2003 21:13:46 schreef Carel M.:
Een van beide of wellicht allebei mijn redenaties kloppen niet.
Haha, zo kun je soms uren bezig zijn met het overdenken van situaties en niks opschieten omdat je het niet ziet 
Mag ik dat ongeveer vergelijken met het werk dat een preprocessor doet in bv. een C-compiler?
Jep, goed begrepen.
TRISB staat toch op adres 0x86, het lijkt mij dan dat de XOR hier de waarde 0x03 moet opleveren. Juist andersom dus.
Ehm, je hebt helemaal gelijk. TRISB zit op 0x86.
Ik kan het allemaal even niet meer onthouden omdat ik namelijk bezig ben met het bestuderen van een AVR controller en met een Motorola 32bits processor. En alle 3 die merken(incl Microchip dus) werken anders dus is een beetje verwarrend voor me geworden 
Even los van het selecteren van de juiste bank moet er, als ik die gedachtegang doorzet, hetvolgende gebeuren:
- stop b11111000 in W
- zet de inhoud van W weg op plaats 0x03 (wat het Statusregister is !!!)
je 1e regel klopt. Je 2e niet. Er staat
MOVWF TRISB^0x80
Ik ga ervanuit dat er ergens bovenin het programma staat:
TRISB EQU 0x06
De expressie 0x06 ^ 0x80 levert dan op 0x86
Terug naar waar we waren blijven hangen, het word dan dus:
MOVWF 0x86
Voor zover ik weet, is het de bedoeling van het programma dat RB3 een input moet worden ipv een output en dat doe je toch door in TRISB bit3 te 'setten'?
Ja of te clearen, ik weet niet meer welke van de 2. Moet je even in mijn tutorial kijken of datasheet.
Op 17 januari 2003 21:23:06 schreef Bastiaan:
Ik ga ervanuit dat er ergens bovenin het programma staat:
TRISB EQU 0x06
In de 16F84A.INC file staat dat genoemd maar dan als: TRISB EQU 0x86
Het wordt dan toch MOVWF 0x03 maar het 'beschrijven' van het STATUS register kan ik toch nog niet rijmen me de verklarende tekst achter de code.
Ik ga morgen maar eens met MPLAB aan de slag en kijken wat er gebeurt als ik die code intik.
Bastiaan
Bachelor of Engineering -- Microcontrollers AVR, PIC (asm, C), PC applicaties (C, C++), Webpages (HTML, CSS, PHP, SQL), Rail-infra engineer
Op 17 januari 2003 21:39:48 schreef Carel M.:
[...]
In de 16F84A.INC file staat dat genoemd maar dan als: TRISB EQU 0x86
Het wordt dan toch MOVWF 0x03 maar het 'beschrijven' van het STATUS register kan ik toch nog niet rijmen me de verklarende tekst achter de code.
Ik ga morgen maar eens met MPLAB aan de slag en kijken wat er gebeurt als ik die code intik.
0x86 XOR 0x80 = 0x06
Yep, was even de kluts kwijt. Heb hem weer gevonden, dank je.
Ik weet nu waar ik in het programma de gewenste wijziging moet aanbrengen en ook hoé dat zou moeten. Ik laat je wel weten of het gelukt is.
Bastiaan
Bachelor of Engineering -- Microcontrollers AVR, PIC (asm, C), PC applicaties (C, C++), Webpages (HTML, CSS, PHP, SQL), Rail-infra engineer
Op 17 januari 2003 21:47:04 schreef Carel M.:
Yep, was even de kluts kwijt. Heb hem weer gevonden, dank je.
Ik weet nu waar ik in het programma de gewenste wijziging moet aanbrengen en ook hoé dat zou moeten. Ik laat je wel weten of het gelukt is.
Is goed.
Het werkt Bastiaan, maar ik wil het toch anders.
In het programma wordt RB2 gebruikt om een 'sidetone' (meeluistertoon) van circa 650Hz uit te sturen. Dit signaal gaat in het ritme van de morsetekens aan en uit, en veroorzaakt daardoor een hinderlijke schakelklik in het audio van de kortegolf ontvanger. Door RB2 tussen het op- en afzetten van de sidetone, van uitgang naar ingang (TRISB) om te schakelen dacht ik die schakelklik te verminderen. Het resultaat staat in fig. 2 en is feitenlijk het omgekeerde van de oorspronkelijke instelling (fig. 1) waarin RB2 éénmalig in het programma als uitgang ingesteld wordt. Dat hielp dus niets.
Door nu in het OPTION REGISTER bit RBPU = 1 te zetten (disable pull-ups PORTB) krijg ik de signaalvorm van fig. 3 en klinkt de meeluistertoon al heel wat vriendelijker. Toch blijft er nog enig 'geklik' over wat te wijten is aan het opslingerverschijnsel in het smalband audiofilter waarin dit signaal geïnjecteerd wordt. De inslingerpuls is duidelijk zichtbaar op de scoop.
Echter door de wijziging in het OPTION REGISTER zijn ook de overige ingangen van PORTB hun pull-ups kwijt en moet ik dat oplossen met externe weerstanden. Op zich niks mis mee, maar ik zou ze liever weglaten en zoek dus een oplossing om alleen RB2 in tri-state modus te krijgen. Gaat dat op een of andere manier?
Carel.
Bastiaan
Bachelor of Engineering -- Microcontrollers AVR, PIC (asm, C), PC applicaties (C, C++), Webpages (HTML, CSS, PHP, SQL), Rail-infra engineer
Op 21 januari 2003 21:24:59 schreef Carel M.:
Op zich niks mis mee, maar ik zou ze liever weglaten en zoek dus een oplossing om alleen RB2 in tri-state modus te krijgen. Gaat dat op een of andere manier?
Nee, deze PIC heeft geen tri-state modus. Wel kun je misschien een kleine condensator op die uitgang zetten zodat de puls minder stijl loopt.