EFM32

[Icecap]

Jag sitter och gör program till en EFM32G230F128. Jag är inte helt kompis med databladet men jag lär mig.
Använder Simplicity Studio då jag definitivt inte kom överens med den IAR som kom med STK3600.

I databladet namnger de GPIO som:
GPIO_PA0_DOUT
Men fan om kompilern vill äta det!

Felet: "...:19:21: error: 'GPIO_PA0_DOUT' undeclared (first use in this function)"

Så hur tusan namnger man dom då? Jag behöver komma åt pinnarna på något vis, helst en pin åt gången men sviker allt annat kan jag ta en hel port åt gången och fibbla med bits.

[AndLi]

Kan inte ett av de många exemplen de skickar med i simplicity ge några ledtrådar?
Jag körde en EFM ett tag men råkade kortsluta någon pinne till 12V, så nu är det STM istället...
Men jag är rätt säker på att jag klipp och klister kodade från något exempel för att toggla en pinne..

[baron3d]

Hjälper detta ?
https://eewiki.net/display/microcontrol ... +Cortex-M3
Under "GPIO Example Using Direct Register Access"

[Icecap]

baron3d: där satt den!!! Kanon! TACK!
Vilket satans system - men OK, de tycker väl att det är billigt och enkelt.
Men nu kan jag iaf. skaka bits och komma vidare.

AndLi: Tyvärr inte, "alla" deras exempel (ingen alltså) använde en massa omskrivningar i sjuttielva nivåer utan att det går att få vett i skiten.

Nu kompilerar första stegen utan problem - så nu ska jag sova. Jag kommer att få en del att göra i helgen.

[newbadboy]

Kan inte annat än "småle" lite. När en av de mer erfarna på forumet som ofta räddar mig sitter och frågar en" typiskt simpel nybörjarfråga."

Då vet man att det verktyget kanske inte är så intuitivt

[Lennart Aspenryd]

Jättebra exempel att vi , i olika perioder, befinner oss på olika nivåer!
Att vara och tänka som en fyraåring, kan vara väl unnat en mångkunnig .
Det är väl det forumet är till för!

[Icecap]

newbadboy: nu är det inte verktyget som är så dumt (även om jag definitivt inte är kompis med IAR's verktyg), men ARM's sätt att styra portpinnar på. Man får dock ge dom "ära" för att de har varit mycket modulära men kommer man från en Renesas RX, PIC, Fujitsu, Intel är det ganska knasigt sätt att göra vissa saker på.

Men ARM är ju gjort för att vara en billig µC och jag kan tänka mig att det mest är en fråga om vana, rent teknisk fungerar det ju.

Databladet från Silicon Labs är dock under mycket kritik, det pratas mycket om hur bra skiten är och verkliga data ges - men hur man styckar ihop dessa data är mycket vagt.

[AndLi]

Nä, nu ska vi inte ge fel företag äran för databladen...
EFM32 dök upp i Silabs sortiment efter det att de köpt Norska Energy Micro, dokumentstrukturen för dessa datablad kommer alltså därifrån!
Tittar man på Silabs lite mer avancerade chip i egna familjer vill man bara springa åt andra hållet, om det ens finns någon dokumentation att tillgå. Oftast fick man nöja sig med lite exempelkod för att jobba sig runt diverse egenheter...

[lillahuset]

Icecap: ARM är helt oskyldiga när det gäller hur portarna är konstruerade. Du får klaga på guttarna i Trondheim. Var det väl? Norge iallafall.

[Icecap]

OK, jag klagar på norrmännen. Bra konstiga var de iaf.

Men jag tror (än så länge) att jag har fått det till att fungera i närheten av vad det ska men jag kommer nog att svära en del mer senare.

[lillahuset]

Så är det alltid när man börjar med en ny processor. Men välkommen till ARM-världen.

[Icecap]

lillahuset: Jo tack - om bara skiten var lika välkomnande!

Jag har gjort ett program som är stommen i det hela, för tillfället ska det bara växla nivå på en portpinne men inte heller det kan jag få till att köra.

Jag har lyckats starta kristalloscillatorn (16MHz) men det är allt.

Jag försöker köra dessa instruktioner strax efter CHIP_Init();
CMU_OscillatorEnable(cmuOsc_HFXO, true, true); // Start 16MHz X-tal oscillator
Men fan om skiten rör på sig. Debuggningen visat att det fastnar i em_cmu.c i denna loop:

Kod: Markera allt

    /* Wait for clock to become ready after enable */
    if(wait)
      {
      while(!BUS_RegBitRead(&CMU->STATUS, rdyBitPos));

Dessa ska köra strax efter raden ovan men den kommer aldrig hit.
CMU_ClockSelectSet(cmuClock_HF, cmuSelect_HFXO);
CMU_ClockEnable(cmuClock_HFPER, true); /* Enable High Frequency Peripherals */
CMU_ClockEnable(cmuClock_GPIO, true); /* Enable clocks to GPIO */

[lillahuset]

Tyvärr vet jag inget om EMF-träsket men det kanske kan vara en liten tröst att STs bibliotek är rätt kassa. Vi köpte en CAN-stack från Tyskland med bra support. Jag frågade hur mycket av STs bibliotek de tyckte man skulle använda. "As little as possible."

Och ja, tyvärr är tröskeln ganska hög. Men det beror mest på tillverkarna, ARMs del är bara processorn och interruptcontrollern.

Men som jag brukade säga till valparna i bolaget jag förut var delägare i: Sluta gnäll, om det vore lätt skulle ni vara tvungna att äta blodpudding.

[Icecap]

Ja, största problemet er att databladet är så otroligt kasst att det borde vara dödsstraff för det.
Det beskriver en massa - men ingen verklig information.

Renesas RX210 är ingen lek heller med ett datablad på 1630 sidor - men där finns det ren faktuell information, rätt namn på register, verklig beskrivning av vilka bits som gör vad osv. Det finns säkerhetsregister osv. men man kan faktisk hitta rätt och korrekt information istället för att få veta att den minsann kan... och sedan inget mer.

[lillahuset]

Som sagt, jag vet inget om EFM men STs "datablad" är också rätt dåliga. Jag kom från PIC via AVR till ST och båda övergångarna var ganska tunga.

Om du vill kan jag skicka dig en STM32F4 Discovery så kan jag eventuellt bidra med råd.