Gyakorlatilag ezt csinálom, egy külön fájlban vannak definiálva a portok, csak az a baj, hogy az a fájl nem a program neve. Lehet, hogy a fö programban kéne ezeket a definiciokat megcsinálni, mert azt mindig egy uj néven lehetne elmenteni. Igy attol függ, hogy melyik panel van a géphez kötve akkor a megfelelö föprogramot kellene csak elinditani ill. betölteni.
( nem kell programozhatova tenni, csak az adott HW-be a megfelelö verziot kellene betölteni.)

Pontosan miben is térnek el egymástól ezek a panelek? Különböző típusú mikrokontrollerek vannak rajta? Vagy lehetnek ugyanolyanok de mégis más kiépítésben?

Köszi, én sajnos csak ASM-be tudok ugy ahogy programozni.

Ott vannak olyanok hogy
"include equats.inc"

Azaz kb akkor ezt kéne tennem:

FöprogramA
Include equatsA.inc

FöprogramB
Include equatsB.inc

Stb.

Holnap ki is probálom.

Kösz

Asm2-ben ezt ugyanúgy meg lehet csinálni,ahogy csatti2 írta és csak egy fájlt kell csatolni.

Gyakorlatilag fillérekért vettem egy sereg Arduino kiegészitö paneleket, mind 328-s procikkal. (nano stb.) ami nekem eddig nagyon bevált.
De 3 tipus van, és egyiken csak 14 kivezetés van ( 2 port) a másikon vagy 20 a harmadikon meg ha jol számolom 22. Az én berendezéseim többségébe elég a legkisebb is, de a mechanikus kivitel miatt más portkombináciokat kell használnom, illetve néha több bemenö port kell ilyenkor a nagyobb panel kell ( a kimenetek azonosak, csak rendszerint más porton.).

Én már nagyon régóta nem vesződőm assemblerrel. A mai fordítok hatékonyabb kódot fordítanak, mint amit én ki tudok hozni az ASM-ből. Aki úgy gondolja, hogy ez nem igaz, mert ő jobbat ír, az nem tud rendesen c-ben (vagy c++-ban) programozni.

Itt trükkösebb a helyzet, mert ugyanaz a uC-d. Marad a preprocesszoros megoldás.

Egyébként ha valaha úgy érzed, hogy neked három féle kódot kell elmentened egy projektből, akkor vagy preprocesszor a jó irány, vagy valamilyen verzió kontroll szoftver (pl. git). Szerencsére ez utóbbiakat is támogatja az Atmel Studio alapból.

Ez teljes mértékben vonatkozik rám, soha nem jutottam el a C nyelvig. Valamikor Basicot nyomtam (z80) aztán az ASM-t ( az elsö PIC-ek a 80-s évek közepén, végén, akkor profi szinten). Majd sok évtizedes szünet után ujra tanulom az AVR-t.

Szerintem hanyagold az ASM-et. Tanuld meg inkább a c-t és a c++-t. Könnyebben készíthetsz összetett (és sokkal átláthatóbb) kódot.

Ma már nem, de holnap kiprobálom a verziok kezelését. Nagy gond eddig sem volt, csak eléggé káotikus a kezelés mert szinte minden programkönyvtárban ugyanazok a fájlok többsége van ( amiket már egyszer megirtam mint pl. display meghajto, motor meghajto, eepromkezelö, makrok, definciok stb.) igy a keresö talál egy sereget, de soha nem vagyok biztos, hogy ezek azonosak- e vagy sem. Ezért lenne jo, hogy ami közös és változatlan csak egyszer legyen meg, a program/HW specifikus dolgok meg külön legyenek valahogyan megnevezve.

Az mi az a glt? Ilyesmivel még nem futottam össze.

Verzió kezelő
git

