Snap verschil tussen RB0 en RB1 van 16F88 niet.

Misschien ergens bij de poortinstellingen iets mis gedaan?

Dat denk ik niet. Beide poorten werden via TRISB als ingang geschakeld en zowel in de hardware als de software gelijk behandeld. Toch reageren ze verschillend dus waarschijnlijk zie ik wel wat over het hoofd maar wat?

Niet per ongeluk SPI of I2C aangezet?

Nee, geen van beiden. Ik gebruik wel I2C maar deze wordt door MikroC softwarematig geemuleerd.

Voor de duidelijkheid zal ik aangeven hoe de datasheet de poorten omschrijft:

RB0: Bidirectional I/O pin, external interrupt pin, Capture input, Compare output, PWM output.

RB1: Bidirectional I/O pin, SPI data in, I2C data.

is het niet iets met een TTL type en ST type pin? (ff geen zin in datasheet zoeken)

Zonder code is het moeilijk maar RB0 is ook CCP1 dus
das de capture compare pwm module , heb je die uitgeschakeld?

Beide pins zijn TTL bij bidirectional I/O en ST bij de andere funkties. Bij MikroC moet je de PWM module apart inschakelen. Met welke funktie op RB0 start de 16F88 op bij een reset? Is dit terug te vinden in de datasheet?

Zie hoofdstuk reset (waar anders )

Ongetwijfeld maar als beginner kom ik daar niet echt uit. Ik vermoed dat RB0 als ST geschakeld is. Hoe schakel ik zo'n pin dan om naar IO of te wel TTL?

Op 30 juli 2009 16:41:10 schreef PE2BS:
Ongetwijfeld maar als beginner kom ik daar niet echt uit.

Dan wordt het wachten op iemand die wel de hele datasheet voor je doorspit

Ik vermoed dat RB0 als ST geschakeld is.

Waarom vermoed je dat?

Hoe schakel ik zo'n pin dan om naar IO of te wel TTL?

CMCON & ANSEL, heeft MikroC geen instructie om alle ingangen digitaal te maken?

Toevallig if (portb.0 = 1) gedaan in plaats van if (portb.0 == 1)

Op 30 juli 2009 17:02:21 schreef Henry S.:
Dan wordt het wachten op iemand die wel de hele datasheet voor je doorspit

????? gezien de moeite die ik zelf onderneem om antwoord te krijgen op mijn vraag voel ik me niet aangesproken.

Ik denk aan ST omdat de 5V op RB0, ondanks de pull down weerstand, behouden blijft tot RB0 naar massa wordt kortgesloten. Daarna blijft de waarde op 0 V staan tot ik de poort met 5V even aantik. RB1 laat zich wel naar 0 trekken door de pull down weerstand.

CMCON gebruik ik in het programma en heeft, volgens de datasheet blz. 121 betrekking op de twee comparators van PORTA. ANSEL gebruik ik om de analoge input uit te schakelen, uitgezonderd RA2 die ik analoog gebruik voor de signaal meter van mijn ontvanger. Alle analoge inputten zitten op PORTA.

Voor zover ik kan nagaan hebben CMCON en ANSEL dus geen invloed op PORTB, tenzij ik wat over het hoofd zie.

Voor de duidelijkheid hieronder een stukje code uit mijn programma:
/* initialiseren variabelen en procedures */
TRISA = 0b00111100; /* PORTA op output, RA2, RA3, RA4, RA5 zijn input */
TRISB = 0b00000010; /* PORTB op output, RB1 op input */
PORTA = 0b00000000; /* PORTA op nul */
CMCON = 0x07; /* Disable analog comparators */
ADCON1= 0x80; /* configureerd analoge input en Vref */
ANSEL = 0b00000100; /* Disable analog input, RA2 analog input */

Op 30 juli 2009 17:05:07 schreef Stynus:
Toevallig if (portb.0 = 1) gedaan in plaats van if (portb.0 == 1)

Nee, zie code hieronder:

/* Test en schrijft sideband op scherm */

void ssb(void){

if (PORTB.F1) Lcd_Out(1, 1, "lsb");
else Lcd_Out(1, 1, "usb");
}

[Bericht gewijzigd door Henry S. op donderdag 30 juli 2009 19:30:05 (0%)]

Op 30 juli 2009 19:15:56 schreef PE2BS:
[...]
????? gezien de moeite die ik zelf onderneem om antwoord te krijgen op mijn vraag voel ik me niet aangesproken.

Maar daar komt het wel op neer, en het heeft geholpen (re: CMCON en ANSEL).

Ik denk aan ST omdat de 5V op RB0, ondanks de pull down weerstand, behouden blijft tot RB0 naar massa wordt kortgesloten. Daarna blijft de waarde op 0 V staan tot ik de poort met 5V even aantik. RB1 laat zich wel naar 0 trekken door de pull down weerstand.

Dat is geen normaal gedrag van een ST ingang, die hoort niet zo te latchen.

