Arduino

[PekkaNF]

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

[PekkaNF]

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.

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).

Koodi [Valitse] Laajenna

#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.

.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.

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

[jyrki.j.koivisto]

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>)

[Kremmen]

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.

[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)

.....
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.

[jyrki.j.koivisto]

Tuosta 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.

[Kremmen]

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:

Koodi [Valitse] Laajenna

#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):

Koodi [Valitse] Laajenna


/* 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...

[PekkaNF]

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

[Kremmen]

[...]
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.

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ä.

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ä :)

Kiitos avusta ja rohkaisusta.

PekkaNF

De nada. Palataan asiaan kun asia etenee.

[PekkaNF]

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.

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ä.

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/. Tuolla on vielä joku vähän vanhempi avr-gcc tutoriaali: 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.

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.

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ä.

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

[Kremmen]

[...]

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.
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.

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 :)

[lekonna]

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.

[Kremmen]

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.

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.

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.

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.

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.

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. 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

[Kremmen]

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ä.

[PekkaNF]

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