Fuse-bitar i PIC?

[oJsan]

Någon som vet när/var fuse-bitarna i en PIC bränns?
Jag använder C-kompilatorn PICC, integrerat i Mplab. Där finns det ett pre-processordirektiv som heter "#fuses" med vilket man kan stänga av watchdog m.m.
När jag kompilerar i Mplab genereras hex-filen som jag sedan använder i ett separat program som tillhör min programmerare "PICkit 2".
I Mplab finns även ett menyval för "configuration bits". Gör dessa override på de som sätts i koden, eller gäller den inställningen bara om man programmerar kretsen inifrån Mplab? Sparas inställningarna för fuse-bitar i hex-filen?

Många frågor... beror på att jag egentligen är ett avrfreak =) Någon som vill räta ut några frågetecken?!

[Icecap]

På MikroC sätts dessa i HEX-filen men hur det är i PICC har jag ingen aning om!

[oJsan]

Sätts de då utefter ett pragmadirektiv eller sätts de med hjälp av inställningar i Mplab eller programmet för att bränna hex-filen?

[spaderkung]

När jag bränt med WinPIC så verkar det som om det man satt i MPLAB inte spelar någon roll mer än att MPLAB skall veta procesor osv. Fusarna sattes alltså i programmeraren.

[bengt-re]

"riktiga" programmerare kan man välja om man tar fuses ifrån HEX filen ELLER overrida dem med inställningar i programmeraren.

[oJsan]

Anledningen att jag frågar är att jag har gjort ett program som fungerar utmärkt när jag bränner med PICkit2 (där det inte finns möjlighet att ändra fuse-bitarna) men när skickar hex-filen till vår fabrik lyckas de inte bränna. Jag vet inte vilken programmerare de använder men jag misstänker att det är skit-bakom-spakarna så att säga, att de overridar inställningarna i hex-filen.

[bengt-re]

Kan också vara strul med hex-formatet. Lusläs lite så inser du vad jag menar, det finns tyvärr mer än ett möjligt hexformat. Ett bra tips är att använda microchip direkts programmeringstjänst och beställa kretsarna därifrån färdigprogramerade - de skickar alltid utvärderingsprover på din firmware också. Billigt, tryggt och bra

[bengt-re]

Och en annan sak, de kan ge dig både färgpluttar och sätta på en label med firmware utgåva eller liknande.

[oJsan]

Har inte sett Microchip Direct förut, intressant. Men jag har svårt att tro att det blir så mycket billigare/enklare än att en kinafabrik programmerar och sätter label.

[sodjan]

> Jag vet inte vilken programmerare de använder

Jag skulle fråga !
Som utvecklare är det ju väldigt viktigt att ha kontroll på hela processen.
Det låter smått otroligt att du inte vet vad de använder för utrustning.

> när skickar hex-filen till vår fabrik lyckas de inte bränna.

Vad är felsymptomen ?

> ...att de overridar inställningarna i hex-filen.

Det ska väl inte hindra att man *bränner* koden. Däremot så kanske den
inte uppför sig som utvecklaren hade tänkt när de försker *köra* koden...

> I Mplab finns även ett menyval för "configuration bits". Gör dessa override på de som sätts i koden, ?

Detta beskrivs på ett, som jag såg det, tydligt sätt i online hjälpen i MPLAB.
Koden har högst prio och ersätter alltid det som sätts i IDE'n vid varje "build".
Undantaget, som jag förstog det, är vid ICD då man kan ändra CONFIG i
IDE'n on-the-fly. Tror jag, det var inte helt solklart där...

Hur som helst, vid en *build* (d.v.s då man skapar en HEX fil) så gäller
kodens inställningar i första hand. Och IDE'ns CONFIG fönster kommer att
uppdateras med kodens inställningar.

Personligen gillar jag inte programmerare där man kan ändra CONFIG
inställningar hur man vill.

PS: "Fuses" har jag aldrig hört talas om i samband med PICs...

[oJsan]

Jag har frågat, men pga tidsskillnaden så tar det tid att få svar ibland. =) Vet i princip att de försökt programmera våra PIC, att de använder Mplab + någon programmerare. Först påstod de att programmet inte gick igång (ingen aktivitet i apparaten). Senare lät det som att programmet inte gick att bränna... (inte alltid man får så utförliga förklaringar...)
Men som sagt, utredning pågår, dom vaknar väl snart.. så i morgon bitti har jag förhoppningsvis lite mer info.

Vi litar på att de kan programmera våra PIC-processorer, de har det gjort förr utan problem. Den här gången krånglar det och då försöker vi reda ut vad som är fel.
Ja visst är det smått otroligt!! Kan knappt förstå det själv! *ironisk*....
(finns ju ingen anledning att ha koll på hela processen)

Vad jag kan utläsa av dokumentationen för Mplab så har kodinställningar högsta prioritet (finns ingen inställning i koden används configurations-menyn). Men då måste man alltså förutsätta att programeraren inte ändrar konfigurationsbitarna... vilket inte min programmerare gör.

PS: Ok, vi säger väl "configuration bits" istället då... PIC är som sagt var inte hemma-arenan, men nu har jag ju lärt mig lite mer...

[bengt-re]

*ler*

Jo, visst, men det fina med microchip direkt är att man kan köra sina programmerade PICár som komponentnummer i BOMén och ge legotillverkaren tillstånd att beställa därifrån. Blilligt, 100% säkert på att det bara är äkta kretsar och mycket strulreducerande.... Det andra alternativet att förse alla slutanvändarkort med programmeringskontakt kan vara vettigt på lågserieprylar där inte platsen är sååå viktig, men i större volym så är det bättre att se till att kretsarna är laddade med antigen sin önskade fimware eller med en bootloader så att man senare enkelt kan uppgradera via något interface man redan har på kortet (om man nu har något...)

Men alla projekt har sin egna regler. Personligen tycker jag dock att det är ett tryggt sätt - man får hem en testkrets och fungerar den så KOMMER det att fungera det som volymbeställs. Träligt med en batch kort med inlödda uC med fel eller inget programm, speciellt om man inte har någon "nåldyna" eller programmeringskontakt.

[oJsan]

I vårt fall skulle det innebära mer krångel än fördel att använda Microchip Direct, men idén är ju smart!

Har nu fått veta att det rörde sig om "wrong settings" när de programmerade våra kretsar... inte så vidare uttömmande svar från deras sida precis, men dom hade alltså gjort fel när de programmerat PIC:en.

[bengt-re]

Skönt att det löst sig iaf - sånt där kan bli otrevlig annars....