Jo det är möjligt att det kan vara någon hårdvarukonflikt på pickit1:et, själv har jag ingen aning.
Testläget går säkert igång om man startar med +5V. Jag har nog fel igen. Damn.
Jag har kopplat som så att...äh...ska försöka fixa en bild på det istället.
Nej, jag ser inte att det kommer ut någonting på TX på oscilloskopet. Ser inte ens någon in-oscillolatorsignal på 16F688. Borde inte det vara en signal även fast man konfigurerar den enligt: "_intrc_osc_noclkout". Tar jag därimot bort "_intrc_osc_noclkout" ur konfigurationen så ser jag oscillolatorsignalen på två ben.
Ja, jag har delay innan jag skickar data till LCDn.
Ska försöka fixa en bild imorron.
/Klas
Seriell LCD igen. Hjälp mig...
> "Ser inte ens någon in-oscillolatorsignal på 16F688"
Helt OK, eftersom det inte finns någon..
> "Testläget går säkert igång om man startar med +5V. Jag har nog fel igen."
"Nog" ??? Manualen till LCDn säger :
"...Temporarily connect the serial input to one of the +5 terminals of J1, then connect power to +5 and GND. The LCD will display a test message."
Ganska tydligt. Så om du bara har 5V inkopplat till LCDn hela tiden så skall det inte vara någon riskt att hamna i självtestläget.
Du ska inte *ta bort* "_INTRC_OSC_NOCLKOUT", du ska *byta ut* det till "_INTRC_OSC_CLKOUT" (om du vill köra på INTOSC, och det måste man på PICkit1, samt ha ut klocksignalen på RA4). Se botten av filen P16F688.INC i MPASM katalogen i MPLAB installationen.
Du får Fosc/4 på RA4 (8 Mhz -> 2 Mhz på RA4).
Men du ska inte se någon klocksignal på något *annat ben* än RA4.
Förresten, och det här är faktiskt lite jobbigt, varför skriver du bara "på två ben" och inte *VILKA* ben ?? Hur ska någon annan veta vilka ben du menar ??
När det gäller konflikter på själva PICkit1 kortet, så skulle det väl kunna vara med t.ex lysdioderna eller liknande (tror inte det själv)..
Sitter MAX232'an monterad ? Är den "inkopplad" ? Hur är det med strappen mellan TX och RX ("JP1"), kan den störa ?
Helt OK, eftersom det inte finns någon..
> "Testläget går säkert igång om man startar med +5V. Jag har nog fel igen."
"Nog" ??? Manualen till LCDn säger :
"...Temporarily connect the serial input to one of the +5 terminals of J1, then connect power to +5 and GND. The LCD will display a test message."
Ganska tydligt. Så om du bara har 5V inkopplat till LCDn hela tiden så skall det inte vara någon riskt att hamna i självtestläget.
Du ska inte *ta bort* "_INTRC_OSC_NOCLKOUT", du ska *byta ut* det till "_INTRC_OSC_CLKOUT" (om du vill köra på INTOSC, och det måste man på PICkit1, samt ha ut klocksignalen på RA4). Se botten av filen P16F688.INC i MPASM katalogen i MPLAB installationen.
Du får Fosc/4 på RA4 (8 Mhz -> 2 Mhz på RA4).
Men du ska inte se någon klocksignal på något *annat ben* än RA4.
Förresten, och det här är faktiskt lite jobbigt, varför skriver du bara "på två ben" och inte *VILKA* ben ?? Hur ska någon annan veta vilka ben du menar ??
När det gäller konflikter på själva PICkit1 kortet, så skulle det väl kunna vara med t.ex lysdioderna eller liknande (tror inte det själv)..
Sitter MAX232'an monterad ? Är den "inkopplad" ? Hur är det med strappen mellan TX och RX ("JP1"), kan den störa ?
Tja.
Vet inte ifall jag vågar skriva någonting mer nu...
Men iaf, när jag skriver om till "_intrc_osc_clkout" som du sa får jag inte bara signal på RA4, utan jag får signal på följande ben:
2 (RA5/T1CKI/OSC1/CLKIN)
3 (RA4/AN3/T1G/OSC2/CLKOUT)
11 (RA2/AN2/T0CKI/INT/C1OUT)
12 (RA1/AN1/C1IN-/VREF/ICSPCLK)
Dock är signalen "tydligast" på RA4, men definitivt inte otydlig på de andra benen som jag nämnt.
Ingenting på den högra sidan av kortet är inkopplat så varken MAX232 eller JP1 finns.
Digitalkameran behövde laddas, kan försöka fixa en bild imorron istället, om det behövs?
Känns som att det antingen är konfigurationen eller någonting med oscillolatorn eller baud rate som strular.
/Klas
Vet inte ifall jag vågar skriva någonting mer nu...
Men iaf, när jag skriver om till "_intrc_osc_clkout" som du sa får jag inte bara signal på RA4, utan jag får signal på följande ben:
2 (RA5/T1CKI/OSC1/CLKIN)
3 (RA4/AN3/T1G/OSC2/CLKOUT)
11 (RA2/AN2/T0CKI/INT/C1OUT)
12 (RA1/AN1/C1IN-/VREF/ICSPCLK)
Dock är signalen "tydligast" på RA4, men definitivt inte otydlig på de andra benen som jag nämnt.
Ingenting på den högra sidan av kortet är inkopplat så varken MAX232 eller JP1 finns.
Digitalkameran behövde laddas, kan försöka fixa en bild imorron istället, om det behövs?
Känns som att det antingen är konfigurationen eller någonting med oscillolatorn eller baud rate som strular.
/Klas
"Vet inte ifall jag vågar skriva någonting mer nu..."
Sorry...
Det är klart att du ska !
Vad jag försökte säga var att kvaliteten på den hjälp du får, beror mest på kvaliteten på det du *själv* skriver. Inget konstigt med det, som man frågar får man svar, heter det ju.
Att utelämna "detaljer" gör det hela bara svårare att förstå.
EDIT : Jag vill inte säga att ovanstående är "problemet", det var mer en generell kommentar...
På RA4 ska du ha en 2 Mhz fyrkantssignal.
Det andra du ser kan vara någon överhörning eller liknande.
En sak är att *oanslutna* pinnar bör sättas som *utgång* (via TRISx). Om man sätter dom som 1 eller 0 spelar mindre roll, men man bör inte ha oanslutning pinnar som ingångar. De plockar upp "brum" (t.ex 50Hz brum från 230Vs nätet), och kan ge förhöjd strömförbrukning och i värsta fall (inte speciellt vanligt) fel i funktionen på processorn.
Ett alternativ är att sätta oanvända pinnar som ingång och att ansluta dom till +5 eller 0 V (helst genom ett motstånd).
En aktuell version av din programvara vore också bra...
Jag skulle lägga till något i koden som t.ex blinkar med en lysdiod i samband med att send rutinen anropas. Eller, eftersom du har flera lysdioder, tänd dom i lite olika "mönster" på olika platser i koden, så ser man var processorn "är".
Sorry...
Det är klart att du ska !Vad jag försökte säga var att kvaliteten på den hjälp du får, beror mest på kvaliteten på det du *själv* skriver. Inget konstigt med det, som man frågar får man svar, heter det ju.
Att utelämna "detaljer" gör det hela bara svårare att förstå.
EDIT : Jag vill inte säga att ovanstående är "problemet", det var mer en generell kommentar...
På RA4 ska du ha en 2 Mhz fyrkantssignal.
Det andra du ser kan vara någon överhörning eller liknande.
En sak är att *oanslutna* pinnar bör sättas som *utgång* (via TRISx). Om man sätter dom som 1 eller 0 spelar mindre roll, men man bör inte ha oanslutning pinnar som ingångar. De plockar upp "brum" (t.ex 50Hz brum från 230Vs nätet), och kan ge förhöjd strömförbrukning och i värsta fall (inte speciellt vanligt) fel i funktionen på processorn.
Ett alternativ är att sätta oanvända pinnar som ingång och att ansluta dom till +5 eller 0 V (helst genom ett motstånd).
En aktuell version av din programvara vore också bra...
Jag skulle lägga till något i koden som t.ex blinkar med en lysdiod i samband med att send rutinen anropas. Eller, eftersom du har flera lysdioder, tänd dom i lite olika "mönster" på olika platser i koden, så ser man var processorn "är".
"På RA4 ska du ha en 2 Mhz fyrkantssignal."
Stämmer bra det.
"En sak är att *oanslutna* pinnar bör sättas som *utgång* (via TRISx)..."
Ska ske. Det var en nyhet för mig. Ska lägga den på minnet.
"Jag skulle lägga till något i koden som t.ex blinkar med en lysdiod"
Låter som en riktigt bra idé. Smart tänkt.
Vet inte om det är någon större idé att uppdatera koden någonting eftersom jag inte har gjort så mycket åt den. Vi (du) har ju inte hittat så mycket mer fel, allting är väl i princip fixat i den senaste uppdateringen, förutom "_intrc_osc_noclkout", men det har jag som sagt ändrat nu.
Kan göra en update när jag har fixat lysdioder-som-blinkar-på-bra-ställen-i-koden-(så-man-ser-hur-långt-programmet-körs-(som-du-sa))-ändring.
/Klas
Stämmer bra det.
"En sak är att *oanslutna* pinnar bör sättas som *utgång* (via TRISx)..."
Ska ske. Det var en nyhet för mig. Ska lägga den på minnet.
"Jag skulle lägga till något i koden som t.ex blinkar med en lysdiod"
Låter som en riktigt bra idé. Smart tänkt.
Vet inte om det är någon större idé att uppdatera koden någonting eftersom jag inte har gjort så mycket åt den. Vi (du
) har ju inte hittat så mycket mer fel, allting är väl i princip fixat i den senaste uppdateringen, förutom "_intrc_osc_noclkout", men det har jag som sagt ändrat nu.Kan göra en update när jag har fixat lysdioder-som-blinkar-på-bra-ställen-i-koden-(så-man-ser-hur-långt-programmet-körs-(som-du-sa))-ändring.
/Klas
Ett annat sätt att debugga (lysdioder måste ju blinka ganska långsamt för att man skall se dom) är att "pulsa" en ledig pinne på olika ställen i koden. Det kan ske utan fördröjning, om man använder oscillioskopet för att "titta" på dom.
Man kan lägga olika många pulser på olika ställen så vet man var programmet är, t.ex bsf/bcf på ett ställe och bsf/bcf/bsf/bcf på ett annat.
Eller bsf/nop/bcf på ett ställe och bsf/nop/nop/nop/bcf på ett annat (olika långa pulser).
Eller olika kombinationer så att det blir som "koder" som man kan identifiera på oscillioskopet.
Om programmet har en stor huvudloop, kan man lägga dit en extra puls på en annan pinne som kan användas som "trig" på oscillioskopet, så att man får en stabil referens för de andra pulserna, kan vara lite trickigt att få det att trigga "snyggt" annars.
Dessutom (vilket jag gjorde när jag testkörde ditt program), ändra "goto stop" till "goto main", så att programmet går hela tiden. Enklare att felsöka då.
Det finns många sätt, bara man gör NÅGOT...
Ett annat standard sätt att debugga är att förenkla, skala av, tills man har en liten kärna som bara *ska* fungera, när den gör det kan man lägga tillbaka det man tog bort (eller kommenterade bort, så klart).
Det här med att inte ha oanslutna CMOS ingångar gäller alla digitala CMOS kretsar, det är inget specifik för PIC eller processorer alls. CMOS ingångar har så hög impedans att de "snappar" upp elektriska fält som nästan alltid finns "i luften", speciellt på ett bord där det finns batterieliminatorer och liknande.
/Janne.
Man kan lägga olika många pulser på olika ställen så vet man var programmet är, t.ex bsf/bcf på ett ställe och bsf/bcf/bsf/bcf på ett annat.
Eller bsf/nop/bcf på ett ställe och bsf/nop/nop/nop/bcf på ett annat (olika långa pulser).
Eller olika kombinationer så att det blir som "koder" som man kan identifiera på oscillioskopet.
Om programmet har en stor huvudloop, kan man lägga dit en extra puls på en annan pinne som kan användas som "trig" på oscillioskopet, så att man får en stabil referens för de andra pulserna, kan vara lite trickigt att få det att trigga "snyggt" annars.
Dessutom (vilket jag gjorde när jag testkörde ditt program), ändra "goto stop" till "goto main", så att programmet går hela tiden. Enklare att felsöka då.
Det finns många sätt, bara man gör NÅGOT...
Ett annat standard sätt att debugga är att förenkla, skala av, tills man har en liten kärna som bara *ska* fungera, när den gör det kan man lägga tillbaka det man tog bort (eller kommenterade bort, så klart).
Det här med att inte ha oanslutna CMOS ingångar gäller alla digitala CMOS kretsar, det är inget specifik för PIC eller processorer alls. CMOS ingångar har så hög impedans att de "snappar" upp elektriska fält som nästan alltid finns "i luften", speciellt på ett bord där det finns batterieliminatorer och liknande.
/Janne.
Att skala ner programmet för att det ska bli så lite som möjligt att felsöka är nog ganska uteslutet då programmet redan är så litet det kan bli. Eller hur? Det var iaf tanken med det när jag skrev om det från första versionen.
Okej, goto main och pulser istället för lysdioder. Sir, yes sir.
Jag har laddat kameran, tömt minneskortet och inspirerats av din vishet sodjan. Går till attack imorron.
/Klas
Okej, goto main och pulser istället för lysdioder. Sir, yes sir.
Jag har laddat kameran, tömt minneskortet och inspirerats av din vishet sodjan. Går till attack imorron.
/Klas
Tjo...
Nu så har jag skrivit till en liten snutt så att en LED på Pickit1:et blinkar om man call:ar den. D0 om den informationen är viktig...
Gör jag det ser jag att den går alla steg som det är tänkt. Jag ser dessutom att macrot-"mdly" funkar bra.
Tror själv att det är någonting fel med antingen
INITIALIZING CONTROLLER
eller
SET BAUD RATE TO COMMUNICATE
LED:en ger väl iaf en bekräftelse på att main-programmet funkar som det ska va?
Bild och programmet fixas ikväll, då jag har svårt att komma åt servern härifrån.
/Klas
Nu så har jag skrivit till en liten snutt så att en LED på Pickit1:et blinkar om man call:ar den. D0 om den informationen är viktig...
Gör jag det ser jag att den går alla steg som det är tänkt. Jag ser dessutom att macrot-"mdly" funkar bra.
Tror själv att det är någonting fel med antingen
INITIALIZING CONTROLLER
eller
SET BAUD RATE TO COMMUNICATE
LED:en ger väl iaf en bekräftelse på att main-programmet funkar som det ska va?
Bild och programmet fixas ikväll, då jag har svårt att komma åt servern härifrån.
/Klas
> "D0 om den informationen är viktig..."
Nja, det är intressantare att veta att det är RA4 och RA5 som används
Du sätter alltså RA4=1 och RA5=0, eller hur ?
> "LED:en ger väl iaf en bekräftelse på att main-programmet funkar som det ska va?"
Ja, om "blink-mönstret" känns igen och det inte kan komma från något annat (slumpmässigt) blinkade, så borde det göra det.
Kan du utifrån LED'en konstatera att PIC'ens oscillator går med den hastighet som är tänkt (8 eller 4 Mhz, eller hur du nu "kör den" för tillfället) ?
Det som gäller nu är att se till att få ut *något* på TX. D.v.s att få USART'en att sända. Sedan, när det fungerar, blir nästa steg att se till att sända något som LCDn "förtstår", men det är ju inte så akut så länge inte USARTen inte sänder någonting. Ett oscillioskop är ovärderligt för att kolla det.
En aktuell kod vore bra...
EDIT : "INITIALIZING CONTROLLER" och "SET BAUD RATE TO COMMUNICATE", är det något i din kod eller något annat ?
Nja, det är intressantare att veta att det är RA4 och RA5 som används
Du sätter alltså RA4=1 och RA5=0, eller hur ?
> "LED:en ger väl iaf en bekräftelse på att main-programmet funkar som det ska va?"
Ja, om "blink-mönstret" känns igen och det inte kan komma från något annat (slumpmässigt) blinkade, så borde det göra det.
Kan du utifrån LED'en konstatera att PIC'ens oscillator går med den hastighet som är tänkt (8 eller 4 Mhz, eller hur du nu "kör den" för tillfället) ?
Det som gäller nu är att se till att få ut *något* på TX. D.v.s att få USART'en att sända. Sedan, när det fungerar, blir nästa steg att se till att sända något som LCDn "förtstår", men det är ju inte så akut så länge inte USARTen inte sänder någonting. Ett oscillioskop är ovärderligt för att kolla det.
En aktuell kod vore bra...
EDIT : "INITIALIZING CONTROLLER" och "SET BAUD RATE TO COMMUNICATE", är det något i din kod eller något annat ?
"Du sätter alltså RA4=1 och RA5=0, eller hur ?"
Jo.
"Du sätter alltså RA4=1 och RA5=0, eller hur ?..."
Nja, jag har inte direkt kollat hastigheten sedan jag jorde det sisst. 2MHz var det ju sisst jag kollade om du mins?
"EDIT : "INITIALIZING CONTROLLER" och "SET BAUD RATE TO COMMUNICATE", är det något i din kod eller något annat ?"
Om du söker efter det i koden så förstår du vad jag menar.
Återkommer med en update och bild lite senare...
/Klas
Jo.
"Du sätter alltså RA4=1 och RA5=0, eller hur ?..."
Nja, jag har inte direkt kollat hastigheten sedan jag jorde det sisst. 2MHz var det ju sisst jag kollade om du mins?
"EDIT : "INITIALIZING CONTROLLER" och "SET BAUD RATE TO COMMUNICATE", är det något i din kod eller något annat ?"
Om du söker efter det i koden så förstår du vad jag menar.
Återkommer med en update och bild lite senare...
/Klas
OK, ett par snabba sakar utan att ha testkört koden...
Du tänder D0 via TRISA. Det *kan* fungera, bara man vet vad som ligger i PORTA. Är det avsiktligt du använder TRISA ? På ett ställe ser det ut som om du tänkte göra "MOVWF PORTA", men det står bara "BANKSEL PORTA" där. Kolla mot slutet, Är det som du har tänkt ? Blinkar D0 ungefär som är rimligt ?
En annan sak är att jag tidigare inte såg att MDLY är ett macro. Jag trodde att det var en subrutin som anropades med CALL (kollade dåligt). Nu skapas massor av kod varje gång macrot anropas. Kolla LST filen. Inte för att jag tror att det är rellaterat till dina problem, men i alla fall LST filen blir lite onödigt svårläst. Om man skall göra om det så är det lite som behöver ändras. HIGH och LOW fungerar inte, utan man får ladda HIGHI och LOWI först, sedan anropa MDLY med ett CALL (plus ändra lite till). Men som sagt, detta borde inte orsaka problem, så strunta i det tillsvidare....
Jag skulle ta bort "PULS" och bara lägga några bcf/bsf på strategiska platser i koden. Om det går för snabbt på LED'en för att se, så går det bra med oscilloskopet.
Jo, det är kanske lite svårt att direkt peka på något utifrån bilden, men ett par saker...
Du matar in 5V via de två kablarna upptill, eller hur ? Och sedan till båda PICkit1 och LCDn via några av de svarta kablarna ? Du har en gemensam "jord" mellan PICkit1 och LCDn ?
Kan du få LCDn i självtest genom att sätta serien ingången hög innan 5 V kopplas in till den ?
Hur många sladdar sitter i J3 (14-pol kontakten) och vad har de för funktion ? Det borde väll bara vara en sladd !? Seriesignalen till LCDn.
Är LCDns 5V kopplad till +5_SWITCHED (uttag 13 i J3) ? I så fall skulle jag flytta den till en fast 5V. Jag vet inte riktigt hur styr-procesorn på PICkit1 hanterar +5_SWITCHED...
Ja, lite att fundera på kanske...
Du tänder D0 via TRISA. Det *kan* fungera, bara man vet vad som ligger i PORTA. Är det avsiktligt du använder TRISA ? På ett ställe ser det ut som om du tänkte göra "MOVWF PORTA", men det står bara "BANKSEL PORTA" där. Kolla mot slutet, Är det som du har tänkt ? Blinkar D0 ungefär som är rimligt ?
En annan sak är att jag tidigare inte såg att MDLY är ett macro. Jag trodde att det var en subrutin som anropades med CALL (kollade dåligt). Nu skapas massor av kod varje gång macrot anropas. Kolla LST filen. Inte för att jag tror att det är rellaterat till dina problem, men i alla fall
LST filen blir lite onödigt svårläst. Om man skall göra om det så är det lite som behöver ändras. HIGH och LOW fungerar inte, utan man får ladda HIGHI och LOWI först, sedan anropa MDLY med ett CALL (plus ändra lite till). Men som sagt, detta borde inte orsaka problem, så strunta i det tillsvidare....Jag skulle ta bort "PULS" och bara lägga några bcf/bsf på strategiska platser i koden. Om det går för snabbt på LED'en för att se, så går det bra med oscilloskopet.
Jo, det är kanske lite svårt att direkt peka på något utifrån bilden, men ett par saker...
Du matar in 5V via de två kablarna upptill, eller hur ? Och sedan till båda PICkit1 och LCDn via några av de svarta kablarna ? Du har en gemensam "jord" mellan PICkit1 och LCDn ?
Kan du få LCDn i självtest genom att sätta serien ingången hög innan 5 V kopplas in till den ?
Hur många sladdar sitter i J3 (14-pol kontakten) och vad har de för funktion ? Det borde väll bara vara en sladd !? Seriesignalen till LCDn.
Är LCDns 5V kopplad till +5_SWITCHED (uttag 13 i J3) ? I så fall skulle jag flytta den till en fast 5V. Jag vet inte riktigt hur styr-procesorn på PICkit1 hanterar +5_SWITCHED...
Ja, lite att fundera på kanske...
"...Blinkar D0 ungefär som är rimligt ?"
Den blinkar väldigt rimligt tycker jag.
"En annan sak är att jag tidigare inte såg att MDLY är ett macro. Jag trodde..."
Justa, det blir ganska mycket kod när man kompilerar om man använder macron, men jag tror att jag skiter i det tills vidare och försöker hitta problemet till att det inte kommer upp på displayen.
"Jag skulle ta bort "PULS" och bara lägga några bcf/bsf på strategiska platser i koden."
Varför? Är det inte smidigare med en subrutin? LEDn blinkar fin iaf.
"Du matar in 5V via de två kablarna upptill, eller hur ? Och sedan..."
Nej. Jag matar ingenting. Däremot så får pickit1:et matning från USB:n. Från Pickit1:ets 5V-pinne på J3 går en sladd till LCDn. Från en annan pinne på J3 går en sladd till SER på LCDn. Jord kommer också från J3 till LCDn. 3 sladdar från Pickit1:et till LCD alltså. Andra sladdar på bilden är bara till för mätningar som jag gjort.
"Kan du få LCDn i självtest genom att sätta serien ingången hög innan 5 V kopplas in till den ?"
Ja.
"Är LCDns 5V kopplad till +5_SWITCHED (uttag 13 i J3) ? I så fall skulle jag flytta den till en fast 5V. Jag vet inte riktigt hur styr-procesorn på PICkit1 hanterar +5_SWITCHED..."
Hmm... Switched. Ja, det är den jag använder. Spänningen ser ruskigt stabil ut för att vara switchad. Spikrak på oscilloskopet.
/Klas
Den blinkar väldigt rimligt tycker jag.
"En annan sak är att jag tidigare inte såg att MDLY är ett macro. Jag trodde..."
Justa, det blir ganska mycket kod när man kompilerar om man använder macron, men jag tror att jag skiter i det tills vidare och försöker hitta problemet till att det inte kommer upp på displayen.
"Jag skulle ta bort "PULS" och bara lägga några bcf/bsf på strategiska platser i koden."
Varför? Är det inte smidigare med en subrutin? LEDn blinkar fin iaf.
"Du matar in 5V via de två kablarna upptill, eller hur ? Och sedan..."
Nej. Jag matar ingenting. Däremot så får pickit1:et matning från USB:n. Från Pickit1:ets 5V-pinne på J3 går en sladd till LCDn. Från en annan pinne på J3 går en sladd till SER på LCDn. Jord kommer också från J3 till LCDn. 3 sladdar från Pickit1:et till LCD alltså. Andra sladdar på bilden är bara till för mätningar som jag gjort.
"Kan du få LCDn i självtest genom att sätta serien ingången hög innan 5 V kopplas in till den ?"
Ja.
"Är LCDns 5V kopplad till +5_SWITCHED (uttag 13 i J3) ? I så fall skulle jag flytta den till en fast 5V. Jag vet inte riktigt hur styr-procesorn på PICkit1 hanterar +5_SWITCHED..."
Hmm... Switched. Ja, det är den jag använder. Spänningen ser ruskigt stabil ut för att vara switchad. Spikrak på oscilloskopet.
/Klas
"Den [D0] blinkar väldigt rimligt tycker jag."
OK, alltså 15 gånger, en gång för varje anrop till sendchar ?
Och för varje blink så skall det komma ett "tecken" på TX.
Jag tycker dock fortfarande att du har blandat TRISA och PORTA lite "osnyggt" i PULS. Det gör det svårt att verifiera att PULS gör det den är tänkt att göra. Men å andra sidan, p.g.a av det sätt som LEDarna är anslutna så kanske det är rätt... Del blinkar ju i alla fall...
Hm...
Ang 5V till LCDn...
Eftersom det inte framgår av manualen hur PICkit1 hanterar 5V_SWITCHED, så skulle i alla fall jag försöka hitta en garanterad stabil 5V. Jag gissar att huvudprocessorn på PICkit1 manipulerar +5_SWITCHED under själva programmeringen i alla fall. Är den helt stabil hela tiden ? Både under programmering och "drift" ?
Notera att "switched" här inte har något med switch-aggregat att göra !!
Det betyder bara att huvudprocessorn kan koppla bort den om den vill, t.ex i inledningen av en programmering av target-processorn. Så när den är "på" så är den lika stabil som den o-switchade 5 volten...
Nä, jag tror att vi måste fokusera på att få ut *någonting* på TX !
Jag ska ladda din senaste kod igen och se om det var något mer som jag gjorde som jag missade att säga föra gången...
Idéerna börja tryta...
/Janne.
r
OK, alltså 15 gånger, en gång för varje anrop till sendchar ?
Och för varje blink så skall det komma ett "tecken" på TX.
Jag tycker dock fortfarande att du har blandat TRISA och PORTA lite "osnyggt" i PULS. Det gör det svårt att verifiera att PULS gör det den är tänkt att göra. Men å andra sidan, p.g.a av det sätt som LEDarna är anslutna så kanske det är rätt... Del blinkar ju i alla fall...
Hm...
Ang 5V till LCDn...
Eftersom det inte framgår av manualen hur PICkit1 hanterar 5V_SWITCHED, så skulle i alla fall jag försöka hitta en garanterad stabil 5V. Jag gissar att huvudprocessorn på PICkit1 manipulerar +5_SWITCHED under själva programmeringen i alla fall. Är den helt stabil hela tiden ? Både under programmering och "drift" ?
Notera att "switched" här inte har något med switch-aggregat att göra !!
Det betyder bara att huvudprocessorn kan koppla bort den om den vill, t.ex i inledningen av en programmering av target-processorn. Så när den är "på" så är den lika stabil som den o-switchade 5 volten...
Nä, jag tror att vi måste fokusera på att få ut *någonting* på TX !
Jag ska ladda din senaste kod igen och se om det var något mer som jag gjorde som jag missade att säga föra gången...
Idéerna börja tryta...
/Janne.
r
