Testailin vähän encoderin lukua Arduino:lla,
netistä löytämääni ohjelman tynkää muuttamalla
sainkun sainkin, näytöön nousevan ja laskevan
arvon.Ohjelma käytää ohjaimen molempia ulkoisia
keskeytyksiä.
Ojelma myös "kadottaa" kymmenyksen kun siirtyy
nolla pisteen yli tai alle??.
Ohjelmointikieli on c-kielen tyyppistä, pitääkin
kaivaa esiin "paperit" kahdeksan vuoden takaiselta
c-kurssilta : )
(http://encoder.jpg)
Tarkoitatko suunnanvaihtoa (kun hukkaa nollapisteen)?
Jos näin, lue aina vaihtuva tila A&B-pulsseista.
Olen joskus tehnut aloituksen aiheesta, missä on useammalla
eri kielelle ohjelmaesimerkit, en löytänyt sitä tähän hätään...
Ujosti off-topic, mutta on muuten aivan vallaton peli tuo arduino.
Itsekin fanitan kyseistä laitosta. Ääri helppoa saada hilavitkuttimia up-and-running Arduinolla.
USkallatko laittaa jakoon encooderin-luku-snippettiä?
Arduino on tosiaan helppo saada toimimaan, ja
hintakin n20e ei paha.
Encoderi ohjelma käyttää keskeytyksiä
(joita 2) A: ssa ja Index linjassa,kymmenys
katoaa aina kun encoderi mene nollasta -0.1
Kun A saa aikaan keskeytyksen niin B linja
lukemalla saadaan pyörimis suunta (näin olen
ymmärtänyt).Linkki keskusteluun josta olen
ohjelman "lainannut"(Bluemarble:n postaus).
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1185064568
Lainaus käyttäjältä: Pete2 - 20.12.09 - klo:08:53
Kun A saa aikaan keskeytyksen niin B linja
lukemalla saadaan pyörimis suunta (näin olen
ymmärtänyt).
Joo tuo on yksinkertaisin tapa saada liike ja suunta ulos kvadratuurienkooderista. Siinä on (huonolla ohjelmakoodilla) pieni riski saada asema liukumaan jos enkooderi tärisee tai vaihtaa suuntaa hyvin usein pienellä liikevälillä. Tähän törmäsin itsekin vuonna miekka ja kilpi kun näitä palkan eteen toteutettiin.
Tehokkain tapa lukea q-enkooderia on ottaa kiinni jokainen tilanvaihto kummastakin kanavasta, siis sekä nousevat että laskevat pulssinreunat A- ja B-kanavasta. Noista on helppo toteuttaa tilakone joka laskee asemaa/nopeutta 4 kertaa tarkemmin kuin lukemalla vain A-kanavan nousevalla pulssinreunalla.
Tilakaavio menee näin (olettaen, että A-kanavan nouseva reuna tulee eteenpyörimisessä ennen B-kanavan nousevaa):
Kanava| A B | A B | A B | A B |
Tila| 0 0 | 0 1 | 1 0 | 1 1 |
A(nous) | --- | --- | Et | Ta |
A(lask) | Ta Et --- --- |
B(nous) | --- | Ta | --- | Et |
B(lask) | Et | --- | Ta | --- |
Kanava = kanava jonka tilaa katsotaan
Tila = kanavan tila lukuhetkellä
A(nous) jne = kanavan tilamuutos joka käynnistää tilojen luvun
Et = enkooderi pyörii nimellisesti eteen
Ta = enkooderi pyörii nimellisesti taakse
Pseudokoodi liikkeen dekodaukseen (olettaen, että on 1 keskeytys johon kaikki tilanvaihdot on ohjattu)
case kanava
A_nouseva: begin
if B_kanava = 0 then Asema = Asema +1 else Asema = Asema -1
end
A_laskeva: begin
if B_kanava = 1 then Asema = Asema +1 else Asema = Asema -1
end
B_nouseva: begin
if A_kanava = 1 then Asema = Asema +1 else Asema = Asema -1
end
B_laskeva: begin
if A_kanava = 0 then Asema = Asema +1 else Asema = Asema -1
end
end case
Tuolla algoritmilla Q-enkooderista irtoaa tarkin mahdollinen asema- ja liiketieto, eikä se missaa tilanvaihtoja (joista syntyy asemavirhettä). Haasteeksi tulee nyt tunnistaa, mikä tilanvaihto aiheutti keskeytyksen. Ratkaisuja tähän on useita erilaisia riipuen siitä, millaiset resurssit on käytettävissä. Simppelein on tietty 4 keskeytystuloa, joita palveltaessa ensin kirjataan keskeyttänyt kanava ja sitten ajetaan tuo algoritmi. Tai ne voidaan tallentaa erikseen luettaviksi parilla lisäpiirillä. Tai jos on sekä nousevalla että laskevalla reunalla aktivoituva keskeytystulo käytettävissä, niin kytketään tuloon (A XOR B) jolloin saadaan tilanmuutos keskeytystulossa jokaisesta reunasta. Tai sitten voi tehdä niin, että ylläpitää kanavien tilaa muistissa ja vertaa edelliseen tilaan jolloin keskeyttänyt pulssinreuna selviää vertailussa. Tällöin ei saa missata yhtään keskeytystä koska tila menee väärin ja hukataan pulsseja.
Nopeuden laskenta pulssijonosta on jo huomattavasti haastavampaa enkä laita mitään pseudokoodiakaan tähän kun siinä on aika monta liikkuvaa osaa. Mikäli joudutaan laskemaan nopeutta suurella dynamiikka-alueella ei pelkkä pulssien vähenteleminen toisistaan enää riitä vaan joudutaan myös ajastamaan pulssien välejä.
Tulipa vaan mieleen, vähä menee ohi aiheen mutta eikös pulssi anturilla saisi toteutettua manuaali sorviin karan ns. paikotuksen. Et laittas käsiporakoneen tk pitimeen kiinni, et saa porattua akseliin reikiä tietylly jaolle. Pulssi anturi ja joku näyttö ja karasta pyörittäs asteet kohdilleen ja pistäs jarrun päälle ja tökkäis reijän ja nii edelleen
Ohjelma esimerkissä index on kytketty toiseen
keskeytykseen jolla nollataan kymmenykset,ja
aletaan lasku uudestaan, niin virhe ei muodostu
kovin isoksi.
Tuo nouseva ja laskevat pulssireunat on
vaikea hahmottaa : )
Arduinossa on vain 2 keskeytystä,ehkä
indexin voisi lukea muullakin tavalla.
Lainaus käyttäjältä: Pete2 - 20.12.09 - klo:08:53
Linkki keskusteluun josta olen
ohjelman "lainannut"(Bluemarble:n postaus).
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1185064568
Vilkaisin tuota koodia. Ei se ehkä ihan ammattilaisen kirjoittamaa ole, mutta noin pääpiirteissään ajaa asiansa. Muutama seikka siitä paistaa läpi jotka viittaavat siihen, että asialla on kaveri joka ymmärtää tehtäväksiannon, mutta ei varmaan tee koneenohjausta eikä koodausta vakityönä (no, niinhän tekijä itsekin sanoo). Siitähän ei ole mitään pahaa sanottavaa, mutta aika helpo tuota koodia on toisaalta vähän parannellakin.
Lainaa
Bluemarble: PROBLEMS - for some reason it misses one tenth of a turn when the counter goes from 0.0 to -0.1.
Maybe someone could fix this?? it is not a huge problem.
Also, I'm not a programmer, if anyone sees ways I can clean up this code please let me know.
Yhden selvän mokan ainakin löysin: muuttuja
volatile unsigned int encoder0Pos = 0; //the encoder position variable.on sinänsä esitelty oikein, paitsi kun sitä käytetään myöhemmin, lause
if (encoder0Pos == -1){ // if encoder position is equal to -1on selkeästi esittelyn vastainen. Lukuarvo -1 ei ole unsigned int arvoalueella. Kääntäjästä riippuen koodin käyttäytyminen vaihtelee arvaamattomasti. Huolellisempi parseri ei edes päästäisi tuota objektikoodiksi asti. Muuttuja pitää ehdottomasti esitellä:
volatile int encoder0Pos = 0; //the encoder position variable.jos sitä noin käytetään.
Sitten tuo koko kierroslaskurin ja indeksipulssin käsittely on vähän sekavaa. Tekijällä ei ole oikein ollut selkeää näkemystä mitä hän on tekemässä, tai ainakaan se ei näy koodista. Tämä nyt lienee toki ihan testiohjelmaksi tarkoitettu rykäisy joten ei pidä olla liian kriittinen, mutta silti itse miettisin toisin mm. nämä asiat:
-Koodista näkyy, että anturin pulssimääräksi / kierros on päätetty 500. Hyvän koodaustavan mukainen nipotus vaatisi laittamaan tuon lukuarvon esitellyksi vakioksi eikä hautaamaan sitä koodiin. Nyt esim tuo 499 joka esiintyy koodissa on aika täydellinen taikaluku. Sehän on tietenkin 500 -1 ja pitäisi noin muotoilla myös koodissa (käyttäen siis sitä nimettyä vakiota), koska jos kaveri myöhemmin päättää että anturissa onkin vain 200 p/r niin mitä tuo 499 silloin tarkoittaa?. No, tämä on toisaalta vain tyylikysymys mutta ammattiohjelmoija saisi turpaansa jos tuollaista vääntäisi :D.
- Indeksipulssin käsittelyssä pitää olla tarkkana. Jos lukemaa käsitellään sen perusteella, niin ainakin pitää tietää montako pulssia indeksi enkooderin kiekolla kattaa. Kierrettäessä indeksin kohdalle eri suunnilta pitää pulssinreunojen paikkaero huomioida, muuten laskenta menee väärin. Aikanaan paljon käytettiin herra tohtori-insinööri Johannes Heidenhainin vehkeitä joissa indeksi tosin on lyhyt, vain yhden inkrementin (1/4 jakson) pituinen ja osuu väliin jossa sekä A että B =1.
Indeksi ei tarvitse omaa keskeytystä, vain tulosignaalin jonka arvo tarkistetaan jokaisella pulssikeskeytyksellä. Ensin muodostetaan suuntatieto ja sen jälkeen katsotaan onko indeksi mennyt päälle tällä keskeytyksellä. Jos on, tiedetään saavutun indeksialueelle kyseisestä suunnasta ja asema voidaan merkata kiinteästi kun tunnetaan indeksin peitto kooderin kiekolla. Heidenhainilla siis peitto = 1 inkrementti, joten asema voidaan suoraan nollata tähän. Arduinoon en ole milloinkaan koskenut, mutta jos siinä on 2 keskeytystä jotka saa liipaistua sekä nousevalla että laskevalla reunalla niin ne kanaviin kiinni. Indeksi normaliin tuloon.
Tuo näytön yhden desimaalin virhe tulee aivan varmasti joutosilmukassa olevasta näyttörutiinista. En sitä vaivautunut enempää analysoimaan, se on selvästi aivan rikki jo syntyessään. Tapa käsitellä kokonaisia ja desimaaleja tuolla tavalla aivan eri muuttujina on amatöörimäinen :) ja tarpeettoman vaikea. Kaveri ei ole uskaltanut/osannut tehdä tuota "oikein" käyttäen 2-komplementtiaritmetiikkaa. Jos tässä aikaa jää tänään muilta hommilta niin voin laittaa toimivaa koodia tuosta osuudesta, ellei joku muu ehdi ensin.
Lainaus käyttäjältä: Pete2 - 20.12.09 - klo:08:53
Arduino on tosiaan helppo saada toimimaan, ja
hintakin n20e ei paha.
Encoderi ohjelma käyttää keskeytyksiä
(joita 2) A: ssa ja Index linjassa,kymmenys
katoaa aina kun encoderi mene nollasta -0.1
Kun A saa aikaan keskeytyksen niin B linja
lukemalla saadaan pyörimis suunta (näin olen
ymmärtänyt).Linkki keskusteluun josta olen
ohjelman "lainannut"(Bluemarble:n postaus).
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1185064568
Kun oli aikaa niin viilasin vähän tuota esimerkkikoodia. Tämä ei ehkä juuri tällaisena käänny suoraan Arduinolle, kun minulla ei semmoista eikä sen käännösaikaisia kirjastoja ole. AVRStudio ja GCC kelpuuttavat tämän noin pääosin. Pienellä mekaanisella viilaamisella pitäisi mennä läpi.
Alkuperäisen kirjoittaja ei ollut huomioinut mm. sitä, että pitää olla varovainen käsiteltäessä muuttujia joiden arvo saattaa päivittyä keskeytyksen aikana. Pahimmassa tapauksessa arvo on muuttunut tai rikki (monitavuisilla rakenteilla) jos keskeytyksen aiheuttama päivitys osuu keskelle lauseen evaluointia. Ja sehän osuu ennemmin tai myöhemmin...
Desimaalivirhe oli helppo - perinteinen off by one ja helppo fiksata.
#include <avr/interrupt.h>
#define encoder0PinA 3 //Quadrature Track A
#define encoder0PinB 4 //Quadrature Track B
#define encoder0PinC 2 //Index Track
#define ENCODER_RESOLUTION 500 // Resoluutio kerrotaan nimetyllä vakiolla joka esitellään, eikä koodiin hautaamalla!
#define SUBDIVISIONS 10 // Moneenko osaan kierros jaetaan näytöllä
//encoder variables
volatile int encoder0Pos = 0; //the encoder position variable.
volatile int turn = 0; //the total turns.
volatile int cw; // pyörii myötäpäivään (miksikähän alkup tekijä oli valinnut vastapäivään)
volatile int atIndex; // INDEKSITIETO KESKEYTYKSESTÄ JOUTOSILMUKKAAN
volatile unsigned int chA, chAPrev; // Enkooderin A-kanavan viimeinen ja viimeistä edellinen tila
volatile unsigned int chB, chBPrev; // Enkooderin B-kanavan viimeinen ja viimeistä edellinen tila
// int start = true; //variable used to indicate the first time the encoder sees the index track.
int decimal = 0; //tenths of a turn.
int encoderHome = 0; //used to reset encoder0Pos if any counts are missed during a rotation.
// pitäisi olla volatile kun muutetaan keskeytyspalvelijasta!! No ,tätä ei enää käytetä joten jätä kommentoiduksi
// int ccw = false; //which direction the encoder is spinning.
int display = 0; //variable for display data on LCD screen.
void setup(){
//encoder pinModes
pinMode(encoder0PinA, INPUT);
digitalWrite(encoder0PinA, HIGH); // turn on pullup resistor
pinMode(encoder0PinB, INPUT);
digitalWrite(encoder0PinB, HIGH); // turn on pullup resistor
pinMode(encoder0PinC, INPUT);
digitalWrite(encoder0PinC, HIGH); // turn on pullup resistor
/* MOLEMMAT KESKEYTYKSET ENKOODERIN KANAVIIN */
attachInterrupt(0, doEncoder, CHANGE); // encoder track A on interrupt 0 - pin 3
attachInterrupt(1, doEncoder, CHANGE); // encoder track A on interrupt 1 - pin 4
beginSerial(19200); //start communications with LCD screen Matrix Orbital LCD0821
Serial.print(254, BYTE); //turn off the cursor on LCD
Serial.print(84, BYTE); //turn off the cursor on LCD
Serial.print(254, BYTE); // turn on the LCD backlight //remove any of these if needed
Serial.print(66, BYTE); // turn on the LCD backlight
Serial.print(0); // turn on the LCD backlight
}
void loop(){
int tmpPos, tmpTurn;
Serial.print(12, BYTE); //clears the LCD screen.
Serial.println ("Turns ="); //print "Turns =" on the LCD screen.
cli(); // VOLATILE-MUUTTUJAN KÄSITTELY PITÄÄ KEHYSTÄÄ KESKEYTYSKIELLOIN!
tmpPos = encoder0Pos;
tmpTurn = turn;
sei();
decimal = (tmpPos * SUBDIVISIONS / ENCODER_RESOLUTION);
if (tmpTurn <0) {
display = abs(tmpTurn+1);
decimal = abs(decimal); // Tässä oli syy miksi yksi desimaali putosi pois. Klassinen off-by-one -virhe
Serial.print ("-"); //print a negative sign when turns is negative
} else {
display = tmpTurn;
}
Serial.print (display); //show turns on LCD
Serial.print ("."); //print a decimal point after the turns
Serial.print (decimal); //print the tenths of a turn after the decimal point.
delay(20); //delay 20ms so that the LCD screen doesnt flood
}
void doEncoder(){
int dA, dB, chC;
chA = digitalRead(encoder0PinA); //OLETUS: TÄMÄ FUNKTIO ASETTAA ALIMMAN BITIN ARVOON 1/0 JA MUUT 0
chB = digitalRead(encoder0PinB);
dA = chA ^ chAPrev;
dB = chB ^ chBPrev;
// tsekataan kumpaan suuntaan inkrementti tuli ja päivitetään inkrementtilaskuri sen mukaan.
// Otetaan välistä ulos suuntatieto muuttujaan cw
cw = ((dA && (chA ^ chB)) || (dB && !(chA ^ chB)));
encoder0Pos += cw - ((dA && !(chA ^ chB)) || (dB && (chA ^ chB)));
chAPrev = chA;
chBPrev = chB;
chC = digitalRead(encoder0PinC);
if (chC) { // olisko indeksisignaali just nyt päällä
atIndex = true;
encoder0Pos = 0;
if (cw) turn +=1 else turn -= 1;
}
Lainaus käyttäjältä: tanantunari - 20.12.09 - klo:12:06
Tulipa vaan mieleen, vähä menee ohi aiheen mutta eikös pulssi anturilla saisi toteutettua manuaali sorviin karan ns. paikotuksen. Et laittas käsiporakoneen tk pitimeen kiinni, et saa porattua akseliin reikiä tietylly jaolle. Pulssi anturi ja joku näyttö ja karasta pyörittäs asteet kohdilleen ja pistäs jarrun päälle ja tökkäis reijän ja nii edelleen
Kyllä kai tuon voisi tehdä. Muutama haastehan siinä tulisi, lähinnä kai se, ettei anturin lukema ole mikään lukko joka estäisi karaa liikkumasta. Kun ei sorvissa normaalisti ole mitään karajarrua niin pitäisi keksiä sellainen joka lukittuu liikuttamatta karaa yhtään. Ei varmaan mahdotonta mutta eikö helpompaa olisi soveltaa johderuuvin hammaspyörävälityksiä ja keksiä niihin lukitusmekanismi? Sopivilla rattailla saisi aika joukon jakoja aikaan.
Nyt kun pyöritän encoderia kierrokset
vain kasvavat ja decimaali pisteen
jälkeen 0,on kun tieto suunnasta ei
päivity vaan on + kokoajan.
Muutokset että sain käännettyä ohjelmaan ja tietenkin
Lcd näytön sarjaväyläisestä tavalliseksi:
if (chC) { // olisko indeksisignaali just nyt päällä
atIndex = true;
encoder0Pos = 0;}
else if (cw) {turn +=1;}
else {turn -= 1;}
Mutta kun meitin sorvissa on karajarru, siinä kara lähtee pyörii eteen ja taakse kun vetää joystikistä ylös ja alas ja sivuille on jarru ja vapaa. Niin minkähänlainen pulssi anturi siihe tarvis olla ja sit joku lcd näyttö mistä näkis asteet. Ei varmaan maksaiskaa ihan mansikoita.
Lainaus käyttäjältä: Pete2 - 20.12.09 - klo:20:11
Nyt kun pyöritän encoderia kierrokset
vain kasvavat ja decimaali pisteen
jälkeen 0,on kun tieto suunnasta ei
päivity vaan on + kokoajan.
Muutokset että sain käännettyä ohjelmaan ja tietenkin
Lcd näytön sarjaväyläisestä tavalliseksi:
if (chC) { // olisko indeksisignaali just nyt päällä
atIndex = true;
encoder0Pos = 0;}
else if (cw) {turn +=1;}
else {turn -= 1;}
Tuo ei noin kirjoitettuna toimi samalla tavalla, eikä itse asiassa ollenkaan. Menisikö tämä läpi sinun kääntäjästäsi:
if (chC) {
atIndex = true; // tätä ei itse asiassa nyt edes käytetä missään, joten voi jättää poiskin...
encoder0Pos = 0;
if (cw) {
turn += 1;
} else {
turn -= 1;
}
}Koodinpätkän tarkoitus on indeksin tullessa asetta indeksitieto, nollata positolaskuri sekä liikkeen suunnasta riippuen joko kasvattaa tai vähentää kierroslaskuria.
Lainaus käyttäjältä: tanantunari - 20.12.09 - klo:21:17
Mutta kun meitin sorvissa on karajarru, siinä kara lähtee pyörii eteen ja taakse kun vetää joystikistä ylös ja alas ja sivuille on jarru ja vapaa. Niin minkähänlainen pulssi anturi siihe tarvis olla ja sit joku lcd näyttö mistä näkis asteet. Ei varmaan maksaiskaa ihan mansikoita.
No tässähän sinun laskuriasi koko ajan koodataan ;D. Semmoinen anturi jota tässä nyt on käsitelty, eli kvadratuuri-inkrementtianturi kelpaisi hyvin.
Suuri, ehkä suurin haaste on julmettu resoluutiovaatimus pulssianturille. Veikkaan että homma todellisuudessa kaatuu tähän.
Seuraava suuri haaste on keksiä pulssianturille sopiva asennuspaikka. Välystä ei isommin passaisi olla, joten aika kiinteästi pitäisi saada karaan kiinni. "Helppo" tapa olisi laittaa karan jatkoksi, mutta kun siinä on se reikä keskellä ja joskus sieltä saattaa tulla rautaa läpi :).
Joku viritys pitää siis rakentaa, ehkä hammashihna tms jolla saa anturin pois karan akselilta. Tämmöisiin vaan tuppaa helposti syntymään periodisia kulmavirheitä jolloin reikiä tulee kyllä oikea määrä mutta jako on pikkaisen pielessä suuntaan ja toiseen kierroksen matkalla.
Tarkkuusvaatimusta voi arvioida vaikka tälleen: oletetaan että sorviin mahtuu sellainen kappale, että jakoympyrän max säde olisi 100mm. Sanotaan että jako halutaan satasen tarkkuudella. Kulmavirhettä saa silloin olla ~0,0001 radiaania eli noin 0,0057 astetta. Kiertokulman resoluutio pitää tällöin olla n. 62800 inkrementtiä / kierros. Ei mahdotonta, mutta jos tietäisit mitä tuollaiset anturit maksaa niin muuttuisit kalpeaksi kuin lakana.
Kaikkea voi viritellä ja varmaan tuohonkin löytyisi jotain konsteja, mutta ehdotan luopumaan. Hyvän mekaanisen jakopään saa murto-osalla tämmöisen keksinnäön kustannuksista vaikkei omalle työlle laskisi mitään.
Nyt laskee täysiä kierroksia yhteen suuntaan,ei kymmenyksiä.
Encoderini antaa 400 p/k joten muutin ENCODER_RESOLUTION.
void doEncoder(){
int dA, dB, chC;
chA = digitalRead(encoder0PinA); //OLETUS: TÄMÄ FUNKTIO ASETTAA ALIMMAN BITIN ARVOON 1/0 JA MUUT 0
chB = digitalRead(encoder0PinB);
dA = chA ^ chAPrev;
dB = chB ^ chBPrev;
// tsekataan kumpaan suuntaan inkrementti tuli ja päivitetään inkrementtilaskuri sen mukaan.
// Otetaan välistä ulos suuntatieto muuttujaan cw
cw = ((dA && (chA ^ chB)) || (dB && !(chA ^ chB)));
encoder0Pos += cw - ((dA && !(chA ^ chB)) || (dB && (chA ^ chB)));
chAPrev = chA;
chBPrev = chB;
chC = digitalRead(encoder0PinC);
if (chC) {
atIndex = true; // tätä ei itse asiassa nyt edes käytetä missään, joten voi jättää poiskin...
encoder0Pos = 0;
if (cw) {
turn += 1;
} else {
turn -= 1;
}
}
}
Lainaus käyttäjältä: Pete2 - 20.12.09 - klo:22:47
// tsekataan kumpaan suuntaan inkrementti tuli ja päivitetään inkrementtilaskuri sen mukaan.
// Otetaan välistä ulos suuntatieto muuttujaan cw
cw = ((dA && (chA ^ chB)) || (dB && !(chA ^ chB)));
encoder0Pos += cw - ((dA && !(chA ^ chB)) || (dB && (chA ^ chB)));
En itse pääse debuggaamaan tuota joten koetapa muokata lausetta vähän:
cw = ((dA && (chA ^ chB)) || (dB && !(chA ^ chB)));
ccw = ((dA && !(chA ^ chB)) || (dB && (chA ^ chB))); // tämä muuttuja on esiteltävä samoin kuin cw
if (cw) {
encoder0Pos += 1;
} else if (ccw) {
encoder0Pos -= 1;
}
Jotain muutakin bugia tuossa vielä täytyy olla. Kokeile nyt tuolla niin katsotaan mitä tapahtuu.
Nyt laskee kymmenyksiä eteenpäin riipumatta
pyörityssuunasta kunnes 800 tulee täyteen jonka
jälkeen - merkki(muutuu negatiiviseksi) eteen ja
laskeminen taaksepäin 0:aan ja taas alusta.
Liitteenä ohjelma.
Tuosta olit pudottanut pois kierrosten laskun keskeytyspalvelusta. Ei sitä ollut tarkoitus poistaa.
#include <avr/interrupt.h>
#include <LiquidCrystal.h>
#define encoder0PinA 3 //Quadrature Track A
#define encoder0PinB 4 //Quadrature Track B
#define encoder0PinC 2 //Index Track
#define ENCODER_RESOLUTION 400 // Resoluutio kerrotaan nimetyllä vakiolla joka esitellään, eikä koodiin hautaamalla!
#define SUBDIVISIONS 10 // Moneenko osaan kierros jaetaan näytöllä
//encoder variables
volatile int encoder0Pos = 0; //the encoder position variable.
volatile int turn = 0; //the total turns.
volatile int cw, ccw; // pyörii myötäpäivään (miksikähän alkup tekijä oli valinnut vastapäivään)
volatile int atIndex; // INDEKSITIETO KESKEYTYKSESTÄ JOUTOSILMUKKAAN
volatile unsigned int chA, chAPrev; // Enkooderin A-kanavan viimeinen ja viimeistä edellinen tila
volatile unsigned int chB, chBPrev; // Enkooderin B-kanavan viimeinen ja viimeistä edellinen tila
// int start = true; //variable used to indicate the first time the encoder sees the index track.
int decimal = 0; //tenths of a turn.
int encoderHome = 0; //used to reset encoder0Pos if any counts are missed during a rotation.
// pitäisi olla volatile kun muutetaan keskeytyspalvelijasta!! No ,tätä ei enää
käytetä joten jätä kommentoiduksi
// int ccw = false; //which direction the encoder is spinning.
int display = 0; //variable for display data on LCD screen.
LiquidCrystal lcd(7, 8, 9, 10, 11, 12);
void setup(){
//encoder pinModes
pinMode(encoder0PinA, INPUT);
digitalWrite(encoder0PinA, HIGH); // turn on pullup resistor
pinMode(encoder0PinB, INPUT);
digitalWrite(encoder0PinB, HIGH); // turn on pullup resistor
pinMode(encoder0PinC, INPUT);
digitalWrite(encoder0PinC, HIGH); // turn on pullup resistor
/* MOLEMMAT KESKEYTYKSET ENKOODERIN KANAVIIN */
attachInterrupt(0, doEncoder, CHANGE); // encoder track A on interrupt 0 - pin 3
attachInterrupt(1, doEncoder, CHANGE); // encoder track A on interrupt 1 - pin 4
lcd.begin(16, 2);
lcd.noCursor();
}
void loop(){
int tmpPos, tmpTurn;
lcd.clear(); //clears the LCD screen.
lcd.print ("Turns ="); //print "Turns =" on the LCD screen.
cli(); // VOLATILE-MUUTTUJAN KÄSITTELY PITÄÄ KEHYSTÄÄ KESKEYTYSKIELLOIN!
tmpPos = encoder0Pos;
tmpTurn = turn;
sei();
decimal = (tmpPos * SUBDIVISIONS / ENCODER_RESOLUTION);
if (tmpTurn <0) {
display = abs(tmpTurn+1);
decimal = abs(decimal); // Tässä oli syy miksi yksi desimaali putosi pois. Klassinen off-by-one -virhe
lcd.print ("-"); //print a negative sign when turns is negative
} else {
display = tmpTurn;
}
lcd.print (display); //show turns on LCD
lcd.print ("."); //print a decimal point after the turns
lcd.print (decimal); //print the tenths of a turn after the decimal point.
delay(20); //delay 20ms so that the LCD screen doesnt flood
}
void doEncoder(){
int dA, dB, chC;
chA = digitalRead(encoder0PinA); //OLETUS: TÄMÄ FUNKTIO ASETTAA ALIMMAN BITIN ARVOON 1/0 JA MUUT 0
chB = digitalRead(encoder0PinB);
dA = chA ^ chAPrev;
dB = chB ^ chBPrev;
cw = ((dA && (chA ^ chB)) || (dB && !(chA ^ chB)));
ccw = ((dA && !(chA ^ chB)) || (dB && (chA ^ chB))); // tämä muuttuja on esiteltävä samoin kuin cw
if (cw) {
encoder0Pos += 1;
} else if (ccw) {
encoder0Pos -= 1;
}
chAPrev = chA;
chBPrev = chB;
chC = digitalRead(encoder0PinC);
if (chC) {
encoder0Pos = 0;
if (cw) {
turn += 1;
} else {
turn -= 1;
}
}
}
Nyt laskee eteenpäin ok paitsi että
kymmenykset nollautuvat 20:nessä
taaksepäin laskee kymmenykset
samalla tavalla,mutta kierroslaskuri
muutumaton.
Luulisin että hardware ok
Olisi ehkä pitänyt aloittaa Ledin vilkutus ohjelmalla,
eikä heti kesketyksiä ja nosevia reunoja : )
Viimeksi olen vääntänyt assembler koodia 8085 processorille : )
vuosia sitten.Basic stamp II löytyy myös,mutta se on hidas
lukemaan encoderia.
Nuo mikrocontrollerit näyttävät mielenkiintoiselta. Aloitin kolmenkymmentä vuotta sitten mikrorakentelun. Kerhoomme kuului tuhansia jäseniä. 1800 User`s Club oli kerhon nimi ja prosessori oli RCA 1800 sarjasta. Koneen nimi oli Telmac. Hauskaa kesti muutaman vuoden kunnes hankin PC:n. Nyt tuntuu, että tuo Arduino olisi lupaus tulevasta. Onko joutilasta osaajaa, joka joutaisi kertomaan hieman lisää. Mistä koneen voi hankkia ja siitä eteenpäin. p. 050-595 4464 Honkanen tai yksityisviestilläkin. En vielä rohjennut klikata linkkiä. Kyllä "poikakin" voi olla vanha(naikainen)
En ole osaaja mutta joutilas : )
Ostin oman Arduinon huutonetistä tuli n viikossa
Honkongista,Arduinosta on olemassa monta mallia
ja monta kloonia.Ainakin Robomaa.com myy Suomessa.
Erittäin hyvin dokumentoitu netissä.
Ostin omani elektrokit.se ruotsista. Voin suositella. Postit ei maksa sen enempää juurikaan kuin suomesta.
Omasta mielestä arduinon hienous on nimenomaan saatavilla oleva suuri määrä dokumentoitua koodia ja esimerkkejä joita netti on pullollaan. Lsiäksi arduinon koodikirjastolla (vaimikäsenyoli) on helppoa saada mm. lcd:t, servot, pwm ym. toimimaan vaan minuuteissa.
Siitä sitten muokkaamaan ja kehittämään omaa sovellusta.
Lainaus käyttäjältä: Pete2 - 21.12.09 - klo:14:32
Nyt laskee eteenpäin ok paitsi että
kymmenykset nollautuvat 20:nessä
taaksepäin laskee kymmenykset
samalla tavalla,mutta kierroslaskuri
muutumaton.
Luulisin että hardware ok
Olisi ehkä pitänyt aloittaa Ledin vilkutus ohjelmalla,
eikä heti kesketyksiä ja nosevia reunoja : )
Viimeksi olen vääntänyt assembler koodia 8085 processorille : )
vuosia sitten.Basic stamp II löytyy myös,mutta se on hidas
lukemaan encoderia.
Ei tämäkään niin rakettitiedettä ole, ettei voisi näillä aloittaa :)
Tein piruuttani eilen iltapuhteeksi AVR Studiolla testiohjelman, jossa simuloin kaikki koodinpätkät pulssikeskeytyksen ja näyttölaskennan käsittelyssä. Simulattorisa ne toimivat kyllä aivan tarkoitetulla tavalla, eli positio laskee ylös/alas, indeksi päivittää kierroslaskurin ja nollaa position, kierros- ja desimaalinäyttö seuraavat laskentaa kuten pitää. Minulla siis AVR Studio joka käyttää kääntäjänä AVR-GCC ja simulaation tein mega32:a matkien (millä ei pitäisi olla väliä, koska piirin ominaisuuksia ei testiohjelmassa käytetä mihinkään).
Oletko varma, että nuo LCD-näytön ohjaukset todellisuudessa toimivat juuri olettamallasi tavalla? Niitä en pysty simuloimaan kun minulla ei ole tuota Arduinoa itsellä.
Ehkä Lcd ohjelmassa kielletään kesketykset,kun
se lähettää byten 4bittiä kerrallaan näytöön?
Ajattelin laittaa vähän "hardwarea" encoderin jälkeen
että ei tarvitse tarkistella pyörimissuuntaa vaan vain
pulsseja ,netissä oli joku 74ls74:lla toteutanut moisen.
Jos se näyttö on HD44780-klooni niin silloin ei pitäisi olla tarvetta kieltää keskeytyksiä missään vaiheessa näytönpäivitystä. Mutta kukapa tietää ennekuin lukee sorsakoodista onko vai ei. Voihan siihen jkoku syy olla.
Kokeile toki sitä piiriratkaisua jos siltä tuntuu. Puusta katsoen tuon keskeytyksen ei pitäisi tarvita mitään pitoa flipflopilla mutta saahan sitä kokeilla. Miten muuten meinasit saada selville pyörimissuunnan jos vain "tarkistelet pulsseja" mutta et pyörimissuuntaa? Meinaan että jos tuo tieto ylipäänsä muodostetaan niin jostain se johtopäätös on kuitenkin tehtävä.
Kytkin 74ls74 näin:
http://profmason.com/?p=775
Testasin ledillä kaikki ok.
Sitten kytkin kaksi Diodia outputeihin,
josta johto vain kesketys pinniin.
(Näin keskeytys jos pullssi eteen tai taakse
outputissa)
En käytä indexiä,mutta nyt sille olisi vapaana
viimeinen "pinnikeskeytys"
Nyt toimii jos pyörittää encoderia hitaasti,
mikähän on "pullonkaula" : ) flifloppi vai
laskeeko jännite liikaa diodien takia kun "liipaisu"
aika lyhenee.
Tuo kytkentä antaa sinulle nyt yhden inkrementin kestoisia pulsseja eteen/taakse kahden inkrementin välein. Resoluutio siis on tässä kytkennässä puolet siitä mitä esimerkkiohjelmassa. Jos ymmärsin oikein, e/t -pulssit on kytketty omiin inputteihinsa ja kumpikin diodin kautta vielä yhteen keskeytystuloon.
Pullonkaula ei ainakaan ole 74-logiikan hitaus, se kun on hyvinkin nopeaa. Tilanvaihdot tapahtuvat nanosekunneissa.
Tuo diodiviritys kuullostaa hyvin epäilyttävältä. Jos käyttämäsi piiri on LS-sarjaa niin se low power schottky-teknologia auttaa vähän, mutta silti 74-sarjan piirien kytkeminen erilaisiin virityksiin ei ole takuuvarman onnistumisen paikka. Jos nuo diodit ovat katodi keskeytystuloon päin niin silloin kun kumpikaan flipflop ei ole 1-tilassa, inputti efektiivisesti kelluu. Jos tuloportin ylösvetovastus on aktivoitu, niin sen virta ei mene mihinkään (kun ei pääse diodista läpi flipflopin 0-tilassa olevaan lähtöön) vaan hinaa inputtia kohti 1-tilaa. Ellei ylösvetoa ole aktivoitu, portti kelluu epämääräisessä tilassa. Eli keskeytystuloon pitäisi kytkeä vielä vastus maihin jotta se saadaan luotettavasti 0-tilaan. Vastus pitää mitoittaa niin, että se luotettavasti vetää inputin nollatilaan mutta toisalta niin, että LS-piirin lähtö jaksaa työntää tarpeeksi virtaa jotta tila nousee myös luotettavasti 1-tasoon. Nyt kun alasvetovastusta ei ole, voi käydä jopa niin, että keskeytyksen liipaisee se pieni varausten tasausvirran aiheuttama jännitenökö, joka keskeytystulossa todennäköisesti näkyy kun flipflop putoaa 1-tilasta 0-tilaan. Tuo on äärettömän epämääräinen signaaliksi ja tapahtuu sitä paitsi aivan väärällä ajanhetkellä. Jos arvaan tässä oikein, niin ensinnäkin pyörintäsuunta tulkitaan helposti väärinpäin ja toiseksi pulssititetojen luku tapahtuu hyvin lähellä flipflopin tilanvaihtoa. Voi siis olla ettei viritys kestä nopeampaa pyöritystä siksi, että ajoitukset menevät ristiin eikä mitään järkevää näy (luettaessa nopeasti pyörivää enkooderia tulot ovat aina 0-tilassa lukuhetkellä).
Tällainen 74-logiikan lähtöjen yhdistäminen tehtäisi "oikein" käyttäen piiriä, jossa avoin-kollektorilähtö. Tuollainen lähtö vetää signaalia vain nollaan, mutta ei ykköseen päin. Näitä voi yhdistää rinnan montakin, kunhan niitä lukevassa tulopiirissä on se ylösvetovastus jolla 1-tila saadaan aikaan kun mikään lähtö ei vedä 0-tilaan päin. Tuossa käyttämässäsi ls74:ssä on komplementtilähtö joten sitä ei voi käyttää tähän tapaan. Enpä suoraan muista olisko 74-sarjassa dual d-fliparia o/c lähdöllä, mutta voisihan tuohon lähdön perään laittaa open collector invertterin tai driverin.
Minusta tämä viritys ei ole ainakaan parempi ratkaisu kuin alkuperäinen. Puolet resoluutiosta on menetetty ja kytkentä on monimutkaisempi, ja tällaisena epäluotettava. Tämä ei sitäpaitsi tee mitään mitä alkuperäinen ei myös tehnyt, vaan vähemmän (ei kierroslaskentaa). Periaate sinänsä on ihan OK, mutta minusta turha käyttää tässä sovelluksessa jossa käytössä on prosessori jonka laskentavoima kevyesti pesee parin flipflopin tuoman lisäarvon. Minusta sinun kannattaisi ennemmin hieroa nystyrää kunnes tarkkaan ymmärrät mitä sen alkuperäisen koodin on tarkoitus rivi riviltä tehdä, ja etsit siitä syyn toimimattomuuteen. Se löytyy kyllä ja kun olet sen löytänyt, olet yhden kynnyksen ylemmällä osaamisessa.
Mutta tämä on siis vain minun mielipiteeni. Teet tietysti ihan mitä haluat - kyllä se viisaus lisääntyy monella eri tavalla ;D
Resuluutio kyllä piisaa näinkin,ja inputin jouduin
laittamaan digitalWrite(encoder0PinA, LOW)
että sain toimimaan.
Taidan koittaa seuraavaksi flip flopin antoja
molemissa kesketyksissä, ilman diodi "härpäkkeitä",
Ja sitten palaan taas ensimäiseen versioon : )
Joo epäilinkin että ylösvetovastuksen käyttö estäisi toiminnan.
Nuo fliparien lähdöt suoraan kahteen keskeytykseen niin voi muitta mutkitta laskea joko ylöspäin tai alaspäin siitä riippuen kumpi keskeytys tuli.
Terve
Jos tarvitsette apuja tuossa AVR:n kanssa, olen sulautettujenjärjestelmien ohjelmoija / HW-suunnittelija.
Kesällä perustin oman yrityksen tarjoamaan CNC-kone huoltoa / valmistusta, Mekaniikka / elektroniikkasuunnittelua.
Erikoisosaamisena Propo / servo hydrauliiikan ohjaukset ja CanOpen ohjaukset.
Pitääpä laittaa oikeen yritys esittely tuonne tarjouspuolelle....
Täällä on aika kattava AVR kirjasto:
http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/main.html
Tuossa linkki suoraan encoder fileen.
http://www.mil.ufl.edu/~chrisarnold/components/microcontrollerBoard/AVR/avrlib/docs/html/encoder_8c-source.html
*Tuosta muokkaamalla saa ihan hyvän encoder kirjaston itselleen.
Hyviä jouluja
Taas vähän "testattu" laitoin AMT102 encoderin resulaatioksi 48 ppr (pulssia/kierros),
kun luen encoderia kesketyksillä molemmista kanavista A ja B niin resulutio on 192 ppr.
Jos luen encoderia kanavasta A ja pyörimissuunan tarkistan B stä niin resulutio on
silloin ....96 ?
AMT102 Daatoissa oli maininta että indexpulssin toiminta voi häiriintyä
jos lähellä voimakas mangneettikenttä,kuten stepperissä.
Lainaus käyttäjältä: Pete2 - 27.12.09 - klo:20:38
Taas vähän "testattu" laitoin AMT102 encoderin resulaatioksi 48 ppr (pulssia/kierros),
kun luen encoderia kesketyksillä molemmista kanavista A ja B niin resulutio on 192 ppr.
Jos luen encoderia kanavasta A ja pyörimissuunan tarkistan B stä niin resulutio on
silloin ....96 ?
AMT102 Daatoissa oli maininta että indexpulssin toiminta voi häiriintyä
jos lähellä voimakas mangneettikenttä,kuten stepperissä.
Juu noin pitääkin olla. Siis että "resoluutio" tuplaantuu eri lukutapojen välillä. Tuo valittu resoluutio 48 ppr tarkoittaa yhden kanavan pulssilukumäärää, siis esim a-kanavan nousevien reunojen lukumäärää / kierros. Yhdessä kanavassa on 2-kertainen määrä reunoja jos laskevat luetaan mukaan, ja jos molemmat kanavat otetaan mukaan niin 4-kertainen määrä. 48*2=96, 96*2=192. Erilaisilla dekoodausskenaarioilla saa kaikki nuo resoluutiot ulos laitteesta. Yksinkertaista, Watson ;D (Itseasiassa tämä jopa todetaan enkooderin datalehdelläkin: "All resolutions are before quadrature decoding").
Tuo AMT 102 ei perustu optiseen vaan kapasitiiviseen ilmaisuun joten varmaan indeksipiirissä sitten on jotain magneettikentästä häiriintyvää...
Lainaus käyttäjältä: Pete2 - 27.12.09 - klo:20:38
AMT102 Daatoissa oli maininta että indexpulssin toiminta voi häiriintyä
jos lähellä voimakas mangneettikenttä,kuten stepperissä.
Luin lisää datalehteä. Indeksipulssi generoidaan käyttäen apuna Hall-anturia jonka ilmaistessa (sisäänrakennettua magneettia?) päästetään läpi 1 kahdeksasta kierroksen aikana tulevasta kapasitiivisesta indeksipulssista. Ulkoinen magneettikenttä saattaa häiritä (s.o. varmasti häiritsee ollessaan tarpeeksi voimakas) Hall-anturia jolloin sen ilmaisuaika on liian pitkä tai liian lyhyt, häiriövuon suunnasta riippuen. Läpi voi siis päästä yhden sijasta 0 tai useita pulsseja. Datalehdessä mainitaan kriittiseksi magneettivuon tiheydeksi 40 gaussia joka vastaa SI-yksiköissä 4 mT. Tämmöisen vuontiheyden saa aikaan jo melko pienelläkin magneetilla, joten asiaan kannattaa kiinnittää huomiota. Aikoinaan mittailtiin Strömbergin GNAU-sarjan tasavirtamoottoreiden takalaakerikilven keskiöstä magnetointi päällä jopa ~700 gaussia joskin silloin puhuttiin kertaluokkaa 100kW+ koneista. Eipä sitten suunniteltu Hall-enkoodereita noihin koneisiin ;)
Pulsin komenolla saa luettua microsekunneissa kuinka kauan
joku io pinni on 1 tai 0.
Luin encoderin A kanavaa (reso 48ppr) ja arvo oli n5000 kun pyöräytin
akselia. Tästä saanee "helposti" laskettua Kierrosta/minuutissa : )
Lainaus käyttäjältä: Pete2 - 28.12.09 - klo:20:30
Pulsin komenolla saa luettua microsekunneissa kuinka kauan
joku io pinni on 1 tai 0.
Luin encoderin A kanavaa (reso 48ppr) ja arvo oli n5000 kun pyöräytin
akselia. Tästä saanee "helposti" laskettua Kierrosta/minuutissa : )
Kierroslukunäytön tuosta saa tosiaan helposti laskettua. Sehän on yksinkertaisesti n = K * 1/ (Ni * t), missä
n = kierrosluku valitussa mittayksikössä
K = sovituskerroin
Ni = enkooderin laskettavien inkrementtien määrä per kierros
t = yhden inkrementin kestoaika
A-kanavassa siis on tuo 48 inkrementtiä/kierros kun kvadratuuria ei huomioida. Jos sait laskuriin 5000 niin pulssi on kestänyt 5 ms. Kierrosluku olisi tällöin
n = 60 * 1/(48 * 5 * 10^-3) = 250 r/min
Vähän päivitystä (vuoden välein : ).
Ostin Arduino Megan jossa on 6 ulkoista kesketystä,
(Duemilanovessa vain 2)
mutta index pulssi encoderista (AMT102) oli aivan
sekaisin niitä tuli n16 per kierros.
Vika korjaantui siirtämällä encodeeri pois
stepperin mangneettikentästä kuten manuaalissa
neuvottiin.(index pulssi on toteutettu hal-anturilla).
Manuaalissa ei varoiteta servomoottorien mangneetti
kentistä, joten mangneettikenttä varmaan heikompi?.
(http://p1040001)
Muisti palailee pätkittäin... Tämmöistähän tosiaan uutterasti työstettiin vuosi sitten.
Onko Megan hankinnan myötä syntynyt uutta viisautta, vai saitko jo sen alkuperäisen viritelmän toimivaksi?
Pian taas koodataan : )
Edellinen "sessio" jäi vähän kesken kun
sille indexi pulssille ei piisannut keskeytystä.
Täytyy kyllä sanoa että näillä Arduino
microcontroleilla "kynnys" ohjelmointiin ja
sovellusesten tekemiseen on saatu tosi
matalaksi.
Arduino 328 + 2x AFmotor + 3 x Bebek 10€ moottorit pelittää mainiosti. Moottoriohjaus Adafruitin ohjaimilla, joilla saa kaksi askelmoottoria. Kaksi päällekkäin uros/naaras piikeillä ja ylemmän AFMotor siirtorekisterin datain siirretään digital-2 pinniin ja pieni muutos koodiin. Kaikki softa mahtuu mega328 suorat, ympyrät bezierkäyrät ja 16-segment kirjaimet.
Arduinoon löytyy myös G-koodi tulkki mutta jos olen ymmärtänyt oikein
niin teho/kapasiteetti ei ihan piisaa SD-kortilta g-koodin lukuun ja mootorien
ohjaamiseen samaan aikaan...
Voisi olla tosi mielenkiintoista kokeilla vähän vastaavaa mutta tehokkaampaa kapinetta; Olen viime aikoina työstänyt jotain pikku juttuja Arduinolla, mm. viimeksi ajoportin ohjauksen. Kun siinä kuitenkin on henkilöturvallisuus kyseessä ja talvella on kylmäkin, niin olen käyttänyt vakio-Arduinon sijasta Olimexin Olimexino-328 -korttia. Se on tehty industrial-tason komponentein, kelpuuttaa standardin +24VDC syötön, kestää lämpötiloja -25 - +80 ja siinä on standardi UEXT-laajennusliitin. Tuohon saa suoraan kiinni mm. niiden MOD-IO-kortin jossa on 4 optoerotettua tuloa, 4 relelähtöä ja 4 analogituloa. Noita I/O-kortteja voi vielä ketjuttaa ja nekin on ohjelmoitavia, eli niissä on samanlainen AVR-prosessori ja JTAG-liitin joten kaikki Atmelin kehityskalut käy niille suoraan. Joten yksinkertaista logiikkaa voi koodata suoraan I/O-kortille pois pääkonetta kuormittamasta.
No mutta asiaan: Olimexilla on myös Olimexino-STM32 joka on mekaanisesti kuin Arduino Uno, mutta moottorina on STM32, 32 bittinen tehomylly verrattuna 8-bittiseen ATMega328:iin. Tosin tuo ei ole Atmelin vaan ST:n piiri, joten Arduinon kehitysympäristö ei siihen käy suoraan. Lähelle kumminkin, nimittäin tuosta on kehitetty 32-bittiselle sopiva Maple-IDE joka on niinikään ilmainen ja vapaasti ladattavissa. Toimintaperiaate on ihan sama kuin vakio Arduinollakin.
STM32:ssa voisi olla puhtia vääntää g-koodi auki samalla kun ohjaa moottoreita. Fyysisestihän kortti siis on samanlainen joten useimmat Arduinon "shieldit" varmaan toimivat suoraan.
P.S. niin siis tuo STM32 on ARM Cortex-sarjan prosessori jossa löytyy vääntöä ihan kivasti.
RÄGÄTSI!
Etsiskelen pikkuista/edullista sovellusalustaa johon on olis sen verran ohjelmointiohjelmaa tarjolla, että vois tehdä pienimuotoista muutaman bitin I/O ohjauksia, joihin ei tarvita oikeata teollisuus PLC:tä.
Muistin tämän ketjun, koska olen päivän googlannut arduinnoo. Jotenkin tuntuu, ettei siinä ympäristössä ketään kiinnosta, että kaikki I/O on kytketty surutta suoraan prossun pinneihin ilman mitään cläppiejä, ferriittejä, erottimia, jumalauta mitään??
Sitten sä mainitsit tästä teollisuustason Olimexionosta.
Jos pitäis ohjata paria nimellisesti 12VDC 100w lyjyakku latureita, etteivät ne ala riitelemään ja säätlemään samoja asioita, vaan yksi tekee syklinsä loppuun, ennekun mahdollisesti vaihdetaan vahtivuoroa. 1-3 AI, muutama DI/O, ehkä pari nappia ja lediä tai 2*16 merkkinen näyttö.
Näyttö löytyi:
https://www.olimex.com/Products/Duino/Shields/SHIELD-LCD16x2/open-source-hardware
Muttei mitään RTC:tä, eikä I/O:ta tähän tyyliin:
https://www.adafruit.com/product/1141
http://www.adafruit.com/products/196
Myöhemmin erillisenä projektina pikkuinen ja hidas dataloggeri, jollei löydy valmista sitä ennen.
PekkaNF
Tuolla uudella linkkisivulla olevasta kaupasta löytyy paljon pientä ja edullista Arduino -tavaraa. Noissa hinnoissa ei ole alv mukana, mutta toimituskulut on. Jos ostoksen hinta on pieni, niin kirje tulee ilman lisäkuluja postitse suoraan kotiin.
Arduino-tavaraa täällä (http://www.thanksbuyer.com/electronics/for-arduino?tracking=52bf2fd4223b7)
----
Tullin sivuilta:
"Jos olet saanut saapumisilmoituksen, jossa edellytetään tavaran tulliselvittämistä, mutta mielestäsi kyseessä ei ole tullattava lähetys (tavaran hinta ilman lähetyskuluja on enintään 22 euroa tai lahjalähetyksen arvo enintään 45 euroa), voit soittaa Tulliin, puh. 040 332 6711 (ma-pe klo 8-16) tai lähettää sähköpostia e-mail: lentoposti@tulli.fi. "
Vierastan kiinalaisten tuotteiden ostamista. Mieluiten ostaisin euroopasta. Mutta toki ostan, jos ei muuta löydy. Yhdessä suomalaisen liikeen myymässä MPPT säätimessä oli sellainen ongelma, ettei se ollut ollenkaan MPPT, vaikka valmistaja väittää. Esimerkiksi.
Taidan päätyä ostamaan perusarduinnon ja varmaan joudun askartelemaan I/O:ta itse.
DO-puolella releohjaus sujuu, mutta high-side switch ja puskurit, partco tms. helposti saatavilla komponeneteilla on hakusessa.
DI puolella kaipaisin jotain linkiikä/ohjetta/kytkistä miten saa puskuroitua jonkin tason (esim 5v) signaalit siten, ettei mene kaikki häiriö suoraan prosulle esim vieressä olevien releiden tai WIFIN takia.
Ennen tein AI sisäänmenoihin puskurin ja alipäästösuodattimen ihan perus opampilla, mutta mitäs olis nykyisin tarjolla.
PekkaNF
No joo, minä voin sulle piirtää I/O-kuvia jahka saan tästä päivän työt pulkkaan ja päästään viikonlopun viettoon. Mille jännitetasoille tarvitsisit tulosignaaleja, ja millaisia jännitetasoja olisi tarve mitata? Niitä akkun napajännitteitäkö vain?
Wau. Upeeta. Oikeista linkeistäkin olisi apua.
Analogiapuolelta ainoa kohtalaisen tarkka (noin 8-10bit) on akun napajännite ja siitäkin mielenkiintoisin alue n. 10-15V. Mietin jopa kahta tai kolmea aseteltavaa komparaattoria 11,0/13,8/14,2 V jotka olis kytketty digitaalituloihin, mutta karkee tarkkuus riittää valvontaan ja päätöksen tekoon siitä mikä laturi pistetään päälle ja mitä kuormaa tiputetaan alas.
Toki mukavaa olisi mitata paneelijännitettä, joka on noin 0-64V, mutta sillä on enempi loggausarvo ja "nice to know" kun mitään muuta.
Toinen "nice to know" olisi virranmittaus "systeemin" ja akun negatiivisen navan välissä, jotain +/- 5A tms. Shuntti vai hal?
Digitaalitulot varmaan kannattaa ottaa optolla, ne kaikki on 5 tai nimellisesti 12 v. Näillä ei ole nopeusvaatimusta, mutta joku RC-suodatus olisi kiva järjestää, ettei joku satunnainen häiriö aiheuta vääriä johtopäätöksiä.
Käyttöjänniteen jakelussa arvon releiden ja high-side switchien välillä. Rele olisi "selvä peli", mutta onhan feteissäkin puolensa.
Ajattelin käyttää ihan vanhanaikaisa sulakkeita johtosuojana, Joissakin high side switcheissähän on virranvalvontaa yms. Ehkä ei kannata harjoitella liikaa kerralla.
Tällä ei ole kiirettä ja oikeestaan tuo analogiasignaalin puskurointi ja DI/DO puskuri logiikkasignaaleille prossun jännitetasolla on se mikä tulee ensiksi vastaan, enkä haluaisi mällätä.
PekkaNF
http://openenergymonitor.org/emon/node/2109
Tuolle piirille ACS785 on aika paljon matskua netissä .
Tuossa yksi linkki mitä hyödynsin sain jopa toimimaan jotenkin.
Jännite oli trimmattu vastusjaolla sopivaksi sitten käräytin tuulimyllyssä koko hommelin.
Jännitteen mittauksen kanssa jäi ongelma, se pitää saada myös galvaanisesti erotettua. koska jännite saattaa
nousta 600V dc ja myös poweri jännitteet meni piikien muodossa sekaisin.Turvallisuudesta puhumattakaan.
Sellaisen piirin kuin il300 ajattelin iskeä tuohon oli joku toinenkin ,mutta taidot loppui kesken toteuttaa.
Jos oikein ymmärsin pulma oli tämän suuntainen.
Seurataan mielenkiinnolla :D
Lainaus käyttäjältä: PekkaNF - 24.01.14 - klo:10:54
Wau. Upeeta. Oikeista linkeistäkin olisi apua.
Katsotaan saadaanko linkkejäkin lueteltua, mutta tässä nyt lisäkommentteja aluksi alkuperäisen tekstin väleihin
Lainaa
Analogiapuolelta ainoa kohtalaisen tarkka (noin 8-10bit) on akun napajännite ja siitäkin mielenkiintoisin alue n. 10-15V. Mietin jopa kahta tai kolmea aseteltavaa komparaattoria 11,0/13,8/14,2 V jotka olis kytketty digitaalituloihin, mutta karkee tarkkuus riittää valvontaan ja päätöksen tekoon siitä mikä laturi pistetään päälle ja mitä kuormaa tiputetaan alas.
Toki mukavaa olisi mitata paneelijännitettä, joka on noin 0-64V, mutta sillä on enempi loggausarvo ja "nice to know" kun mitään muuta.
Akkujen jännitteitä voidaan mitata suoraankin, komparaattorit on varmaan helpompi tehdä softaan kuin rautaan. Jollei tarvita galvaanista erotusta ja kaikkien mitattavien signaalien maataso on yhteinen, selvitään yksinkertaisella jännitejaolla. Akkujännitettä mitatessa voi vastusjaon laittaa mieleisekseen, esim A/D-muuntimen täysi arvo 20,48V jännittellä tuottaa tarkkuuden 20,48/1024 =20 mV / bit mikä riittänee hyvin. Varaudu kuitenkin siihen, että softassa täytyy käyttää ja tallentaa kestomuistiin korjauskertoimia. Vähintään niin, että lasket jännitteen kaavalla
U = ax + b missä
U = jännitteen mitta-arvo softassa
x = A/D-muuntimelta mitattu lukema
a = jännitteen kulmakerroin (V/bit)
b = offset jolla asetetaan lukeman nollakohta paikalleen.
Kehittyneempi ja vielä inhimillinen laskettava on toisen asteen sovitus jossa
U = ax^2 + bx + c saman systeemin mukaan. Mutta ehkä sitä ei tässä tarvita kun piirissä ei ole lähtökohtaisesti epälineaarisia elementtejä ja A/D-muuntimen perusvirheet tulee säädyllisesti kompensoitua jo tuolla lineaarisellakin korjauksella. A/D-muuntimen differentiaalinen epälineaarisuus ja kvantisointivirheet jää tällä tavalla hoitamatta, mutta menee jo vähän haasteellisemmaksi niin unohdetaan toistaiseksi..
Tiesithän, että Arduinon moottorissa, eli ATMega328-prosessorissa on lämpötila-anturi kiinteänä osana A/D-muunninsysteemiä. Haluttaessa/tarvittaessa sitä voi käyttää mikäli tarvitsee säätää akkujen maksimi latausjännitteitä. Lyijyakkujen latausjännitehän nousee kun lämpötila laskee. Tiedä sitten onko tuolla merkitystä aurinkopaneeleiden yhteydessä.
Joka tapauksessa suositeltavaa iltalukemista jolla moni asia Arduinosta selviää: http://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet.pdf (http://www.atmel.com/Images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet.pdf)
Perus-Arduinossa voi valita A/D-muuntimen referenssijännitteeksi joko DEFAULT ( 5V tai 3,3V riipp. kortin käyttöjännitteestä), INTERNAL (sis. 1,1 V bandgap) tai EXTERNAL (ulkoa syötetty referenssi 0-5V). Sisäinen bandgap on näistä tarkin eikä vaihdu syöttöjännitteen mukaan. Sille sopiva vastusjako 20,48 -> 1,1 V olisi esim. R1 = 15,00 kohm, R2 = 852 ohm millä saadaan 1,100742 V. Tuon 852 ohmin saa aikaan kolmella E12-sarjan standardivastuksella tarkasti; esim 22+150+680 tai 22+270+560 tai 10+22+820.
Kuvassa VSense.PNG on simppeli vastusjako ja ensimmäisen asteen passiivinen suoto. Elektrolyyttikonkilla saa suodon kulmataajuuden helposti hyvinkin alas, mutta silloin pitää myös huomioida, että elkot vuotaa. Jonkun luokkaa 100 uF olevan elkon vuotovirta saattaa olla kymmeniä mikroampeereja ja 15 k ylävastuksen yli sellainen virta aiheuttaa jo satojen millivolttien jännitehäviön. Joten jos suodatat isoilla elkoilla niin mittauksen joutuu ehdottomasti kalibroimaan ja ehkä toistamaankin kun elkot vanhenee. Riippuu nyt tietty siitä kuinka tarkkaan mittaukseen oikeasti pyritään. Tuolla nyt ainakin yksi vapaasti jaeltu paperi aiheesta: http://www.tadiranbatteries.de/pdf/applications/leakage-current-properties-of-modern-electrolytic-capacitors.pdf (http://www.tadiranbatteries.de/pdf/applications/leakage-current-properties-of-modern-electrolytic-capacitors.pdf)
Lainaa
Toinen "nice to know" olisi virranmittaus "systeemin" ja akun negatiivisen navan välissä, jotain +/- 5A tms. Shuntti vai hal?
Shuntti. Minä tekisin tuon pienellä muutaman milliohmin Kelvin-kytketyllä sense-vastuksella ja mittavahvistimella. Eipä tule sen arvokkaammaksi kuin tarkkuudeltaan vähän sinnepäin hal-anturikaan. Laitoin tuosta piiriesimerkin (kuva ISense.PNG). Ohmiten mittavastuksista datalehteä löytyy täältä: http://www.ohmite.com/cat/res_fc4l.pdf (http://www.ohmite.com/cat/res_fc4l.pdf). Mittavahvistin on TI:n tekele: http://www.ti.com/lit/ds/symlink/ina199a1.pdf (http://www.ti.com/lit/ds/symlink/ina199a1.pdf).
Lainaa
Digitaalitulot varmaan kannattaa ottaa optolla, ne kaikki on 5 tai nimellisesti 12 v. Näillä ei ole nopeusvaatimusta, mutta joku RC-suodatus olisi kiva järjestää, ettei joku satunnainen häiriö aiheuta vääriä johtopäätöksiä.
Opton tarve riippuu siitä onko systeemin maatasot eri potentiaalissa vai ei. Ja tietysti vähän siitäkin halutaanko kiertovirtoja välttää vai eikö sillä ole väliä. Voin toki piirtää optotulon, nehän on yksinkertaisia. Mutta niistä ei saa paljoa iloa ellei opton tulopuoli ole syötetty erillisestä lähteestä, koska muussa tapauksessa syöttöjännite on joka tapauksessa galvaanisesti yhdistetty.
Esimerkkejä suojatuista ei-optisesti erotetuista tuloista kuvassa DIO.PNG. Tulosignaalit on passattu vähintään 0 - 5V tasoille, mutta kestävät kyllä paljon enemmänkin - ei noiden pitäisi tykätä kyttyrää vaikka työntäisit verkkojännitettä sisään, mutta älä nyt sentään koeta sitä. Avaan vähän tuota piiriä niin sen idea ehkä siitä hahmottuu:
-prosessori on erotettu ulkomaailmasta kokonaan siten, että sen inputteja ohjaa CMOS hex Schmitt trigger 40106. Tämä piiri myös torppaa värähtelyjä jos inputin taso vaihtuu hitaasti. Huomaa, että nuo on invertoivia joten signaalin suunta kääntyy triggerin yli mennessä.
-Schmitt-triggerin ja tuloliittimen välissä on ensinnäkin resistiivinen suojaus vastuksilla. Kymppikiloiset input-vastukset on syytä olla palamattomia läpireiän komponentteja jotta saadaan riittävä ryömintäväli jos inputtiin sattuu tosiaan osumaan vaikkapa se verkkojännite tai vielä pahempaa. Niin ei synny flashoveria niin helposti.
-Tulovastusten väliin on kytketty SP721 triple ESD-suojadiodipaketti. Tämä leikkaa pois kaikki tasot 0 > Uin > Vcc. Piikkijännitteet on pyritty maadoittamaan eikä ohjaamaan jännitteensyöttöön joka ei myöskään ehkä niin kovasti piikeistä tykkää. Sitä varten SP721 ei ole kytketty suoraan syöttöön vaan erillisen suojauspiirin kautta. +5V syötöstä otetaan ensin veto suurtaajuusferriittisuotimen läpi rajoitusvastukselle joka syöttää 4,3V zenerdiodia 1N4731. Zener kääntyy tällöin johtavaksi ja siihen on syynsä. Tarkoitus nimittäin on, että tuo zener maadoittaa kaikki häiriöpiikit suojamaahan, joka on kytketty sen anodille. Kuitenkin kun zener on johtamattomassa tilassa sillä on selkeä viive johtavuustilaan siirtymisessä. Tänä aikana zenerin impedanssi on suuri ja piikit etenevät signaalilinjoissa koko turn-on viiveen ajan. Sen sijaan kun zener jo johtaa ei viivettä ole vasan se nappaa piikit viiveettä. Nappaamista avustamassa on pieni 100 nF keraaminen konkka.
Laitoin kuvaan muutamia mahdollisia kytkimiä joilla inputteja voi ohjata. Ylimmät kolme on ajateltu aktiivisille lähteille jotka siis ohjaavat signaalia sekä ylös että alas. Alemmissa kolmessa on vetovastukset jolloin niitä voi ohjata yksinkertaisilla mekaanisilla tai trankkukytkimillä.
Vaihtoehtona kuvassa Optoin.PNG on yksinkertainen optoerotettu tulo. Siinä nyt ei ihmeitä ole, mutta pari huomiota:
-jos laitteen omaa +5V (tms) apujännitettä käytetään syöttämään kytkimiä, ei optoista ole hirveästi iloa. Voi ne siellä olla, mutta häiriöt saattaa uida sisään jännitesyötöistä. Kuvasssa ei ole esitetty +5V syötön suojausta. Ainakin pitää huolehtia jotenkin ettei oikari polta koko vehjettä. Joko siis sulake (mikä vinkkinä kuvassa) tai opton sarjavastus siirrettävä syöttöjohtoon. Miten kannattaa tehdä, riippuu kovasti siitä millaisella kytkimellä optoa ohjataan. Kuvan piirissä opton diodi ei ainakaan mene ylivirralle vaikka siihen kytkettäisi jännite (+5V) suoraan.
-Signaalin suodatus on tehty vasta opton jälkeen missä impedanssitasoja voidaan nostaa "järkeviksi". Esitetyillä komponenttiarvoilla aikavakioksi tulee noin 10ms ja siis rajataajuudeksi siinä 16 Hz. Konkaa kasvattamalla rajataajuus alenee lineaarisesti suhteessa.
Lainaa
Käyttöjänniteen jakelussa arvon releiden ja high-side switchien välillä. Rele olisi "selvä peli", mutta onhan feteissäkin puolensa.
Releillä vaan. Ne on idioottivarmoja, galvaanisesti erottavia ja oikein käytettynä vähintään yhtä luotettavia kuin fetit. Fetin lähes ainoa etu on kyky suurtaajuiseen toimintaan jatkuvasti, ja tietty osin se, ettei hilan ohjaaminen vaadi tehoa. Mikä nyt ei yleensä releelläkään ole mikään ongelma.
Lainaa
Ajattelin käyttää ihan vanhanaikaisa sulakkeita johtosuojana, Joissakin high side switcheissähän on virranvalvontaa yms. Ehkä ei kannata harjoitella liikaa kerralla.
Sulake on oikein hyvä. Se ainakin toimii silloin kun pitää ja on helppo ymmärtää. Kaikenmaailman polyfuset ja muut viritykset voi olla hirmu käteviä joissain erikoistapauksissa mutta perussulakkeen paikkaan kannattaa laittaa perussulake.
Lainaa
Tällä ei ole kiirettä ja oikeestaan tuo analogiasignaalin puskurointi ja DI/DO puskuri logiikkasignaaleille prossun jännitetasolla on se mikä tulee ensiksi vastaan, enkä haluaisi mällätä.
Näillä päästänee alkuun; jatketaan keskustelua epäselvistä kohdista tai jos ratkaisu ei vastaa tarvetta jossain kohdissa.
Jos oikeasti kiinnostaa niin voin kyllä vääntää piirikaavion myös tuolle Hannun esittämälle lineaarioptoerotukselle. Sillä saa edullisia ja kohtuuhyviä ratkaisuja aikaan.
Jos teillä on DipTrace käytössä niin kuvat löytyy sillä tehtyinä ja voin niitä vähän siistiäkin vielä.
Kiitos paljon. Mun pitää tutkia noita ajatuksella ja piirrellä tota omaa doodlausta (ei voi nimittää schemaksi), jotta saan selville mitä pitää labrata.
Pitää kirjoitella aurinkolaturin valmistajalle ja kysellä saako sen laturin kytkettyä väylän kautta irti ja saako siitä viestiä ulos mitä se on mittaamassa ja duunamassa.
Akun lämpötila tosiaan pitää mitata ja latureissa on aina sisäiset mittaukset (jollei ole kytketty ulkoista mittausta).
Optot ja galvaaninen kärväyttämien oli tuttua kun tein veilä hommia Siemens S5:n kanssa ja niihin oli kytketty milloin mitäkin. Muutamaan tuhanteen I/O:n mahtui välillä jokunen yllärikin. Sitä luulis oppineen, silti ei ole pitkä aika kun epähuomiossa yhdistin hakkurin välipiirin postitivisen maadoitettun mittaukseen. Zzappp.
Kiitos paljon. Mun pitää tukisa noita, voi mennä vähän aikaa.
PekkaNF
Joo ihan rauhassa vaan. Mullahan ei ole mitään aikataulua tässä, että ihan miten itsestä tuntuu ja homma etenee.
Lainaus käyttäjältä: Kremmen - 25.01.14 - klo:13:17
Jos oikeasti kiinnostaa niin voin kyllä vääntää piirikaavion myös tuolle Hannun esittämälle lineaarioptoerotukselle. Sillä saa edullisia ja kohtuuhyviä ratkaisuja aikaan.
Kiinnostaa kovinkin ,tämä on jo sellainen oppitunti että menee aikansa ennen kuin kaiken ymmärtää.
Tuo zenerin esivirittäminen mm. aikamielenkiintoinen.
Tämä mun mitattava jännite on tosiaan maksimissaan n.600V DC ja toinen tapaus tämä pätkittynä
pwm taajuudella joka on muutama Khz ehkä.
Näin mittaukselle tulee jonkin asteinen nopeus vaatimus.Prossu laskisi tästä tehollisarvon.
Joo kiinnostaa noi Hannunkin viritykset.
Tutkiskelin noita hieman, tosin atmellin iltalukeminen on vielä vähän kesken ;D
DIO on vähän mun silmien/monitorin/bittiresoluution rajoilla, mutta kun ymmärsin ton resoluution, niin alkoi selvitä. Periaateessa tiesin ton virtalähteen erotuksen, mutta tosiaan tuo zener oli hauska, ei tullut ainakaan opiskeluaikaan vastaan, ehkä ohimennen jollekkin aturille sarjavastus ja hakkureista puhunut ope taisi mainita ferriittihelmen. Mutta tuo on hauska nähä piirikaaviona ja selostettuna.
Säikäytti hieman tuo pintaliitosshuntti. Mä olen onnistuntu välttämään pintaliitoskamat toistaiseksi ;D
Hyvä nähdä kaavioita, joista ei tarvii ruveta arvaamaan ensiksi, että mitä pielessä.
Teki melkein mieli ladata diptrace, mutta se viivästyttäisi vielä enemmän prjektin alouitusta. Tilasin arduinnon oikean unon ja pari proto piirilevyä.
No nyt autotalliin sorvaamaan valurautaa hieman ja sitten pesemään naama.
T: PekkaNF
No niin, tässä yksinkertainen kohtuullisen tarkkuuden omaava kaksois-lineaarioptovahvistin. Tämä kytkentä vaatii kaksipäisen syötön ja input on nollasta ylöspäin, eli siis unipolaari. Palataan lopussa siihen miten noita juttuja voi säätää tarvittaessa.
Piirin vasen puoli on mitattavan kohteen potentiaalissa, ja oikea puoli "turvallisessa" potentiaalissa. Huomaa, että kummankin puolen käyttöjännitteet ja maataso on myös oltava galvaanisesti eri piirejä, muuten mitään erotusta ei tapahdu. Seuraava selostus liittyy piirikaavioon "Optoerotusvahvistin.pdf".
Vasemmanpuoleinen mittausvahvistin (U501):
Vahvistin on kytketty aivan normaaliin invertoivaan kytkentään, jolloin siihen pätee normaalit invertoivan vahvistimen laskusäännöt. Kertauksena muutama juttu operaatiovahvistimista yleisesti ja invertoivasta vahvistimesta peruskytkennässä erikseen:
1. vahvistin vahvistaa + ja - inputtien välistä jännite-eroa (ideaali = ääretön vahvistus). Jos + inputi on positiivisempi kuin -, vahvistimen lähtö ohjautuu positiivisen jännitteen suuntaan
2. inputtien kautta ei kulje lainkaan virtaa
3. invertoivassa eli kääntävässä vahvistimessa + inputti maadoitetaan. Tulosignaali ohjataan - inputille vastuksen kautta, ja samoin outputti vastuksen kautta - inputtiin.
4. Kun tulosignaalin jännite nyt nousee se pyrkii nostamaan - inputin jännitettä, jolloin vahvistimen lähtö alkaa ajautua negatiiviseen jännitteeseen päin (koska + inputti on maadoitettu eli 0V niin - input on nyt positiivisempi).
5. Koska tulosignaali ja vahvistimen lähtö on kumpikin kytketty vastuksen kautta samaan pisteeseen (- inpputti) ne muodostavat ikäänkuin jännitejaon, jossa - inputin jännite määräytyy tuon jaon perusteella.
Kirchoffin virtalain perusteella tiedetään, että piirin solmuun saapuvien ja sieltä poistuvien virtojan summa on 0. Kun inputit eivät ota virtaa niin koko se virta joka syntyy tulojännitteestä tulovastuksen läpi, on mentävä vahvistimen outputtiin takaisinkytkentävastuksen kautta. Eli tällöin pätee
Uin/Rin + Uout/Rfb = 0 (1) ja tästä edelleen
Uin/Rin = -Uout/Rfb (2) uudelleenjärjestelemällä tekijät saadaan
Uout/Uin = -Rfb/Rin (3) eli kytkennän vahvistus on vastuksien suhde suoraan, ja etumerkki kääntäen.
Nyt optovahvistimesta ei kuitenkaan näytä löytyvän kuin tulovastus R504. Ja onkin totta, ettei suoraan yhtä Rfb:tä vastaavaa vastuskomponenttia. Kuitenkin meillä on takaisinkytkentä transistorin Q501, opton ledin Q502.1 ja opton fotodiodin Q502.2 kautta. Ideahan on tasapainottaa vahvistimen - inbputtiin tulevat ja sieltä lähtevät virrat. Ja se tapahtuu tässä piirissä näin:
Tulojännite liittimien J502-J503 välillä synnyttää tulovirran vastuksen R504 läpi (koska vahvistimen - inputti on virtuaalimaa eli pyrkii pitämään saman nollatason kuin + inputtikin).
Vahvistimen lähtö alkaa ohjautua negatiiviseen suuntaan jolloin PNP-transistori Q501 alkaa johtamaan ja opton ledissä Q502.1 alkaa kulkea virta.
Ledin virta synnyttää opton fotodiodeissa fotovirran ja nyt fotodiodi Q502.2 on kytketty - inputin ja maan välille niin, että siinä syntyvä virta alka vetää R504:n läpi kulkevaa tulovirtaa maihin. Kun vahvistimen lähtö on ohjannut optolle tarpeeksi virtaa niin, että fotovirta juuri vastaa tulovirtaa on systeemi tasapainossa ja saavuttaa jatkuvuustilan kunnes tulojännite muuttuu ja homma toistuu.
Vahvistimella näkyy suora takaisinkytkentä pienellä konkalla C503. Yhdessä tulovastuksen R504 kanssa se muodostaa vahvistimen siirtovasteeseen navan jolla estetään taipumus suurtaajuiseen värähtelyyn. Pitkä takaisinkytkentäketju aiheuttaa nimittäin vaihesiirtoa ja voi vaarantaa stabiilisuuden jos vahvistus säilyy suurilla taajuuksilla korkeana.
Kaiken edellisen sepustuksen jälkeen siis toiminta on äärettömän simppeli: vahvistinkytkentä pyrkii tekemään tulovirrasta Uin/R504 ja diodin Q502.2 fotovirrasta identtiset. Seuraava kysymys, että minkä suuruinen tuon virran nyt sitten pitäisi olla? Lasketaan taas vähän:
Kaksoisoptoille määritellään kolme K-arvoa seuraavasti:
K1: Servo current gain, eli "servosilmukan" virtavahvistus. Tämä on juuri se silmukka joka edellä kyhättiin. Laskennallisesti siis
K1 = Ip1/If missä
Ip1 on fotodiodin 1 virta
If on opton ledin virta
K2 on myötävahvistus eli sama kuin edellinen, mutta kohdistuen fotodiodiin 2 (toisiopuolen diodi)
K2 = Ip2/If
K3 on ns. siirtovahvistus (transfer gain) eli myötä- ja servovahvistuksien suhde
K3 = K2/K1 ideaalitapauksessa K3 = 1,0 jolloin molemmat diodit generoivat täsmälleen saman fotovirran, mutta käytännön komponenteissa on aina toleranssia.
Mitoitetaan piiri yleisesti käytetyn ja kohtuuedullisen komponentin HCNR200 mukaan. Perusteet kelpaa kaikille muillekin kunhan K-kertoimet ja maksimiarvot otetaan käytetystä komposta. Tälle lukuarvot ovat:
Ledivirta (abs. max): 25 mA
K1: min 0,25, typ 0,5, max 0,75
K3: min 0,85, typ 1,0, max 1,15
Tähdätään nimellistulojännitteellä vaikkapa 1 mA tulovirtaan. Se on riittävän pieni ollakseen aiheuttamatta mainittavia tehohäviöitä mutta tarpeeksi iso jotta ei ole kovin häiriöherkkä. Tällöin siis fotodiodin 1 fotovirta olisi tuon suuruinen ja siitä kertoimella K1 laskettuna ledin virta, variaation huomioiden 1/0,25 ... 1/0,75 mA eli 4 ... 1,33 mA. Tämä on ainakin turvallisen kaukana sallitusta maksimivirrasta.
Tästä saadaan siis tulovastuksen R504 mitoitus suoraan:
R504 = Uin_max/1mA eli helppo muistisääntö: Niin monta kilo-ohmia kuin voltteja. 10V = 10 kohm jne.
Toinen vastusarvo joka voidaan kiinnittää on opton ledinohjauksen sarjavastus R502. Se viime kädessä rajoittaa ledin läpi kulkevaa virtaa ja toimii samalla audiomiehille tuttuna trankun Q501 emitterin degenerointivastuksena. Tästä on seurauksena, että mitä suurempi R502, sitä enemmän operatiovahvistimen lähdön pitää muuttua jotta haluttu virran muutos saadaan aikaan. Pidetään vastuksen arvo kohtuullisena niin vahvistimen lähdön swingi pysyy maltillisena eikä nousunopeusraja tule niin nopeasti vastaan. Näillä jännitteillä voisi kokeilla jotain 220 - 330 ohmia.
R501 toimii trankun Q501 emitterin ylösvetovastuksena eli osaltaan varmistaa että trankku menee myös kiinni. Arvo ei ole mitenkään kriittinen, pari kiloa tai sinnepäin on ok.
Vahvistin ohjaa trankun kantaa vastuksen R503 kautta. Sopiva arvo riippuu transistorin virtavahvistuksesta joka 2N3906:lle on siinä luokkaa 100. Ledivirtaa tarvittiin enimmillään 4 mA ja siitä sadasosa tarkoittaisi 40 uA kantavirtaa. Kerrotaan tuo nyt vaikka kymmenellä varmuudeksi ja katsotaan mikä olisi resistanssi jos vastuksen yli jäisi esim 5 V. Eli 5V / 400 uA = 12,5 kohm. Laitetaan kymppikiloinen vastus R503.
R506 on varmistamassa että mahdolliset vuotovirrat ei käännä lediä päälle tahattomasti. Arvo voi olla muutama kymmenen kiloa,
Oikeanpuoleinen erotusvahvistin U502):
Nyt kun vasen puoli on hanskassa, on oikea puoli lähes triviaali. Käytetylle optolle K3-arvo on 1,0, joten molemmat fotodiodit käyttäytyvät identtisesti. Näin ollen kun päätettiin, että mittavahvistimen puolella on nimellistulojännitettä vastaava fotovirta 1 mA niin se on sama tälläkin puolella diodissa 2. Takaisinkytkentävastuksen R505 läpi pitää siis kulkea tuo samainen fotovirta 1 mA ja näin vastuksen yli jäävä jännitehäviö on suoraan toisiopuolen lähtöjännite (koska vahvistimen - inputti on kiinnitetty virtuaalimaahan). Täälläkin taas pieni konkka taittamassa vahvistimen suurtaajuusvahvistusta ettei ala pärähtelemään.
Siinäpä se pähkinänkuoressa. Kunhan pidetään mitoituksella huoli, ettei opton ledivirta mene tolkuttomaksi, niin tässä meillä on simppeli ei-kääntävä erotusvahvistin jonka jännitevahvistus on yksinkertaisesti G = R505/R504.
Sanoinko jo, että molempien puolien jännitteet ja maat on pidettävä galvaanisesti erillään. Tämä tarve mutksitaa käytännön ratkaisuja huomattavasti, kun sama jännitelähde ei noin vain käy molemmille puolille. Paljon käytetty ratkaisu on virittää pieni muuntajaerotettu hakkuri tekemään jännitteet - tyypillisesti pieni flyback-kytkentä. Silloin syöttö voi olla galvaanisesti erossa kummastakin puolesta kun on muuntajan käämit välissä.
---
Epilogi: Hälvennetään samantien mahdollisesti syntyvä hämmennys joka voi seurata, ellei tiedosta miten tuo opto toimii "oikeasti". Piirikaaviota katsellessa ja mikäli muistelee kääntävän vahvistimen lauseketta jossa vastusten suhde määrää vahvistuksen, voi herätä kysymys, miten tuo fotodiodi voi toimia kun se on kytketty - inputin ja maan väliin. Jos sitä ajattelee muuttuvana vastuksena vähän samaan tapaan kuin fototransistoria tavallisessa optossa niin eihän tuo piiri voi toimia. Kun siellä vastuksen toisessa päässä pitäisi olla muuttuva jännite jotta - inputti saataisi pysymään nollajännitteessä.
Vaan tässä optossapa onkin fotodiodit ja ne on hienostuneita kvanttimekaanisia laitoksia. Saihan Einstein vuoden -22 Nobelin palkinnonkin tuon efektin selittämisestä. Kun fotoni osuu fotodiodn puolijohdeliitokseen se irroittaa sen kiderakenteesta elektroni/aukkoparin. Nuo yhdessä eivät ole mitään muuta kuin sähkövirtaa ja niinpä fotodiodi toimii valo-ohjattuna virtageneraattorina. Päinvastoin kuin luulisi, virta kulkee katodilta anodille koska virran muodostaa käänteinen rekombinaatio bipolaarisessa puolijohteessa. Mutta se nyt ei ole tärkeää, vaan se, että komponentti generoi valosta oman virtansa eikä tarvitse mitään apujännitettä jota ohjailla.
Huh ,hyvät sydämen tykytykset sain innosta kuin selasin tuon äkkiä läpi,Kiitos.
opton pdf sentään löytyi koneelta ,mitähän siittä on joskus meinattu tehdä :D.
Ei muuta kun miettimään tuota tekstiä ajatuksen kanssa ja postia Mouserille.
Tosiaan tässä kyllä vierähtää tovi.
Lainaus käyttäjältä: PekkaNF - 26.01.14 - klo:13:30
Joo kiinnostaa noi Hannunkin viritykset.
Tutkiskelin noita hieman, tosin atmellin iltalukeminen on vielä vähän kesken ;D
DIO on vähän mun silmien/monitorin/bittiresoluution rajoilla, mutta kun ymmärsin ton resoluution, niin alkoi selvitä. Periaateessa tiesin ton virtalähteen erotuksen, mutta tosiaan tuo zener oli hauska, ei tullut ainakaan opiskeluaikaan vastaan, ehkä ohimennen jollekkin aturille sarjavastus ja hakkureista puhunut ope taisi mainita ferriittihelmen. Mutta tuo on hauska nähä piirikaaviona ja selostettuna.
Säikäytti hieman tuo pintaliitosshuntti. Mä olen onnistuntu välttämään pintaliitoskamat toistaiseksi ;D
Hyvä nähdä kaavioita, joista ei tarvii ruveta arvaamaan ensiksi, että mitä pielessä.
Teki melkein mieli ladata diptrace, mutta se viivästyttäisi vielä enemmän prjektin alouitusta. Tilasin arduinnon oikean unon ja pari proto piirilevyä.
No nyt autotalliin sorvaamaan valurautaa hieman ja sitten pesemään naama.
T: PekkaNF
Piti laittamani ne piirikaviot pdf-muodossakin mutta se jäi sitten. Ei se mitään, laitn ne vielä tulemaan niin ei tarvitse tihrustella.
Alkaa olemaan läpireiän juottajilla ankeat ajat kun yhä enemmän on tavaraa jota saa vain pintaliitoksena. Se shuntti on vielä helppo, sehän on iso kuin voileipäkeksi mutta se mittavahvistin on sot23-6 paketissa ja se on jo aika pieni ja ikävä kolvata vanhan liiton maksi-wellerillä...
Noiden digitaalitulojen toiminnan uskallan tosiaan luvata, samat piirithän on käytössä siinä taannoisessa kierroslukumittarissa eikä ole kuulunut että olisi huolia ollut.
Tuo viimeisin erottava optovahvistin on ihan paperiharjoitus, sitä pitää labrata ennenkuin uskaltaa julistaa toimivaksi. Mutta enempi varmaan on kiinni layoutin yksityiskohdista kuin varsinaisesta piirikaaviosta.
Sitten tämmöinen kommentti tuohon sinun Diptrace-huomioosi: sen lataaminen ja opiskelu saattaa kyllä hidastaa projektin aloitusta mutta toisaalta se saattaa vauhdittaa projektin loppuunsaattamista. Jos nimittäin meinaat oikeasti tehdä lisäkortin Arduinolle niin jotain työkalua kannattaisi kyllä käyttää. Vaikka olisikin protokortti niin piirin mallaus kortille käy kyllä ihan eri lailla kun on oikean piirilevytyökalun tuki takana. Eikä se kynnys nyt niin iso ole; pitävät Diptracea aika helpponakin oppia - ainakin perusjuttuja. Ja apujahan saa.
Laitan nitä pdf:iä kohtapuoliin.
Kiitos kiitos kiitos, noi pitää printata ja miettiä ihan paperin ja ajatuksen kanssa. Pari ajtustakin vähän jäänyt vireeseen, mutta mietitään.
PekkaNF
Tässäpä nuo kuvat pdf-muodossa, sekä kaikki vielä yhdessä Diptrace-tiedostossa.
Laitoin tuon zippinä mutta txt-päätteellä koskapa zip ei ole hyväksytty formaatti. Viruksia tuossa ei ole joten ainoa mitä paketista löytyy on Diptracen "Arduino IO.dch" piirikavio.
OK. Pari päivää olen puljannut Arduino UNO R3:n kanssa ja harjoiteltu hommia tämän listan mukaan ylhäältä alas ja vasemmalta oikeelle:
http://arduino.cc/en/Tutorial/HomePage
Samalla olen lukenut ton C:n mallisen kielen syntaksia:
http://arduino.cc/en/Reference/HomePage
Tämän luin:
http://arduino.cc/en/Reference/StyleGuide
Ok, jos kirjoitetaan selosta ja tehdään ohjelmaa teknologisesti rajoittuneelle, niin varmaan ok, mutta minua alkoi ahdistaa.
Olisko suositella jotain tämän palstan ihmisten luonteeseen sopivaa opasta C:n opiskeluun (edellisen kerran opiskelin -88 ja silloin käytettiin pointtereita ja aivan saatanasti includattiin kirjastoja?
Tilasin pari kirjaa:
1) Getting Started with Arduino, 2nd Edition
http://shop.oreilly.com/product/0636920021414.do?green=1F313C24-404C-586A-ACAD-9471D450CFD5&intcmp=af-mybuy-0636920021414.IP
Otin sekä kovana, että PDF:nä. Mutta tämä kirja oli vähän vikatikki. Näyttää paljolti päällekäiseltä virallisten sivujen kanssa.
2) Arduino Cookbook, 2nd Edition
Recipes to Begin, Expand, and Enhance Your Projects
http://shop.oreilly.com/product/0636920022244.do?intcmp=il-na-books-videos-product-intsrch_arduino_ct
Tämä on jo koneella PDF:nä, mutten ole vielä aloittanut.
Itseasiassa kun nyt kerran pitää opiskella, niin vois tehdä sen oikein. Joten olen käynyt noita esimerkkejä läpi ajatuksella ja modannut niitä kutakin pariin otteeseen. Olen käyttänyt leipälevyä ja jumppereita ja kolvannut joitakin juttuja jo pikaistuksissani kokoon (lähinnä antureita piuhoihin yms.)
Yksi asia joka on tullut mieleet, että pisäis hankkia joku ESD alusta jonka päällä vois tehdä noita koekytkentöjä. Mieluiten eri matto, kun mitä käytetään rakentamiseen....ei ole kauan aikaa kun käräytin yhden pikkuhakkurin, kun oli alustalle unohtunut sivarilla katkaisuja lankoja. Olisko jotain ei ihan überkallista vaihtoehtoo.
Kattelin tota:
http://www.yeint.fi/index.php?main=64&productCat=2677&productID=15520&productCode=ITE+7804.874&brand=ITECO&mainProductGroup=ESD+SUOJAUS&subProductGroup=MAADOITUSRASIA
ja
http://www.yeint.fi/index.php?main=64&productCat=2673&productID=17966
*********
sitten yksi asia minua on kovasti askarruttanut: Mitenkä näissä sulautetuissa rakennetaan I/O:n logiikka? Perinteisesti teollisuuden logiikaohjaimissa on merkkereitä (flags) ja muuttujia, joita käsitellään tikapuuna jne. ja sitten syklin lopussa päivitetään prosessikuva, joka vasta vaikuttaa fyysisiin lähtöihin. Eikä inputitkaan muutu matkan varrella.
Arduinnossa taas saa I/O:ta ihan rauhassa rukata pitkin sykliä ja ilmeisesti se vaikuttaa fyysiseen lähtöön sen samantien? Eli jos haluaa rakentaa tilalogiikan, niin pitääkö ensin tehdä nippu muuttujia, joihin luetaan I/O, sitten käsitellään lukitukset ja lopuksi kirjoitetaan nämä outputteihin, vai onko tässä joku fiksumpikin menetelmä?
PekkaNF
Kremmeni tähän varmasti vastailee myöskin mutta kerron nyt oman mielipiteen näistä Arduinoista. Aivan ensimmäiseksi unoha koko Arduino, se on vain sen alustan nimi ja ilmeisesti tarkoitettu että sillä saisi jotain näennäisen toimivaa nopeasti tehtyä.
Etsi mikrokontrollerin datalehti ja ala käymään sitä läpi, sillä pääsee jo aika pitkälle. Porttien toteutus on vissiin se ensimmäinen kohta mihin kannattaa kiinnittää huomiota.
Logiikan voi sitten rakentaa monella eri tapaa kunhan ensin ymmärtää miten portit rakentuu. Itse lähtisin siitä tosiasiasta että portin voi asettaa moneen tilaan, input, output jne. Porteissa on myös ylösvetovastukset hyvin usein aseteltavissa ja portin voi myös laittaa "open collector" tilaan jne. jne.
C ei ole varmastikkaan paljoa siitä muuttunut, C++:ssaa ei liene tarkoituksenmukaista tähän sotkea koska se vaatii jo jonkin verran prossulta pinnan alla.
Lainaus käyttäjältä: PekkaNF - 02.02.14 - klo:15:03
OK. Pari päivää olen puljannut Arduino UNO R3:n kanssa ja harjoiteltu hommia tämän listan mukaan ylhäältä alas ja vasemmalta oikeelle:
http://arduino.cc/en/Tutorial/HomePage
Samalla olen lukenut ton C:n mallisen kielen syntaksia:
http://arduino.cc/en/Reference/HomePage
Tämän luin:
http://arduino.cc/en/Reference/StyleGuide
Ok, jos kirjoitetaan selosta ja tehdään ohjelmaa teknologisesti rajoittuneelle, niin varmaan ok, mutta minua alkoi ahdistaa.
Olisko suositella jotain tämän palstan ihmisten luonteeseen sopivaa opasta C:n opiskeluun (edellisen kerran opiskelin -88 ja silloin käytettiin pointtereita ja aivan ruohosipulisti includattiin kirjastoja?
C ja C++ on kaikille samat, joten varsinaisen kielen opiskelu on yksi asia joka kannattaa mutta eri asia on sitten vielä soveltaa kieltä käytännössä. Matalan tason sulautetuissa systeemeissä kuten Arduinossa ja päinvastoin kuin esim PC:ssä, ei ohjelman ja raudan välissä ole mitään virtualisointi- tai abstraktiokerrosta kuten vaikkapa käyttöjärjestelmää. Tällöin iso osa systeemin suunnittelua ja toteutusta on ohjata sulautettuja oheislaitteita ja GPIO:ta (siis General Purpose I/O, eli yleiskäyttöiset tulot ja lähdöt eli portit) suoraan. Tämän hallitsemiseksi tarvii osata prosessorin sulautetut oheislaitteet, sen porttirakenne sekä käytetyn alustan (tässä siis Arduinon) piirikaavio.
Arduinon mukana tulee sen oma IDE jolla noita "sketchejä" kirjoitetaan. Miksiköhän niitäkään ei ole voinut rehellisesti kutsua ohjelmiksi... No, joka tapauksessa IDE ei käännä mitään, vaan koodin tuottaa taustalla vanha tuttu avr-gcc joka on siis ei mikään muu kuin Atmelin prosessoreille sovitettu GNU C/C++ kääntyri, varmaan maailman eniten käytetty. Arduinolla ei siis ole mitään omaa ohjelmointikieltä, vaan se on puhdas C/C++ sellaisena kuin avr-gcc sen toteuttaa (Arduino Unon "moottorihan" on ATMega328). Kaikki avr-gcc:n ajonaikaisen kirjaston (AVR Libc) funktiot on käytettävissä, ja _ne_on_syytä_oppia_. Löytyy täältä: http://www.nongnu.org/avr-libc/ (http://www.nongnu.org/avr-libc/). Tuolla on vielä joku vähän vanhempi avr-gcc tutoriaali: http://www.8051projects.net/files/public/1242392126_2569_FT22383_avr_tutorial.pdf (http://www.8051projects.net/files/public/1242392126_2569_FT22383_avr_tutorial.pdf).
Ja omana mielipiteenä kannattaisi juuri Arduinon kanssa treenata C++:n käyttöä, koska niin Arduino tekee itsekin. Vaikkei sitä missään mainostetakaan niin Arduinon koodin rakenne on suoraan C++:n mukaista ja valtaosa sen omia ja kolmansien kirjoittamia kirjastoja on itse asiassa C++ -luokkia. C++:n käytöllä saa useita etuja mutta ei joudu maksamaan muuta kuin opettelemisen vaivan. Yleensä C++ -kielen käyttöä väistellään sillä perusteella että se olisi raskasta, mutta se ei kyllä pidä paikkaansa teorian eikä oman kokemuksenkaan perusteella. C++:n periaate on "no penalty" eli jos jotain ominaisuutta ei käytä, se ei tule mukaan lopulliseen koodiin. Tätä nykyä kirjoitan kaikki sovellukset C++:lla jos vaan käytetty ympäristö sitä tukee. Muun muassa taannoin jäsen senaattorin aloitteesta toteuttamani kierroslukumittari on kokonaan C++:lla koodattu.
Eli: opettele kieli ja käännösympäristö, opettele prosessori, ja opettele ajoympäristö eli Arduinon piirikaavio.
Eikä koodia ole mikään pakko kirjoittaa käyttäen Arduinon vakiokirjaston hömppäfunktioita joista suosikki-inhokki on Digitalwrite().
Seuraava koodi toimii Arduinossa mainiosti. Selvitäpä itsellesi mitä se tekee (selvitykseen tarvitaan AVR-Libc:n ja ATMega328-prosessorin I/O:n tunteminen).
#include <avr/io.h>
uint8_t count;
void setup(void) {
PORTB = 0;
DDRB = 0xff;
count = 0;
}
void loop(void) {
PORTB = count++;
}
Lainaa
Tilasin pari kirjaa:
1) Getting Started with Arduino, 2nd Edition
http://shop.oreilly.com/product/0636920021414.do?green=1F313C24-404C-586A-ACAD-9471D450CFD5&intcmp=af-mybuy-0636920021414.IP
Otin sekä kovana, että PDF:nä. Mutta tämä kirja oli vähän vikatikki. Näyttää paljolti päällekäiseltä virallisten sivujen kanssa.
2) Arduino Cookbook, 2nd Edition
Recipes to Begin, Expand, and Enhance Your Projects
http://shop.oreilly.com/product/0636920022244.do?intcmp=il-na-books-videos-product-intsrch_arduino_ct
Tämä on jo koneella PDF:nä, mutten ole vielä aloittanut.
Arduino ei ole juuri muuta kuin ATMEga328, poweri ja USB-liitäntä. Niinpä kaikki sulautettujen järjestelmien oppaat kelpaa soveltaen myös Arduinolle. Itse hakisin mielummin aihepiirin mukaan kuin toteutusalustan. Mutta ei mulla ole oikein antaa linkkejä kun en ole itse moisia kirjoja kaipaillut.
Lainaa
Itseasiassa kun nyt kerran pitää opiskella, niin vois tehdä sen oikein. Joten olen käynyt noita esimerkkejä läpi ajatuksella ja modannut niitä kutakin pariin otteeseen. Olen käyttänyt leipälevyä ja jumppereita ja kolvannut joitakin juttuja jo pikaistuksissani kokoon (lähinnä antureita piuhoihin yms.)
Yksi asia joka on tullut mieleet, että pisäis hankkia joku ESD alusta jonka päällä vois tehdä noita koekytkentöjä. Mieluiten eri matto, kun mitä käytetään rakentamiseen....ei ole kauan aikaa kun käräytin yhden pikkuhakkurin, kun oli alustalle unohtunut sivarilla katkaisuja lankoja. Olisko jotain ei ihan überkallista vaihtoehtoo.
Kattelin tota:
http://www.yeint.fi/index.php?main=64&productCat=2677&productID=15520&productCode=ITE+7804.874&brand=ITECO&mainProductGroup=ESD+SUOJAUS&subProductGroup=MAADOITUSRASIA
ja
http://www.yeint.fi/index.php?main=64&productCat=2673&productID=17966
Itse hommasin aikanaan hyvin samanlaisen plugin, 120x60cm kumimaton, rannelenkin ja pari nepparikierrejohtoa. Maton taisin tilata Partcon kautta, hehän toimittavat olikos se nyt Farnellin ja Elfan kamaa -jommankumman kataloogista muistaakseni löytyi matto kohtuuhintaan. Kumimatto on hyvä, se kestää kuumaa kolvia ja askartelua, ei tarvii varoa.
Lainaa
*********
sitten yksi asia minua on kovasti askarruttanut: Mitenkä näissä sulautetuissa rakennetaan I/O:n logiikka? Perinteisesti teollisuuden logiikaohjaimissa on merkkereitä (flags) ja muuttujia, joita käsitellään tikapuuna jne. ja sitten syklin lopussa päivitetään prosessikuva, joka vasta vaikuttaa fyysisiin lähtöihin. Eikä inputitkaan muutu matkan varrella.
Arduinnossa taas saa I/O:ta ihan rauhassa rukata pitkin sykliä ja ilmeisesti se vaikuttaa fyysiseen lähtöön sen samantien? Eli jos haluaa rakentaa tilalogiikan, niin pitääkö ensin tehdä nippu muuttujia, joihin luetaan I/O, sitten käsitellään lukitukset ja lopuksi kirjoitetaan nämä outputteihin, vai onko tässä joku fiksumpikin menetelmä?
Kyllä toki; mikrokontrollerin I/O-operaatiot suoritetaan välittömästi. Niin ne tehdään logiikassakin, onhan sielläkin prosessori sisällä, mutta logiikan käyttis hoitaa homman sekvensoidusti. Jollain Arduinolla joudut tekemään homman käsin juuri kuten esität, eikä ole periaatteessakaan olemassa sen fiksumpaa tapaa. Noin niitä tehtiin jo kultaisella 80-luvulla kun meikällekin maksettiin palkkaa paperiteollisuuden automaation kyhäilystä prosessoreilla.
Lainaa
PekkaNF
Jos haluat päästä asiassa eteenpäin ja ehkä vähän murtaa Arduino-kalteria niin yksi helppo konsti on asentaa ilmainen Atmel Studio 6.1 ja sille Visual Micron Arduino-plugin. Näin pääset kirjoittamaan Arduino-koodia ihan "oikeassa" kehitysympäristössä joka toimii sitten mille tahansa Atmelin prosessorille, ARMit mukaan luettuna. Siis jos/kun ruokahalu kasvaa. Visual Micron mukana tulee myös alkeellinen Arduino-debuggeri joka on parannus verrattuna siihen, että Arduinossa itsessään ei ole mitään. Plus, että Studio tekee koodaamisen ja koodin hallinnan jumalattoman paljon helpommaksi.
Kiitos paljon.
Mulle ei ole vielä ollut iso ongelma tuo portien konffaus ja I/O:n rajoitusten ymmärtäminen, jotenkin on itsestään selvää, että tuloilla on joku impedanssi ja ylosvetovastus, sekä lähdöt voivat olla kelluvia, sink/source ja mahdottomia niistä ei virtaa saada.
Mutta paholainen makaa yksityiskohdissa. Alkuun pitää päästä nopeesti, muuten loppuu momentti kesken, mutta asiat pitäisi oppia niin hyvin, ettei sitten joku laskuri pyörähdä ympäri jonkun viikon päästä ja ohjelma mene mikämikä-maahan.
Eiköhän se C sieltä palaa pätkittäin ja pitää katsoo minkä verran sitä tarvii opiskella uudestaan.
ESD. Kiitos. Plan B:
http://www.partco.biz/verkkokauppa/index.php?cPath=18_1183
ja jos tulee partcolta jotain tilattua, niin sitten samalla varaosaksi prossu, jossa bootloaderi:
http://www.partco.biz/verkkokauppa/product_info.php?cPath=5&products_id=16250
Mä luen nuo viestit ajatuksella läpi ja palaan vielä asiaan.
KIITOS!
PekkaNF
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
C ja C++ on kaikille samat, joten varsinaisen kielen opiskelu on yksi asia joka kannattaa mutta eri asia on sitten vielä soveltaa kieltä käytännössä. ...
Ja omana mielipiteenä kannattaisi juuri Arduinon kanssa treenata C++:n käyttöä, koska niin Arduino tekee itsekin. ....
Eli: opettele kieli ja käännösympäristö, opettele prosessori, ja opettele ajoympäristö eli Arduinon piirikaavio.
Missäs perkuleessa se Kerningham ja Ritchie nyt luuraskaan? Kiitos uskottavasta mielipiteestä. Ajattelin tässä lukee samalla teoriaa ja käpistellä noita käytännön asioita.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Eikä koodia ole mikään pakko kirjoittaa käyttäen Arduinon vakiokirjaston hömppäfunktioita joista suosikki-inhokki on Digitalwrite().
Seuraava koodi toimii Arduinossa mainiosti. Selvitäpä itsellesi mitä se tekee (selvitykseen tarvitaan AVR-Libc:n ja ATMega328-prosessorin I/O:n tunteminen).
#include <avr/io.h>
uint8_t count;
void setup(void) {
PORTB = 0;
DDRB = 0xff;
count = 0;
}
void loop(void) {
PORTB = count++;
}
OK. katsotaampa nyt samantien pikaistuksissani, veikkasin:
* #include <avr/io.h> Includetaan I/O kirjastoo. Ajattelin ensin tehdä tän katsomatta kirjastoon ja vaan arvaamalla nimistä/heksoista, mutta en saanut vamuutta. http://www.nongnu.org/avr-libc/user-manual/group__avr__io.html
äägh. ei ollut suorilta kultalautasella, joten arvataan.
* uint8_t count; määritellään 8-bitin integgeri kääntäjävapaasti
* DDRB = 0xff; tota näy missään, joten em. libin pitää käyttää sitä tod. näk jonkun portin konfaamiiseen. Sen jälkeen FF heksana tarkoittaa kaikki 8 bittiä pystyssä. Output High (Source)???
* em. kokonaislukumuuttujatavun alkuarvoksi annetaan nolla. Jokin syy, että määritellään luupin ulkopuolella noinkin globaaliksi.
* void setup(void) Määritellään pääohjelma, jolle ei anneta nimettyjä argumentteja (menihän se oikein? pitää kerrata, mutta siis syötettä sulkujen sisällä).
Loputtomiin PORTB = count++; eli portin arvoksi annetaan laskuri, jota indeksoidaan yhdellä loputtomiin....mutta koska se on byte, niin se saa lukuarvoja 0-255 desimaalin välillä.
Kurkaampa mitä toi "portti" tekee, eli oletus on se, että ihminen on looginen eläin, eli PORTB todella tarkoittaa porttia B, vähän ikävää että saman porttiin on kytketty kellon pinnit tms. Joten sitten varmaan käytetään ilman ulkoista kidettä?
Ääh mä en saa tosta mitään selvää, luen vähän yhtä kirjaa ja rupeen nukkumaan. Jatkan joku toinen kerta.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37.Itse hommasin aikanaan hyvin samanlaisen plugin, 120x60cm kumimaton, rannelenkin ja pari nepparikierrejohtoa. Maton taisin tilata Partcon kautta, hehän toimittavat olikos se nyt Farnellin ja Elfan kamaa -jommankumman kataloogista muistaakseni löytyi matto kohtuuhintaan. Kumimatto on hyvä, se kestää kuumaa kolvia ja askartelua, ei tarvii varoa.
Kotiutettu ESD pistoke, jatkojohto, ranneke ja matto. Pinta on rauhallisen värinen, joten sitä jaksaa käyttää varmaan työskentelyyn. Pitäis löytää vielä jostain joku pikkuinen matto tai tarjotin näihin koekytkentöjen käpistelyyn.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Jos haluat päästä asiassa eteenpäin ja ehkä vähän murtaa Arduino-kalteria niin yksi helppo konsti on asentaa ilmainen Atmel Studio 6.1 ja sille Visual Micron Arduino-plugin. Näin pääset kirjoittamaan Arduino-koodia ihan "oikeassa" kehitysympäristössä joka toimii sitten mille tahansa Atmelin prosessorille, ARMit mukaan luettuna. Siis jos/kun ruokahalu kasvaa. Visual Micron mukana tulee myös alkeellinen Arduino-debuggeri joka on parannus verrattuna siihen, että Arduinossa itsessään ei ole mitään. Plus, että Studio tekee koodaamisen ja koodin hallinnan jumalattoman paljon helpommaksi.
Tuo ei näytä kamalan kallilta tai vaikeelta. Pitää vaan priorisoida nyt oikein, että pysyy "momentti" päällä.
Kiitos,
PekkaNF
Lainaus käyttäjältä: PekkaNF - 04.02.14 - klo:23:33
Missäs perkuleessa se Kerningham ja Ritchie nyt luuraskaan? Kiitos uskottavasta mielipiteestä. Ajattelin tässä lukee samalla teoriaa ja käpistellä noita käytännön asioita.
OK. katsotaampa nyt samantien pikaistuksissani, veikkasin:
* #include <avr/io.h> Includetaan I/O kirjastoo. Ajattelin ensin tehdä tän katsomatta kirjastoon ja vaan arvaamalla nimistä/heksoista, mutta en saanut vamuutta. http://www.nongnu.org/avr-libc/user-manual/group__avr__io.html
äägh. ei ollut suorilta kultalautasella, joten arvataan.
* uint8_t count; määritellään 8-bitin integgeri kääntäjävapaasti
* DDRB = 0xff; tota näy missään, joten em. libin pitää käyttää sitä tod. näk jonkun portin konfaamiiseen. Sen jälkeen FF heksana tarkoittaa kaikki 8 bittiä pystyssä. Output High (Source)???
* em. kokonaislukumuuttujatavun alkuarvoksi annetaan nolla. Jokin syy, että määritellään luupin ulkopuolella noinkin globaaliksi.
* void setup(void) Määritellään pääohjelma, jolle ei anneta nimettyjä argumentteja (menihän se oikein? pitää kerrata, mutta siis syötettä sulkujen sisällä).
Loputtomiin PORTB = count++; eli portin arvoksi annetaan laskuri, jota indeksoidaan yhdellä loputtomiin....mutta koska se on byte, niin se saa lukuarvoja 0-255 desimaalin välillä.
Kurkaampa mitä toi "portti" tekee, eli oletus on se, että ihminen on looginen eläin, eli PORTB todella tarkoittaa porttia B, vähän ikävää että saman porttiin on kytketty kellon pinnit tms. Joten sitten varmaan käytetään ilman ulkoista kidettä?
Ääh mä en saa tosta mitään selvää, luen vähän yhtä kirjaa ja rupeen nukkumaan. Jatkan joku toinen kerta.
Kiitos,
PekkaNF
Liittämällä mukaan avr/io.h kääntäjälle tulee mukaan muitakin headereitä. Noita Atmeleita samoin kuin Microchipin piccejä on sen miljoona joten yleensä tehdään noin, samalla tulee semmottista yleispätevää sorsakoodia mikä sopii muillekin prossuille (riippuu vähän mistä roikkuu)
uint8_t tyyppi määritelmä määritetään C99 mukaisessa stdint.h headerissä, ennemmin esimerkiksi "int" oli/on hyvin epämääräinen ja saattoi vaihdella ympäristöstä toiseen.
DDRB määritellään juuri kyseisen prossun headerissä mille olet kääntämässä ohjelmaa, oikea headeri tulee mukaan tuon liittämällä avr/io.h joka sitten ottaa mukaan juuri ko. prossulle olevan headerin. (<avr/ioXXXX.h>)
Jep, ja siis selvennyksenä edelliseen esimerkkiini, niin koodi siis toimii hienosti, mutta ei tee mitään sinänsä järkevää, eli se ei ollut siinä pointtina.
Lainaus käyttäjältä: jyrki.j.koivisto - 05.02.14 - klo:09:52
Liittämällä mukaan avr/io.h kääntäjälle tulee mukaan muitakin headereitä. Noita Atmeleita samoin kuin Microchipin piccejä on sen miljoona joten yleensä tehdään noin, samalla tulee semmottista yleispätevää sorsakoodia mikä sopii muillekin prossuille (riippuu vähän mistä roikkuu)
.....
DDRB määritellään juuri kyseisen prossun headerissä mille olet kääntämässä ohjelmaa, oikea headeri tulee mukaan tuon liittämällä avr/io.h joka sitten ottaa mukaan juuri ko. prossulle olevan headerin. (<avr/ioXXXX.h>)
Muuttujan määrittelyt oli sitä vanhaa ja tuttua, mutta mitenkäs tuo nyt kokonaisuudesaan toimis, jos haluttais määritellä yleispätevästi portti ja sitten halutaan kertoa kääntäjälle, että TÄSSÄ tapauksessa koodi tulee nyt Arduino Unon 28 pin DIL ATMEGA328P-PU (tai oikeestaan sama bootlaoaderilla)????
Jotenkin hämärästi luulen ymmärtäväni konseptin, mutta se vaatii jonkin verran määrittelyjä...Onko tästä jotain "lyhyttä johdantoo" eli alle 700 sivua?
Kiitos,
PekkaNF
PS. Vaikka koodi ei tekisikään mitään järkevää, niin eikös tuo pääluuppi pyöri "ikuisesti" ja muuttuja PORTB saa arvon 0 ja siitä se sitten inkrementoituu 255:n, vuotaa yli nollaan ja ad.infinitum ad.nauseaum.??? Eihän tässä ole niinkun joissakin signaaliprossuilla, että voidaan määrätä luku saturoitumaan jompaan kumpaan laitaan, eikä pyörähdä ympäri. Uni/työvelan jälkeen vois lukee vähän ja ehkä kokeilla Arduinolla jotain pientä esimerkkiä ajatuksen kanssa.
Tuosta http://www.atmel.com/Images/8161s.pdf (http://www.atmel.com/Images/8161s.pdf) kun kattoo tuon Atmelin pinnijärjestyksen niin ilmeisestikin tarkoitat juuri tuon prossun pinniä 28 DIL paketissa? Sivulla 2 siinä kohtaa DIL paketin kohilla lukee PC5 (ADC5/SCL/PCINT13), eli tuossa pinnissä on portin "C" pinni 5 ja muuta jännää. Portti C on datalehden mukaan vain 7-bitin levyinen eli käytössä on PC0-PC6.
Portin suuntaa ohjataan sitten rekisterillä jonka nimi on DDRC (Oliko tuo nyt sitten Data Direction Register) DDRB ohjaa portin B suuntaa jne. Tässä kohtaa tämä on juurikin nuin mielikuvituksetonta ja simppelisti nimetty.
DDRx rekisterin bitit vastaa yksi yhteen portin "pinnejä" eli bitti 0 on Px0 jne. En ole pitkään aikaan leikkinyt Atmeleilla, Kremmenille nämä taitaa olla tutumpia, mutta näissä Atmeleissa ja Microchipin tuotoksissa nämä on melko lailla samanlaiset.
IDE (Integrated Development Enviroment) jota käytät osaa kertoa kääntäjälle mille prossulle koodia tullaan tekemään. Kun luot projektin niin samalla valitset prossun, loppu on automaattista.
Joo Arduinossa ei ole saturoituvia muuttujia. Ne on tyypillisesti enempi juurikin signaliprosessorien ominaisuus eikä niitä esiinny yleiskäyttöisissä prosessoreissa. Ja siis tuo koodi toimii kuten totesit; muuttuja kasvaa kunnes vuotaa yli jolloin aloittaa taas nollasta ja homma jatkuu iloisesti maailman tappiin.
Mitä tulee tuohon yleispätevyyteen niin siinä on mahdollisuuksia mutta myös rajoituksia. avr-gcc -kääntyrin include-tiedosto avr/io.h hoitaa osan hommasta:
#ifndef _AVR_IO_H_
#define _AVR_IO_H_
#include <avr/sfr_defs.h>
#if defined (__AVR_AT94K__)
# include <avr/ioat94k.h>
#elif defined (__AVR_AT43USB320__)
# include <avr/io43u32x.h>
#elif defined (__AVR_AT43USB355__)
...
...
#elif defined (__AVR_ATmega3250PA__)
# include <avr/iom3250pa.h>
#elif defined (__AVR_ATmega328P__)
# include <avr/iom328p.h>
#elif (defined __AVR_ATmega328__)
#include <avr/iom328.h>
#elif defined (__AVR_ATmega329__)
...
...
Elikkäs kun Arduino tai vaikka Atmel Studio potkaisee avr-gcc -kääntyrin vauhtiin saa kääntyri muiden muassa sellaisen käynnistysdirektiivin joka identifioi että kyseessä on prosessori __AVR_ATmega328P__ ja sen perusteella ottaa mukaan prosessorikohtaisen I/O-määrittelyheaderin avr/iom328p.h. Itse asiassa tämä on se headeri jota ohjelmasi käyttää nimetäkseen portit ja prosessorin sulautettujen oheislaitteiden rekisterit.
No. Tähän asti hyvä. Jos nyt haluat omassa ohjelmassasi käyttää jotain nimettyä fyysistä I/O-porttia kuten vaikkapa porttia B, niin se tunnetaan järjestään nimillä PINB (tulorekisteri) PORTB (lähtörekisteri) ja DDRB (suuntarekisteri jossa määrätään mikä portissa on input ja mikä output-pinni). Tähän tyyliin (iom328p.h):
/* Registers and associated bit numbers */
...
#define PINB _SFR_IO8(0x03)
#define PINB0 0
#define PINB1 1
#define PINB2 2
#define PINB3 3
#define PINB4 4
#define PINB5 5
#define PINB6 6
#define PINB7 7
#define DDRB _SFR_IO8(0x04)
#define DDB0 0
#define DDB1 1
#define DDB2 2
#define DDB3 3
#define DDB4 4
#define DDB5 5
#define DDB6 6
#define DDB7 7
#define PORTB _SFR_IO8(0x05)
#define PORTB0 0
#define PORTB1 1
...
Tällä systeemillä nimetty portti on tosiaan yleispätevästi mäpätty prosessorin I/O-avaruuteen niin että voit osoittaa porttia nimellä riipumatta siitä, mikä prosessori koodia sattuu ajamaan. Mutta tässä on rajoite: portin täytyy olla olemassa siinä prosessorissa jota käytät. Joku kälyinen ATTiny saa juuri kehitettyä muutaman pinnin porttiin B ja se on siinä. Sitten jossain 144-kinttuisessa Megassa tai miljoonapalloisessa ARM-BGA-paketissa on portteja aakkoset läpi. Voihan nekin virtualisoida niin, että kutsut porttia vaikka Erkiksi ja mäppäät sen itse johonkin sopivaan fyysiseen porttiin kunhan olet ensin varmistanut jollain esiprosessorin makrovirityksellä, että käyttämässäsi prosessorissa tosiaan on sellainen fyysinen portti. Mutta yleensä tämä ei enää maksa vaivaa, koska piirikaaviotasolla joutuu joka tapauksessa tietämään mistä pinnistä kama halutaan ulos tai sisään.
Eli "alle 700-sivuinen" yhteenveto: Arduino-kääntyrille tai Atmel Studiolle - tai viimeistään avr-gcc-kääntäjälle jos koodaat komentoriville - on kerrottava kääntyrin direktiivillä mille prosessorille koodi generoidaan. Arduino-IDE ja Studio osaa tehdä tämä automaagisesti kunhan olet itse ensin valinnut selväkieliseltä listalta kohteen. Sen jälkeen rekisterinnimet toimii ja avr-gcc käyttää samoja tekstuaalisia nimiä kuin Atmelin datalehtien rekisterinnimet. Eli vaikka "TCCR1A" on Timer/Counter 1 Control Register A sekä datalehdellä että avr/io.h:n mielestä. Mutta olen mä joutunut kaivamaan jotain eksoottisempia nimivirityksiä suoraan ioxxxx.h -tiedostoista kun homma on mennyt oikein vaikeeksi...
Koivisto, kiitos asiahan on selvä kun pläkki! Noi avatut lyhenteet kuullosti aivan tutuilta. Onneksi mikään ei ole muuttunut sitten -80-luvun lopun!
Kremmen, kiitos paljon. Ymmärrän nyt paremmin. Duoda, duoda, mitenkähän ne I/O määrittelyt sitten kannattais tehdä tälläisissä kotitarveprojekteissa edes puolisäällisesti?
Yksi tapa on tietysti Arduinon tapa, jota on tutoriaalit täynnä....mutta se on ilmeisesti saastaista.
Mä mielellään määrittelisin ne alussa ja kunnolla, ehkä käyttäisin, joitakin globaaleja lippuja (merkkeri/flag) tilatietoina pitkin koodia, todnäk. analogia erikseen ja PLC tyyppinen tilalogiikka erikseen ja syklin lopussa symboolisten "Bittien" kirjoitus lähtöihin.
Vielä pari liikennejuttua ja sarjaliikenteen mahdollinen labraus, sitten olis DIO labrausta aivan vähän ja sitten pitäisi jo vihdoin päästäkkin tohon analogiapuolen mittausvahvistin hässäkkään.
Yllättäviä pieniä onnistumisia on ollut, vaikka koodista vielä mitään ymmärrä....
Kiitos avusta ja rohkaisusta.
PekkaNF
Lainaus käyttäjältä: PekkaNF - 05.02.14 - klo:23:42
[...]
Yksi tapa on tietysti Arduinon tapa, jota on tutoriaalit täynnä....mutta se on ilmeisesti saastaista.
No saastaista ja saastaista. Sanotaan mielummin, että "sopii aloittelijalle". Muitakin tapoja on.
Lainaa
Mä mielellään määrittelisin ne alussa ja kunnolla, ehkä käyttäisin, joitakin globaaleja lippuja (merkkeri/flag) tilatietoina pitkin koodia, todnäk. analogia erikseen ja PLC tyyppinen tilalogiikka erikseen ja syklin lopussa symboolisten "Bittien" kirjoitus lähtöihin.
Mitä tulee vaikkapa porttien määrittelyyn, niin saanko ehdottaa omaa tapaani ainakin osaratkaisuksi. Itse kyhään aina "xxxcommon.h" -nimisen header-tiedoston johon kasaan tiedot kaikista yhteisistä resursseista joihin on sitten kiva viitata nimellä kun tuo tiedosto on includattu. Kierroslukumittarin RPMcommon.h liitteenä näytiksi.
Jo kultaisella 80-luvulla rakenneltiin "ohjelmoitavia logiikoita" ihan omasta päästä kun piti paperi- ja päällystyskoneita yms ohjata, ja niissä riitti vipua ja vipstaakia mitä piti hämmentää. Kehiteltiin silloin koodin ja ruutupaperi-CADin yhdistelmä, eli meillä oli koodissa paketoituna logiikkafunktioita kuten vaikkapa portteja ja flipareita, laskureita yms yms mitä nyt ohjelmoitavassa logiikassa tarvitaan. Nuo kapineet piti itse yllä omaa sisäistä tilaansa, vaikkapa laskuri esim omaa lukuarvoaan. Tänä päivänä kun Arduinokin tukee hienosti C++:aa niin nuo suorastaan huutaa toteuttaa C++:lla omiksi objekteikseen. Sillä systeemillä saisi sairaan kauniin toteutuksen joka olisi tosi helppo vielä ymmärtääkin. Jos aihe kiinnostaa niin apuja löytyy kyllä.
Lainaa
Vielä pari liikennejuttua ja sarjaliikenteen mahdollinen labraus, sitten olis DIO labrausta aivan vähän ja sitten pitäisi jo vihdoin päästäkkin tohon analogiapuolen mittausvahvistin hässäkkään.
Yllättäviä pieniä onnistumisia on ollut, vaikka koodista vielä mitään ymmärrä....
Kyllä se siitä :)
Lainaa
Kiitos avusta ja rohkaisusta.
PekkaNF
De nada. Palataan asiaan kun asia etenee.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
C ja C++ on kaikille samat, joten varsinaisen kielen opiskelu on yksi asia joka kannattaa mutta eri asia on sitten vielä soveltaa kieltä käytännössä.
Tänhän piti olla helppoo...koulustakaan ei ole kun noin 25 vuotta. Pökäleet. Materiaalista on oikein runsaudenpulaa:
https://noppa.aalto.fi/noppa/kurssi/as-0.3302/materiaali
Täällä onkin reippasti:
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/
Tuo näyttää hyvältä:
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-087-practical-programming-in-c-january-iap-2010/
Ainoa huono puoli, että ainoa asia joka saa minut nukahtamaan nopeemmin on Siemens S5 manuaalit...tuntuu, ettei mitään ole muistissa ja kaikki on levällään.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Matalan tason sulautetuissa systeemeissä kuten Arduinossa ja päinvastoin kuin esim PC:ssä, ei ohjelman ja raudan välissä ole mitään virtualisointi- tai abstraktiokerrosta kuten vaikkapa käyttöjärjestelmää. Tällöin iso osa systeemin suunnittelua ja toteutusta on ohjata sulautettuja oheislaitteita ja GPIO:ta (siis General Purpose I/O, eli yleiskäyttöiset tulot ja lähdöt eli portit) suoraan. Tämän hallitsemiseksi tarvii osata prosessorin sulautetut oheislaitteet, sen porttirakenne sekä käytetyn alustan (tässä siis Arduinon) piirikaavio.
OK. Tämä onkin se mielenkiintoinen puoli. Tässä mun pitäis pysyä hereillä.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Arduinon mukana tulee sen oma IDE jolla noita "sketchejä" kirjoitetaan. Miksiköhän niitäkään ei ole voinut rehellisesti kutsua ohjelmiksi... No, joka tapauksessa IDE ei käännä mitään, vaan koodin tuottaa taustalla vanha tuttu avr-gcc joka on siis ei mikään muu kuin Atmelin prosessoreille sovitettu GNU C/C++ kääntyri, varmaan maailman eniten käytetty. Arduinolla ei siis ole mitään omaa ohjelmointikieltä, vaan se on puhdas C/C++ sellaisena kuin avr-gcc sen toteuttaa (Arduino Unon "moottorihan" on ATMega328). Kaikki avr-gcc:n ajonaikaisen kirjaston (AVR Libc) funktiot on käytettävissä, ja _ne_on_syytä_oppia_. Löytyy täältä: http://www.nongnu.org/avr-libc/ (http://www.nongnu.org/avr-libc/). Tuolla on vielä joku vähän vanhempi avr-gcc tutoriaali: http://www.8051projects.net/files/public/1242392126_2569_FT22383_avr_tutorial.pdf (http://www.8051projects.net/files/public/1242392126_2569_FT22383_avr_tutorial.pdf).
Räkä...tätä ei ole vielä aloitettukaan. Pitääkin laittaa oikein muistiin lusittavaksi.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Ja omana mielipiteenä kannattaisi juuri Arduinon kanssa treenata C++:n käyttöä, koska niin Arduino tekee itsekin.
Joo, oppimiskäyrä oli aluksi jyrkkä, mutta nyt alkaa tuntua olo tyhmältä eikä ohjelmat toimi ihan niinkun kuvittelin. Lisää harjoitusta. Ei kai se tyhmennä, vaikka ohjelmat olisivat poikkeuksellisen huonoja.
Tähän on ollut apuna
Arduino Cookbook, 2nd Edition
Recipes to Begin, Expand, and Enhance Your Projects
http://shop.oreilly.com/product/0636920022244.do?intcmp=il-na-books-videos-product-intsrch_arduino_ct
Vaikuttaa aika kivalta kirjalta.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Vaikkei sitä missään mainostetakaan niin Arduinon koodin rakenne on suoraan C++:n mukaista ja valtaosa sen omia ja kolmansien kirjoittamia kirjastoja on itse asiassa C++ -luokkia. C++:n käytöllä saa useita etuja mutta ei joudu maksamaan muuta kuin opettelemisen vaivan. Yleensä C++ -kielen käyttöä väistellään sillä perusteella että se olisi raskasta, mutta se ei kyllä pidä paikkaansa teorian eikä oman kokemuksenkaan perusteella. C++:n periaate on "no penalty" eli jos jotain ominaisuutta ei käytä, se ei tule mukaan lopulliseen koodiin. Tätä nykyä kirjoitan kaikki sovellukset C++:lla jos vaan käytetty ympäristö sitä tukee. Muun muassa taannoin jäsen senaattorin aloitteesta toteuttamani kierroslukumittari on kokonaan C++:lla koodattu.
Mä luin ton parikin kertaa, mutten sisäistänyt kun "no penalty" kohdasta eteenpäin. Pitäne googlata objekti ja luokka, jotenkin tutun kuuloinen, mutta oppimatta. Google on ystävä.
Lainaus käyttäjältä: Kremmen - 02.02.14 - klo:16:37
Jos haluat päästä asiassa eteenpäin ja ehkä vähän murtaa Arduino-kalteria niin yksi helppo konsti on asentaa ilmainen Atmel Studio 6.1 ja sille Visual Micron Arduino-plugin. Näin pääset kirjoittamaan Arduino-koodia ihan "oikeassa" kehitysympäristössä joka toimii sitten mille tahansa Atmelin prosessorille, ARMit mukaan luettuna. Siis jos/kun ruokahalu kasvaa. Visual Micron mukana tulee myös alkeellinen Arduino-debuggeri joka on parannus verrattuna siihen, että Arduinossa itsessään ei ole mitään. Plus, että Studio tekee koodaamisen ja koodin hallinnan jumalattoman paljon helpommaksi.
Miten tämä liittyy "AVR-OHJELMOINTILAITE Atmel AVRISPmkII"
AVR 8-bittisille tarkoitettu USB-ohjelmointilaite. 6-pinninen ISP / PDI / TPI -liitäntä. ....Hmmm.
http://www.partco.biz/verkkokauppa/product_info.php?cPath=5&products_id=15872&osCsid=mmd3pkcuskn2f1c66ulvn9ksk1
Missä vaiheessa tämä parantaa mun elämänlaatua ;D?
Mä en halua haukata liian isoo palaa kerralla. Alan jo miettiä, että koska muut peruspalikat alkaa olla tsekattu tilaan "tehtävissä", pitäiskö sittenkin tehdä virranmittaus ja labrata se. Se on mulle jonkinlainen epävarmuustekiä.
PekkaNF
Lainaus käyttäjältä: PekkaNF - 09.02.14 - klo:20:41
[...]
C ja C++ -kielistä löytyy käsittämättömät määrät materiaalia netistä. Jos vaan jaksaa kahlata niin kaikki info on kyllä siellä, mutta ei välttämättä hirveen jäsennettynä kokonaisuutena.
Jokainen oppii ja opiskelee asioita omalla tavallaan enkä mä nyt halua tyrkyttää, mutta muutamia juttuja joita itse pitäisin tärkeinä tai ainakin ymmärrystä edistävinä:
-Valkoinen Jänis kysyy kuninkaalta kirjassa Liisa ihmemaassa: "mistä aloittaisin, teidän majesteettinne" ja kuningas vastaa: "aloita alusta, ja jatka kunnes olet päässyt loppuun". Hyvä neuvo - ei kannata aloittaa puolivälistä ennenkuin perusteet on hanskassa. Niin näppärä kuin Arduino onkin, niin riski on päätyä vain lätkimään muiden tekemiä palikoita peräkkäin ja yrittää räplätä niihin henkeä ymmärtämättä oikeasti kuinka homma toimii. Ensin opettele kielen perusteet niin että sinua ei viedä kuin litran mittaa. Arduino skene on niin puolillaan paskaa koodia että pahaa tekee vielä enempi riipii kun suuri osa jengistä on aivan pihalla tästä faktasta. Aika vähällä pohjatyöllä siitä suosta pääsee ylös ja pystyy itse olemaan osa ratkaisua eikä ongelmaa.
Jos tarkoitus on vain käyttää Arduinoa (tai mitä muuta komponenttia tahansa) osana jonkin akuutin tarpeen ratkaisua niin silloin ymmärryksellä ei ole niin väliä. Mutta jos tähtäin on homman hallinnassa niin ei kannata sortua houkutukseen päästä äkkiä maaliin kolvaamalla mustia laatikoita peräkkäin.
-Arduino itse - siis sen koodirunko ja vakiokirjastot - on kirjoitettu C++:lla. Se on ihan sitä perus ++:aa mitä avr-gcc tukee ja jossa ei ole otettu mukaan kaikkein raskaimpia C++:n ajonaikaisen ympäristön ominaisuuksia. Kuitenkin avr-gcc ja sitä myötä myös Arduino tukee kaikkia C++:n olennaisia ydinpiirteitä, jotta sillä voi hyvin koodata täysiveristä C++:aa. Itse olen pari vuotta sitten tehnyt piruuttani kameradollyn ohjausohjelman, jossa Arduinon kestomuistiin pystyi tallettamaan dynaamisesti päätteeltä luodun ohjelman jossa oli kameran liikkeet, ajastukset ja valotukset vapaasti ohjelmoitavissa ja talletettavissa kestomuistista noudettaviksi ohjelmiksi. Homma perustui linkitettyihin listoihin joiden nodet luotiin ajonaikana dynaamisesti allokoituun muistiin. Näin siis Arduinossa toteutettiin kekomuistin (heap) hallinta varauksineen ja vapautuksineen ihan kuin aidossa PC:ssä konsanaan. Eikä vaatinut montaakaan koodiriviä. No kokonaisuus kyllä vaati, mutta muistinhallinta oli aika suoraviivaista.
Noissa linkkaamissasi kurssimatskuissa oli luentosarjoja joissa olio-ohjelmoinnin perusjuttuja käydään läpi, mutta pähkinänkuoressa idea on seuraava:
Perinteisessä ohjelmointitavassa on tietorakenteita ja sitten funktioita ja proseduureja jotka käpistelevät noita rakenteita. Tietorakenteet ovat joko ihan primitiivimuuttujia kuten vaikka C-kielen perustyypit, esim integer, tai sitten struktuureja jotka kokoavat useita primitiivimuuttujia yhteen rakenteeksi (vaikkapa string on tämmöinen, eli se on tavujono joka kokonaisuutena esittää jotain tekstinpätkää; mutta paljon mutkikkaammatkin on mahdollisia). Sitten on vaikkapa klassinen "print()"-funktio joka tulostaa merkkijonon jonnekin.
Jos tuo edellinen toteutettaisi olio-ohjelmoinnin periaattein esim C++ -kielisenä niin meillä olisi olio, eli C++:n termein luokka nimeltä vaikkapa "string". Kaikki ohjelman merkkijonot olisivat nyt luokan "string" ilmentymiä. Eli luokka on malline josta voidaan poikia niin monta ilmentymää kuin halutaan ja ne kaikki "käyttäytyvät" samalla tavalla. Miten ne käyttäytyvät, määrätään toteuttamalla luokalle ns "metodeja" jotka itse asiassa ovat niitä funktioita jotka perinteisessä ohjelmoinnissa ovat erillisiä. Aluksi tämä varmaan tuntuu tyhjänpäiväiseltä kikkailulta, mutta on itse asiassa erittäin voimakas konsepti kun siihen pääsee sisälle.
No toi AVRISP mkII sitten on yleiskäyttöinen Atmelin prosessoreiden ohjelmointilaite. Sillä voi ohjelmoida vaikka Arduinon jos huvittaa. Esim se Unon ja muidenkin 6-pinninen liitinrima on suoraan Atmelin debugwire-signaloinnin mukainen ja sen kautta voi ohjelmoida ja debugata Arduinon suoraan Atmel Studiosta käsin. Tosin se ei sen jälkeen enää varsinaisesti ole Arduino jos ylikirjoitat bootloaderin :)
Mutta AVRISP:llä voi ainoastaan ohjelmoida. Jos minä miettisin jotain tuollaista, niin hommaisin kyllä ennemmin Atmelin JTAGICE 3:n jolla voi myös debugata koodia. Ai niin, mutta mullahan onkin semmoinen, samoinkuin vähän vanhempi JTAGICE mk II :). Eli ihan vakavasti - AVRISP on oiva peli kun haluat ohjelmoida piirejä. Mutta kun yleensä sitä ennen se koodi pitäisi saada toimimaan. Ei kukaan ammatikseen sulautettuja tekevä alkaisi mihinkään ilman debuggeria. Ja suoraan sanon että sillä säästää ämpäreittäin hikeä ja kyyneliä, joten pistä ihmeessä kolme- neljä kymppiä lisää pottiin ja homma JTAGICE 3: http://fi.mouser.com/ProductDetail/Atmel/ATJTAGICE3/?qs=sGAEpiMZZMteY%252blXHTQ5JNQSom8qJIi0 (http://fi.mouser.com/ProductDetail/Atmel/ATJTAGICE3/?qs=sGAEpiMZZMteY%252blXHTQ5JNQSom8qJIi0).
Ja siis kun pääset tähän asti niin olet vapaa Arduinon ikeestä (jos se nyt on joku ies). Lätkäiset vaan jonkun AVR:n kiinni lautaan, annat sille vähän sähköä ja debuggerilla pääset kiinni sen sielunelämään suoraan. Ihan jotain muuta kuin Arduinon kanssa taistelu.
Lainaa
Missä vaiheessa tämä parantaa mun elämänlaatua ;D?
Kun haluat ohjelmoida AVR-prosessorin joka ei ole Arduino-laudassa. Tai vaikka olisikin :). Ja se debuggeri korottaa homman seuraavalle tasolle, kun vielä näet mitä se ohjelma tekeekin (etkä joudu vaan luulemaan mitä se toivottavasti tekisi). Mä toistan itseäni, mutta silläkin uhalla: debuggausmahdollisuus on ihan ehdoton kun aletaan tekemään vähänkään haastavampia juttuja kuin ledin vilkutus.
Pistin piruuttani sen kameradollyn lähdekoodin tuohon liitteeksi niin voit vilkaista jos huvittaa. Siellä on aika paljon ihan rehellistä C++:aa ja Arduino nielee sen mukisematta. Tosin tuo koodi on vanhassa Arduino-formaatissa joka ei käänny enää uusimmilla IDE:illä, mutta lukea sitä kuitenkin voi ihan hyvin :)
c++, tai sanotaanko ennemminkin olio-tyyppinen ohjelmointi sulautetussa järjestelmässä on vähän siinä ja tässä tämän koodarin näkökulmasta.
Olioilla saa todella mukavasti käsiteltäviä kokonaisuuksia joilla itse toiminnallisuus on kiva koodata ja kaikki menee loogisesti. Ongelmana on että näillä saa myös lisättyä helposti ja vaivattomasti kompleksisuutta itse käännettävään loppubinääriin niin runsaasti että se alkaa näkyä jo pienen porsaan toiminnassa. periyttäminen, operaattorikuormitus jne aiheuttaa todella helposti pitkiä pointteriketjuja jotka syövät aikakriittisessä aplikaatiossa aika paljon perffiä. Muisti accessi on yleensä enemmän kuin yksi käsky, joten varsinkin tämmönen in-order prosari stallaa helposti pitkäksi aikaa yhden periytetyn luokan operaattoria käsitellessä. Jos mennään astetta järeämpiin kontrollereihin mistä löytyy välimuisteja, tämä homma pitää oikeasti ottaa huomioon koodatessa.
pahinta tässä on että itse koodia lukemalla tämä kompleksisuus on vaikea havaita, koska oliot kätkevät sen niin nätisti.
joo, kääntäjät on parantuneet kyllä kokoajan mutta ei nekään ihmeisiin pysty. Itse suosin seuraavaa: Raudan tasolla C, ylempänä se millä helpoimmin saa homman tehtyä. c++, perl jne eri hommiin eri työkalut.
muuten tuohon liitettyyn koodiin liittyen. suosittelisin tekemään DEBUG_MSG() makron joka riippuen DEBUG definestä määritellään joko tyhjäksi tai printiksi. #ifdef jokaisen debug printin ympärillä sotkee koodin luettavuutta aikalailla.
Lainaus käyttäjältä: lekonna - 10.02.14 - klo:08:40
c++, tai sanotaanko ennemminkin olio-tyyppinen ohjelmointi sulautetussa järjestelmässä on vähän siinä ja tässä tämän koodarin näkökulmasta.
Meillä on jokaisella mielipiteemme useimmista asioista ja totuus harvoin onkaan mustavalkoinen. Asioista voi ja kannattaa aina keskustella.
Lainaa
Olioilla saa todella mukavasti käsiteltäviä kokonaisuuksia joilla itse toiminnallisuus on kiva koodata ja kaikki menee loogisesti. Ongelmana on että näillä saa myös lisättyä helposti ja vaivattomasti kompleksisuutta itse käännettävään loppubinääriin niin runsaasti että se alkaa näkyä jo pienen porsaan toiminnassa. periyttäminen, operaattorikuormitus jne aiheuttaa todella helposti pitkiä pointteriketjuja jotka syövät aikakriittisessä aplikaatiossa aika paljon perffiä.
Näinhän sitä tupataan sanomaan, mutta minäpä puolestani väitän, että jos vertaillaan kunnolla niin useimmat näistä argumenteista tuppaavat sulamaan käsiin. On totta, että määrätyt C++:n konstruktiot vaativat koodia ja/tai muistia toimiakseen, mutta sitä kritisoidessa ei sovi unohtaa, että niin vaatii C:kin jos toiminto tehdään sillä kielellä.
Vaikkapa nyt tuo periyttämisen aiheuttama overhead ei ole mitenkään kirkossa kuulutettua. Jos käytät virtuaalimetodeja ja periytät niitä, niin vtableen on toki metodin osoite lätkäistävä. Mutta koetapa hoitaa sama tarve C:llä ihan miten vaan niin huomaat että ei sekään ollut ilmaista. Vain erotuksella on lopulta merkitystä. Tavallinen periyttäminen ei tuota overheadia.
Operaattoreita olen itse kuormittanut näissä yhteyksissä aika vähän - ei sille oikein isoa tarvetta tunnu löytyvän ainakaan pienissä sovelluksissa. Operaattorikuormituksen pääasiallinen motiivihan lienee yhdenmukaistaa olioiden käyttöä suhteessa primitiivisiin tyyppeihin. Useimmat keisit joissa itse olen törmännyt valituksiin siitä kunka operaattorikuormitus hidastaa ja turvottaa koodia, ovat kyllä olleet toteutuksen (tai joissain harvoissa tapauksissa kääntyrin) heikkouksia eikä kuormituksen sinänsä. En äkkiä keksi miksi operattorikuormituksen pitäisi tuottaa mitään lisärasitetta mutta kerro jos tiedät.
Lainaa
Muisti accessi on yleensä enemmän kuin yksi käsky, joten varsinkin tämmönen in-order prosari stallaa helposti pitkäksi aikaa yhden periytetyn luokan operaattoria käsitellessä. Jos mennään astetta järeämpiin kontrollereihin mistä löytyy välimuisteja, tämä homma pitää oikeasti ottaa huomioon koodatessa.
Mä en nyt saa tuosta ajatuksesta oikein kiinni. Pienissä AVR:issa ei ole cachea joka voisi stallata. Itse asiassa kun luokan metodit ovat lokalisoituneet muistissa lähekkäin on osoitus yleensä tehokkaampaa kuin jos ne olisivat hajallaan satunnaisesti ympäri koodimassaa.
Lainaa
pahinta tässä on että itse koodia lukemalla tämä kompleksisuus on vaikea havaita, koska oliot kätkevät sen niin nätisti.
Voidaan tosiaan argumentoida, että C++ on kompleksisempaa kuin C - sisältäähän se kaikki C:n ominaisuudet ja sen päälle vielä objektiorientoituneen viitekehyksen. Mitaleilla on aina kaksi puolta ja minä suhtaudun asiaan näin: On koko joukko C++:n ominaisuuksia joiden käyttö ei tuo mitään overheadia verrattuna C:n käyttöön. Tässä siis lähdetään siitä, että jokin piirre tai toiminnallisuus halutaan ylipäänsä toteuttaa, jolloin se tulee toteutettavaksi käytetiin kumpaa kieltä tahansa. Ellei haluta niin se on siinä. Mutta jos ominaisuus sisältyy C++:n kielioppiin niin sille on tuki suoraan kielen syntaksissa. Vastaavan toiminnallisuuden toteuttaminen C:llä on ohjelmoijan koodin varassa ja yleensä aina lopputulos on huonommin vakioitu ja hallittu.
Sitten on joukko C++:n piirteitä jotka kasvattavat joko koodin määrää tai ajoaikaa. Yleensä nämä liittyvät ajonaikaiseen tyypintunnistukseen tai myöhäiseen sitomiseen. Niitä joko on syytä välttää tai sitten ei - riippuu ihan siitä mitkä ovat prioriteetit. Naiivi / varomaton koodari voi kokea yllätyksiä, mutta ei se ole kielen vika vaan puute osaamisessa. Senpä takia suosittelin ja suosittelen perusasioiden ottamista hanskaan ennenkuin edetään liian pitkälle.
Lainaa
joo, kääntäjät on parantuneet kyllä kokoajan mutta ei nekään ihmeisiin pysty. Itse suosin seuraavaa: Raudan tasolla C, ylempänä se millä helpoimmin saa homman tehtyä. c++, perl jne eri hommiin eri työkalut.
Mikä ettei, mutta en ole huomannut mitään ongelmaa siinä, että vaikkapa prosessorin sulautettuja oheislaitteita virtualisoidaan luokan sisään. Ihan pelkästä GPIO:n räpläämisestä nyt ei ehkä paljoa riemua repeä C++:lla, mutta jo timerit, muuntimet, linjaohjaimet hyötyvät kyllä. Näinhän itse asiassa Arduinokin tekee, vaikka en mitenkään esitä että ne luokat olisi mitään malliesimerkkejä best practice-toteutustavasta. Jos homman tekisi kunnolla niin ne pitäisi tehdä singleton-luokiksi nyt alkuun.
Lainaa
muuten tuohon liitettyyn koodiin liittyen. suosittelisin tekemään DEBUG_MSG() makron joka riippuen DEBUG definestä määritellään joko tyhjäksi tai printiksi. #ifdef jokaisen debug printin ympärillä sotkee koodin luettavuutta aikalailla.
On siinä paljon muutakin mikä pitäisi ensin siistiä. Jos se olisi kirjoitettu jollekin muulle kuin Arduinolle niin olisin jakanut sen kunnolla eri käännösyksiköihin, mutta halusinpa nyt pitää kaiken yhdessä tiedostossa vaikka siitä vähän kömpelö tuleekin sillä tavalla. Muutakin pitäisi parantaa, ei vähiten nuo osin huonosti koodatut kirjastot joita otin käyttöön. Mutta enpä jaksanut alkaa kun ohjelma on kumminkin varsin simppeli eikä sen hallinnassa nyt näinkään ollut ongelmia.
Tämäkin vertailu on tietysti ikuisuuskysymys. Jonkun assembler-uskovaisen mielestä me kaikki ollaan kerettiläisiä, ja saattaapa joku olla sitäkin mieltä, että miksi vaivautua kääntämään mitään kun konekoodit on julkista tietoa :).
Minulle C++:n arvo on ehkä eniten siinä miten koodin rakenteen saa jäsennettyä ylivoimaisen selkeäksi verrattuna muihin relevantteihin vaihtoehtoihin. Kaikki puhe turvonneesta koodista ja hitaista suoritusajoista on kiinnostavaa vasta jos siitä muodostuu ongelma.
Tällä foorumilla ei varmaan ole kovin tuttu kaveri Computer Sciencen grand old man Donald Knuth http://fi.wikipedia.org/wiki/Donald_Knuth (http://fi.wikipedia.org/wiki/Donald_Knuth). Hän on kuitenkin "piireissä" legendaarinen hahmo ja kirjoittanut yhden alan perusteoksista, moniosaisen "The Art of Computer Programming" jossa kaikki nykyisinkin käytössä olevat perusrakenteet ja algoritmit on seikkaperäisesti esitelty ja työstetty läpi. Muutama osa löytyy edelleen minunkin kirjahyllystä. Hänen lentäviin lauseisiinsa kuuluu yksi jonka olen koettanut aina pitää mielessä ja joka ei ole pettänyt:
Premature optimization is the root of all evil.
Ennenaikainen optimointi on kaiken pahan alku.
http://en.wikiquote.org/wiki/Donald_Knuth (http://en.wikiquote.org/wiki/Donald_Knuth)
Iltaa lajitoverit.
Yllätin itseni ja intouduin verestämään takavuosien muistoja ajoilta jolloin ohjelmoitavat logiikatkin oli tehtävä itse.
Kun kerta puhetta oli pienistä muutaman I/O:n logiikkavirityksistä, niin kyhäsinpä äkkiseltään alustavan esityksen aiheesta. Jos tämä jotakuta kiinnostaa niin asiaa voidaan edistää pidemmälle.
Oheen liitetty Arduino-sketsi "logic.ino" sisältää pienen demologiikan jonka ajatus on muka ohjata ajoporttia käskyjen mukaan auki ja kiinni. Sketsitiedosto käyttää kirjastoa "logiikka.h" / "logiikka.cpp" jossa on määriteltynä muutam flipflop ja ylös/alas-laskuri. Tuohon kirjastoon voi rakentaa sitten kaikkea muutakin kivaa jos intoa ilmenee.
Varsinaisessa sketsissä määritellään muutamia ympäristöjuttuja kuten käytettävät I/O-pinnit, logiikkamodulien alustukset setup():issa, sekä varsinainen logiikkaohjelma muutamassa funktiossa.
Laitoin oheen myös logiikkaohjelman piirikaaviomuotoisen esityksen pdf-tiedostona.
Tuota ei varsinaisesti ole vielä debugattu, joten toiminnasta ei ole takeita tällä hetkellä, mutta toimimaan se saadaan kyllä. Tällä systeemillä tehtyjä kekottimia on Suomen paperitehtaissa kasapäin, elleivät jo ole uudistaneet / romuttaneet kaikkia.
Ohjelma kääntyy jo virheettömästi ja demokoodin koko on hyvin pieni, joten arska pystyy ajamaan kyllä huimasti suurempiakin sovelluksia, ainakin koon puolesta. Mitä tulee suorituskyvyn riittämiseen, niin olen tässä demossa aloittanut koodin jakamisen kolmeen eri aikatasoon, eli osuuksiin jotka toistetaan 10 ms, 100 ms ja 1s sykleissä. Nyt kaikki koodi ajetaan aikakeskeytyksen sisältä, mutta jatkossa voidaan rakennetta tarvittaessa muuttaa niin, että vain herätteet tulevat keskeytyksestä ja ajo tehdään joutoaikatasolla. Sillä tavalla koodi ei koskaan mene solmuun, rupeaa vain hidastumaan jos prosessori ylikuormittuu. No sen näkee sitten.
Laitan tuon iltapuhteina toimintakuntoon parin seuraavan illan aikana ja lisäilen mahdollisesti tarvittavia juttuja.
Sillä välin kaikki kommentit tervetulleita. Vaikka tuo saattaa näyttää aluksi aika monipolviselta, niin oikeasti se on helppo soveltaa ja homman oppii äkkiä.
Kattelin noita läpi pariin otteeseen. En vielä saanut ihan otetta, joten ensin mun opiskella hieman enemmän.
Olen lähinnä lataillut pikkusia harjoitusohjelmia ja katellut miten ne on tehty...kokolailla opiskeltavaa, koska kaikki on vähän hakusessa. Hardis, piirit ja ohjelmointi. Motivaation ylläpitämiseksi pitää välillä tyytä siihen, etten ymmärrä kaikke ja riittävä alkutaso opiskelulle on se, että saan jonkun toisen valmsitaman kortin toimimaan.
Sain Demot toimimaan Arduinon R3:lla ja tällä LCD:llä.
https://www.olimex.com/Products/Duino/Shields/SHIELD-LCD16x2/open-source-hardware
suurin vaikutus sillä, että sille löytyy sekä esimerkit, että kirjasto:
LCD16x2.cpp
LCD16x2.h
keywords.txt
Ok, ei ehkä kaikkein kauneinta, mutta pääsin kiinni nappuloihin ja sain testattua, että LCD ja napulat toimii, sekä varmuuden siitä, että pysytyn käyttämään tota.
RTC oli vähän isompi haaste:
https://www.olimex.com/Products/Modules/Time/MOD-RTC/open-source-hardware
Tolle ei ollut kirjastoa valminaa, mutta google on ystävä ja piirin tyypin avulla löysin sille sopivan kirjaston ja esimerkkiohjelman. Senkin sain henkiin, vaikka siihen jäikin haasteita.
Liitin sen I2C (valmiskaapeli) Olimexino 328:
https://www.olimex.com/Products/Duino/AVR/OLIMEXINO-328/open-source-hardware
Tuokin yllätti välillä, yhtäkkiä se alkoi huutaa sarjaväylän virhettä, kunnes selvis, että sen sarjapiirissä on bugi, joka voidaan kierää käyttämällä vanhempaa ajuria: https://www.olimex.com/forum/index.php?topic=2031.0
Mutta viimeinen ostettu kortti Releitä, optoerotettuja tuloja ja anlogiatuloja osoittautui haastavaksi:
https://www.olimex.com/Products/Modules/IO/MOD-IO/open-source-hardware
Tälle en löytänyt kirjastoo, sen firmis löytyy ja sieltä löytyy MOD-IO(I2C-Slave)_v1.02.zip\API support files kaikenlaista sekä pari readmetä, mutta mä en osaa yhdistää pisteitä edes niin, että tietäsin mitä en tiedä.
Muistan, että joskus kirastot tuli C-sorsana ja ne piti kompilloida, mutta nuo kamat eivät näytä kovin tutulta. Enkä oikein keksi muuta, kun että pitäis kirjoittaa itse koodia, mutta ensin pitäis saada varmaan nuo zipin filet varmaan auki jollain, jotta vois käyttää käänteistä insinöörityötä ja tehdä oma kirjasto tai muuten komentaa tota?
Aargh. Olen niin tietämätön, että vaikuttaa helpommalta tehdä oma I/O yksinkertaisesti liuska/rasteri PC-levylle ja ohjata sitä Arduinon tavalla suoraan porteista. Mutta olisihan se ollut kivaa kokeilla totakin korttia.
PekkaNF
Encoderin lukuun löysin kirjaston joka toimii hyvin,
kuvassa 200 p/rev encoderi mutta tarkuus 800
kun sitä luetaan "qudrature"na.
Vieressä oleva "kortti" on Olimexin basic ohjemoitava
controleri ,vganäyttö ja pcnäppäimistö kiinni
ohjelman save:aus sd kortille jne...
(http://img_4412)
Joo toi Olimexin MOD-IO -laajennuskortti on mielenkiintoinen tapaus. Sehän ensinnäkin käyttää UEXT-liitintä jonka Olimexino on itse speksannut ja julkistanut. Sillä voi periaatteessa kytkeä laitteita käyttäen sarjaväylää, SPI:tä tai I2C:tä. Sitten siinä on kaikennäköistä I/O:ta - digitaalisia ja analogisia tuloja ja relelähtöjä. Itelläkin on niitä hyllyssä muutama kappale.
Laite on kuin sveitsiläinen linkkari - sillä voi tehdä mitä vaan.
Ikävää kumminkin, että tähän linkkariin joutuu melkein tekemään terät ensin itse. Se mukana tuleva koodi on kirjastofunktioita I/O:n käsittelyyn, mutta Arduinon kanssa kommunikointiin ei olekaan mitään muuta kuin tyhjä pääohjelma. Ja vaikka prosessori on sama ATMega328 kuin Arduinossa, tätä korttia ei sitten ohjelmoidakaan USB:llä Arduinon IDE:n avulla, koska USB.liitäntä ei ole, eikä varmaan Arduinon bootloaderiakaan. Hommaan tarvitaan siis perinteinen AVR-ohjelmankehitysympäristö kuten vaikkapa Atmel Studio, ja joku keino ladata binäärit kortille sillä olevien AVRISP- tai JTAG-liittimien kautta. Mulla nuo vehkeet on, mutta Arduinon kanssa niitä ei tule. No, Atmel Studio on toki ladattavissa ilmaiseksi Atmelin nettisaitilta mutta hardwaren joutuu hommaamaan kaupasta. Tosin vaikkapa AVRISP Mk II ei maksa kuin kolme-neljä kymppiä ja sillä hoituu useimmat ellei kaikki Atmelin prosessorit.
Mutta siis perushaaste MOD-IO:n kanssa on, että siihen joutuu itse toteuttamaan sovelluksen, ei se ole mikään valmis Arduinon I/O-laajennus. Toki se sitten toimii sellaisena, ja paljon enempänäkin kunhan sovellus on ensin sille koodattu. Ajatus on varmaan ollut, että sitä käytetään älykkäänä oheislaiteena joka ottaa I/O-laskennan kuormaa pois pääprosessorilta.
Itse olen tuota ajatellut käyttää osana kiinteistön porttien ohjausjärjestelmää, mutta sekin projekti pn vaiheessa. Jos kiinnostusta tuohon kapineeseen on, niin voin kyllä auttaa sen herättämisessä henkiin.
En muista enää onko ollut puhetta juuri tässä keskustelussa, mutta Atmel Studiolla voi siis hyvin ohjelmoida Arduinoja "kunnollisessa" IDE-ympäristössä. Studion laajennusosavalikosta vaan aktivoi Arduino-pluginin kunhan Arduno-IDE on ensin asennettu, että löytyy kirjastot. Sen jälkeen voi koodata ja ladata Arduinoja koskematta siihen kälyiseen Arduino.IDEen ollenkaan. Samalla on otettu puoli askelta kohti oikeaa sulautettujen koodausta. Sitä ei ole paljoa matkaa enää omien korttien kyhäämiseen. Se Arduinolla oleva Mega328 esim on hirmu helppo herättää henkiin; ei se tarvii juuri mitään ympärilleen. Niinkuin ei monet mutkaan modernit MCUt.
P.S. Muistin vähän väärin. MOD-IO:ssa on 8 MHz Mega16 joten se on hitaampi ja vähemmän muistia kuin arskassa, mutta muuten sama juttu.
Lainaus käyttäjältä: Kremmen - 23.02.14 - klo:21:29
Joo toi Olimexin MOD-IO -laajennuskortti on ....
Laite on kuin sveitsiläinen linkkari - sillä voi tehdä mitä vaan.
Ikävää kumminkin, että tähän linkkariin joutuu melkein tekemään terät ensin itse. ...
Heheh....kävin kerran puukon taontakurssin, joten hyvä alku
.
Lainaus käyttäjältä: Kremmen - 23.02.14 - klo:21:29
En muista enää onko ollut puhetta juuri tässä keskustelussa, mutta Atmel Studiolla voi siis hyvin ohjelmoida Arduinoja "kunnollisessa" IDE-ympäristössä. Studion laajennusosavalikosta vaan aktivoi Arduino-pluginin kunhan Arduno-IDE on ensin asennettu, että löytyy kirjastot. Sen jälkeen voi koodata ja ladata Arduinoja koskematta siihen kälyiseen Arduino.IDEen ollenkaan. Samalla on otettu puoli askelta kohti oikeaa sulautettujen koodausta. Sitä ei ole paljoa matkaa enää omien korttien kyhäämiseen. Se Arduinolla oleva Mega328 esim on hirmu helppo herättää henkiin; ei se tarvii juuri mitään ympärilleen. Niinkuin ei monet mutkaan modernit MCUt.
On harkinnassa, kunhan nyt ensin pääsee alkuun. Mukavampaa jos useempi aloittais samaan aikaan pohjalta, niin olis usemapi prsastelija, eikä oma tyhmyys tunnu niin suunnattomalta.
PekkaNF
Lainaus käyttäjältä: PekkaNF - 23.02.14 - klo:23:05
Heheh....kävin kerran puukon taontakurssin, joten hyvä alku
.
On harkinnassa, kunhan nyt ensin pääsee alkuun. Mukavampaa jos useempi aloittais samaan aikaan pohjalta, niin olis usemapi prsastelija, eikä oma tyhmyys tunnu niin suunnattomalta.
PekkaNF
Ei meistä kukaan tainnut syntyä näppäimistö edellä, niin että alusta on jokainen aloittanut, kuka enempi, kuka vähempi aikaa sitten. Se, ettei tiedä jotain ei ole tyhmyyttä ja korjautuu kyllä helposti kun vaan opettelee.
Alkuun pääsee minusta parhaiten kun valkkaa jonkun realistisen mutta pikkasen haastavan projektin ja lähtee sitä ratkomaan. Juuri viikonloppuna esim. jelppasin yhdellä toisella foorumilla kaveria ohjelmoimaan Arduino nano-pohjaisen pakokaasulämpömittarin. Kaveri oli itse suunnitellut siihen raudan jossa vähän konsultoin, ja sitten opastin häntä sen koodauksessa. Eipä sihenkään projektiin paljoa Arduinoa tullut, mitä nyt pari digitalWrite-komentoa. Enempi se oli laskentaa, suoraa rekisterinkäsitelyä ja keskeytysten ohjelmointia.
Jos sulla on mielessä joku projekti niin voin kyllä autella vaikeimpien kivikoiden yli, ja muutenkin.
Lainaus käyttäjältä: Kremmen - 23.02.14 - klo:21:29
Joo toi Olimexin MOD-IO -laajennuskortti on mielenkiintoinen tapaus. ...
Kysyvä ei tieltä eksy?
https://www.olimex.com/forum/index.php?topic=2778.0
Yritin kokeilla vastauksen #2 ohjelmaa, vastauksesta #9 saadulla kirjastolla. Kolmen tunnin taistelun jälkeen en saa järkee kirjastoon. Ne vaikuttaa arduinon oppaan mukaan muodollisesti oikeilta, mutta ei toimi.
Tämä:
#include <Wire.h>
#include <MOD_IO.h>
#include <delay.h>
// Control MOD-IO at address 0x2C
MOD_IO modio();
Tuottaa tämän:
MOD_IO_test1.ino: In function 'void setup()':
MOD_IO_test1:10: error: request for member 'begin' in 'modio', which is of non-class type 'MOD_IO ()()'
Joten kirjastossa on muodollisesti jotain väärin. 7-bitin ascii (ANSI), ongelma jossain CR/LF? Vai kopioitu väärin. Kokeilin notepädiä ja notepäd++ tägääys sulkeutuu ja kaikkee....
Kaikenlisäksi windows oli asennellut uudet ajurit, joten vaati tunnin taistelua, ennenkun Arduinon IDE suostu toimimaan (USB-ajuri ja Java......).
PekkaNF
No ei ollut iso vika.
Älä kirjoita
#include <MOD_IO.h>
vaan
#include "MOD_IO.h"
Yksi C-kielen "ihanuuksista" joka ampuu kokematonta/varomatonta nilkkaan. Nuolisulut ja lainausmerkit erottavat mistä kirjastoa haetaan. Nuolisuluilla käännösympäristön vakiopoluista, lainausmerkeillä ensin paikallisesta hakemistosta.
Tuolla muutoksella kääntyy virheettömästi. Minulla siis MOD_IO.h ja MOD_IO.cpp samassa hakemistossa kuin sketsitiedosto.
Kiitos
Eipä todellakaan tullut heti mieleen...nyt pääsin riville 8 asti, nitkahtaa tähän:
modio.begin();
#include <Wire.h>
#include "MOD_IO.h"
#include <delay.h>
// Control MOD-IO at address 0x2C
MOD_IO modio();
void setup () {
Serial.begin(9600);
modio.begin();
}
ja virheilmoitus on:
MOD_IO_test2.ino: In function 'void setup()':
MOD_IO_test2:10: error: request for member 'begin' in 'modio', which is of non-class type 'MOD_IO ()()'
MOD_IO_test2.ino: In function 'void loop()':
MOD_IO_test2:20: error: request for member 'setRelay' in 'modio', which is of non-class type ......
mä olin ennen aika hyvä tulkkaamaan noita ....tein paljon virheitä, joten virheilmoitusten logiikka kävi tutuksi.
Kokeilin myös siirtää "sketch-hakemistoon" kaikki noi samaan hakemistoon. Sama tulos.
Huomenna tutkin lisää...
PekkaNF
Hehe... selvishän se eli osoitteeksi MOD_IO modio(0x58); ja kortti lähti lukemaan tuloja ja vaihtamaan lähtöjen tilaa.
Edistys kehittyy....
PekkaNF