Nu har även jag "fallit i" med denna programmeringsenhet och då jag väl fick knåpat den ihop rätt är den ju härlig enkel!
MEN:
xwisp2w.exe är ju bedrövligt att jobba med! Man "ska" göra en batch-fil för enkelhetens skull, jag är van att ha ett fönster öppet där jag kan välja COM-port, fil som ska programmeras osv, faktisk ha 5 st tillgängeliga med var sin knapp som vid et klick programmeras in i processorn.
Därmed kan man ha den vanliga GUI och när man ska testa den nya versionen man just har kompilerat är det ALT-Tab, klick och ALT-Tab. Klart.
Jag kommer därför att greja "lite" med detta i mån av tid, min lösning kommer att fungera bådera som Command-line tool och, i brist på command-line, med GUI.
Anledningen är att min arbetsgivare kommer att behöva programmera PIC inom kort och det är mitt jobb att se till att de klarar det snabbt och enkelt.
Men innan jag skjuter iväg en del tid på sånt undrar jag: är det någon annan som har gjort detta innan? Man är ju dum om man uppfinnar hjulet fler gånger mot bättre vetande.
WISP628
Det finns ett GUI anternativ : http://home.hccnet.nl/d.a.kuipers/pic/bumblebee/
Varför man vill köra så, övergår dock mitt förstånd...
> Därmed kan man ha den vanliga GUI och när man ska testa den nya versionen man just har kompilerat är det ALT-Tab, klick och ALT-Tab. Klart.
Jag jobbar precis så nu :
- Build (i MPLAB)
- Alt-TAB (till cmd-fönstret med XWisp2)
- pil-up, enter
- Alt-tab tillbaka till MPLAB.
Jag har även en miljö dör MPLAB är ersatt av UltraEdit-32. Där har jag
definierat "knappar" i UE-32, så genom att klicka på en knapp, så :
- sparas alla modifierade filer
- anropas MPASM/MPLINK för att bygga projektet.
- anropas XWisp2 för att flasha om PICen.
Allt med ett enda "klick".
> i brist på command-line
När har man "brist på command-line" ?
> Anledningen är att min arbetsgivare kommer att behöva programmera
> PIC inom kort och det är mitt jobb att se till att de klarar det snabbt
> och enkelt.
Ska de alltså programmera PIC's i en produktionsmiljö från färdiga HEX filer ?
I så fall talar vi om en helt annan sak.
Ni har inte funderat på en "produktions-programmerare" ?
Det har lite med hur man verifierar PIC'en efter programmering.
Det finns två metoder, "development" och "production".
Vid "development" sker verifiering enbart vid 5V (om det är det man använder)
Vid "production" sker verifiering över den aktuella PIC'ens hela spänningsområde.
Ett exempel på en produktions-programmerare : http://www.embedinc.com/proprog/index.htm
Slutligen, om man ändå vill ha ett GUI alternativ, så skulle jag skriva
en "front-tend" till XWisp2, så att man inte behöver underhålla
alla programmerings algoritmer i sitt egen program.
Varför man vill köra så, övergår dock mitt förstånd...
> Därmed kan man ha den vanliga GUI och när man ska testa den nya versionen man just har kompilerat är det ALT-Tab, klick och ALT-Tab. Klart.
Jag jobbar precis så nu :
- Build (i MPLAB)
- Alt-TAB (till cmd-fönstret med XWisp2)
- pil-up, enter
- Alt-tab tillbaka till MPLAB.
Jag har även en miljö dör MPLAB är ersatt av UltraEdit-32. Där har jag
definierat "knappar" i UE-32, så genom att klicka på en knapp, så :
- sparas alla modifierade filer
- anropas MPASM/MPLINK för att bygga projektet.
- anropas XWisp2 för att flasha om PICen.
Allt med ett enda "klick".
> i brist på command-line
När har man "brist på command-line" ?
> Anledningen är att min arbetsgivare kommer att behöva programmera
> PIC inom kort och det är mitt jobb att se till att de klarar det snabbt
> och enkelt.
Ska de alltså programmera PIC's i en produktionsmiljö från färdiga HEX filer ?
I så fall talar vi om en helt annan sak.
Ni har inte funderat på en "produktions-programmerare" ?
Det har lite med hur man verifierar PIC'en efter programmering.
Det finns två metoder, "development" och "production".
Vid "development" sker verifiering enbart vid 5V (om det är det man använder)
Vid "production" sker verifiering över den aktuella PIC'ens hela spänningsområde.
Ett exempel på en produktions-programmerare : http://www.embedinc.com/proprog/index.htm
Slutligen, om man ändå vill ha ett GUI alternativ, så skulle jag skriva
en "front-tend" till XWisp2, så att man inte behöver underhålla
alla programmerings algoritmer i sitt egen program.
Tack för länken till bumblebee'n, den använder doch M$ runtime grejs så den går fet bort.
Rörande front-end har du ganska rätt, det vill ju vara oändligt mer enkelt att ge dom en front-end än ett hel jävla paket som ska uppdateras vid ändringer, bra tänkt.
Ska fundera lite på exakt vad de kommer att behöva och anpassa programmet efter det, dock är det inte aktuellt med en full-scale produktions programmeringsenhet....än iaf. Ska ha det i tankerna dock.
Rörande front-end har du ganska rätt, det vill ju vara oändligt mer enkelt att ge dom en front-end än ett hel jävla paket som ska uppdateras vid ändringer, bra tänkt.
Ska fundera lite på exakt vad de kommer att behöva och anpassa programmet efter det, dock är det inte aktuellt med en full-scale produktions programmeringsenhet....än iaf. Ska ha det i tankerna dock.
Nåväl, jag kör med commandline-versionen för tillfället.
Men ett annat problem har dykt upp:
utlöser
Jag har "Wisp628_110a.hex" i PIC16F628A'an på WISP'en...är det kanske felet? Det står ju dok. att det är den bug-fixade versionen...
Men ett annat problem har dykt upp:
Kod: Markera allt
org h'2100'
de d'0' ; Counted hours
de d'0' ; Counted days
de d'0' ; Counted months
de d'36' ; Target months
Kod: Markera allt
XWisp2 version 1.6.01 (Aug 14 2005, Open Watcom C 1.30)
File \PIC\SERVICETIMER.Hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.10
Detected target: 16F628A revision 08 (ID=1068)
Target erased
Transferring image to 16F628A via Wisp628
Transferring program memory...000000 : OK!
Verifying program memory......000000 : OK!
Transferring ID memory........OK!
Verifying ID memory...........OK!
Transferring data memory......Wbus command failure
004200 : failed after 3.61 seconds, rc 21!
XWisp2 failed after 4.59 seconds, rc 21!
-
JimmyAndersson
- Inlägg: 26578
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
Hoppar bara in med en snabb grejj:
I de allra flesta fall fungerar command-line-versionen för mina behov. "Pil-up" och Enter, som sagt, för att programmera kretsen igen.
Men I de fall när jag t.ex växlar mellan 3-4st hex-filer (tester och debugging) så skulle jag gärna vilja ha ett GUI med en lista på hex-filerna så man har bättre översikt. Visst, "dir *.hex" finns förstås, men något snabbjobbat GUI vore inte alldeles i vägen ändå...
I de allra flesta fall fungerar command-line-versionen för mina behov. "Pil-up" och Enter, som sagt, för att programmera kretsen igen.
Men I de fall när jag t.ex växlar mellan 3-4st hex-filer (tester och debugging) så skulle jag gärna vilja ha ett GUI med en lista på hex-filerna så man har bättre översikt. Visst, "dir *.hex" finns förstås, men något snabbjobbat GUI vore inte alldeles i vägen ändå...
Nu sk a vi se...
h'2100', det är EEPROM arean det.
Tja, det borde fungera.
Jag testade med en 16F870 (bara för att den redan satt i plattan) med
ett progam som fungerade OK tidigare. Jag la till :
(Jag använder "reloc mode" och "deeprom" er en section i LKR filen som
börjar på h'2100').
Hur som helst, allt byggde OK och gick och att flasha OK :
Få se, kör du den "patchade" varianten från robh.nl ?
Jag har (som du eer ovan) fortfarande originalet.
Du har inte kvar processrn till Wispen med firmware 1.09 ?
Alternativt om jag kan få "låna" hela din ASM fil och
prova den i en 628A med mina versioner av Wisp628/XWisp2.
Förresten, jag ser att du kör "XWisp2 version 1.6.01". Prova med en
senare XWisp2 från www.robh.nl. V1.8.1 är den senaste just nu..
h'2100', det är EEPROM arean det.
Tja, det borde fungera.
Jag testade med en 16F870 (bara för att den redan satt i plattan) med
ett progam som fungerade OK tidigare. Jag la till :
Kod: Markera allt
deeprom code
de h'01'
de h'02'
de h'03'
de h'04'börjar på h'2100').
Hur som helst, allt byggde OK och gick och att flasha OK :
Kod: Markera allt
C:\DATA\proj\Blink-a-LED\16F870>xwisp2w port 5 go blink-a-led
xwisp2 version 1.7.02 for Windows (Sep 25 2005, Open Watcom C 1.30)
File blink-a-led.hex loaded and is Intel Hex format conforming
Programmer Wisp628, firmware version 1.09
Detected target: 16F870 revision 01 (ID=0D01)
Target erased
Transferring image to 16F870 via Wisp628
Transferring program memory...OK!
Verifying program memory......OK!
Transferring ID memory........OK!
Verifying ID memory...........OK!
Transferring data memory......OK!
Verifying data memory.........OK!
Transferring fuses memory.....OK!
Verifying fuses memory........OK!
Write-Verify terminated successfully in 0.82 seconds
Putting target in run mode
xwisp2 terminated successfully in 2.23 seconds
C:\DATA\proj\Blink-a-LED\16F870>Jag har (som du eer ovan) fortfarande originalet.
Du har inte kvar processrn till Wispen med firmware 1.09 ?
Alternativt om jag kan få "låna" hela din ASM fil och
prova den i en 628A med mina versioner av Wisp628/XWisp2.
Förresten, jag ser att du kör "XWisp2 version 1.6.01". Prova med en
senare XWisp2 från www.robh.nl. V1.8.1 är den senaste just nu..
Update :
Det är verifierat att det fungerar OK med 16F648A, d.v.s
i princip samma som 628A med med lite mer minne.
Jag har kontakt med Rob Hammerling i Holland och han
kollar på det. Antagligen någon bugg i hanteringen av 628A...
Vill du att jag skickar över en eller ett par 648A så
att du kommer vidare så länge ? Så länge du ligger
under 2Kword kod, så fungerar de i princip likadant.
Det är samma datablad (40044x)...
Det är verifierat att det fungerar OK med 16F648A, d.v.s
i princip samma som 628A med med lite mer minne.
Jag har kontakt med Rob Hammerling i Holland och han
kollar på det. Antagligen någon bugg i hanteringen av 628A...
Vill du att jag skickar över en eller ett par 648A så
att du kommer vidare så länge ? Så länge du ligger
under 2Kword kod, så fungerar de i princip likadant.
Det är samma datablad (40044x)...
Jag är imponerat....och ganska nöjd med att jag inte är så dum som jag trodde 
Jag samplade 3 st. '628A OCH 3 st. '648A förra vecka så ditt erbjudande är mycket vänligt men inte nödvändigt. Tack i alla fall.
Jag kan alltså gå vidare med att ta bort sista buggen (i morgon) och skicka det vidare till kunden.
Tack för hjälpen än så länge.
Jag samplade 3 st. '628A OCH 3 st. '648A förra vecka så ditt erbjudande är mycket vänligt men inte nödvändigt. Tack i alla fall.
Jag kan alltså gå vidare med att ta bort sista buggen (i morgon) och skicka det vidare till kunden.
Tack för hjälpen än så länge.
Det är också nyss verifierat att 628A fungerar OK om man
använder original XWisp istället för XWisp2.
"Problemet" med XWisp är dock att det är skrivet i ett skriptspråk
som heter Python och kräver installation av ett par stora
runtime miljöer. Det var över 8.000 filer när jag kollade...
För den intresserade finns mer info på www.voti.nl.
Jag antar att Rob Hammerlig (som ligger bakom XWisp2)
kommer att kolla varför det skiljer mellan de två verktygen
i detta avseende.
Nu stänger jag för kvällen...
använder original XWisp istället för XWisp2.
"Problemet" med XWisp är dock att det är skrivet i ett skriptspråk
som heter Python och kräver installation av ett par stora
runtime miljöer. Det var över 8.000 filer när jag kollade...
För den intresserade finns mer info på www.voti.nl.
Jag antar att Rob Hammerlig (som ligger bakom XWisp2)
kommer att kolla varför det skiljer mellan de två verktygen
i detta avseende.
Nu stänger jag för kvällen...
Löst.
Det var en lite för "aggresiv" timing i config filen till XWisp2.
Felet ligger i xwisp2_14.cfg (eller xwisp2.cfg för versioner före 1.8.2).
Leta reda på följande ställe :
Ändra "Delay" till (minst) 50.
Notera att 648A lite längre ner i filen redan har 50 som delay...
Beroende på längd på sladdar, kvalitet på koppling m.m kan man, om
det fortfarande strular, prova med ett högre värde en 50. Jag har provat
med värden mellan 50 och 100 utan problem.
/Janne.
Det var en lite för "aggresiv" timing i config filen till XWisp2.
Felet ligger i xwisp2_14.cfg (eller xwisp2.cfg för versioner före 1.8.2).
Leta reda på följande ställe :
Kod: Markera allt
Name = 16F628A
DataSheet = DS41196E
Algorithm = PIC16C
DeviceID = 1060
ProgSize = 4K
DataSize = 128
ProtectMask = 2100
FuseFixedZero = 21FF
FuseFixedOne = 1E00
Delay = 40
Notera att 648A lite längre ner i filen redan har 50 som delay...
Beroende på längd på sladdar, kvalitet på koppling m.m kan man, om
det fortfarande strular, prova med ett högre värde en 50. Jag har provat
med värden mellan 50 och 100 utan problem.
/Janne.
