AVR C++ teegi loomine

[totenhose]

Tervitus kõigile AVR progejatele,
Teema selline, et kribame TTÜ Robotiklubis (www.robotiklubi.ee) suuremat sorti C++ teeki AVR 8-bitistele prosedele. Eesmärk on teha kogu kontrolleri kasutamine objekt-orienteerituks, verbaalseks, lihtsaks, effektiivsemaks ja üldse paremaks. Kompilaatoriks on AvrGcc 4. Siiani on olemas IO registrite, katkestuste, taimerite, ADC, USART toetus ja mitmed abiklassid ning funktsioonid. Kontrolleritest on erineval määral toetatud mega8, mega88, mega128, mega8515, at90usb1287. Kavas on lisada sideprotokolle - XModem ja USB. Kuna asi läheb üsna suureks ja eriti just erinevate kontrollerite tõttu siis ootaks huviliste osavõttu. Vajalik on kogu C++ süntaksi oskamine, AVR raua tundmine ja AVR-i assemblerist aru saamine (et kompileerimise tulemust hinnata). Asi hakkab olema GPL litsentsi all ja Sourceforges.
Viimane versioon on siin: http://www.robotiklubi.ee/_media/pro...revision98.zip

Andke märku!

[digital]

Vs: AVR C++ teegi loomine

Huvitav projekt. Kuigi minu vaateväljas on kontrollerid, sh AVR'id ikkagi enamasti väga reaalaja-kriitilised ja seega tuleb võimalikult raualähedaselt progeda. Põhiliselt siis C ja väga tihti isegi ASM. C++ kaaluga projekti jaoks võtaks juba mingi natuke edevama raua, mis suudab mingit valmis opsüssi jooksutada, omab mälukaitset jms vajalikku (mingid ARM'id vms).
Igatahes edu selle projekti juures.

[totenhose]

Vs: AVR C++ teegi loomine

Kuna teegi kasutamine on funktsioonide põhine, mitte raudvaraliste registrite, siis ei saa välistada, et asja võiks mõne muu protsessori jaoks ka teha. Praegu on olemas programm mis AVR-ide dokumentatsioonist kopeeritud registrite nimekirjast automaatselt genereerib vajalikud registrite ja IO struktuurid - seda võib näiteks ka PIC peale kohandada. Pikemas perspektiivis on plaan vähendada koodi kopeerimist/mugavdamist iga kontrolleri jaoks võttes kasutusele teeki ennast genereeriva programmi Praegu on asju aetud läbi C pre-processori, kuid üks idee on kasutada XML/XSLT - et siis XML-is kirjeldaks kontrolleri funktsioone ja XSLT genereeriks C++ koodi.

Effektiivsusega on nii, et gcc kompilaatorit arendatakse ja midagi halba ei saa õiget optimiseerimist kasutades tulemuse kohta küll öelda - kasutusel on inline funktsioonid ja instantse ilma vajaduseta ei tekitata. Suurema projekti puhul võib OOP oma lihtsusega isegi kvaliteetsema tulemuse anda kui jäik globaalne funktsioonide/muutujate käsitlemine.

[totenhose]

Vs: AVR C++ teegi loomine

Autoriõiguste huvides ei saa teegi koodi jagaga, aga siin on üks lihtne näide tavalise DC mootori juhtimise struktuurist.

 
typedef OutputPin2<PortC> LeftMotorRed;
typedef OutputPin3<PortC> LeftMotorBlack;
 
typedef OutputPin0<PortC> RightMotorRed;
typedef OutputPin1<PortC> RightMotorBlack;
 
typedef OutputPins<PortC, _PC0 | _PC1 | _PC2 | _PC3> MotorPins;
 
template <class Red, class Black> struct Motor
{
    static inline void Forward()
    {
        Red::Set();
        Black::Clear();
        
    } // Forward
    
    static inline void Reverse()
    {
        Red::Clear();
        Black::Set();
        
    } // Reverse
    
    static inline void Stop()
    {
        Red::Clear();
        Black::Clear();
    
    } // Stop
};
 
