Mikrokontrolleri?

Tulipa tarkistettua netistä:

"Helsingin myymälämme on suljettu."

eli Bebek palvelee vain Lahdessa sekä postimyyntinä.
Lahti ( Hirsimetsäntie 26 ):
Ma-pe klo 9-17
Sähköposti: [email protected]
Puhelin: 050 4704941

Ainahan tuota voi yrittää löytää esim. Parcosta - tosin en tiedä myyvätkö tuota vai keskittyvätkö Raspberry Pi -tuotteisiin (ATMEGAa luulisi sieltäki löytyvän).

Miksei voisi STM32:sta, joka on ARM, ohjelmoida assemblyllä? Sehän on konekieli, johon kaikki ohjelmointikielet käännetään ennen muistiin siirtoa.

Tai ehkä parempi kysymys olisi, miksi joku haluaisi ohjelmoida assemblyllä.

Anonyymi kirjoitti:

Miksei voisi STM32:sta, joka on ARM, ohjelmoida assemblyllä? Sehän on konekieli, johon kaikki ohjelmointikielet käännetään ennen muistiin siirtoa.

Tai ehkä parempi kysymys olisi, miksi joku haluaisi ohjelmoida assemblyllä.

Lue lisää

"ehkä parempi kysymys olisi, miksi joku haluaisi ohjelmoida assemblyllä"

No esim. itse koodaan ATMEGA -kontrollereille siten, että suurin osa ohjelmasta FreePascalilla, mutta keskeytysaliohjelmat assemblyllä.

Miksikö?

No, koska keskeytysaliohjelman ajankäyttö on syytä minimoida.

Koska se on pois siitä, mitä pääohjelman käytettäväksi jää.
Ja mikä pahinta, entä jos uusi keskeytys tulee (tai tulisi, jos keskeytykset olisi sallittu) ennen kuin edellistä keskeytystä palveleva keskeytysaliohjelma ehtii loppuun asti, eli CPU:sta riippuen yleensä joko IRET tai RETI ?

Varsinkin viimemainittu on onneton tilanne, koska se johtaa vähintään uuden keskeytyksen viivästymiseen ja pahimmillaan siihen, että keskeytys jää kokonaan käsittelemättä.

Mikrokontrolleri ei ole PC, vaan se suorittaa yleensä laiteläheistä tehtävää.

Assemblyssä on mahdollista laskea kuinka monta kellosykliä keskeytysaliohjelma pahimmillaan kuluttaa (mikään muu ohjelmointikieli ei tue tätä), ja näin varmistua, että keskeytys ehditään käsitellä ennen seuraavan (kriittisen) keskeytyksen saapumista.

Osaan muutamankin eri CPU:n ja mikrokontrollerin assembly-kieltä, esim. Z80, 80x86, ATMEGA328 -sarja jne. Näihin verrattuna tuo ARM vaikutti erittäin sekavalta.
Myös silloisia Microchipin kontrollereita pidin ATMELin tuotteisiin verrattuna sekavalla assemblyllä varustetuksi... ja sitten Microchip osti kilpailijansa ATMELin.


Ehkä koko ARM konekieltä ei ole suunniteltu lainkaan assemblyllä koodattavaksi, vaan lähinnä korkean tason kielten kääntäjien suunnittelijoiden referenssimateriaaliksi.


Sitä voi kysyä, miksi joihinkin CPU / Mikrokontrollereihin laitetaan sekava assembly.

Anonyymi kirjoitti:

"ehkä parempi kysymys olisi, miksi joku haluaisi ohjelmoida assemblyllä"

No esim. itse koodaan ATMEGA -kontrollereille siten, että suurin osa ohjelmasta FreePascalilla, mutta keskeytysaliohjelmat assemblyllä.

Miksikö?

No, koska keskeytysaliohjelman ajankäyttö on syytä minimoida.

