Sida 3 av 4
Postat: 25 juli 2007, 01:27:37
av marcusg
Jag har alltid kopplat in den vita kabeln från wisp628 till LVP (pin10). Har i efterhand läst att det i vissa fall är onödigt, men då jag inte sett att det kan innebära någon skada att göra det så har jag fortsatt att koppla in alla kablar...
Hela projektet finns nu på
http://marcus.ax/filer/SerialServoDriverTx.zip.
OBS! Eftersom en av filerna (rs232.asm) inte låg i projektmappen var jag tvungen att ta bort den från projektet, kopiera filen till projektmappen och sedan lägga till den nya rs232.asm i projektet. Hex-filen ändrades då på några ställen, men det finns med en fil kallad 'Kopia av SerialServoDriverTx.hex'. Den filen är en kopia av den hex-fil som fördes över till picarna.
Jag får lov att återkomma imorgon, klockan är 02.30 här...
Postat: 25 juli 2007, 11:27:16
av sodjan
OK.
Jag ska test-flasha din HEX fil senar i dag så får vi se vad som händer.
Sen tycker jag att du ska lägga till CONFIG2 också.
Annars var det väl inget speciellt, några småsaker som inte har med
flashnings problemet att göra (som att testen av TXSTA, TRMT och laddningen
av TXREG skulle kunna vara i annan ordning för att inte vänta i onödan)...
EDIT:
Det fungerar *oftast* utan den vita LVP kabalen, men om man ansluter den
så sköter Wisp628 om pinnen när det behövs...

Postat: 25 juli 2007, 11:43:44
av marcusg
Programmet är som sagt ett snabbt hopkok, en tredje gradens omskrivning av ett gammal test - taskigt skrivet och ännu sämre kommenterat! Tanken var (är) att snabbt testa om mina idéer fungerade (de externa komponenter och kopplingar jag använde, etc). Om det fungerade så skulle jag börja och skriva ett nytt program helt från början, och t.ex. läsa in mig ordentligt på A/D. Nu var målet bara att få det att fungera för detta test
Tack så mycket för att du (och många andra) tar sig tid att hjälpa till!
Postat: 29 juli 2007, 20:11:52
av Christopher
Hittade ni någon lösning?
Misstänker att jag har samma
problem.
Postat: 29 juli 2007, 21:19:53
av sodjan
Vilka "ni" ??

