Raar PIC-programmeerprobleem

Hallo,

Ik weet niet of hier PIC-specialisten zitten, maar ik probeer het toch maar.

Bij een programmeerproject met een PIC 16F88 loop ik tegen een volkomen maf probleem aan: een hoog-toestand op RB7 (pen 13) als ingang wordt niet herkend, wat ik ook probeer. Als ik RB7 als uitgang programmeer, doet hij hij het prima, en ook alle andere I/O-pennen doen precies wat ik wil.

Ik heb me helemaal suf gezocht naar wat dit kan veroorzaken -- een verkeerd draadje in de hardware, de configuratiewoorden, allerlei speciale functieregisters, en ik zal wel iets heel simpels verkeerd doen, maar ik kom er niet uit. De hardware varieert van een breadboardje tot een schakeling op een print, en de rest heb ik al vele malen nagekeken. Het enige wat er aan RB7 hangt, is een pull-down-weerstand van 10K.

Het onderstaande proefprogrammaatje doet het al niet goed, en dan met name de lus; deze moet ervoor zorgen dat een led (plus serieweerstand) op RB6 gaat knipperen zodra RB7 hoog wordt -- maar PORTB,7 wordt *altijd* als laag gezien, ongeacht wat ik er op aansluit, zelfs als ik de +5V direct op de pen van de chip houd. Zodra ik hetzelfde probeer met bijvoorbeeld PORTB,4 werkt alles wel zoals verwacht. Overigens wordt RB7 elektrisch gezien wel degelijk een ingang, want ik kan de spanning met hoogohmige weerstand zowel naar +5 volt als naar nul trekken (met de pull-down-weerstand uiteraard losgetrokken).

Iedere suggestie is welkom -- en hopelijk zit ik al die dagen over een hele domme fout heen te kijken, want dat zijn meestal de simpelste oplossingen ;-)

LIST P=PIC16F88

include "/usr/share/gputils/header/p16f88.inc

__CONFIG _CONFIG1, _CP_OFF & _CCP1_RB0 & _DEBUG_OFF & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF & _BODEN_OFF & _MCLR_ON & _PWRTE_ON & _WDT_OFF & _INTRC_IO __CONFIG _CONFIG2, _IESO_OFF & _FCMEN_OFF

CNTHI equ H'20' ; 2-byte teller CNTLO equ H'21'

org 0000 goto begin ; Interrupt-vector overslaan

; Initialisatie begin clrf PORTB ; Poort B laag bsf STATUS,5 ; Naar Bank 1 movlw H'BF' movwf TRISB ; Poort B6 uitgang, de rest ingangen movlw H'5C' movwf OSCCON ; Interne RC-oscillator op 2MHz bcf STATUS,5 ; Terug naar Bank 0

; *************** Het volgende gaat dus al niet goed: lus btfsc PORTB,7 ; RB7 laag? call led6 ; Nee: Een keer knipperen op RB6 goto lus

; *************** De led gaat nooit aan -- en met lus btfss PORTB,7 ; *************** blijft de led juist knipperen

led6 movlw H'40' ; Zet led op RB6 0,2 seconde aan movwf PORTB call del02s clrf PORTB ; Zet de led uit en wacht weer 0,2 seconde call del02s return

del02s movlw H'81' ; Vertragingslus van ~0,2 seconde movwf CNTHI dellp decfsz CNTLO,F goto dellp nexthi decfsz CNTHI,F goto dellp return

end

Richard Rasker

--
http://www.linetec.nl/
Reply to
Richard Rasker
Loading thread data ...

PIC specialist ben ik niet (vroeger veel gebruikt, maar tegenwoordig liever avr), maar omdat het probleem zo vreemd is kon ik het toch niet laten om de datasheet eens op te slaan. ;-)

In je code zie ik je nergens de analog inputs disablen, als ik de datasheet goed lees, staan de analoge inputs default aan (register ANSEL).

Verder staat daar: Note 1: Setting a pin to an analog input disables the digital input buffer. The corresponding TRIS bit should be set to input mode when using pins as analog inputs. Only AN2 is an analog I/O, all other ANx pins are analog inputs

Zie ook Table 5-4 en Figure 5-15

Wel vreemd dat het met bijv. RB6 wel werkt, deze zou default ook analoog in moeten zijn.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

                   Read the JOVE BOOK
Reply to
Stef

[knip A/D-ingang standaard aan met voorrang]

Jep, dat was 'm inderdaad ... Ik wist dat het iets simpels moest zijn, maar las er bij de beschrijving van ANSEL steevast overheen -- en bij de beschrijving van poort B wordt dit gedrag niet genoemd.

Uitgerekend die pen wordt alleen als uitgang gebruikt, vandaar. Alle andere aansluitingen van poort B zijn wel als ingang in gebruik en getest. En bij andere projecten met de 16F88 blijk ik de A/D-capabele ingangen telkens als uitgang te hebben gebruikt, zodat ik daar ook nooit tegen het probleem aan ben gelopen :-/

Hoe dan ook, mijn dank is groot!

Richard Rasker

--
http://www.linetec.nl/
Reply to
Richard Rasker

Ga eens in CCS PCW programmeren, het opent een hoop nieuwe mogelijkheden. En het argument dat assembly kleiner zou zijn wordt door de nieuwe pic's ruim ingehaald kwa capaciteit. Het blijft trouwens verbazingwekkend hoeveel pagina's code er in willen, en mocht je 16F vol zijn dan is er meestal een pin compatible 18F om verder te gaan. Dus doe jezelf een plezier en ga in C verder, heb ik ook gedaan. Zou het nog mogelijk zijn een 18F met een datasheet van 100en pagina's in assemby te programmeren?

Klaas.

Reply to
Hein Tunnel

Tuurlijk, elke processor kun je in assembly programmeren. En ook als je in C programmeert zul je de hele datasheet moeten lezen. En ook als je in C programmeert ontkom je niet aan een stukje assembly, op z'n minst zul je de startup code die de omgeving klaar zet voor je C programma moeten nakijken of aanpassen.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

                   Read the JOVE BOOK
Reply to
Stef

Valt erg mee hoor, na de 16c84 heb ik geen letter asm meer geschreven. De datasheet kijk ik hooguit even na om te zien hoe de timers ingesteld wordt. Verder worden alle functies door ccs ingesteld. Ik heb nu een uitgebreide floating point berekening in een 18F2620 inc dcf, i2c, rs232 en en rf afstandbediening decoder zonder dat ik zelfs de datasheet heb.

Reply to
Hein Tunnel

Dank voor de welgemeende raad, maar in mijn toepassingen is de taal doorgaans niet het probleem -- het gaat meestal om relatief simpele toepassingen met vooral veel individuele bitjes inlezen, aan- en uitzetten en verschuiven, wat in assembly net zo vlot of zelfs vlotter gaat dan in C.

Maar overstappen naar een hogere taal is zeker een overweging als ik tegen een project aanloop waarbij complexere dingen moeten gebeuren.

Richard Rasker

--
http://www.linetec.nl/
Reply to
Richard Rasker

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.