Conclusies: Je aanname is fout, PortB ingangen zijn default digitaal I/O, en er is wat vreemds met jouw PortB.0.

Het blijft een vreemd probleem. Hetzelfde programma in een andere 16F88 vertoont hetzelfde gedrag op RB0. De CCP1 verleggen van RB0 naar RB3 (kan in het CONFIG1 register) lost het probleem ook niet op. Vervolgens heb ik de external interrupt uitgeschakeld (INTCON=0x00) maar ook dan blijft het latch gedrag. Ik weet het even niet meer maar iedereen bedankt voor het meedenken.

PortB bevat ook weak pull-up's hier al na gekeken of je die uit hebt staan.
Zouden deze aan staan dan zouden deze het signaal wel eens hoog kunnen houden.

Al geprobeerd met een simpel stukje code om bijv. alleen een ledje aan/uit te doen als RB0 hoog/laag is?
(Desnoods in ASM, dan weet je of het de compiler niet is die wat vreemds doet...)

Op 30 juli 2009 21:54:18 schreef Red-E:
PortB bevat ook weak pull-up's hier al na gekeken of je die uit hebt staan.
Zouden deze aan staan dan zouden deze het signaal wel eens hoog kunnen houden.

De weak pull-ups uitgezet via bit 7 van OPTION_REG. Helaas het latch effect blijft.

Op 30 juli 2009 22:18:08 schreef Arco:
Al geprobeerd met een simpel stukje code om bijv. alleen een ledje aan/uit te doen als RB0 hoog/laag is?
(Desnoods in ASM, dan weet je of het de compiler niet is die wat vreemds doet...)

Bedankt voor de tip. Door "kaal" te beginnen en registers en funkties toe te voegen ontdekte ik waar de oorzaak zit.

RB0 start inderdaad als I/O pin op maar bij LCD_Config() configureerd MikroC een LCD scherm op de B-poort:

Initializes LCD at port with default pin settings:
D7 -> port.7
D6 -> port.6
D5 -> port.5
D4 -> port.4
E -> port.3
RS -> port.2
RW -> port.0

RW van het LCD scherm wordt wel geconfigureerd op RB0 maar wordt in de praktijk aan massa gelegd. Daardoor lijkt RB0 vrij te zijn maar is in werkelijkheid dus in gebruik.

Iedereen bedankt voor het meedenken en de tips.

Op 31 juli 2009 13:07:54 schreef PE2BS:
RB0 start inderdaad als I/O pin op maar bij LCD_Config() configureerd MikroC een LCD scherm op de B-poort:
[...]
RW van het LCD scherm wordt wel geconfigureerd op RB0 maar wordt in de praktijk aan massa gelegd. Daardoor lijkt RB0 vrij te zijn maar is in werkelijkheid dus in gebruik.

Lekker is dat, R/W wordt eigenlijk nooit gebruikt.Dus een beetje onnozel van MikroE om die poort te gebruiken.

Welke versie van MikroC gebruik jij eigenlijk?

Ik gebruik zelf ook MikroC en ik kan elke pin van de LCD naar gelijk welke pin op de PIC instellen.

Zelfs in de vorige versies die ik gebruikte kon dat ook,
met als enige beperking dat de Datalijnen op een poort zaten en de Control lijnen allen op een Poort zaten.

De RW pin is niet gebruikt (hangt aan massa) en bezet ook geen PIC pin.

[Bericht gewijzigd door tubos op vrijdag 31 juli 2009 23:25:16 (11%)]

Versie 8.2. Je kunt bij het installeren van de LCD kiezen voor twee opties:

- LCD_Config, configureerd LCD naar vaste pins op Port B. Deze optie heb ik gebruikt.RW wordt hier naar RB0 toegewezen met bovenstaand resultaat.

-LCD_Custom_Config, configureerd LCD datalijnen naar zelf te kiezen PORT en pinnen en de LCD controllijnen naar zelf te kiezen PORT en pinnen. Deze kun je inderdaad helemaal zelf instellen maar ook bij deze wordt RW aan een pin toegewezen. Het is de vraag hoe deze pin daarna reageert en of deze daarna nog voor andere doeleinden is te gebruiken.

kun je um niet overschrijven met een bitmask?
dus eerst LCD instellen en daarna overschrijven?
simpel weg even testen en kijken wat het resultaat is lijkt mij

[Bericht gewijzigd door Red-E op zaterdag 1 augustus 2009 12:15:58 (27%)]

Op 1 augustus 2009 12:15:37 schreef Red-E:
kun je um niet overschrijven met een bitmask?
dus eerst LCD instellen en daarna overschrijven?
simpel weg even testen en kijken wat het resultaat is lijkt mij

Bedoel je TRISB opnieuw declareren?

jpjp, eerst trisB configen via LCD_CONFIG (eventueel _COSTUM) en daarna het betreffende bitje in TrisB weer terug plaatsen naar de door jouw gewenste stand...