Lainaus käyttäjältä: Jonne - 02.01.10 - klo:18:35
Jos kellään ei ole mitään vastaan, voitaisiin käyttää tuota levyä, hinta ei minusta ole yhtään paha. Lopullinen versio sitten ihan omalle levylle, ylimääräiset pois.

Kuulemma nuo Mikroelektronican kääntäjät ovat hiukan bugisia, ainakin BASIC, mutta eiköhän niillä selviä. Ja kaipa tuon kanssa voi käyttää mitä kääntäjää haluaa.

Mikroelektronican BASIC-kääntäjä mahdollistaa ihanan  :P : konekielen sotkemisen BASICin sekaan. BASIC olisi monelle, kuten myös minulle, huomattavasti selkokielisempää kuin C++, jolloin muutkin tajuaisivat koodin toiminnan kuin C-kielen hallitsevat. Eiköhän tuossa MEGAssa ole sen verran voimaa, jotta sen voi tehdä kökömmilläkin kielillä, encoderien luku ja muut tiukat paikat konekielellä.

Täältä voi tsekata ominaisuuksia:

http://www.mikroe.com/en/compilers/mikrobasic/avr/

Mutta jos yleisesti ollaan sitä mieltä, että se pitää tehdä C:llä, niin ei minulla sitä vastaankaan ole mitään.

Kortti käy kyllä noin periaatteessa mutta kannattaa huomata, että nuo kaikki näyttivät olevan atmega128 ei atXmega128. Yhden X:n ero on tässä aika iso... Luulenpa että onnistuu kyllä mega128:llakin, joskaan niitä Xmegan erityispiirteitä ei sitten pysty soveltamaan.
Jos ram pystyy meille kortit tekemään niin pitäiskö kuitenkin miettiä tuota vielä. Protolautoina nuo kortit ovat hyvinkin kiinnostavia, mutta tähän ohjaimeen niissä on toisaalta aika paljon tarpeetonta ja toisaalta vähän puutteita. Liikahan ei sinänsä haittaa kun ei nuo ole hinnalla varsinaisesti pilattu. Tuota sinun toivomaasi käyttöliittymää ei tuohon taida kyllä saada kun siinä ei noita kiertovalitsimia ole. Mahtoiko olla yhtään kappaletta?

Siitten sorry vaan jos olen taas kovin negatiivinen, mutta mä olen sen verran jotain... omasta mielestä ammattilainen, muiden mielestä varmaan vaan pösilö, että en rupea enää tässä iässä työstämään basicilla. Kun minusta se vaan ei ole C:n veroinen tällaisissa hommissa. Jonnekin kehuu ensin assembleria mutta menee sitten ehdottamaan basiccia, mitäs tästä nyt pitäisi ajatella  :P Tiedän kyllä, että basiccia näkee mutta mitä vetoa että missä sitä on käytetty on liki kaikki muutaman sadan koodirivin kyhäelmiä, ei sen isompia.
Minä olen jo sen verran vanha pieru, että kun on 80-luvulta asti koodattu sitä assya, PL/M:ää, C:tä, C++:aa ja loppuviimeksi jaavaa jotka kaikki on selkeästi sukulaisia niin ei pysty taipumaan enää muuhun. Jos basic on tiukka vaatimus niin sitten minä kiitän ja kumarran. Ellei, niin käviskö että ne jotka koodin kirjoittaa saa valita kielen  ;)?
Jonne olet siinä oikeassa, että koodin toiminta pitää tehdä selväksi. Se, että koodi dokumentoisi itsensä on kuitenkin niin huono periaate, että oikeasti pitää dokumentointi perustaa muuhun kuin siihen, että käytetty kieli on riittävän helppoa ymmärtää. Speksit, ainakin jonkinlaiset, pitää kirjoittaa ihan teksteinä, ja lähdekoodin dokumentoinnissa ilmainen Doxygen http://www.stack.nl/~dimitri/doxygen/ on hyvin yleisesti käytetty ja toimii fiksusti sekä linukassa että windowsilla. Ei vaan valitettavasti basicille.
Doxygenistä sanotaan sen helpin esittelyssä näin:

Introduction
Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D.

It can help you in three ways:

