Svenska ElektronikForumet

Varför kod som skiftar 258 steg? Det motsvarar ju ungefär 10 upphöjt till 77, vilket närmar sig mängden atomer i universum, typ. Känns lite underligt.

Morten: Shift med mer än 8 positioner behövs helt klart om det är en mer-än-8-bit CPU.
Det behövs upp till processorns databredd faktisk.

Men ja, 258 är ganska orealistisk och tyder på att programmörn inte har helt koll på variabler osv.

Är man i behov för att shifta en sammansatt variabel, t.ex. 64 bit i en 32-bit CPU får man fixa lite i programmet för att lösa detta.

Vänster-skift-operatorn i C (<<) är faktiskt exakt definerad hur den skall funka.

Ex. a << b

Den andra operanden, b i exemplet ovan får ej vara negativ och ej större än eller lika med första operandens längd.
Vad som i så fall händer är odefinerat.

Det är alltså definerat som att vara odefinerat, eller i praktiken är det den som tillverkar kompilatorn som bestämmer vad som skall hända.

Man SKALL alltså se till att andra operanden (b i exemplet ovan) ligger inom korrekta gränser.

Icecap skrev: ↑12 oktober 2021, 18:16:05 Morten: Shift med mer än 8 positioner behövs helt klart om det är en mer-än-8-bit CPU.
Det behövs upp till processorns databredd faktisk.

Det Morten menar är att det behövs inte mer än 8 bitars värde för att shifta 256 bitpositioner.
Tekniskt sett räcker det med 5 bitars värde för att täcka en 32 bitars cpu.

Precis, och barrel shiftern inne i CPUn har inte större shift-range än vad som behövs. Då skulle shiften ta flera klockcykler. Sedan är ju många CPUer RISC, och då kan man ju få in shiftvärdet som en del av instruktionen också. Annars blir det segt:-)

Shiftvärdet (hur många steg som ska shiftas) kan ju bara läggas in som en del av instruktionen om det är ett fast värde. Är det en variabel så krävs ju ändå att värdet laddas först i något register.

Jag hjälpte en kollega med felsökning av kod ungefär enligt nedan som skulle skicka 24 bitar över bitbangad SPI till en DAC.
Efter byte av kompilator fungerade den inte längre.
Någon aning om varför det inte funkade?

Kod: Markera allt

void send_to_dac(uint32_t val)
{
  for (uint32_t bit = 1 << 23; bit != 0; bit >>= 1)
  {
    set_mosi((val & bit) != 0);
    pulse_clk();
  }
}

Svar:

[VISA]: Felet var att
uint32_t bit = 1 << 23;
har undefined behavior om int är 16 bitar, vilket det var på den här kompilatorn/processorn.

1 << 23 räknas ut som int eftersom vänstra operanden 1 är int.
Att värdet senare lagras i en uint32_t ändrar inte betydelsen av skiftoperationen.
I den gamla kompilatorn så råkade de höga 16 bitarna av 32 bitars mellanresultatet behållas och felet märktes aldrig.
Det är väl en av de lurigaste bitarna med C/C++ undefined behavior -- att det ofta "fungerar" precis som man tänkte sig men att det senare slutar fungera i en annan kompilator, nyare version av samma kompilator, när man ändrar optimeringsinställningar eller kanske bara när man ändrar annan kod i programmet.

Koden rättades till
uint32_t bit = 1UL << 23;

men

uint32_t bit = (uint32_t)1 << 23;

är ju ett annat alternativ.

Om man använder MPLAB X för att programmera en Microchip-processor, och väljer in FreeRTOS mha. Harmony, så är default minneshantering "heap_1".

Problemet med "heap_1" är att denne saknar möjlighet att frigöra minne (Beskrivning av de olika alternativen).
Och när märker man detta? Jo, när programmet kraschar pga. slut på minne.

Så ska man göra någonting dynamiskt i FreeRTOS, tex. skapa och ta bort tasker dynamiskt, så måste man ändra detta.

Skulle inte bli förvånad om det är samma sak i fler liknande verktyg än just MPLAB också.

Svenska ElektronikForumet

Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar

Re: Enkla men fatala buggar