nem glt, hanem git. Verziókövető rendszer. Visszatudod nézni mit csináltál a "commit"-ok között (ezek afféle mentési pontok). Készíthetsz leágazásokat ha ki akarsz valamit próbálni de nem vagy benne biztos jó ötlet és nem akarod összeszemetelni a fő kódot. Ha beválik, akkor csinálhatsz egy "merge"-t (összefésülöd a módosításokat a rendes kóddal). Támogatja ezért a több felhasználós munkákat is. Szerverrel szinkronizálhatod a kódot. Bármelyik mentési pontra visszaugorhatsz. Megcímkézheted a különböző állapotokat (pl v1.0, v1.1, stb.). Ezért könnyű például patch-t készíteni egy korábbi szoftververzióhoz, amilyen terméket már mondjuk nem készítesz de mégis támogatni kell. Szóval ezernyi dologra jó, akár egyfelhasználósként használod akár többedmagaddal.

Ez valami külön program vagy a Studio része? Ott még nem akadtam bele.

Itt van pár kép, hogy is néz ez ki:
Pl. látszik a beépülő menü. Illetve a másik képen követhető mi változott a kódban az adott mentéskor. A harmadikon pedig egy egyszerűbb projekt "története" látszik.

Alapból nem. Kell hozzá egy beépülőt telepíteni. Ezenkívül kell még a git, illetve az ahhoz való GUI (tortoiseGIT).

Kösz. Ez igy elég bonyolultnak látszik ( föleg, ha az ember már csak hobbiszinten hodol a programozásnak).
Mindenképpen holnap megnézem hogyan tudnám egyszerüsiteni a verziok kezelését. Ha sikerül megoldanom a feladatot, akkor jo lesz az ugy is - abban van már legalább némi gyakorlatom.

Nem bonyolult. uC-t én is csak hobbiból programozok. Egyszer kell csak megérteni, hogy működik (nem nehéz) és utána nagyon komoly segítség.

