µC för nybörjare

[Magnus_K]

Tack för svaren.

@TomasL: Det här kommer jag titta på.
@sodjan och Icecap: Ok, förstår. Antagligen kommer jag inte ha något som helst behov än av högre frekvens än vad min PIC's INTOSC kan leverera på väääldigt länge.

Bara en ytterligare liten följdfråga; Hur märker man att man behöver högre noggrannet eller frekvens?

Ledsen om det blir lite många frågor men det är frivilligt att svara!

[TomasL]

Du märker att du behöver högre nogrannhet, när loopar mm inte stämmer i tid, eller att kommunikation RS232/SPI/I2C mm inte funkar.
Högre fart, när processorn inte hänger med och kan utföra det den tänkt att göra.

[adent]

I min Julljusstake jag gjorde så har jag en kristall (8MHz tror jag) eftersom den även är en "klocka". Jag kör en timer med nån neddelning, vi säger att det var 512. Så när timern har räknat till 15625 så har det gått en sekund. Då har jag mina egna variabler som jag räknar upp sekunder, minuter och timmar. Hade jag kört på intern RC-oscillator hade nog klockan dragit iväg ordentligt ganska fort. Med kristall handlar det om sekunder på ett dygn.

Vi genererade även videosignal i mjukvara en gång och körde med intern RC-oscillator. Då visade sig problemen genom att linjerna till video-signalen inte började på riktigt samma ställe. Klockan ändrar hastighet beroende på hur mycket processorn har att göra och hur mycket ström allt drog med mera. Så där syntes det tydligt att det var skillnad på kristall och intern RC-oscillator

MVH: Mikael

[sodjan]

> Hur märker man att man behöver högre noggrannet eller frekvens?

Det är ingenting som man "märker", det framgår av de krav som man har sammanställt.
Sedan jämför man de kraven med vad t.ex den interna oscillatorn presterar eller med vad
en extern kristall ger, då ser man ganska enkelt vad som krävs i det aktuella fallet.
Så det beror helt och hållet på kraven på det som du gör just vid det tillfället.

Om du från början vet att du behöver tex 0.1% onoggranhet, så finns det ju ingen anledning att
ändå köra med INTOSC (som ger ca 1-2% onoggranhet) för att sen "märka" att det inte duger.

> ...när loopar mm inte stämmer i tid

Loopar kommer *aldrig* att "stämma i tid" oavsett om man har kristall eller inte,
frågan är bara hur stor avvikelse som man accepterar.

[jesse]

Om det inte behöver vara någon precision på klockan så använder jag gärna den interna RC-oscialltorn. Känns onödigt att behöva sätta dit en kristall då. Men ska jag kommunicera med UART (RS232 / RS485 etc.) så vill jag vara säker på att den inte går för mycket fel, då sätter jag dit en kristall med en "bra" frekvens, t.ex. 3.6864 MHz - som då lätt kan användas till de vanligaste överföringshastigheterna utan fel. (till exempel så är 19200 baud = 3686400 Hz / 192). Är det gott om tid att utföra instruktionerna brukar jag sänka CPU-frekvensen internt till omkring 1 MHz - då drar processorn mindre ström. Är det mycket arbete som ska utföras på kort tid kanske jag väljer en kristall på t.ex. 19.66080 MHz (vilket är 1024 ggr 19200 baud).

[Magnus_K]

Tack för kanonsvar! Det räcker för att jag ska vara nöjd för tillfället!

[ie]

Jag har byggt ett antal projekt med AVR som har haft både UART och bitbangad seriekommunikation utan några problem. Jag har aldrig använt extern kristall/oscillator utan bara kört på den interna oscillatorn.

[Magnus_K]

Visste inte om jag skulle starta en tråd eller fortsätta på denna men det blev här till slut. Tanken var att dom flesta börjar nog tröttna på mig vid det här laget men då kan man alltid strunta i just den här tråden istället för en massa nyskapade trådar... (tankevurpa?)

Så till fråga. Vad är egentligen skillnaden på nedan (mikroC)exempel ?
Anledningen är att jag frågar är att jag kollade på en tutorial på youtube där han använde sig av alt 2. Det jag blev fundersam över var om inte det kan ställa till en del otyg eller alternativt använda mer minne? Eller ja, någon som kan förklara? Kanske finns för och nackdelar?
Känns spontant som om man vill har port-config utanför main eller har jag snubblat nu igen?

Kod: Markera allt

void main()
{
       TRISA = 0;
       KOD....
}

Kod: Markera allt

void init()
{
       TRISA = 0;
}

void main()
{
       init();
       KOD....
}

[adent]

Jag tror inte det där ger någon overhead alls. Skickar man in parametrar till funktionen kan det bli lite overhead.
Stackpekaren flyttas väl, men allt det där är egentligen försumbart.

Den stora vinsten är organisatorisk/mental i det här fallet. Ordning på torpet helt enkelt

Generellt så vill man använda funktioner när man kan, bryta ner stora problem till flera små och gärna
stoppa dem i funktioner. main() blir ofta väldigt tydlig då. Mycket lättare att förstå vad man gjort.

MVH: Mikael

[Magnus_K]

Låter väldigt klokt det du säger.. Kanon, tack. Nyttigt då man (mot förmodan) försöker strukturera tankesättet lite kring hur man planerar och programmerar.

[sodjan]

Desssutom, med de rellativt enkla exemplen, så är det mycket
möjligt att båda exemplen kommer att ge samma kod efter kompilering,
kompilatorn kan helt enkelt välja att göra om init() funktionen till
inline-kod (d.v.s så som i exempel 1).

