Ilokseni huomasin että raspillekkin saa oikean javan.
Minulla on pieni java ohjelma joka ohjaa/lukee usb:n kautta arduinoon liitettyä askelmoottoria ja mittalaitetta, ja piirtää niiden tietojen mukaan taulukon. Ohjelma lähettää askelmoottorille askel käskyn ja pyytää sen jälkeen mitta-arvon, askelkäskyjä ja mitta-arvoja on yhteensä 1440kpl/taulukko joka melko hidasta.
Olisikohan tämä mahdollista toteuttaa nopeampana raspilla jolloin usb väylä jäisi pois välistä?
Minulla on pieni java ohjelma joka ohjaa/lukee usb:n kautta arduinoon liitettyä askelmoottoria ja mittalaitetta, ja piirtää niiden tietojen mukaan taulukon. Ohjelma lähettää askelmoottorille askel käskyn ja pyytää sen jälkeen mitta-arvon, askelkäskyjä ja mitta-arvoja on yhteensä 1440kpl/taulukko joka melko hidasta.
Olisikohan tämä mahdollista toteuttaa nopeampana raspilla jolloin usb väylä jäisi pois välistä?
Vastaukset 9
Vanhimmat
Jotenkin minusta tuntuu, että ei se USB tuollaisessa mikään pullonkaula ole. Tosin en ole varma ymmärsinkö projektiasi ihan oikein.
Mutta jos mahdollista suinkin, jätä ihmeessä Arduino väliiin. Jos jotain menee pieleen, on kivampi paskoa parin euron Arduino, kuin Viiden kympin Raspberry.
Sarjaliitäntä noiden välillä on todella simppeli
https://oscarliang.com/raspberry-pi-and-arduino-connected-serial-gpio/
Tuntuu jotenkin hölmöltä tuo ratkaisusi. Miksi arduino ei voisi suoraan ohjata askelmoottoria. PC antaisi koodinaatin ja arduino lukee paikka_anturia ja tekee tarpeellisen korjauksen. Mutta jos askelmoottorijärjestelmä on oikein mitoitettu ei askelia huku.
Vastaus kysymykseen riippuu hyvin paljon siitä, mihin tuo aika prosessissa kuluu.
Kuinka paljon aikaa kuluu kaikkiaan tuon taulukon läpi ajamiseen?
Kuinka suuri osa ajasta kuluu mittaamiseen ja stepperin ohjaamiseen?
Kuinka suuri on siirretyn tiedon määrä ja millainen tiedonsiirtonopeus? Ilmeisesti käytät virtuaalista sarjaporttia.
Siirrätkö vain sen datan mikä on pakko siirtää vai lähetätkö kaiken tekstimuodoisena?
Vaatiiko datan käsittely paljon liukulukulaskentaa vai miksi et tee sitä Arduinossa?
Ainoa syy, minkä keksin todellisuudessa puoltavan raspia on energiankulutus: Se kun taitaa pärjätä n. 12W:lla muuntajasta päätellen. Arduino ei paljoa päristele menemään, mutta PC voi napata helposti 300W monitorin kanssa. Eli jos järjestelmä on 24/7 tyyppinen, vuoden päälläolossa voi säästää jo satasia! Toisaalta Arduino SD-muistikortti on myös havaittu toimivaksi yhdistelmäksi data-loggeri käytössä. Kaikki riippuu mitä tarviit: 8 bittisellä on hankalaa käsitellä 16 bittistä dataa ja homma menee vielä helposti liian hitaaksi, jos bittiluku kasvaa vaikka 32:een.
Toisaalta tuollainen dataloggeri raspilla toteutettuna avaa uusia mahdollisuuksia: Siihen saa vaikka ethernet-liittymän, jos tarvitsee siirtää dataa paljon. Datan saa halutessaan kiintolevylle. Lisäksi on ihan mukavasti tehoa rouskuttaa dataa oikeaan muotoon jo valmiiksi mittauksen yhteydessä, esim. erillaisia kohinasuodatuksia voi ajaa jo valmiiksi, kuten myös keskiarvoistamista jolloin siirrettävän datan määrää saattaa voida pudottaa paljonkin.
Raspilla on mittausten kannalta kuitenkin sama ongelma kuin PC:lläkin eli käyttöjärjestelmä. Toisaalta se voi olla hyötykin.
Arduinon defaulttikielessä on 32-bittinen long -lukutyyppi valmiina, joten vaikeaa homma ei ole. Hitaudesta ei tiedä, kun lkupäeräinen kysyjä ei ole kertonut kunnolla taustoja sovelluksestaan.
No se on tietysti kielen ominaisuus, rekisteritasolla taitaa manipulointi olla pääasiassa 8-bittistä avr:llä.
Homma menee siis eräällä tapaa prosessorin kannalta allekkain laskuksi ja rekisterien yhdistelemiseksi carry-bitin kautta. AVR:llä yhteenlasku vie yhden kellojakson ja kertolasku kaksi ja molempia tarvitaan lopputuloksen saamiseksi. Siispä jos aikoo kertoa kaksi 32 bittistä lukua keskenään, menee se prosessorin kannalta "ohjelmallisesti", vaikka default-kieli sitä tukisikin yksinkertaisella "a * b" lausekkeella. Tätä se RISC-arkkitehtuuri teettää. Verrattuna 8-bit tilanteeseen yhden asm-käskyn sijasta prosessori joutuu siis huhkimaan alirutiinissa aika pitkään. Ja raspissa tuo käsky sitten löytyy, eli 32bit x 32bit => 64bit vastaus. Eron huomaa siinä, että avr:ssä kellotaajuus on matala 12MHz luokkaa ja tuo vie kellojaksoja aivan hurjana ja taas arm:ssa ollaan tyypillisesti 700MHz yläpuolella ja käytetään booth-algoritmia ja laskennan keskeytystä(early termination), jolloin maksimissaan kellojaksoja kuluu 32 1. Uudemmissa versioissa sitäkin on paranneltu.
Löysin tämän, mikä selittää ongelman luonnetta paremmin avr:llä:
https://mekonik.wordpress.com/2009/03/18/arduino-avr-gcc-multiplication/
Eli ohje: Vältä avr:llä kaikkea mikä ei ole 8-bittistä niin paljon kuin voit!
Nyt ei ole kerrottu mitä tuo tarkemmin tekee ja mikä on haluttu nopeus? Tietysti 32 bittinen on nopeampi 32 bittisten numeroiden käsittelyssä, mutta kyllä AVR:lläkin tekee todella paljon.
Itse olen tehnyt AVR:llä mittauslaitteen, joka mittaa yhdeksää eri suuretta 50 kertaa sekunnissa. Kellotaajuutena käytän vain 4 MHz (ko. AVR pystyy 32 MHz). Kaikki suureet ovat 32 bittisiä liukuluja ja niille tehdään kerto ja jakolaskuja sekä trigonemetrisiä funktiota ennen datan lähettämistä sarjaliikenteellä tietokoneelle.
Ennen minäkin luulin, että AVR on niin hidas, että pitää ehdottomasti välttää liukulukuja ja yrittää tehdä kaikki mahdollisimman lyhyillä kokonaisluvuilla. Noin tein 2000-luvun alussa korkeusmittarin. Ohjelmointi oli työlästä, kun piti miettiä kokoajan vuotaako lyhyet kokonaisluvut yli laskutoimituksissa. Toimihan tuo hyvin, mutta nyt tekisin ehdottomasti liukuluvuilla.
Rasperissa on käyttis. Se tekee siitä paljon huonomman moneen asiaan kuin 8 bittisestä AVR:stä.
Raspiin saa toimimaan ilman perinteistä käyttistäkin
http://wiki.freepascal.org/Ultibo_core/fi
Jos Arduinon nopeus tuntuu loppuvan kesken mutta tykkää ratkaisun yksinkertaisuudesta niin vaihtoehtona voisi olla Adruino Due. Siinä samainen ohjelmointiympäristö ja liitännät toimivat 32 bittisen ARM Cortex-M3 prosessorin AT91SAM3X8E avulla kellotaajuuden ollessa 84 MHz. Kertolaskujen tekeminen tapahtunee hieman nopeammin.