Koska se on pois siitä, mitä pääohjelman käytettäväksi jää.
Ja mikä pahinta, entä jos uusi keskeytys tulee (tai tulisi, jos keskeytykset olisi sallittu) ennen kuin edellistä keskeytystä palveleva keskeytysaliohjelma ehtii loppuun asti, eli CPU:sta riippuen yleensä joko IRET tai RETI ?

Varsinkin viimemainittu on onneton tilanne, koska se johtaa vähintään uuden keskeytyksen viivästymiseen ja pahimmillaan siihen, että keskeytys jää kokonaan käsittelemättä.

Mikrokontrolleri ei ole PC, vaan se suorittaa yleensä laiteläheistä tehtävää.

Assemblyssä on mahdollista laskea kuinka monta kellosykliä keskeytysaliohjelma pahimmillaan kuluttaa (mikään muu ohjelmointikieli ei tue tätä), ja näin varmistua, että keskeytys ehditään käsitellä ennen seuraavan (kriittisen) keskeytyksen saapumista.

Osaan muutamankin eri CPU:n ja mikrokontrollerin assembly-kieltä, esim. Z80, 80x86, ATMEGA328 -sarja jne. Näihin verrattuna tuo ARM vaikutti erittäin sekavalta.
Myös silloisia Microchipin kontrollereita pidin ATMELin tuotteisiin verrattuna sekavalla assemblyllä varustetuksi... ja sitten Microchip osti kilpailijansa ATMELin.


Ehkä koko ARM konekieltä ei ole suunniteltu lainkaan assemblyllä koodattavaksi, vaan lähinnä korkean tason kielten kääntäjien suunnittelijoiden referenssimateriaaliksi.


Sitä voi kysyä, miksi joihinkin CPU / Mikrokontrollereihin laitetaan sekava assembly.

Lue lisää

Monipuolisemman prossun assembly on tietysti monimutkaisenpaa. Simulaattorilla voi katsoa kuinka monta sykliä kestää, jos ei osaa tuotettua assemblya lukea. Riippuen mitä tekee voi keskeytyksiin tulla monimutkaisia rakenteita kielestä riippumatta, jolloin on mahdotonta laskea syklejä kaikkiin tilanteisiin.

Itse osaan assemblya kohtuudella lukea, mutta teen lähes kaiken C:llä. Joskus on tarpeen laittaa yksittäisiä assemblyrivejä sekaan (lähinnä "nop" tai io-pinnin tilan muutos), mutta kokonaista keskeytysrutiinia en ole sillä tehnyt.

En tunne juuri STM32:sta, mutta yleensä tuollaisissa on mahdollisuus määritellä eri prioriteettejä keskeytyksille, jolloin ne aikakriittisimmät tulevat tehtyä oikeaan aikaan muista riippumatta. Tietysti pitää osata koodata niin, ettei alemman prioriteetin keskeytyksen keskeytys riko koko hommaa, mutta siihen ei assemblyä tarvita.

Anonyymi kirjoitti:

Monipuolisemman prossun assembly on tietysti monimutkaisenpaa. Simulaattorilla voi katsoa kuinka monta sykliä kestää, jos ei osaa tuotettua assemblya lukea. Riippuen mitä tekee voi keskeytyksiin tulla monimutkaisia rakenteita kielestä riippumatta, jolloin on mahdotonta laskea syklejä kaikkiin tilanteisiin.

Itse osaan assemblya kohtuudella lukea, mutta teen lähes kaiken C:llä. Joskus on tarpeen laittaa yksittäisiä assemblyrivejä sekaan (lähinnä "nop" tai io-pinnin tilan muutos), mutta kokonaista keskeytysrutiinia en ole sillä tehnyt.

En tunne juuri STM32:sta, mutta yleensä tuollaisissa on mahdollisuus määritellä eri prioriteettejä keskeytyksille, jolloin ne aikakriittisimmät tulevat tehtyä oikeaan aikaan muista riippumatta. Tietysti pitää osata koodata niin, ettei alemman prioriteetin keskeytyksen keskeytys riko koko hommaa, mutta siihen ei assemblyä tarvita.