typedef Motor<RightMotorRed, RightMotorBlack> RightMotor;
typedef Motor<LeftMotorRed, LeftMotorBlack> LeftMotor;

[bloody-orc]

Vs: AVR C++ teegi loomine

ühesõnaga loote C++'is Basicut? mnjah.... Kellele see koodi lõpptulemus mõeldud on? Õppimise eesmärgiks on 99% mõtekam kasutada puhast C keelt. saab teada ka, mis proses tegelikult toimub. Kui see aga noortele, keda asi võibolla üldse ei huvita, siis andge aga minna.

Ise TTÜ's robotikursusel nägin oma silmaga. kõik vurasid koodi kirjutada selleks ajaks valmis olnud teekidega, aga midagi aru ei saanud, mis tegelikult toimus. kõrvalistujad vaatasid kohe VÄGA suurte silmadega, kui midagi registritest või bittidest räägiti . ise üritasin GCC's teha, sain asja selgeks ja oli ma arvan rohkem kasu

[KaruTEC]

Vs: AVR C++ teegi loomine

leiutate jalgratast ?

[felch]

Vs: AVR C++ teegi loomine

Progemise õpetamise seisukohast on asjal mõte olemas. Aga Bloody märkus on samuti omal kohal - "puhtast" progemisest ainult pole kasu. Peab ka aru saama, mida raud seal all teeb ja et asju saab 5 prose asemel ka ühe tagasihoidlikuga teha. Ja veel: robotexi masinaid vaadates tekkis (vahest väär) arvamus, et liikumise füüsika (inerts kasvõi) jäeti hoopis välja. Ja vahest tuleks esimese asjana õpetada seda, et kood ei käitu masinal pea kunagi nii, nagu simulaatoris. Karm reaalsus tuleb vahele. Näe, NASAkad said sel alal õppetunni: http://www.nasa.gov/mission_pages/mgs/
Idee ise on hea, edu!

[bloody-orc]

Vs: AVR C++ teegi loomine

ah ja seda ka, et proovige see teegindus võimalikult pisikeseks saada. Tegin selle asjaga seal LED blinkeri programmi. 60% AVR M8 mälust näinud... ADC väärtusest sõltuv blinkimise interval aga võttis ruumi 5000 (jah viis TUHAT)% mälust. -os oli peal...
lihtsalt väike soovitus.
Ja edu tulevasel 2007 köieronimis võistlustel loodan, et seal seda koodindust ei kasuta... äkki siis ka võidate (lõpuks).

[andreie]

Vs: AVR C++ teegi loomine

Tore on ju, kui riistvarapealik toob tarkvarapealikule musta kasti, millele läheb külge ainult toide ja puna-mustad juhtmed stepperite jaoks. Ega tarkvarapealik ei pea meeles, kas stepper on PORTB.[01] või PORTC.[67].

Kuigi asi on GPL-i all, huvilistele seda ei jagata:
Kahju küll, aga sinu tublidusest ei piisa, et edasi liikuda, selleks on vastavaid õigusi vaja. Minu arust BSD litsents oleks kohasem - siis saaks ka kommertsis tegutsevad inimesed abiks olla.

Kindlasti on ka paremaid näiteid kui mootor... Mina olen seni lihtsalt läbi saanud:

#define MOTOR_PORT PORTB
#define MOTOR_RED_BV _BV(2)
#define MOTOR_BLACK_BV _BV(3)

// forward
MOTOR_PORT = MOTOR_RED_BV;

// backward
MOTOR_PORT = MOTOR_BLACK_BV;

// stop.
MOTOR_PORT = MOTOR_RED_BV | MOTOR_BLACK_BV

ja pole probleemi olnud. Ehk annab C++'i mallide massi natukene vähendada - näiteks klass "Motor" võiks otse portidega tegeleda ilma abiklasside vahenduseta?