Nu så spelar ju det ingen roll, *källkoden* i exempel2 kan ju
fortfarande i alla fall vara enklare att läs.

[Magnus_K]

Mycket intressant det du säger om att koden eventuellt skulle se likadan ut efter kompilering. Det skulle ju verkligen bevisa att ni har rätt i att det handlar mer om "ordning på torpet" än funktionallitet. Ska testa för skoj skull.

Tänkte slänga in en fråga till...
Köpte ju ett Pickit 2 (starterkit) innehållande en PIC16F690 (datablad) och pga pågående flytt så blir det mycket läsande snarare än labbande och kopplande.
I går satte jag mig ner med databladet och tänkte skriva en väldigt "enkelt" program i MikroC och försöka tyda databladet till punkt och pricka. Programkoden syns här nedan. Tydligen har jag inte följt det till punkt och pricka eftersom det orsakar fel vid kompilering.
Felen är relaterade till mina definationer inom init(). Från början hade jag skrivit:

Kod: Markera allt

     TRISA0 = 0;                 // Define port RA0 as output
     ANS0 = 0;                    // Define RA0 as digital (non-analog)
     C1ON = 0;                   // Disable comparator 1
     PCON = 0x00000000;     // Disable ULPWU (bit 5)

Varför fungerar inte ovan? Databladet säger "TRISA<5:0>: PORTA tri-state control bit". Tolkade detta som ytterligare ett sätt att sätta register TRISA bit 0, till 0 (output)...

Kod: Markera allt

 //*******************************************************//
 //  Microcontroller: PIC18F690                                                             //
 //  Program function: Blink LED 1 at power up                                         //
 //  Pin assignment:                                                                            //
 //           RA0 = LED 1                                                                        //
 //                                                                                                   //
 //*******************************************************//
 
void init() {
     TRISA = 0x00000000;         // Define all PORT A's as outputs
     ANSEL = 0x00000000;        // Define all analog ports as digital (non-analog)
     CM1CON0 = 0x00000000;    // Disable comparator 1
     PCON = 0x00000000;         // Disable ULPWU (bit 5)
                                          // Don't think ICSPDAT needs to be disabled since
                                          // "other" conditions will not be met.
}
 
void main() {
     init();
     while(1){
              PORTA.RA0 = 1;
              Delay_ms(500);
              PORTA.RA0 = 0;
              Delay_ms(500);
     }
}

EDIT: Förtydligande

[sodjan]

> Varför fungerar inte ovan?

*Vad* fungerar inte? Det vore väldigt märkligt om du inte också
fick något slags felmeddelanden !?

Jag har bestämt för mig att MicroC manualen har ett kapitel som beskriver just bit-operationer
mot register. Det finns flera varianter av MikroC, men en t.ex detta förklarar ju det:

Kod: Markera allt

Accessing Individual Bits Of Variables

If you are familiar with a particular MCU, you can access bits by name:
  // Clear Global Interrupt Bit (GIE)
  GIE_bit = 0;

Also, you can simply use the direct member selector (.) with a variable, followed by
one of identifiers B0, B1, … , B7, or F0, F1, … F7, with F7 being the most significant
bit:
  // Clear bit 0 in INTCON register
  INTCON.B0 = 0;
  // Set bit 5 in ADCON0 register
  ADCON0.F5 = 1;

> Varför fungerar inte ovan? Databladet säger "TRISA<5:0>: PORTA tri-state control bit".
> Tolkade detta som ytterligare ett sätt att sätta register TRISA bit 0, till 0 (output)...

Det som databladet säger har inget med MicroC att göra.
Du måste kolla hur *MicroC* har valt att definiera det!
Det är det som dokumentationen är till för.

Det är lite underligt, om jag söker på "bit" i MicroC manualen så är tredje träffen
en rad i indexet som säger "Accessing Individual Bits . . . . . . . . . . . . . . . 119"
och på den sidan står det som jag har citerat ovan, hittade du inte det?

OK, det finns flera versioner av MikroC (och jag kan ha en gammal manual) så läs
den manual som hör till just den MikroC version som *du* använder.

> Mycket intressant det du säger om att koden eventuellt skulle se likadan ut efter kompilering.

Ja, i detta fall eftersom init() enbart innehåller en enda rad. Med flera rader så är det
inte säkert. Å andra sidan så anropas bara init() från en plats, och det kan också få
optimeraren att lägga det "inline". Spelar kanske inte så stor roll, det viktiga är att
källkoden är lättläst.

[Magnus_K]

Aj då, hjulet snurrade men hamstern var död.. Nej jag hittade inte det då jag inte ens förstod att detta står i programmets dokumentation.
Tack för hjälpen sodjan.

[sodjan]

OK.
Det bör fungera om du bara rättar till det enligt dokumentationen.
Där står för övrigt även:

Kod: Markera allt

Predefined Globals and Constants

To facilitate programming of PIC compliant MCUs, the mikroC PRO for PIC
implements a number of predefined globals and constants.

All PIC SFR registers and their bits are implicitly declared as global variables.
These identifiers have an external linkage, and are visible in the entire project.
When creating a project, the mikroC PRO for PIC will include an appropriate (*) file
from defs folder, containing declarations of available SFR registers and constants.

For a complete set of predefined globals and constants, look for “Defs” in the mikroC
PRO for PIC installation folder, or probe the Code Assistant for specific letters
(Ctrl+Space in the Code Editor).