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.
Pic går bara programmera en gång?
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.
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.
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.
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.
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.
-
spaderkung
- Inlägg: 138
- Blev medlem: 12 maj 2007, 11:24:24
- Ort: Sjöbo
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å.
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å.
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'.
Kod: Markera allt
xxxx xxxx xxxx xxxx
OR 0011 1111 0010 1010
= xx11 1111 xx1x 1x1x
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å.
Senast redigerad av Icecap 16 februari 2008, 11:38:02, redigerad totalt 1 gång.
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.
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
Kod: Markera allt
PICmicro configuration information can be put in the generated hex and assembly file. ID locations can
also be programmed. The configuration information is generated IF AND ONLY IF the #pragma config
statement is included.
Note that some PICmicro programming devices may reject this information, especially setting of the ID
locations.
Syntax:
#pragma config <id> = <state> [, <id> = <state>]
<id> : PWRTE, WDTE, FOSC, BODEN, ID
<state> : on, off, LP,HS,XT,RC, <number>, ~<number>
#pragma config WDTE=off, FOSC=HS
#pragma config WDTE=0, FOSC=2, PWRTE=1
#pragma config |= 0x100 // set bit 8
#pragma config &= 0xFFFC // clear bit 0 and 1
#pragma config &= ~3 // clear bit 0 and 1
More than one #pragma config statement is possible. 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.
Kod: Markera allt
__config 0x2007, 0x3F2A
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.
> "<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.
-
spaderkung
- Inlägg: 138
- Blev medlem: 12 maj 2007, 11:24:24
- Ort: Sjöbo
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]
Kod: Markera allt
/****************************************************************/
/*
CONFIG
[1][0] 1H1L
[3][2] 2H2L
[5][4] 3H3L
[7][6] 4H4L
[9]∞ 5H5L
[b][a] 6H6L
Device specific! 18F2620
*/
#pragma config[0] = 0x00 // Not used (ff, but winpic reads as 0)
#pragma config[1] = 0x02 // ExtRCIO67:0x08, HS:0x02
#pragma config[2] = 0x19 //
#pragma config[3] = 0x1e //
#pragma config[4] = 0x00 // Not used (winpic reads as 0)
#pragma config[5] = 0x81 //
#pragma config[6] = 0x81 //
#pragma config[7] = 0x00 // Not used (winpic reads as 0)
/***********************************************************/
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 !
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?
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?
