Svenska ElektronikForumet

JustNeed: Du har nog inte förstådd det där riktigt...
#pragma config |= 0x3F2A sätter INTE din config till 0x3F2A!!!

Ska du göra det på det vis ska raden heta:
#pragma config = 0x3F2A

Som det är nu gör du en bit-vise OR med 0x3F2A enl:
#pragma config = config OR 0x3F2A

Och då config från start är ???? (okänd) har du inte ett smack koll på vad din CONFIG egentligen är.

sodjan: Det är möjligt att det går att göra på ett mer lättläst sätt men det är så jag har skrivit det Försökte att skriva ut det mer lättförståeligt också men jag kanske missade något.

Icecap: sättet att skriva är ctrl+c, ctrl+v från början och det har funkat hittills även när jag har satt om config så det kan inte vara det som är problemet.

Jo, det kan det!

Men OK, vill du inte ha svar kan jag väl skita i dig!

Ha det bra och lycka till, du lär behöva det!

jag känner att det börjar spåra lite.
Icecap: Jag ber om ursäkt om jag verkar dryg. Vad jag ville säga var att jag alltid har skrivit så utan bekymmer.
Det är helt upp till dig om du svarar eller inte, men "lycka till" är definitivt ett svar jag klarar mig utan.

on topic: jag har inte kopplingen här, men jag tror det löser sig själv om jag får sova lite.

PS. Jag googlade lite kodexempel och det verkar vara så man skriver i cc5x helt enkelt (såg förövrigt att det gick att skriva hela raddan med inställningar ex pragma config = _PWRTE_ON & _WDT_ON & _LP_OSC osv också). Orkar inte ta reda på varför just nu dock.

> pragma config = _PWRTE_ON & _WDT_ON..... o.s.v...

Exakt. Så ska det ser ut. Då går det faktiskt att se vad du gör.

> och det verkar vara så man skriver i cc5x helt enkelt

Hm, kanske det, det verkar väldigt snurrigt det hela.
I de exempel som din länk går till så sätts antingen "#define CP_off |= 0x3F30"
(så att det går att använda i pragma config senare), eller så sätter man
"#pragma config |= 0x3F71" *efter* att man har satt "#pragma config" till
något känt, och då kan en OR kanske fungera.

Varför har man inte lagt in dessa "# define" för alla rellevanta CONFIG bitar
i respektive .H fil för varje "supportad" processor ? Verkar väldigt slappt
från leverantören.

[Lite senare...]

Jo, nu vet jag varför man måste skriva på det där sättet...

Knudsen påstår att CC5X stöder en lång rad av processorer, men för många (d.v.s
i princip alla nyarna modeller) så gör de det inte alls. De enda fördefinierade
symbolerna för pragma config är PWRTE, WDTE, FOSC, BODEN och ID. För
övriga för man definiera upp sina egna symboler. Visst det beskrivs lite
övergripande på sidan 53 i manualen, men väldigt ytligt. Om man kollar
lite hur .H filerna är uppbyggda så ser man att det är en produkt som en gång
skrevs för några äldre processorer. Sedan har man byggt på med stöd för senare
modeller. Se t.ex hur de i H filen anger att vissa register är "predefined", medan
andra läggs till. Symboler för nyare CONFIG saknas helt, alltså finns bara de
ursprungliga för de där gamla processorerna fördefinierade. Ta en 16F886
t.ex, den har 14 CONFIG bitar. Och de 5 som är fördefinierade stämmer
inte överens med de faktiska. BODEN i CC5X heter i dag BOREN0 och BOREN1
för att ta ett exempel.

Här gäller det verkligen att veta vad man gör och studera de delar av databladet
som ofta hör de lite mer svåra att greppa. Inte direkt något för en nybörjare.

Personligen är jag inte speciellt imponerad av produkten, om jag nu inte har
missförstått allt. Det verkar vara en gammal produkt som med lite konstgjord
andning kan fås att fungera till nyare processorer, men inte utan att man
som användare vet vad man gör (eller följer exempel i forum utan att
riktigt förstå dom). Men men, jag har aldrig kollat på produkten tidigare
så det kan finnas något som jag har förbisett.

Mina erfarenheter av BKND (och övriga Demo-kompilatorer):

De två största fördelarna är att det inte är strikt C utan tillåter ex PORTB.2 = 1, vilket underlättar övergång från Assembler (försök med detta i Hitechs eller Microchips) samt att koden faktiskt optimeras bra. Pröva ex att "blinka LED" och "skriva LCD" genom ovan nämnda produkter så skall ni se. MikroC utmärker sig i denna tävling och priset för att få med gratis bibliotek är högt.

Stor nackdel är att kompilatorn inte förstår komplicerade uttryck. Alls. Men detta leder ju endast till mer text på skärmen och inte större hex-fil.

CONFIG skrivs inte på samma sätt i någon kompilator jag sett. Likaså hur stor en INT är eller om den är signed by default, så man måste ALLTID kolla i manualen samt i de filer som följer med kompilatorn. Och jämföra med de filer i MPLAB som beskriver samma processor. Just config minns jag som lurigt, men genom att ta fram PIC-datablad över registren (2A, 3B osv) och inte använda namn som "PWRT" så var det bara att köra så det rök. Upp till 2K ord, alltså.