Lue lisää

"Monipuolisemman prossun assembly on tietysti monimutkaisenpaa."

huono tekosyy.

Vaikka erilaisia assemblykäskyjä olisi jopa 2000, se ei sinänsä tee asiaa monimutkaiseksi.
Kyse ei siis tuossa ARMissa ole siitä, että käskyjä olisi liikaa, vaan siitä, että olemassaolevien käskyjen nimet (engl. "mnemonic") ovat täysin poikkeavia kaikista muista mikroprosessoreista tai -kontrollereista minkä kanssa olen ikinä ollut tekemisissä (Z80, x86, atmel avr, tai edes Intel 8051) .

Lisäksi on outoa, jos 32 -bit kontrollerissa ei ole 32 -bittistä load -käskyä, vaan sen sijasta loadhi ja loadlo, kumpikin lataa (joko ylemmät tai alemmat) 16 bittiä kerrallaan täyden 32 bitin sijasta.

Iso suunnitteluero, vertaa vaikkapa Z80 -käskyt:

LD HL, 1234h

Jos nyt oikein muistan, niin Z80 sallii myös LD BC, FF82h

Ja tuon on 8 -bittinen CPU, mutta niin vaan sallii 16 -bittisen datan lataamisen kerralla rekisteripariin.

Käsittämätöntä söhellystä, jos 32- bit CPU ei osaa ladata 32 bittiä kerralla, vaan on pakko jakaa tuo 32 bitin lataaminen ala -ja yläosaan.

Anonyymi kirjoitti:

"Monipuolisemman prossun assembly on tietysti monimutkaisenpaa."

huono tekosyy.

Vaikka erilaisia assemblykäskyjä olisi jopa 2000, se ei sinänsä tee asiaa monimutkaiseksi.
Kyse ei siis tuossa ARMissa ole siitä, että käskyjä olisi liikaa, vaan siitä, että olemassaolevien käskyjen nimet (engl. "mnemonic") ovat täysin poikkeavia kaikista muista mikroprosessoreista tai -kontrollereista minkä kanssa olen ikinä ollut tekemisissä (Z80, x86, atmel avr, tai edes Intel 8051) .

Lisäksi on outoa, jos 32 -bit kontrollerissa ei ole 32 -bittistä load -käskyä, vaan sen sijasta loadhi ja loadlo, kumpikin lataa (joko ylemmät tai alemmat) 16 bittiä kerrallaan täyden 32 bitin sijasta.

Iso suunnitteluero, vertaa vaikkapa Z80 -käskyt:

LD HL, 1234h

Jos nyt oikein muistan, niin Z80 sallii myös LD BC, FF82h

Ja tuon on 8 -bittinen CPU, mutta niin vaan sallii 16 -bittisen datan lataamisen kerralla rekisteripariin.

Käsittämätöntä söhellystä, jos 32- bit CPU ei osaa ladata 32 bittiä kerralla, vaan on pakko jakaa tuo 32 bitin lataaminen ala -ja yläosaan.

Lue lisää