It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in ) from a set of documented source files. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly from the sources, which makes it much easier to keep the documentation consistent with the source code.
You can configure doxygen to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams, which are all generated automatically.
You can even `abuse' doxygen for creating normal documentation (as I did for this manual).

Hups ,nuo mun proto kortit oli ilman tota X:ää.

Jos jyrsimällä ei pääse riittävän pieniin väleihin niin pystyn tekemään esi proton
filmille ja syövyttämään vaikka kaksipuoleisena.

Tuolla tuo PCI_GT:jpg esim. huomaa tuo iso lutikka tinattu onnistuneesti.
http://www.cnc-tekniikka.com/CNC-forum1/index.php?topic=304.15

Lainaa

Painettaessa jotain nappia on isäntä ainakin hiukan hereillä ,mitä nyt tapahtu.
Ensin mietin että kytkinten asento voitaisiin lukea hetken kuluttua niiden muuttamisesta sisään,
mutta ei hyvä, se on silloin jonkin asteen automaatti.

Juu, ja kiertokytkimet voisi lukea aina yksi kerrallaan, sitten tarvitaa vain neljä inputtia ja jokaiselle kytkimelle oma output.

Lainaa
Jonnekin kehuu ensin assembleria mutta menee sitten ehdottamaan basiccia, mitäs tästä nyt pitäisi ajatella  :P

No varmaan sitä, että BASIC on selvätajuisin vaihtoehto. Assemblerkin on helppotajuisempaa kuin C... Konekielen viehätys onkin juurikin siinä yksinkertaisuudessa ja helppotajuisuudessa.

Lisäksi nykyiset BASICit ovat tehokkaita ja jokainen kotikutoinen ohjelmoija (kuten allekirjoittanut) sitä osaa. Itse kyllä opettelisin mieluusti C:n, jos olisi ylimääräistä aikaa, mutta nykyisin se on kortilla. Tietysti nythän olisi tilaisuus opetella....

Eli omasta puolestani sen saa koodata vaikka FORTRANilla, jos tarpeeksi löytyy kiinnostuneita. Tietysti yksi vaihtoehto olisi Coridium ARM, johon löytyy BASIC-käännin, muistaakseni paukutti miljoona riviä sekunnissa BASIC-koodia, ja on ohjelmoitavissa normaalin nettiselaimella ja ethernetin kautta. Protolevy maksaa jotain 50$. I/O:ta ei kamalasti ole, mutta luultavasti tähän lystiin riittävästi... Yritän kaivaa nettisivun esiin Googlella...

Lainaa
Tuota sinun toivomaasi käyttöliittymää ei tuohon taida kyllä saada kun siinä ei noita kiertovalitsimia ole. Mahtoiko olla yhtään kappaletta?

Eipä tainnut olla, mutta siinähän on I/O-portit. DIPeillä voi simuloida kiertokytkimien asentoja, jos ei raaski ostaa.

Sehän löytyikin nopeasti, 60Mhz ARM7, BASIC-kääntäjällä:

http://www.coridiumcorp.com/index.php

Itselläni on yksi tuossa jemmassa, mutta ei ole juuri tullut testailtua... Pitääkin kokeilla lähiaikoina...


Muokattu:

Ilmoitinkin väärin tuon nopeuden: Coridium pystyy suorittamaan 10 miljoonaa riviä (!!!) BASICiä sekunnissa ja yhteen miljoonaan I/O-suoritukseen sekunnissa. Ja kuka väitti ettei BASICit ole nopeita...

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:21:51
Sehän löytyikin nopeasti, 60Mhz ARM7, BASIC-kääntäjällä:

http://www.coridiumcorp.com/index.php

Itselläni on yksi tuossa jemmassa, mutta ei ole juuri tullut testailtua... Pitääkin kokeilla lähiaikoina...

No juu, onhan ARMit ihan tehokkaita laitteita. Tällaisessa sovelluksessa ei vaan oikein pääse hyötymään 32-bittisyydestä kun se aritmetiikka nyt ei lopulta ole niin hirveän haasteellista (joissain paikoissa 32 bittiä ja enemmänkin on kyllä tarpeen). Noin periaatteessa turhan leveä arkkitehtuuri tekee ne paljon yleisemmät bittioperaatiot vaan raskaammiksi, vaikka ei tuolla oikeasti varmaan mitään merkitystä ole. Prosessorin vääntö kyllä peittää sen. Onhan Atmelillakin toki vastaavia AVR32-tuoteperheessä mutta taitavat tehdä toteutuksesta työläämmän tuomatta paljoakaan vastapainoksi. Mutta jos kiinnostaa aidoasti sairas vääntö niin otetaan Atmelilta DIOPSIS 940HF moniydinkontrolleri. Vaikka koko verstaan koneiden cnc saadaan laskettua sen signaaliprosessorilla, siitä kun lähtee miljardi liukulukuoperaatiota sekunnissa   ::)

Käytä vaan tilaisuus hyväksi ja opettele C. Eläin ei siihen pysty mutta ihminen kyllä. Ja melkein veikkaan ettei sen jälkeen paluuta basicciin enää ole...

juhannusruusu, kai tässä pitää taipua nykykehityksen alla  ;)

Milloin pystyisit tekemään alustavan C-koodin pohjan kommentoituna (mieluiten siten, että jokainen "VOID" sun muu on selitettynä, miten toimii mikin ja miksi), tässä saataisiin sitten pikakurssi C-kieleen koko porukka. Lisäksi jos saa esittää tyhmiä kysymyksiä C-kielestä projektin aikana, voisin luulla että tuon voisi oppiakin. Kuitenkin, kielihän se vain on muiden joukossa, eikä taida moderneista BASICeistä juuri erota? Mitä joskus C:tä opiskelin (ennen turhautumista), siitä tuli jollain tapaa mieleen konekieli, bittirullausta ja sen sellaista...

Mutta: mitä C(++)-käännintä käytettäisiin? Itseäsi kiinnostaa tuo Mikroelektronikan kääntimet, vaikuttavat erittäin monipuolisilta ja "helpoilta", ilman turhaa jargonia, ohjelmointilaitteita tai muuta skeidaa. Lisäksi saman talon kehityslevy kiinnostaisi jo tulevia projekteja ajatellen. Huomasitko muuten sen firman sivuilta, että siellä on tuota kehityslevyä vaihdettavilla mikrokontrollereilla, joten samaa levyä voi käyttää useamman eri valmistajan kontrollereihin?

Juu... C:tä mielellään opiskelisi. Aika on vaan aina kortilla. C-ohjelmia olen kyllä kirjotellut, kun siirryin Linuxin käyttöön ja siinähän on kaikki kivat editorit ja kääntäjät helposti ulottuvilla. Sillä GCC kääntäjällä tekee koodin kai vaikka PICeille ja atmelleille... kuulemma... ja kai vissiin vaikka millä kielellä... En ole ehtinyt enempää hämmästelemään.

Oppimateriaalejakin tuli haalittua ja olen niitä lueskellut, mutta ei se pelkkä lukeminen riitä. Mihin kaikki aika häviää ??

Eräässä VTT-projektissa jututin heidän ohjelmointigurujaan ja he sanoivat nykyisten C-kääntäjien tuotoksen pärjäävän kirkkaasti assembler-gurujen koodille. Ovat kuulemma sen verran jo hiottuja työkaluja.

Sama vika rahikaisella, että näin rautakeskeisenä miehenä tuo assembleri on jotenkin luonnollista. Kaikki korkeamman tason kielet kun muuttuu abstrakteiksi.

Nimim.. Esittävän taiteen ystävä

Lainaus käyttäjältä: Jonne - 02.01.10 - klo:23:32

Milloin pystyisit tekemään alustavan C-koodin pohjan kommentoituna (mieluiten siten, että jokainen "VOID" sun muu on selitettynä, miten toimii mikin ja miksi), tässä saataisiin sitten pikakurssi C-kieleen koko porukka. Lisäksi jos saa esittää tyhmiä kysymyksiä C-kielestä projektin aikana, voisin luulla että tuon voisi oppiakin. Kuitenkin, kielihän se vain on muiden joukossa, eikä taida moderneista BASICeistä juuri erota? Mitä joskus C:tä opiskelin (ennen turhautumista), siitä tuli jollain tapaa mieleen konekieli, bittirullausta ja sen sellaista...

Varmaan voisi aloittaa silleen, että kasataan ensin porukalla läpikäyden karkealla tasolla toiminnalliset kokonaisuudet omiksi lohkoikseen ja hahmotetaan niiden toiminnallisuus koodin rakenteeksi. Tässä vaiheessa ei vielä edes tarvita varsinaista leipäkoodia vaan voidaan mennä pitkälti modulien rajapintojen esittelyn tasolla. Tämä  siis tapahtuu jo C-kielellä mutta ei vielä kanneta huolta varsinaisesta koodista vaan rakennetaan ensin kunnollinen toimiva "rautalankamalli". Tässä vaiheessa on hyvä järkeillä joukolla läpi koodin toiminta-ajatus ja  dokumentoida se sisään noihin lähdekoodimoduleihin vaikka sitä Doxygeniä käyttäen (ei ole vaikeeta). Siinähän tulee tutuksi samalla sekä koodin ajateltu toiminta että C:n muotokieli. Voisin saada viikon-parin sisään aika uskottavan rungon aikaan. Tässä tietysti tulee jossain vaiheessa se hetki että pitää siirtyä konkretiaan eli on pakko tietää mikä prosessori ja millaiset oheiskomponentit on käytettävissä. Aivan alussa on ehkä parempikin hahmottaa ilman niitä muutta maaliin päästään vasta kun nuo on tiedossa.
Kysymyksiä varmaan joudutaan esittämään kaikki, eikä vain ohjelmointikielistä. Ja onhan täällä muitakin C-taitoisia että vastaukset sille puolelle löydetään kyllä. Mielelläni autan C:n omituisuuksien ymmärtämisessä, vaikka ei me varmaan pyritä kaikkein kummallisimpia rakenteita tähän toteutukseen pesiyttämään. Kuten totesit se on vain kieli muiden joukossa. (Tähän kohtaan pitää muistaa mainita sellainen viisaus, että oikea vanhan liiton koodari pystyy kyllä ohjelmoimaan Fortrania millä tahansa ohjelmointikielellä  ;D).

Lainaa
Mutta: mitä C(++)-käännintä käytettäisiin? Itseäsi kiinnostaa tuo Mikroelektronikan kääntimet, vaikuttavat erittäin monipuolisilta ja "helpoilta", ilman turhaa jargonia, ohjelmointilaitteita tai muuta skeidaa. Lisäksi saman talon kehityslevy kiinnostaisi jo tulevia projekteja ajatellen. Huomasitko muuten sen firman sivuilta, että siellä on tuota kehityslevyä vaihdettavilla mikrokontrollereilla, joten samaa levyä voi käyttää useamman eri valmistajan kontrollereihin?

Sellainen onnellinen tilanne, että voi käyttää vaikka useita eri kääntäjiä. C on kielenä kohtuullisen hyvin standardoitu joten eri kääntäjät tuottavat samasta sorsakoodista samoin toimivaa binääriä. Mikroelektronikan kääntyrit on varmaan ihan kelpoja, mutta ne penteleet maksavat, jotain 250 taalaa. Atmelilla on tämä ilmainen AVR Studio IDE joka käyttää WinAVR-koodigeneraattoria (eli siis AVR_GCC). GNU C++ joka tuossa siis on sisällä on varmasti yksi tehokkaimpia koodigeniksiä mitä löytyy enkä yhtään yllättyisi vaikka Mikroelektronika käyttäisi taustalla sitä myös. AVR Studio on todella helppokäyttöinen ja ilmaisena sen voi ottaa muitta mutkitta käyttöön kaikille jotka haluavat koodaukseen jollain tavalla osallistua. AVR Studio tukee suoraan koodin latausta kohdejärjestelmään käyttäen esim JTAG-liitäntää. Tuollainen noissa Mikoelektronikan laudoissa näytti olevan joten se puoli on kunnossa. JTAGhan on valmistajariippumaton teollisuusstandardi joten varmaan pelittää.
Melkein kääntäjää tärkeämpi kysymys on mitä ajonaikaista kirjastoa käytetään. Kielihän on vasta puoli ratkaisua, kirjastofunktiot ratkaisevat sen toisen puolen. Jos olemme tekemässä tästä edes jollain tasolla avoimen lähdekoodin projektia niin silloin tämä kysymys kannattaa ottaa aika vakavasti. Yhden valmistajan oma tekijänoikeuksin suljettu kirjasto tuntuisi vaaralliselta valinnalta koska silloin ei ole takeita sen käytettävyydestä tai kustannuksista. Ajonaikaisen kirjaston on oltava sama kautta linjan, muuten homma karkaa kädestä heti lähdössä.
Mitenkään epäilemättä Mikroelektronikan tuotteiden kelvollisuutta, ehdotan kuitenkin yllämainituista syistä että valittaisi kääntäjäksi AVR_GCC ja kirjastoksi avr-libc http://www.nongnu.org/avr-libc/user-manual/index.html. Nuo ovat vapaasti saatavissa ja käytettävissä, niissä on ei-kaupallinen kehittäjätaho takana ja ne ovat erittäin laajalti käytössä, joten ei ole pelkoa niiden katoamisesta yhtäkkiä. Jokainen koodaukseen osallistuva voi sitten valita itselleen sopivan IDE:n jos tuo AVR Studio ei tunnu istuvan käteen. Esim äärettömän suosittuun Eclipse IDEen saa AVR pluginin jolloin voi koodailla käyttäen Eclipseä. http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin. Jaava-koodareistahan Eclipseä käyttää ainakin kaikki ellei jopa useampikin.  :P

Tässä pikaohje miten saat heti toimivan koodausympäristön käyttäen WinAVR + AVR Studio -paketteja:

- Hae ensin WinAVR-kääntäjä täältä http://sourceforge.net/projects/winavr/files/ - klikkaa vihreää Download now-nappia. Käynnistä asennus kun paketti on koneella. Asennus puhuu jopa suomea jos niin haluaa, mutta eipä ole isompaa tarvetta. Antaa vaan mennä läpi ehdotetuilla asetuksilla niin asentaja tekee kaiken tarvittavan käsin koskematta. Asennus avaa lopuksi selaimeen käyttäjän manuaalin (lontooksi) jota voi ihmetellä, mutta ei se tässä vaiheessa ole enempää tarpeen.
- Hae Atmelilta AVR Studio täältä http://www.atmel.com/forms/software_download.asp?fn=dl_AvrStudio4Setup.exe. Vaatii rekisteröitymistietojen antamisen mutta ei sen kummempaa. Sen jälkeen latauksen voi käynnistää sivulla joka tulee näkyviin. Lataustiedosto on aika miehekäs, 117 megaa joten siinä menee hetki. Toisaalta sitten saa kyllä studion helpissä tosi kattavan ohjeistuksen Atmelin kehitystyökaluihin. Asenna paketti taas oletusarvoilla niin asentaja hoitaa hommat toimivaan kuntoon ja löytää WinAVR-kääntäjän ilman apuja. Jos kysyy Jungo.driverin asennuksesta niin anna asentaa. Se on RS232/USB-ajuri muutamille erikseen hankittaville kehitysalustoille ja työkaluille, kuten debuggerit jne.

Kun käynnistät AVR Studion se kysyy haluatko avata olemassaolevan projektin vai luoda uuden. Alussa ei tietty ole entisiä olemassa joten uusi pitää luoda. Vaihtoehtona on C/C++ tai assembler-projekti :) Että sitäkin pääsee kyllä harjoittelemaan jos haluaa. Tässä vaiheessa pitää päättää missä hakemistossa projekti asuu ja mikä on sen käynnistystiedoston nimi. Kun nuo on valittu, saat tyhjän työtilan jossa pääohjelman tiedosto on valmiina muokattavaksi. Jos annoit nimeksi vaikka test niin pääohjelma asuu tiedostossa test.c

Perinteisesti kaikki C-ohjelmat käynnistyvät aina proseduurista jonka nimi on main, eli "pääproseduuri". C-kielinen esittely on perinteisesti:

void main(void); {
...
}

Void tarkoittaa, ettei kyseisessä kohdassa esiinny muuttujaa, eli main ei ota mitään parametreja eikä se palauta mitään. AVR Studio tuntuu kyllä tykkäävän enemmän esittelystä:

int main(void) {

jolloin main palauttaisi integer-tyyppisen muuttujan. Tällä ei ole oikeasti hevon väliä koska jos main ikinä menee loppuun eli muka palauttaisi jotain, koko sovelluksen ajo päättyy.
Mutta tämän nimine proseduuri siis on kirjoitettava ja siitä suoritus lähtee.

"Oikeat" s.o. varsinaisilla tietokoneilla ajettavat sovellukset voivat kyllä ottaa sisään komentoriviltä annettuja parametrejä eli komentoriviargumentteja, jolloin perinteinen esittely olisi

void main(int argc, char *argv[]) {

Ensimmäinen argumentti on integer-tyyppiä (prosessorin luontaisen pituinen kokonaisluku) ja sisältää komentoriville kirjotettujen erillisten sanojen lukumäärän. Sana on tässä mikä tahansa jono merkkejä jonka 1 tai useita välilyöntejä erottaa seuraavasta sanasta (merkkijonosta).
Toinen argumentti on osoitin kyseisten sanojen listaan. C-kielessähän stringi eli merkkijono esitetään puskurina jossa merkit peräkkäin ja viimeisenä heksanolla (C-tyyliin 0x00 eli null [tuo 0x tarkoittaa jäljessä tulevan numerovakion olevan heksadesimaalimuodossa]). Käytössä puskuriin viitataan sen osoitteella. Tuo konstruktio menee näin
char    = kirjaimia
       * = osoitin edellisen tyyppiseen muuttujaan
         argv = muuttujan nimi
                [] = arrayn eli jonomuuttujan esittely. Kun sulkujen välissä ei ole mitään, se tarkoittaa ettei jonon jäsenten lukumäärää tiedetä tässä vaiheessa (se on muuttujassa argc). Tästä syystä ajonaikainen kirjasto rakentaa muistiin himmelin, jossa jokainen merkkijono on peräkkäin (nullilla päätettynä) ja vielä viimeisen merkkijonon jälkeen on toinen null. Näppärä kaivaa tästä esiin kaikki käyttäjän kirjoittamat sanat ohjelman käyttöön.

No, kun olet saanut studion käyntiin niin toimivuuden voi kokeilla vaikka tämmöisellä typerällä koodinpätkällä (tämä ei siis tee mitään älykästä, kunhan työllistää koodigeneraattoria jotta nähdään kaiken toimivan).



/* typerä koodinpätkä joka ei saa mitään hyödyllistä aikaan */

int main(void) {  // perinteinen esittely

int i, x, y;       // esitellään kolme kokonaislukumuuttujaa nimeltä i, x ja y. C-kielessä muuttujat on aina esiteltävä etukäteen

   x = 0;   // nollataan ne (jotkin kääntäjät takaavat että muuttuja on nolla mutta ei kannata luottaa)
   y = 0;

   for (i=0; i<10; i++) {   // C-tyylinen silmukka laskurina i; aloitetaan nollasta, jos i alle 10 niin mennään silmukkaan, lopuksi kasvatetaan i:tä yhdellä (se on tuo i++)
      x = i;     // jotain aivottomia laskutoimituksia
      y += (x * i); // += on pikakirjoitusta ja sama kuin y = y + ...
   }    // silmukan lohko päättyy
}   // main lohko päättyy ja samalla koko suoritus

// oikeassa sovelluksessa main ei koskaan pääty, vaan ajetaan jonkinlaista ikuista silmukkaa.



Luento päättyy   ;)

Täältä kans ääni tuolle c- kielelle ja winavr:lle. varsin kiinnostava aihe jo pelkästään oppimis mielessä. laitanpa tuohon yhden vaihtoehdon. tuolle kun tekee emokortin voi käyttää muihinkin projekteihin.

http://www.olimex.com/dev/avr-hx128a1.html

Lainaus käyttäjältä: jussi - 03.01.10 - klo:02:59
laitanpa tuohon yhden vaihtoehdon. tuolle kun tekee emokortin voi käyttää muihinkin projekteihin.
http://www.olimex.com/dev/avr-hx128a1.html

Tuollainen helpottaa kovasti elämää jos meillä on haasteita saada jyrsimällä riittävän tiheää piirikorttia aikaan. Vähänhän tuo maksaa mutta onneksi varsin vähän kun siinä on jo prosessorikin mukana. Ja tuon 32 kHz kiteen avulla siihen saisi vielä rakennettua oikean verstaskellonkin. Lähtisi isäntäkin kahville ajallaan :)

... jatkuu
Debuggauksesta AVR Studiolla:

Jos kuka pisti tuon koodinpätkän Studioon, niin tässä ohjeita perustason simulointiin ja debuggaukseen. Aloita siten, että projekti on auki studiossa.
Ellet jo tehnyt sitä, valitaan mille prosessorille koodi generoidaan ja millä optioilla. Avaa studion päävalikosta kohta Project - Configuration options. Projektin optioikkuna aukeaa. Jos nimesit projektin "test" niin Output File Name on test.elf ja siihen ei tarvitse koskea. Valinta Device määrää mikä prosessori. Valitse joku, minulla on kehityslaudassa kiinni atmega32 joten ota vaikka se niin ohjeet pätee tarkasti. Ainoa muu mistä välitetään tällä hetkellä on kohta Optimization. Tällä määrätään mitä koodinoptimointeja kääntäjä saa käyttää. Debuggaus kaikki optimointi päällä on toivotonta koska kääntäjä säätää niin hirveästi, ettei lopputulos ole lähdekoodista jäljitettävissä kovin hyvin. Valitaan siis vaihtoehto -O0 (ei optimoida). Kuittaa OK-napista ikkuna pois.

Käännetään koodi. Päävalikosta Build - rebuild all. Käsketään kääntäjän työstää koko projekti. Käännös lähtee ja työtilan alakehyksessä pitäisi kohta näkyä tällaista:

Build started 3.1.2010 at 11:13:04
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99 -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT test.o -MF dep/test.o.d  -c  ../test.c
avr-gcc -mmcu=atmega32 -Wl,-Map=test.map test.o     -o test.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  test.elf test.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex test.elf test.eep || exit 0
avr-objdump -h -S test.elf > test.lss

AVR Memory Usage
----------------
Device: atmega32

Program:     226 bytes (0.7% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)


Build succeeded with 0 Warnings...

Aina pitää pyrkiä siihen, ettei kääntäjä anna yhtään varoitustakaan. Jos koodissa on suoranaisia virheitä, ei binääriä ole edes tuotettu joten koodi ei ole käytettävää. Varoitukset eivät estä koodin käyttöä joten sen voi harkiten viedä eteenpäin. Jokainen varoitus tulee kuitenkin joko hieroa pois tai sen syy tarkkaan ymmärtää jotta tietää onko se vahingollinen vai ei. Useimmat varoitukset ovat aiheellisia. No, tässä niitä ei tietenkään tullut kun tämä on näin yksinkertainen pätkä. Mega 32:lle näköjään generoitui 226 tavua koodia joka nielaisi 0,7% koodimuistin määrästä. Tässä on sitten mukana kaikki aloituskoodi eli nuo ohjelman muutama koodirivi ovat vain murto-osa. Onneksi aloituskoodi ei kasva ohjelman koon kasvaessa.
Studion builderi kertoo mitä se on tehnyt ja tässä tapauksessa siinä ylempänä näkyy, että avr-gcc on käynnistetty kahdesti - ekalla kerralla tuottamaan test.c-tiedostosta objektitiedosto test.o ja toisella kertaa objektista muistikartta ja latauskelpoinen test.elf. Tästä on sitten väännetty vielä heksamuotoinen tiedosto test.hex jonka studio pystyy lataamaan esim JTAG-rajapinnan läpi kohdeprosessorille.
Ketä kiinnostaa niin projektihakemistoon on viimeistään nyt ilmestynyt alihakemisto "default" jossa nuo tulostiedsostot makoilevat. Tarkka muistikartta löytyy tiedostosta test.map ja sieltä näkee miten kääntyri on prosessorin muistia käyttänyt. Tottumattomalle tuo ei paljoa sano, mutta kun oppii ymmärtämään mitä mikin tarkoittaa, siitä näkyy lopullinen totuus.
Samoin tuolta löytyy tiedosto nimeltä Makefile. C-koodareille tämä on jokapäiväistä leipää. Komentorivikääntäjän käyttäjät joutuvat tutustumaan ohjelmaan nimeltä make jolla sovelluksen kääntäminen ja kasaus siinä ympäristössä ohjataan. Meillä on helpompaa kun Studio generoi makefileet automaattisesti sen mukaan mitä me olemme ottaneet mukaan projektiin.

No nyt on koodinpätkä käännetty ja pitäisi nähdä mitä se tekee. Meillä ei todennäköisesti ole mitään oikeaa rautaa kytkettynä studioon tällä hetkellä, joten simuloidaan. Studion valikosta auki valinta Debug ja aika alhaalta vielä Select Platform and Device. Debug platformiksi "AVR Simulator" ja prosessoriksi ATmega32 jollei se ollut jo valittu. Finish-napista kuittaus.
Aloitetaan debuggaus Debug - Start Debugging. Studio puhkuu hetken ja sitten pitäisi pääohjelman esittelyrivillä näkyä keltainen nuoli. Tuo on kontrollin kulkukohta ohjelmassa, joka on nyt pysähtyneenä odottamassa askelluslupaa. Askelletaan tämä simppeli ohjelma läpi rivi riviltä. Sitä ennen kuitenkin avataan muuttujien tarkkailuikkuna jotta nähdään mitä arvoja muuttujat saavat ohjelman edetessä. Sitä varten päävalikosta View - Watch ja meille aukeaa watch-ikkuna. Tuplaklikkaus name-sarakkeen ruutuun niin voit kirjoittaa tarkkailtavan muuttujan nimen siihen. Laita i, x ja y omille riveilleen. Älä välitä siitä, että Value-ruudussa lukee hälyyttävästi "invalid location". Ohjelman suoritus ei vaan tällä hetkellä vielä ole noiden muuttujien näkyvyysalueella. Tästä lisää myöhemmin. Siirrä watch-ikkuna johonkin niin, että näet lähdekoodin kunnolla. Stepataan yksi rivi. Joko valikosta Debug - Step Into tai helpommin funktionäppäin F11. Nyt kaikille muuttujille pitäisi ilmestyä arvo watch-ikkunaan koska olemme saapuneet niiden näkyvyysalueelle. Huomaa, että askellus ohitti rivin jolla muuttujat esitellään. Tämä rivi ei generoi koodia joten sitä ei ajon aikana voi "suorittaa". Eli nyt ollaan rivillä jossa lukee x = 0; Tätä riviä ei vielä ole suoritettu vaan se on seuraavana vuorossa. F11 ja nyt watch-ikkunassa näkyy, että x sai arvon 0 kuten tietty pitikin.
Steppailemalla F11 avulla ohjelma jatkaa kulkuaan ja veivaa tuon for-silmukan läpi päättyen lopulta kun pudotaan ulos main-proseduurista. Debug - Reset valmistaa simuloinnin uudelle kierrokselle.
Työtilan vasemmassa laidassa näkyy prosessori-ikkuna jossa yksityiskohtaiset tiedot keskusyksikön tilasta kullakin hetkellä. Oikealla taas I/Olaitteiden tilanne. Huomaa, että simuloinnissa voi esin porttien tilaa muuttaa käsin ja näin simuloida ulkoisia kytkimiä tms.

Debugatessa vähänkään isompaa koodimassaa, ei single steppaus koodin läpi oikein toimi. Se on kuin maalin kuivumista katselisi, eikä varsinkaan oikeaa rautaa debugatessa ajoitukset toimi oikein. Tätä varten on breakpointit eli katkopisteet. Tehdään sellainen: Debug - Stop Debugging jotta päästään ulos tilanteesta. Klikkaa kursori riville josa lukee x = i; ja valitse Debug - Toggle brakpoint tai helpommin F9 (toggle tarkoittaa, että breakpointin tila vaihtuu joka valinnalla; päälle-pois-päälle). Nyt riville ilmestyi punainen pallo aktiivisen breakpointin merkiksi. Debug - Start Debugging. Kun nuoli näkyy, Debug - Run tai F5. Nuoli hyppää samalle riville kuin pallo. Simulaattori ajoi koodia täyttä vauhtia kunnes tultiin katkoriville johon suoritus taukoaa. Nyt voit watch-ikkunasta todeta, että muuttujien arvot on samat kuin edellisellä simulointikerralla tultaessa tähän ekaa kertaa. Painele F5 niin huomaat arvojen hyppivän ylöspäin. Ohjelma kiertää silmukkaa ja pysähtyy joka kierroksella tähän breakpointtiin. Lopulta suoritus karkaa silmukasta ja putoaa ulos pääohjelmasta.
Vielä yksi hyvin tehokas breakpoint-tyyppi: data breakpoint. Kun bugit menevät hankaliksi, on joskus tosi arvokasta nähdä, missä muuttujaa on käsitelty. Tehdään yksinkertainen data breakpoint joka keskeyttää kun muuttuja x saa arvon 5. Data breakpointteja määriteltäessä studion pitää olla debug-tilassa jotta sillä on pääsy aktiiviseen muistikarttaan. Siis tarvittaessa Debug - Start Debugging. Ensin poistetaan kaikki mahdolliset vanhat breakpointit hämäämästä: Debug - Remove all breakpoints. Sitten: Debug - New Breakpoint > Data Breakpoint ja meille aukeaa data breakpoint-ikkuna.
Täytä seuraavasti:
Break when: Location is equal to a value
Location [...] napilla haetaan test.c / main / x ja kuitti OK
Value: 5
Muut saa olla. Nyt meillä on data breakpoint joka laukeaa missä vaan kun X:n arvona nähdään 5. Kuitti OK:lla ja ikkuna sulkeutuu. Nyt työtilan alareunassa näkyy "Breakpoints and tracepoints" -listalla juuri määrittelemämme breakpointti ja täppä ruudussa näyttää sen olevan aktiivinen (sen voi sillä täpällä kääntää pois päältä). Riuhtaistaan suoritus taas liikkeelle F5 ja nuoli stoppaa heti riville y += (x * i); Muistetaan että tämä on seuraavaksi suoritettava rivi, joten viimeinen jo suoritettu on se edellinen, eli x = i; Watch-ikkunasta nähdään x:n olevan 5 kuten pitikin ja tuo juuri suoritettu rivi siis on syyllinen. Data breakpoint on kova työkalu - kuten huomasit sitä määritellessä, ehtoja on vaikka kuinka.
Kaikki määritellyt breakpointit näkyvät työtilan alaosan listalla ja niitä voi kääntää päälle ja pois lennossa aina tarpeen mukaan. Studio muistaa breakpointit jopa istuntojen välillä kunnes niitä erikseen muutetaan.
... jatkuu ...

Joo  22 eksuu maksaa, ja sitä pohjana käyttäen olisi aika helppo edetä protorautaan. Lopullesesta levystähän tulee sitten aika hyvä kehitysalusta. Kaikki IO:t tietty siihen helposti käsille. Kyllähän siitä ihan varmasti joku koodaa myöskin servodriven yms.

No niin... näyttää innostuksenne asiaan jatkuvan kiitettävästi. Ja kun tuli kaksi myönteistä eikä yhtään kielteistä kannanottoa oman alueen perustamiseksi, niin tehdäänpä niin.  Foorumille olen perustanut uuden pääotsikon, johon tämä ketju siirtyy ihan kohta. (Katso liite). 

Siellä on myös (vähän niinkuin varalta) jo pari alakategoriaa, joita saa käyttää, jos on tarvetta erotella tästä yleisestä keskustelusta esimerkiksi vaihtoehtoisten ratkaisuehdotusten äänestyksiä. Itse asiassa suosittelenkin niiden tekemistä sinne, jotta sen tyyppiset jutut eivät rikkoisi varsinaista kehityskeskustelua. Ja projektin suuntautumispäätökset olisi myös helppo löytää.  Äänestyksiähän tänne saa perustaa kuka tahansa rekisteröitynyt, mutta parastahan olisi, jos yhteisymmärrys syntyisi keskustelussa.

Voitte tietenkin tehdä äänestyksen - jos haluatte - myös tämän homman projektipäälliköstä, jos juttu sellaista kaipaa ja haluatte asiasta äänestää.  Projektipäällikköhän on sellainen tyyppi, jonka tehtävänä on saada projektista ulos mahdollisimman hyvä lopputulos riippumatta siitä, että mikä on projektipäällikön oma mieltymys teknisiin yksityiskohtiin. Tällaisessa projektissahan ei projektipäällikön tarvitse vahtia tuotekehityksen työmääriä eikä kustannuksia, mutta lopputuloksen (tuotteen??) kustannustekijät ovat kyllä tärkeitä.

Ja sitten siellä on myös alakategoria dokumentointia varten, jotta ne löytyvät helposti. 

Konemies voi toimia tässä projektissa jonkinlaisena apumiehenä, mutta ei päällysmiehenä. Teen toivomustenne mukaisia asetuksia ja alakategorioita tälle alueelle, jne. Lisäksi varmaan voisin kommentoida silloin tällöin projektin kehittymiseen liittyviä erilaisia asioita, mutta muuten ei ole minun hommani ohjata asiaa. Projekti on siis teidän ja sen hyödyntäminen kunkin omassa vallassa.

Mukava kokeilla tällaista täällä; toivottavasti projekti yhdistää eikä erota porukkaa toisistaan.

Tuo uusi alue on sitten suljettu vierailta....

----
EDIT:  Siis nyt on siirretty...  Kannattaa klikkailla suoraan noita alakategorioita, koska menee väkisinkin muutaman ylätason kautta, mutta omiin linkkeihin voi laittaa tietenkin ketjun osoitteen suoraan... Jos on ongelmia oikeuksien kanssa, niin YV:tä konemiehelle....

Lainaus käyttäjältä: ram - 03.01.10 - klo:12:42
Joo  22 eksuu maksaa, ja sitä pohjana käyttäen olisi aika helppo edetä protorautaan. Lopullesesta levystähän tulee sitten aika hyvä kehitysalusta. Kaikki IO:t tietty siihen helposti käsille. Kyllähän siitä ihan varmasti joku koodaa myöskin servodriven yms.

Niin kannattaa tietenkin saman tien laittaa kaikki kortin ja prosessorin liitynnät käyttökelpoisen kuosiin, se ei maksa mitään ja joku on varmasti kiitollinen myöhemmin.

Tässä artikkeli on interpolaatioiden tekoon, ei tarvi keksiä pyörää uudelleen, muutenkin erittäin mielenkiintoista luettavaa...