Muide, leheküljel "http://www.robotiklubi.ee/projektid/projekt_t/prog" olnud ajaliste viidete jaoks on sobilikum kasutada AVR-i libc funktsioone _delay_us ja _delay_ms - http://www.nongnu.org/avr-libc/user-...il__delay.html

[raivo]

Vs: AVR C++ teegi loomine

ah ja seda ka, et proovige see teegindus võimalikult pisikeseks saada. Tegin selle asjaga seal LED blinkeri programmi. 60% AVR M8 mälust näinud... ADC väärtusest sõltuv blinkimise interval aga võttis ruumi 5000 (jah viis TUHAT)% mälust. -os oli peal...

raske uskuda, nii ebaefektiivne ei tohi C++ olla.
kuigi , mine tea, mis vormis objektidevaheline message'te vahetamine gcc käib, nii lihtne nagu C funktsoonide vaheline, see vist pole.
inline'ing teeb kah oma töö ja nii see kood paisub.
vöiksid programmi , listingu ja mäpi kuhugi üles riputada, kole isu on vaadata.

[bloody-orc]

Re: Vs: AVR C++ teegi loomine

uskuda või mitte... selles pole küsimus. nii oli lihtsalt ja kõik võibolla oli kusagil mingi muu kala. ei tea.
Peale parandusi oli aga asi parem ja roboti kood mahtus taaskord 60% sisse ära.

[totenhose]

Vs: AVR C++ teegi loomine

Paraku jah, enne kui korralikku litsentsi pole ei saa enam teeki jagada. Siin on nüüd üks lihtne eest ära liikuva roboti lähtekood ja listing. Asi on hea, nagu ma juba ütlesin, ainult õiget optimiseerimist kasutades, ehk siis -O2.

#include <inttypes.h>
#include <IO.h>
#include <Interrupt.h>


// Controls
OutputPin4<PortC> LED1;
InputPin5<PortC> Button1;

// Motors
OutputPin0<PortC> Motor1A;
OutputPin1<PortC> Motor1B;
OutputPin3<PortC> Motor2A;
OutputPin2<PortC> Motor2B;

// Sensors
InputPin5<PortD> FrontLeftSensor;
InputPin6<PortD> FrontmiddleSensor;
InputPin7<PortD> FrontRightSensor;
InputPin1<PortD> RearSensor;


/**
*    Main program cycle
*/
int main (void) {

    // Init controls
    LED1.InitOutput();
    LED1.Set();
    Button1.InitInput();
    
    // Init motors
    Motor1A.InitOutput();
    Motor1B.InitOutput();
    Motor2A.InitOutput();
    Motor2B.InitOutput();
    
    // Init sensors
    FrontLeftSensor.InitInput();
    FrontmiddleSensor.InitInput();
    FrontRightSensor.InitInput();
    RearSensor.InitInput();    

    // Global interrupts enable    
    GlobalInterrupts::Enable();

    // Main loop
    while (1) {
        
        // Front middle obstacle
        if (!FrontmiddleSensor.IsSet()) {        
            Motor1A.Clear();
            Motor1B.Set();
            Motor2A.Clear();
            Motor2B.Set();
                        
        // Rear obstacle
        } else if (!RearSensor.IsSet()) {
            Motor1A.Set();
            Motor1B.Clear();
            Motor2A.Set();
            Motor2B.Clear();
            
        // Front left obstacle
        } else if (!FrontLeftSensor.IsSet()) {
            Motor1A.Clear();
            Motor1B.Clear();
            Motor2A.Clear();
            Motor2B.Set();
            
        // Front right obstacle
        } else if (!FrontRightSensor.IsSet()) {
            Motor1A.Clear();
            Motor1B.Set();
            Motor2A.Clear();
            Motor2B.Clear();
        
        // Stand
        } else {
            Motor1A.Clear();
            Motor1B.Clear();
            Motor2A.Clear();
            Motor2B.Clear();
        }
                
        // Test button
        LED1.SetTo(Button1.IsSet());        
    }
}