JustNeed: Jag ska vara juste och förklara dig VARFÖR "#pragma config |= 0x3F2A" är fel.

Att ange de olika _PWRTE_ON osv. är självklart enklast att läsa men med en ordentlig kommentar går det att ge just ett (hexa)decimalt värde.

Men du DU gör med "#pragma config |= 0x3F2A" är att göra en bitwise OR med "det förra värdet" och 0x3F2A och då du inte VET vad config var INNAN kan du inte säga vad det är EFTER utom att just vissa bits är ställda till '1'.
och hur säkert är det då att det står rätt?

Config kan alltså vara:
0x3F2A (som är rätt) eller
0x3F2B eller
0x3F2E eller
0x3F2F eller
0x3F3A eller
.... nåja, ids inte skriva alla 128 kombinationer som är möjliga, jag tror att du fattar (borde fatta iaf.)

Att det har fungerat tidigare tillskriver jag turen och inte skickligheten. Läs lite trådar, det finns en del "men den inställning står så per default..." och när rätt inställning sedan testas blir det ofta: "hoppla... default var vist inte default ändå..."

Du antar alltså felaktigt att den fel du upprepar är OK men att köra en bitwise OR med ett okänd värde och anse att man får ett fast värde av de ÄR felaktigt!!!

Hade du istället skrivit "#pragma config = 0x3F2A" hade det varit OK (men kanske inte så lättläst) och sedan kan du förkasta det allt du vill, jag har likaväl rätt i detta!

Att upprepa ett fel många gångar och sedan påstå att det är rätt är helt enkelt fel ändå.

> CONFIG skrivs inte på samma sätt i någon kompilator jag sett.

Nej, det är därför varje produkt har en egen manual...

Det var inte det det gällde, utan att de bara har definierat upp
symbolen för en mindr del av de olika CONFIG bitarna, resten
får man lista ut själv. Dåligt.

Icecap: Ja, du har naturligtvis rätt i att det inte räcker med |= för att sätta ett register om man inte nollställer det innan.
Jag har undersökt lite och konstigt nog funkar det inte att sätta registret med = i äldre versioner av cc5x så det kan vara därifrån det kommer.

Läste lite i manualen till cc5x (kapitel 4.3) och där står det The default setting of the attributes is 0.
Jag tolkar det som att defaultvärdet av config sätts i kompilatorn till 0 vilket skulle förklara varför det skulle fungera att sätta den med |=
Assemblyfilen från kompilatorn har iaf samma kod hur man än sätter det. Alltid en enda rad, oavsett hur komplicerat man skriver i c-filen. Samma oavsett om man skriver |= eller = eller &:ar allt.
I det här fallet funkar det alltså att skriva som jag har gjort eftersom kompilatorn fungerar så. Det är visserligen kanske det mest svårtydda sättet att göra det, men det funkar alltså i CC5X.

Det var den delen av manual jag menade tidigare. Problemet där är :
> "<id> : PWRTE, WDTE, FOSC, BODEN, ID", det är alltså bara dessa bitar
som finns fördefinierade i kompilatorn. Resten får man antingen skapa
själv eller (som du har gjort) handjaga ihop ett HEX värde som stämmer
(antagligen den sämsta metoden, oavsett om det "fungerar" eller inte).

Ska man ha symboler för CONFIG bitarna alls så ska det vara komplett.

Visst är det bökigt. Och kräver mer dokumentation. Å andra sidan så räcker det med att programmera en enda sorts PIC för majoriteten. Bifogar lite från ett gammalt proj, och ser själv att kommenteringen är ngt bristfällig.
[/code]

Jo, och varför var det nu igen som man skulle använda "enklare"
verktyg som t.ex C istället för assembler ? Var det inte för att göra
det hela enklare ?

Det är inte speciellt lätt att från din kod direkt se hur en viss CONFIG
option är inställd. Och notera att *kommentarer* i just detta fall inte hjälper,
det bör gå lätt att se att koden faktiskt gör det som kommenteren säger.

En felaktig/gammal kommentar till en oläslig kod gör mer skada än nytta !

Det visade sig att problemet inte är att picen bara går att programmera en gång, utan att xwisp2w hänger sig ibland. att det funkade första gången på två olika chip men inte andra var antagligen bara en slump.
Nu kan jag programmera som vanligt, men ibland hänger det sig och om jag startar om så kommer inte programmet åt porten. Det löser sig om man startar om datorn. Jag kör med USB-Serial converter så det kan vara en anledning.
Någon annan som har haft problem med att Xwisp2w hänger sig? Kan man anta att problemet ligger innan wisp648:an (d.v.s serieport, dator, användare) eller kan det lika gärna vara fellödning eller skum koppling hos målchipet?

Jag har ibland problem med USB-dongeln, speciellt om den sitter till ett experiment och man bryter & slår på strömmen. Då får den "lite spader" och jag får unplugga den, ge systemet 10 sek och sedan plugga in den igen, då brukar det fungera igen.

Jag kör med en USB/RS232 dongle från Clas Ohlson och det enda
jag har upplevt är att drivern ibland byter port (COM5 eller COM6).
Ingen aning om vad det beror på. Det är dock samma så länge
som man inte stänger ner Windows. Inga andra hängningar så
vitt jag minns.