Sanoisin, että ARM:ssa on asiat paremmin noiden asm-komentojen osalta: Käskyissä on rakennetta mukana ja koska se on RISC-prosessori, assembler on helppo oppia. Vähän eroa siinä toki on, koska käyttää ns. triplettejä käskyissä eli tulosta ei välttämättä talleteta src tai dest rekisterien päälle, vaan voi olla joku kolmas tulokselle - yleensä mikä tahansa rekisteri. Myöskin ehdolliset käskyn suorittamiset voivat aluksi vähän hämätä - näillä minimoidaan branch-käskyjä ja niihin tottuu.
Samoin, käskystöstä ei löydy perinteisiä push ja pop-käskyjä, vaan niissä on mukana tieto, kuinka monta rekisteriä palautetaan "rekisteritiedoston siirtona" - 32 rekisteristä voi siis palauttaa esim. 16 aliohjelmista paluun yhteydessä ja 16 on automaattisesti scratch-pad rekistereitä alirutiinille. Mitään ret-käskyä ei ole vaan paluu tapahtuu ylikirjoittamalla PC-rekisteri. Palautuksen kannalta ainoa asia, mikä rajaa lo- ja hi- palautusta on kytketyn muistin bittisyys, ts. siirto tapahtuu muistin maksiminopeudella. Sama koskee myös hi- ja lo- osan 32-bittisestä rekisteristä latausta, koska prosessori käyttää pipeline-tekniikkaa: assembler on ehkä hieman höttöä risc-tyyliin, mutta yhtään kellosykliä ei silti hukata. En muista, mistä versiosta alkaen käyttöön tuli MMU-yksikkö, jolloin siirrot muistin ja prosessorin välillä saattoivat olla 32-bittisiä. Idea kuitenkin oli sama kuin PC:ssä, eli hyödynnettiin saatavilla olevia 8/16 bittisiä muisteja jotta järjestelmä pysyi halpana toteuttaa. Prosessorista(MMU:n kanssa) siis löytyy 32-bittiseen lataamiseen käsky kyllä, mutta jos ei ole muistinhallintayksikköä välissä tekemässä 8/16 bittisistä fetch-komennoista muistille 32 bittisiä siitä ei ole mitään hyötyä - vie vaan turhia transitoreita core:ssa ja komento on täten poistettu näistä pienemmistä arm:eista..
Voisi siis saivarrella, että muistiväylän ollessa 16-bittinen, prossu olisi myös ollut 16-bittinen, mutta kykeni silti 32 bittisiin operaatioihin sisäisesti.

Kiitos näistä tähänastisista vinkeistä vastanneille.. Entäpä tämä paljon mainostettu Raspberry Pi .
Mitä sillä on eroa perinteisiin konrolleihin?

Löytyykö näistä vähintään se 18 lähtöä joita voisi käyttää servojen ohjailuun?
-Eki

Anonyymi kirjoitti:

Kiitos näistä tähänastisista vinkeistä vastanneille.. Entäpä tämä paljon mainostettu Raspberry Pi .
Mitä sillä on eroa perinteisiin konrolleihin?

Löytyykö näistä vähintään se 18 lähtöä joita voisi käyttää servojen ohjailuun?
-Eki

Lue lisää

Raspberryn eri versioissa on erilaisia määriä gpio (general purpose input output) pinnejä, mutta juuri nyt se ei ole hyvä valinta heikon saatavuutensa ja nousseen hintanta vuoksi. Jos tarvitset kontrollerissa ethernet tai wlan liitäntää ja linux - käytis on plussaa niin sitten ehkä. Sillonkin ongelmaa voi tuottaa se, että ohjausohjelmistosi ja raudan välissä on käyttöjärjestelmä aiheuttamassa satunnaisia viiveitä. Se käyttis ei yleensä ole RTOS eli reaaliaikainen raudan ohjaamiseen nimenomaisesti suunniteltu käyttöjärjestelmä.

Yleensä esimerkiksi 3d - printtereissä käytetään raspberryn tms ja stepperimoottoreiden ohjainten välissä jotakin tarkoitukseen pyhitettyä prossua, jonka ei tarvitse miettiä mitään muuta kuin ajoitukseltaan oleellisia asioita. Jos prossu on monimutkaisempi (32bit) niin siinä voi olla joku RTOS apuna.

Jos sinulla ei ole kova kiire servojen ohjauksessa niin spi - väylän kautta saa minkä tahansa prosessorin ulostulojen määrää kasvatettua.

Anonyymi kirjoitti:

Raspberryn eri versioissa on erilaisia määriä gpio (general purpose input output) pinnejä, mutta juuri nyt se ei ole hyvä valinta heikon saatavuutensa ja nousseen hintanta vuoksi. Jos tarvitset kontrollerissa ethernet tai wlan liitäntää ja linux - käytis on plussaa niin sitten ehkä. Sillonkin ongelmaa voi tuottaa se, että ohjausohjelmistosi ja raudan välissä on käyttöjärjestelmä aiheuttamassa satunnaisia viiveitä. Se käyttis ei yleensä ole RTOS eli reaaliaikainen raudan ohjaamiseen nimenomaisesti suunniteltu käyttöjärjestelmä.

Yleensä esimerkiksi 3d - printtereissä käytetään raspberryn tms ja stepperimoottoreiden ohjainten välissä jotakin tarkoitukseen pyhitettyä prossua, jonka ei tarvitse miettiä mitään muuta kuin ajoitukseltaan oleellisia asioita. Jos prossu on monimutkaisempi (32bit) niin siinä voi olla joku RTOS apuna.

Jos sinulla ei ole kova kiire servojen ohjauksessa niin spi - väylän kautta saa minkä tahansa prosessorin ulostulojen määrää kasvatettua.

Lue lisää

Jos et ole koskaan tehnyt mitään kontrollerilla, niin kannattaa aloittaa jollakin arduinolla tmv. laitteella. ARM-pohjainen STM32 ja sen CUBE-ympäristö on ehkä hiukan vaativa, koska sen toimintaan saattaminen on kohtuullisen iso prosessi. Dokumentaatio on periaatteessa olemassa, mutta vaatii aika usein esimerkkikoodin katselemista silti. Periaatteessa SDK:ssa on javalla toteutettu C-koodigeneraattori, josta klikkaillaan oikea prosessori ja sitten valitaan pinnien toiminnat GUI:n avulla - totesin tämän vaan aika ikäväksi ja kömpelöksi tavaksi tuottaa koodia ja lopulta löysin Makefile-pohjaisen käännösympäristön github:sta, jota joutuu käsin editoimaan tosin, mutta parin tunnin opetusvideoita youtube:sta katseltuani se on itse asiassa toimivampi. CUBE:n käytön opettelu kannattaa, sillä siellä on melkein kaikelle toiminnolle valmista koodia ja esim. keskeytysohjatun sarjaporttiajurin toteuttaminen omaan ohjelmaan on pikku juttu. Nykyäänhän tuolle on joku uudempikin systeemi olemassa joten sitä voi kannattaa vilkaista myös jos jotain uutta aikoo opetella.
STM32:t ja Megat on aivan eri tasolla suorituskyvyltään ja STM32:lle RTOS voi olla ihan järkevä vaihtoehto, sille voi saada jopa moniajoa toteutettua. Oikeastaan hiukan kärjistettynä STM32 on yhden arm(4)-coren raspi max. 100MHz taajuudella, kun raspissa taisi olla 4 corea ja 1.2GHz taajuus ja hiukan uudempi arm(v7?)-arkkitehtuuri.

Anonyymi kirjoitti:

Kiitos näistä tähänastisista vinkeistä vastanneille.. Entäpä tämä paljon mainostettu Raspberry Pi .
Mitä sillä on eroa perinteisiin konrolleihin?

Löytyykö näistä vähintään se 18 lähtöä joita voisi käyttää servojen ohjailuun?
-Eki

Lue lisää

" Raspberry Pi" - tutustu myös aiheeseen:

https://ultibo.org/

Tuo Raspberry Pi ei ole ihan perinteinen kontrolleri, mutta tuo ultibo ei ole käyttöjärjestelmä, vaan työväline, jolla voi kirjoittaa yhden tarkoituksen sovelluksen, jota suoritetaan suoraan prosessorilla ilman erillistä käyttöjärjestelmää. Tuosta rakenteesta johtuen myös I/O -porttien suora käsittely on mahdollista, toisin kuin suojatun tilan käyttöjärjestelmissä, jossa usein sovelluksien oikeudet käyttää I/O -portteja on estetty.

Anonyymi kirjoitti:

Jos et ole koskaan tehnyt mitään kontrollerilla, niin kannattaa aloittaa jollakin arduinolla tmv. laitteella. ARM-pohjainen STM32 ja sen CUBE-ympäristö on ehkä hiukan vaativa, koska sen toimintaan saattaminen on kohtuullisen iso prosessi. Dokumentaatio on periaatteessa olemassa, mutta vaatii aika usein esimerkkikoodin katselemista silti. Periaatteessa SDK:ssa on javalla toteutettu C-koodigeneraattori, josta klikkaillaan oikea prosessori ja sitten valitaan pinnien toiminnat GUI:n avulla - totesin tämän vaan aika ikäväksi ja kömpelöksi tavaksi tuottaa koodia ja lopulta löysin Makefile-pohjaisen käännösympäristön github:sta, jota joutuu käsin editoimaan tosin, mutta parin tunnin opetusvideoita youtube:sta katseltuani se on itse asiassa toimivampi. CUBE:n käytön opettelu kannattaa, sillä siellä on melkein kaikelle toiminnolle valmista koodia ja esim. keskeytysohjatun sarjaporttiajurin toteuttaminen omaan ohjelmaan on pikku juttu. Nykyäänhän tuolle on joku uudempikin systeemi olemassa joten sitä voi kannattaa vilkaista myös jos jotain uutta aikoo opetella.
STM32:t ja Megat on aivan eri tasolla suorituskyvyltään ja STM32:lle RTOS voi olla ihan järkevä vaihtoehto, sille voi saada jopa moniajoa toteutettua. Oikeastaan hiukan kärjistettynä STM32 on yhden arm(4)-coren raspi max. 100MHz taajuudella, kun raspissa taisi olla 4 corea ja 1.2GHz taajuus ja hiukan uudempi arm(v7?)-arkkitehtuuri.

Lue lisää

Saisikohan tuota STM32:ta (siis tämä:

http://bebek.fi/kauppa/lisatiedot.php?&tuote_id=18032

)

jotenkin koodattua FreePascalilla (tai Ultibolla ) ?

Tuli ostettua tuo, koska sen hinta (10 €) oli erittäin edullinen kokonaisesta kortista, eli hinta sisältää sekä prosessorin että piirilevyn oheiskomponentteineen).

Jos tuota saisi ohjelmoitua joko FreePascalilla tai Ultibolla niin soveltuisi varmasti hyvin moneen tarkoitukseen, joko sellaisenaan, tai kytkettynä lisäpiirikorttiin, jolla sovelluskohtaista muuta elektroniikkaa, jota tuo STM sitten ohjaisi.

Anonyymi kirjoitti:

Saisikohan tuota STM32:ta (siis tämä:

http://bebek.fi/kauppa/lisatiedot.php?&tuote_id=18032

)

jotenkin koodattua FreePascalilla (tai Ultibolla ) ?

Tuli ostettua tuo, koska sen hinta (10 €) oli erittäin edullinen kokonaisesta kortista, eli hinta sisältää sekä prosessorin että piirilevyn oheiskomponentteineen).

Jos tuota saisi ohjelmoitua joko FreePascalilla tai Ultibolla niin soveltuisi varmasti hyvin moneen tarkoitukseen, joko sellaisenaan, tai kytkettynä lisäpiirikorttiin, jolla sovelluskohtaista muuta elektroniikkaa, jota tuo STM sitten ohjaisi.

Lue lisää

Väittäisin, että kaukana ei ainakaan tuen osalta olla: free pascalista saa version arm v3:lle ainakin, tuo linkissäsi oleva on ilmeisesti v4 prosessori. Lisäksi on v6/raspi tuki. Eli luultavasti joutuu itse kääntämään kääntäjän, mikä ei ole tämän mukaan kovin vaikea operaatio:
https://wiki.freepascal.org/TARGET_Embedded
Eri asia sitten on, kuinka paljon joutuu näkemään vaivaa jos haluaa cube-f4:n tyylisen tukikirjaston: Riittääkö .h tiedostojen kääntäminen pascaliksi? Ilmankin toki pärjää..