List

/**
*    Main program cycle
*/
int main (void) {
      ca:    a4 9a           sbi    0x14, 4    ; 20

namespace Assembler
{
    inline void CLI() { __asm__ __volatile__ ("cli"); }
    inline void SEI() { __asm__ __volatile__ ("sei"); }
      cc:    ac 9a           sbi    0x15, 4    ; 21
      ce:    ad 9a           sbi    0x15, 5    ; 21
      d0:    a5 98           cbi    0x14, 5    ; 20
      d2:    a0 9a           sbi    0x14, 0    ; 20
      d4:    a1 9a           sbi    0x14, 1    ; 20
      d6:    a3 9a           sbi    0x14, 3    ; 20
      d8:    a2 9a           sbi    0x14, 2    ; 20
      da:    95 9a           sbi    0x12, 5    ; 18
      dc:    8d 98           cbi    0x11, 5    ; 17
      de:    96 9a           sbi    0x12, 6    ; 18
      e0:    8e 98           cbi    0x11, 6    ; 17
      e2:    97 9a           sbi    0x12, 7    ; 18
      e4:    8f 98           cbi    0x11, 7    ; 17
      e6:    91 9a           sbi    0x12, 1    ; 18
      e8:    89 98           cbi    0x11, 1    ; 17
      ea:    78 94           sei

    // Init controls
    LED1.InitOutput();
    LED1.Set();
    Button1.InitInput();
    
    // Init motors
    Motor1A.InitOutput();
    Motor1B.InitOutput();
    Motor2A.InitOutput();
    Motor2B.InitOutput();
    
    // Init sensors
    FrontLeftSensor.InitInput();
    FrontmiddleSensor.InitInput();
    FrontRightSensor.InitInput();
    RearSensor.InitInput();    

    // Global interrupts enable    
    GlobalInterrupts::Enable();

    // Main loop
    while (1) {
        
        // Front middle obstacle
        if (!FrontmiddleSensor.IsSet()) {        
      ec:    86 99           sbic    0x10, 6    ; 16
      ee:    09 c0           rjmp    .+18         ; 0x102 <main+0x38>
        typedef uint8_t Type;
        typedef reg8_t RegType;

        static inline uint8_t Get() { return Derived::GetRegister(); }
        static inline void Set(uint8_t flags) { Derived::GetRegister() = flags; }
      f0:    a8 98           cbi    0x15, 0    ; 21
      f2:    a9 9a           sbi    0x15, 1    ; 21
      f4:    ab 98           cbi    0x15, 3    ; 21
      f6:    aa 9a           sbi    0x15, 2    ; 21
      f8:    9d 9b           sbis    0x13, 5    ; 19
      fa:    0b c0           rjmp    .+22         ; 0x112 <main+0x48>
      fc:    ac 9a           sbi    0x15, 4    ; 21
      fe:    86 9b           sbis    0x10, 6    ; 16
     100:    f7 cf           rjmp    .-18         ; 0xf0 <main+0x26>
            Motor1A.Clear();
            Motor1B.Set();
            Motor2A.Clear();
            Motor2B.Set();
                        
        // Rear obstacle
        } else if (!RearSensor.IsSet()) {
     102:    81 99           sbic    0x10, 1    ; 16
     104:    08 c0           rjmp    .+16         ; 0x116 <main+0x4c>
        typedef uint8_t Type;
        typedef reg8_t RegType;

        static inline uint8_t Get() { return Derived::GetRegister(); }
        static inline void Set(uint8_t flags) { Derived::GetRegister() = flags; }
     106:    a8 9a           sbi    0x15, 0    ; 21
     108:    a9 98           cbi    0x15, 1    ; 21
     10a:    ab 9a           sbi    0x15, 3    ; 21
     10c:    aa 98           cbi    0x15, 2    ; 21
     10e:    9d 99           sbic    0x13, 5    ; 19
     110:    f5 cf           rjmp    .-22         ; 0xfc <main+0x32>
     112:    ac 98           cbi    0x15, 4    ; 21
     114:    eb cf           rjmp    .-42         ; 0xec <main+0x22>
            Motor1A.Set();
            Motor1B.Clear();
            Motor2A.Set();
            Motor2B.Clear();
            
        // Front left obstacle
        } else if (!FrontLeftSensor.IsSet()) {
     116:    85 99           sbic    0x10, 5    ; 16
     118:    05 c0           rjmp    .+10         ; 0x124 <main+0x5a>
        typedef uint8_t Type;
        typedef reg8_t RegType;

        static inline uint8_t Get() { return Derived::GetRegister(); }
        static inline void Set(uint8_t flags) { Derived::GetRegister() = flags; }
     11a:    a8 98           cbi    0x15, 0    ; 21
            Motor1A.Clear();
            Motor1B.Clear();
            Motor2A.Clear();
            Motor2B.Set();
            
        // Front right obstacle
        } else if (!FrontRightSensor.IsSet()) {
     11c:    a9 98           cbi    0x15, 1    ; 21
     11e:    ab 98           cbi    0x15, 3    ; 21
     120:    aa 9a           sbi    0x15, 2    ; 21
     122:    ea cf           rjmp    .-44         ; 0xf8 <main+0x2e>
     124:    87 99           sbic    0x10, 7    ; 16
     126:    05 c0           rjmp    .+10         ; 0x132 <main+0x68>
        typedef uint8_t Type;
        typedef reg8_t RegType;

        static inline uint8_t Get() { return Derived::GetRegister(); }
        static inline void Set(uint8_t flags) { Derived::GetRegister() = flags; }
     128:    a8 98           cbi    0x15, 0    ; 21
     12a:    a9 9a           sbi    0x15, 1    ; 21
     12c:    ab 98           cbi    0x15, 3    ; 21
     12e:    aa 98           cbi    0x15, 2    ; 21
     130:    e3 cf           rjmp    .-58         ; 0xf8 <main+0x2e>
     132:    a8 98           cbi    0x15, 0    ; 21
     134:    a9 98           cbi    0x15, 1    ; 21
     136:    ab 98           cbi    0x15, 3    ; 21
     138:    aa 98           cbi    0x15, 2    ; 21
     13a:    de cf           rjmp    .-68         ; 0xf8 <main+0x2e>

Vanakooli assembleri/c meestelt aga küsiks kas on mõnus sama koodi ühelt AVR-ilt teisele ja kolmandale viia? Ikka ei ole küll kui kõik registrite ja väljade nimed on koodi sisse kirjutatud. Võite #define loetelusid teha kõigi jalgade kõikidest registritest jms, kuid kui uuel kontrolleril on ikkagi taimeri või muu funktsiooni töölerakendamine teistmoodi siis tuleb koodi surama minna. Ei ole ka sugugi mugav jälgida prose registrite ristkasutamist ja globaalseid muutujaid, rääkimata veel tüütust netist leitud algoritmide oma projekti istutamisest.

Teegi kasutamine ilma kontrolleri siseelu tundmata? Kas keegi õpib tänapäeval kivikirvest tahuma või ostab poest fiskarsi? Ostab on õige vastus. Sama lugu ka selle teegiga - tahad vabaneda pidevast datasheedis tuhlamisest ja tegeleda tulemuse saavutamisega - siis õpi üks kord ära AVR-i põhitõed ja C++ ning kasuta.

Aga jah, praegu otsime kaasautoreid, soovitavalt Tallinnast või heade kommunikatsioonivõimalustega.

[felch]

Vs: AVR C++ teegi loomine

Vanakooli assembleri/c meestelt aga küsiks kas on mõnus sama koodi ühelt AVR-ilt teisele ja kolmandale viia? Ikka ei ole küll kui kõik registrite ja väljade nimed on koodi sisse kirjutatud.

AVRi kohta ei tea kuid PIC-i puhul teen küll just nii. Samuti ei ole probleeme netist leitud koodijupi oma asja jaoks kohandamisega. Arvan, et AVRiga on samamoodi kui vaid progeda osata.Teegi loomine on hea asi, selles pole kahtlust (see litsentside värk välja arvatud). Aga kui inimesed õpivad ainult LEGO klotse kokku laduma, siis inseneri neist ei saa. Peab ikka natuke jagama seda, millele ja mida teed.
Cassini missiooni vennad otsustasid poole tee peal hakata testima maanduri ja "emajaama" vahelist sidet. Lend pikk ja igav hakkab niisama oodates... Selgus, et kõik töötas ilusasti kuid paraku oli mingi näpuvea tõttu kumbki laev omal sagedusel. Missioon tuksis, ütleksid datasheete kartjad? Insenerid mõtlesid natuke ja otsustasid kasutada doppleri nihke nimelist nähtust. Side saadi püsti.

[andreie]

Vs: AVR C++ teegi loomine

Teemaväline kõrvalepõige:

AVR-iga pusides õpitu tööalaseks rakendamiseks pakub Oskando tööd sardkontrollite programmeerijale (ATmega seeria). Äkki kellelegi sobib.

[totenhose]

Vs: AVR C++ teegi loomine

Kui teegi koodi vaadata (mida praegu küll teha ei saa) siis on näha, et paljud funktsioonid on ainult inimkeelsed bittide määramised, lugemised ja võrdlemised. Ehk kui programmeerija kirjutab:

InputPin1<PortC> Button1;
Button1.IsSet();

...siis see ei erine kuigi palju vanas stiilis C-st:

#define BUTTON1_PORT PINC
#define BUTTON1_PIN 1
is_bit_set(BUTTON1_PORT, BUTTON1_PIN);

Mõlemad näite puhul saab iga vähegi programmerida oskav inimene aru, et määratakse Pordi C pinni 1. Ei ole ju kuigi rauakauge lähenemine. (eeldades on inimene on teadlik biti-tehetest).

Vaataks nüüd ka jadaporti saatmist:

using namespace USART;
USART0 Connection;

Connection.SetupAsynchronous(7, RecieverEnable, TransmitterEnable, NoParityCheck, NormalStopBit, DataBitsCount8, Normal, SingleProcessor);    
Connection.Send(66);
Connection.SendArray("test", 4);

Ka selles koodis on välja loetav mida tehakse - ei ole seadeid mida poleks rauas olemas. SendArray on muidugi funktsioon mille kohta rauaga mitte-tuttav inimene ei oska arvata kas massiivi saatmine on tark- või raudvaraline, kuid ka tavalise C puhul tehakse (või võetakse kuskilt) selliste asjade jaoks funktsioonid - nii et teatav distants rauast esineb mõlemal juhul.

Seega põhiosa sest teegist käsitleb kõiki kontrolleri osi ja funktsioone verbaalsete objektide ja funktsioonidena. Pole päris nii, et programmeerija kirjutab väga rauakauge käsu: kutsu mingit funktsiooni 1 sekundi tagant välja. (kuigi selline asi oleks mugav ja võiks vabalt implementeerida). Igatahes piisav ja mõistlikum on teada USART-i puhul mis on parity ja stop-bit kui nende mõlemi Atmeli poolt antud biti nime ja paiknemist erinevate kontrollerite registrites.

Aga jah, kui mugavusi kasutada, siis 100% rauainseneriks ei saa selle teegi kasutajat tõesti nimetada, kuid see polegi nii mõeldud. See on mõeldud vahekihina raua ja rakenduse vahel, et tööd jaotada ja igal tasemel effektiivsemaks teha. Tarkvarainsener on see kes tänu rauakoormast vabanemisele saab palju loovam olla. Aga et tarkvarainsener rauda päris ära ei unustaks tulevad dokumentatsiooni viited vastavatele datasheedis olevatele peatükkidele ja suure tõenäosusega on ta esmasel kasutamisel sunnitud neid ka lugema