Det är inte jag som har problemet, och jag har inte
testat marcusg's program (än)...
Postat: 31 juli 2007, 00:26:37
av marcusg
Satte ihop adaptern jag köpt för att kunna programmera kretsar med Internal-MCLR. Har just testat att programmera en av de strulande PICarna med adaptern inkopplad, men med samma dystra resultat som tidigare.
Använder din 1A@5V för labbplatta, sodjan - när jag använder kretsen för Internal-MCLR (som alltså kortslutet strömförsörjningen en kort stund), skall detta märkas på något sätt? T.ex. att LEDen på 1A@5V blinkar, eller så? Jag märkte ingen skillnad mellan att använda Internal-MCLR-adaptern eller ej - LEDen lyste hela tiden, och varken 7805an eller TIP120an blir ens lite varma. Kan ju hända att adaptern inte fungerar (felkoppling, defekt el. dyl.), så jag skulle vilja veta hur jag kan vara säker på att den fungerar.
Postat: 31 juli 2007, 01:39:14
av sodjan
Jag vet inte exakt hur *länge* den kortsluter spänningen, men Wouter's hemsida
säger "a few milliseconds", så man kanske inte hinner se det...
Det är bara (eller ska bara vara) under tiden som Vpp hinner
upp till 13V. Sen, eftersom trissan i den lilla adaptern ju kortsluter
spänningen, så fårt det inte sitta *allt* för mycket capacitans på
5V'en. Det sitter 100uF på den lilla 5V-PSU'n, och jag vet inte på
rak arm om detta är för mycket för trissan eller inte...
Vi fortsätter tisdag...
EDIT:
Det vore också bra att få allt annat verifierat, d.v.s Wisp628 med en
annan PIC och ett annat program. Har du kollat Wisp628'an så att
det inte har hänt något där ? Glapp i en lödning eller något.
Postat: 31 juli 2007, 08:22:22
av marcusg
Wispen fungerar såvitt jag förstår utmärkt. Suttit och testat lite i helgen med två 16F688, och det har inte varit några som helst problem. T.o.m. 'xwisp2w PASS AUXI [...]' fungerar.
Skulle kanske vara värt ett försök att ta bort 100uF från 5V-PSUn? Eller ta en 16F683 och slå på Internal-MCLR - så man ser om adaptern fungerar som den ska...
Postat: 31 juli 2007, 08:26:10
av Icecap
En enklare lösning ville kanske vara att ha ett låg-Ω motstånd mellan matningen och PIC'en, kanske 27Ω, självklart en 100nF kondensator över PIC'en och sedan testa igen. Då behöver du inte löda.
Postat: 31 juli 2007, 16:19:38
av marcusg
Har nu provat lite saker. TIP120an på adaptern fungerar, så själva adaptern bör fungera. Lyckades en gång få datorn att känna igen en av de strulande PICarna, men då får jag samma fel som när jag skriver 'target 16F88':
Transferring program memory...OK!
Verifying program memory.......failed at 000000, expected: '0000', found: '3FFF'.
Testade även med ett motstånd mellan 5V och PICen. Gav inget resultat (hade dock motståndet där när PICen kändes igen den där enda gången).
Postat: 31 juli 2007, 16:33:49
av sodjan
Du ska *aldrig* behöva använda "target" för en modern PIC.
Kan Wisp628 inte läsa ID från PIC'en, så kan den ganska säkert
inte heller programmera den.
Har du lagt till den andra CONFIG raden ?
Hur ser dina nuvarande CONFIG ut ?
Postat: 31 juli 2007, 16:53:09
av marcusg
CONFIG-raden på PICen är givetvis den som jag nämnt i början på detta träd... Programmet som jag nu försöker föra över ser ut så här:
Kod: Markera allt
LIST p=16f88
include "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
nop
Loop
nop
goto Loop
end
Testade med target en gång förut på dessa två PICar, och kunde då konstatera att PICen förblev oförändrad - PICen körde exakt samma program som innan jag försök med target...
Postat: 31 juli 2007, 17:59:33
av sodjan
OK.
Jag tror att du har något helt annat problem än de som vi har
diskuterat så här långt, något som inte har lyckats "lysa igenom" här än...
Kanske en bild av det hela skulle kunna ge lite nya ideer ?
Postat: 31 juli 2007, 18:50:25
av marcusg
Fantastiskt! Lyckades programmera om båda PICarna nu! Är inte helt säker på hur det gick till, men jag har en gissning.
Kopplade ihop på nytt för att ta en bild, som ni kan se nedan. Fick det plötsligt att fungera en gång, men sen vägrade det igen. Kände numera igen processorn, men programmeringen falerade. Kopplade då bort motståndet mellan MCLR och 5V (invid Vdd för PICen), och då fungerade det utmärkt igen. Kopplade bort Internal-MCLR-adaptern, och konstaterade att det nu fungerade även utan den. Lade i den andra PICen, men då krävdes åter igen adaptern för den första omprogrammeringen. Därefter kunde även den programmeras utan adaptern.
Jag har testat utan det motståndet förut, men så vitt jag minns har jag inte testat utan det sedan jag stoppade ett 47?-motstånd mellan 5V-Vdd. Hade först ett 27?, men det måste ha varit för litet. Jag antar dessutom att motståndet mellan MCLR och Vdd (10k) gjorde så att PICen iaf fick ström via den spänning Wispen lade på MCLR.
Kan detta vara en möjlig förklaring? Kan fortfarande inte förstå varför det skulle vara Internal-MCLR på de där PICarna, dock.

Postat: 31 juli 2007, 18:57:17
av v-g
Den spretiga kabeln som används ska BORT. Använd telekabel eller dylikt, dvs den varianten som sitter i din WISP.