Gondolod, hogy ez müködik ASM-re is?
(Nagyon nem szeretek uj programokat telepiteni, veszödni velük, mert rendszerint egy csomo más problémát okoznak - ami aztán napokba, hetekbe kerül mire az ember megtalálja a hibát, ha egyáltalán. Ma éppen vagy 4 orát veszödtem az egyik legujabb laptoppal W8.1- rendszeresen elveszti a kapcsolatot a wifi-vel a másik 6-7 gép viszont soha.

Minden szöveges fájllal jól működik. Legyen az weblap, xml, programkód, kicad rajz vagy akármi, amit képes szövegként beolvasni.
Nem nyúl hozzá a kódodhoz, csak ha te is akarod (visszatérés egy másik verzióra). Egy plusz könyvtár jelenik majd meg a követett projektjeid mappájában (.git), itt tárolja majd tömörítve a változáskövetés adatait.

Nézd, mi informatikusok állandóan verziókövetőzünk (git, csv, svn,... és társai). Elvileg a program régebbi állapotát megnézheted és vissza is tudod állítani vele. Volt már olyan az elmúlt 2 évben, hogy kellett.

Nem ezért jó. A repóba "git commit"-tal rakod be a fájlokat, de előtte lehet "git diff"-et futtatni, ami sorról sorra megmutatja, hogy mit változtattál meg.

Na ez állandóan megy. Amikor pedig nem értem, hogy mit miért változtattam (ja, csak nyomkövetés közben átírtam és úgy maradt), akkor javítom és újratesztelem. 20-ból egyszer fennakad hibás kód.

A másik az, amikor menet közben rájössz, hogy baromságot csináltál, és újraírsz mindent. Vissza az eredeti állapothoz, törösz minden változást, újratervezés.

Gondolom te "kézzel" verziókövetőzöl, azaz van egy könyvtár, ahol a jó kódot tartod, miközben egy másikban meg programozgatsz (munkakönyvtár), utána másolgatsz. Na pont ugyanezt csinálja meg egy verziókövető rendszer, csak normálisabban.

Sziasztok!
Atmel Studio 6.1 alatt van egy programom, amiben ha ilyen sorrendben jön a két programkód, akkor megfelelő a decicelsius értéke, és hiba nélkül lefordul a program:
Viszont ha megcserélem őket, mert szerintem logikusabb, hogy először 10-zel szorzom, és utána osztom 16-tal, akkor hibát kapok:

, mégpedig: "Warning 1 'decicelsius' is used uninitialized in this function [-Wuninitialized]", és a programban le sem fut, mert 10-szer kevesebbet kapok, mint kellene.
Így van deklarálva: uint32_t decicelsius; először 16bites volt csak, de long-ként is hibás.
Van erre valami szabály, amit nem ismerek?
Köszönöm!

A masodik valtozatban ertelmetlen az elso muvelet. Meg nem adtal neki erteket (tehat a tartalma ismeretlen a valtozonak) es megszorzod 10-el, majd utana felulirod a measure valtozoval. Igy lehet helyesen megoldani, viszont igy tobb muveletet igenyel es nagyobb valoszinuseggel fog tulcsordulni.

Ezt csúnyán benézted. Nézd csak meg jobban mit csináltál. Először szorzod a semmit (inicializálatlan változó), majd utána adsz a változónak értéket, amit nem konvertálsz át... Persze, hogy figyelmeztet a fordító.

Megjegyzés még: A decicelsius = decicelsius*10; helyett írd inkább: decicelsius *= 10;

Hmm, kolléga beelőzött...

Köszönöm mindkettőtöknek. Még reggel van Ezt tényleg benéztem...

Elhiszem, csak én nem vagyok informatikus igy az agyam sem ugy müködik mint nektek. Az persze sok programban nagyon jo, ha visszatérhetsz egy korábbi verziohoz, sok proginak van ilyen backup funkcioja. Amikor az Atmelt kezdtem nekem is nagyon jol jött volna, ma már sokkal jobban odafigyelek.
(Kár, hogy ilyen nincs a studioban ezért, kerestem és találtam egy magánutat, ami eddig többé kevésbé ki is elégitette az igényeimet.).
Lehet, hogy alkalom adtán kiprobálom a git progit, habár nem hiszem, hogy igényeim ilyen mélyrehatoak lennének.
Amire ma szükségem van az egy kicsit más dolog, ahogy irtam, nekem egy mükldö programhoz kell 2-3 verzio az adot HW-hez.

Mindenestere köszönöm a jo tanácsokat - lesz min még gondolkodni....

Szoktam ilyet csinálni. Amilyen chipre fordítasz, olyan kód generálódik. Bár én make-t használok, az meg egy build-del legenerálja az összes kódot. Nem szoktam AVR Studiozni.

Mindenesetre érdemes azonos chip-parkot fenntartani.

Tegnap 1 órám ment el azzal, hogy kiszedtem egy Atmega8535-öset és Atmega16A-t raktam a helyére. Az Atmega8535 elvileg rossz választás volt, mert az Atmega16A az jobb is és olcsóbb is, emellett az összes szimulátor támogatja.

Ráadásul ugyanaz a kód változatlanul nem is megy a két chipen, mert az interrupt tábla mérete más (az Atmega8535 RJMP-zik, az Atmega16A pedig JMP-zik). Gondolom az Atmega32-n az Atmega16 kódja elfut változtatás nélkül.

Nálam megérte levonni a következtetést, hogy koncepcionális hiba volt az Atmega8535-öt választani és teljesen kiírtottam a kódból. Nem követtem el azt a hibát, hogy a régivel is kompatibilis maradjak, hanem egyszerűen kipakoltam.

Nekem is vannak ilyen dolgaim ( bizonyos makrok az szerint müködnek, amilyen chip van a berendezésben), de eddig egyébb HW verziokkal nem volt ilyen gondom. Megyek majd probálgatni.

Kösz

Igyekszem én is 3 -4 chippel dolgozni ( tiny, mega 328 meg a mega 644 eddig kielégitett minden igényt). Most nekem az elöregyártott panelekkel lett gondom, mert azok viszont eléggé különböznek - a chip azonos.