Korrektül ismertetett projektnél valamilyen formában kitérnek erre. Egyébként meg forráskód mellett sem biztos, hogy minden beállításra rájössz.

Annyira azért nem bonyolult, ami beállítható: külső vagy belső oszcillátor, ez egyértelmű, ha van kvarc külső, ha nincs, belső. Ha belső, akkor szerepel a forráskódban egy #define F_CPU 8000000 vagy hasonló, ebből lehet tudni mire kell beállítani. Reset lábat nem tiltanám le, csak úgy mint az SPI programozhatóságot sem. Bootloader kell vagy sem, ez talán egyértelmű. Ha ki van kapcsolva, akkor nem számít, hogy mekkorára van állítva. Lock biteket nem kell beállítani, más talán nincs is.
AtmelStudio gyönyörűen részletezi mit lehet állítani, plusz a szükséges fuse biteket hexadecimális számként is előállítja.

Igazad lehet. Meg tudnád magyarázni mi is történik itt? Piszkál a kíváncsiság, mivel nem jövök rá.

Proteusban lefuttattam Robi98 kódját és valóban ott nem jelenik meg a red[0] értéke.
A lehető legkevesebb módosítással átírtam a kódot (megszabadultam az "s" változótól, meg kettő if()-től) és ekkor már minden megy is ahogy eltervezte.

Ahogy én értelmeztem Robi98 kódjának ezen részét:
- s=1-el kezd majd belép a while(s)-be
- red[0] felveszi "s" értékét -> red[0] = 1
- if(s>=7) hamis mivel "s" = 1 nem lép be az if-be
- 100ms várakozás, ezalatt (is) az ISR jópárszor elküldi az RGB adatokat, az első piros sornak itt már világítani kellene, de nem teszi
- ha "s" kisebb mint 255 , ami igaz, akkor s=(2*s+1) fut le, igy "s" értéke most 3 lesz, red[0] még csak 1
- ha red[6] egyenlő 255 akkor lépünk ki a while(s) ciklusból, ez hamis, maradunk a while(s)-ban

- visszakerültünk a while(s) elejére
- red[0] most (ismét) felveszi "s" értékét, red[0] = 3 lesz
- if(s>=7) most is hamis mivel "s" = 3 nem lép be az if-be
- 2.dik 100ms várakozás, az ISR-nak az első sorban már 2db piros LED et kellene megjelenítenie, de ismét nem teszi meg

... stb stb

Valamit félreértetek a kódban?

Sziasztok!
AVR studio4 ben build inditáskor az alábbi hibaüzrnrt generálódik:

Build started 22.1.2017 at 17:55:31
0 [main] sh 6680 sync_with_child: child 6108(0x1AC) died before initialization with status code 0xC0000142
70541 [main] sh 6680 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable

-------- begin --------
avr-gcc (WinAVR 20100110) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Size before:
0 [main] sh 3424 sync_with_child: child 5876(0x184) died before initialization with status code 0xC0000142
48678 [main] sh 3424 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make: *** [sizebefore] Error 128
Build failed with 1 errors and 0 warnings...

Mi lehet a hiba?

#3 post, szerintem ez a gond..

Köszönöm a segítséget, ez volt a probléma.

Sziasztok!
Van egy problémám, kaptunk feladatot iskolában, de instrukciót semmit hogy hogyan kéne, ez a jöjjünk rá magunktól effektus van.Jelzőlámpát megcsináltam, de nem akar megállni a G1-gombra és ennyi lenne vele a problémám, feltöltöm ide a c és a hex fájlokat is hátha tud segíteni benne valaki.
A portok és a hivatkozások jó, de mégse akar működni...

A válaszokat előre is köszönöm.

A c fájl hiányzik. Az fcf_avr kiterjesztést meg senki sem ismeri rajtad kívül. Hex-et sem fogja senki assembly nyelvre visszafejteni gépi kódból.

Bocsánat!
Pótolom!

Ez még mindig nem a c fájl, tartalmát tekintve sem. Ennek a kiterjesztése fcf_avr.001. Miért nem rakod fel ide inább a Kód gombot megnyomva?

Erre gondolsz?

Az alapvető problémát már látom:
nincs semmi előre definiálva. Ha átlátható és jó kódot akarsz, akkor szét kell szednem részekre.
Nem tudom, hány lámpád van, de most legyen egy. Akkor kell neked piros be, piros ki, zöld be, zöld ki, sárga be, sárga ki. Kb. így: #define PIROS_BE PORTD|=(1<<PD3); csak mondtam egy példát. Ezután a programban mindenhol ezt használod: PIROS_BE. Így könnyen ki fogod szúrni a logikai hibákat. Ezután jöhetnek a függvények, pl. sarga_villog(); váltásnál csak fogod, és meghívod őt. Ezeket külön-külön tudod tesztelni.
Gombnyomásnál ugyanúgy, én így szoktam: if (GOMB_FEL) {fv();}. A GOMB_FEL pedig úgy definiálva, hogy ha le van nyomva a gomb, igazat ad vissza, ha nincs, akkor hamisat.
PORTB = (PORTB & 0xef) | 0x10; - ezek nagyon szépek, de ha 10 sornál hosszabb a program, már látod is, mi a következménye. Megmondhatod a tanárnak is, hogy ez nem hatékony módszer. Goto-t nem használunk! Ha egy gomb le van nyomva, akkor foglalkozni kell azzal is, hogy mikor végrehajtottad amit akartál, a gomb még mindig le lesz nyomva. Te sokkal gyorsabb vagy, mint hogy az ember fel tudja szegény gombot engedni. Meg kell várni, amíg elengedésre kerül! Ezt megteheted egy 50mS delay-jel is, de a legszebb megoldás megvárni, míg nem lesz lenyomva, és még várni egy kicsit, hogy a pergése is lecsengjen.
Ha ilyen sok if(0) meg if(1) van benne, igazán kiválogathattad volna a nem kellő részeket. Másrészt ha tényleg szeretnél váltogatni a két ág között, akkor érdemesebb if(valami) módon az összes összestartozót egyszerre állíthatóvá tenni, mint hogy mindegyik if(0)-t átírod 1-re.
PORTB = (PORTB & 0xef) | 0x10; - ezt még mindig nem értem, miért így csináljátok. Mióta tudja az ember hamarabb beazonosítani a 0xef-et, mint pl. a 0b11101111, vagy ~(1<<4);
Ezzel csak a saját dolgotokat nehezítitek meg.

Flowcode-ba dolgozunk és sajnos ő ezt kalibrálja be magának alapból..Semmi programozási nyelvet nem tanultunk, és ezt erőltetik mert ez grafikus és "egyszerű" de nem egyszer találkoztunk már program hibával, gondolok itt arra hogy programba rossz de a Tbird-be pedig kiválóan működik, vagy fordítva...Megpróbálom a te módszeredet, de vagyí 10-szer át kell még olvasnom legalább.

Akkor rakd be a Flowcode-os ablak képét, ahol látszanak az ábrák. Ahhoz nem értek, majd más ránéz.

Rendben, köszönöm.
Szerinted ha szövegesen akarom programozni az sok idő lenne megtanulni a programnyelvet?

Szövegesen programozni, vagyis flowcode nélkül? Olyan programot írni, mint amit a flowcode generál? Annak van csak értelme. Hogy időben mennyi? Személy függő. Inkább kezdj el Arduinozni, ha ott ráéreztél a lényegre, magadtól át fogsz lendülni a sötét oldalra
Én Arduino-ban próbálgattam a portműveleteket, a timereket, interruptot, és ment. Ezután elhagytam az Arduinot, majd félig visszatértem.

Értem, az a baj hogy nekem ebből májusban vizsgazni kellene.Addig rendbe kéne tenni valahogyan ezt a kérdést.

Informatikusként érdekes látni ezeket a kriksz-krakszokat. Furcsa, hogy lassan 17 éve vagyok a szakmában, de még életemben nem csináltam ilyen flowcode-ot vagy mi a csodát.

Egyszer az életben vizsgára igazán megtanulhatod. Utána úgysem fogod használni semmire.

Megtanulnám én ha elmondanák hogy kell, de ehhez a programhoz még leírást se találtam, hogy mi hogy működne, érdekelne a programozás azért gondoltam hogy nekiállok megtanulni szövegesen programozni, hogy ne vesszen kárba.Nincs valami egyszerű leírás a parancsokról és a használatukról esetleg?

Sajnos az informatika nem így működik. Legalábbis az elmúlt 17 év alatt nem ezt tapasztaltam. Aki úszik fennmarad, aki nem úszik elsüllyed.

Töltsd le a programot és kezdj el vele valamit szórakozni. Úgy látom, hogy van belőle free verzió is.

Amikor kérdezik, hogy kifizessenek-e tanfolyamra x százezer forintot, mindig azt mondom, hogy felesleges. Ha érdekel, akkor előbb-utóbb megtanulod, ha pedig nem, akkor mással kellene foglalkozni.

Az informatika olyan szakma, hogy egyik munkahelyen orvosi ultrahangos műszereket fejlesztesz, a másikon vasúti forgalomirányítást, a harmadikon pénzügyi könyvelést, a negyedikben meg webáruházat. Senki sem fog leülni veled elmagyarázni az elejétől a végéig, vagy úszol és mész előre, vagy elvisz a sodrás.

Ebben a formában igen.

Valahol be kell látni, hogy a folyamatábra nem átlag-számításra való.
Az érintett nyelv folyamatábrával akarja megoldani 3 szám összeadását, a tapasztalat meg azt mutatja, hogy jobb elkerülni ezeket a nyelveket. Hatalmas kódot generálnak és nem lehet megoldani velük semmit. De ez csak a személyes élményem, 2 évig kellett dolgoznom ilyenen. Utána átírtuk C-be és a program sebessége azonnal 5-szörösére nőtt és mindenki átlátta, ráadásul licenszet sem kellett fizetni.

A folyamatábrát kizárólag magasabb szinten tartom elfogadhatónak, például ami az elektronikai adatlapokon van. Túllépnek azon a nehézségen, hogy hogyan történik 3 LED bekapcsolásának folyamata.

Hali mesterek. Nektek bagatel aprósággal zavarlak benneteket. Meg akarom építeni -topi és zsiros dani_-
által közzétett 8 lábbal cikkből a ni-mh töltö attiny 13 al. A programot "pony 2000 proggal"szeretném betölteni de a FUSE biteket nem tudom mit állítsak. Valaki segítene ebben ?

Konkrétan ezt a nyelvet nem ismerem. Amivel én dolgoztam napi 8 órában, az is C nyelvű rutinokat generált a folyamatábrából.
Mutatnám is:



Eszméletlen élmény volt például nyomkövetni, rajongásig odavoltunk érte.

Sziasztok!
Használ valaki XMEGA-t RS485-re DMA-val? Az a gondom, hogy a DMA-ready jel túl korán jön, hátra van még vagy 2 byte és az irányváltás portbitet csak várakozással tudom fordítani. Ez a HW pufferek miatt van, ami egy jó dolog egyébként, de nekem most pont ez a bajom.

Sziasztok!

Egy szögjeladó és egy AVR összekötéséhez kérek segítséget, tanácsot.

Szögjeladó: AEAT-9000-1GSH0 (link a dokumentációhoz)
AVR: ATmega32U4

A szögjeladó SSI segítségével kommunikál (dokumentáció szerint: "Interface output is SSI (2wire SSI / 3wire SSI) with RS485 line transceiver"). A kommunikáció hat vezetéken keresztül zajlik:
NSL+ Differential (for 3wire SSI only)
NSL- Differential (for 3wire SSI only)
DOUT- Differential DOUT (for 3wire/2wire SSI)
DOUT+ Differential DOUT (for 3wire/2wire SSI)
SCL+ Differential clock (for 3wire/2wire SSI)
SCL- Differential clock (for 3wire/2wire SSI)

A probléma a "differential"-lal van. Az elképzelésem az, hogy mind a hat vezetéket bekötöm az AVR digitális be/kimeneteire. A differenciális kimenő jeleket úgy szimulálnám, hogy amikor az egyik vezetékre 1-et írok akkor a másikra 0-t és fordítva. A beérkező jelpár esetén abban bízom, hogy elég a DOUT+ értékét figyelnem. Feltételezem, hogy az AVR beépített SPI-jét nem fogom tudni használni, ezért az órajelet és az adatbeolvasást "bitbang"-olnom kell (van erre magyar kifejezés?).
Szerintetek működni fog ez így?

Ami még fontos információ lehet:
- Az AVR és az érzékelő egyaránt 5V-os tápfeszről fog működni.
- A két eszköz közötti távolság max.3-4cm (NYÁK vezetékek hossza)

Segítségeteket előre köszönöm, Tamás

Szerintem így jó lesz. Ha beteszel egy invertert (1Gate/sot23/5), akkor tudod használni a beépített SPI-t is.

Próbáltad már, hogy a DMA_CHx helyett a TXC megszakításra hallgatsz (a DMA ugyebár a DRE flaget használja triggernek küldéskor)? Csak egy ötlet, mostanában nem programoztam XMEGA-t.

Akkor minden TX-re oda kell figyelnem, mondhatni, a DMA elvesztette a funkcióját. A soros dupla-puffer miatt ott is az utolsó byte elején kapok jelet, tehát az sem jó az irányváltás kezelésének, mert 1 byte még a HW pufferből csorog kifelé, mikor már "adómeghajtó üres" jelem lesz. Ez az egyik puffer, a másik meg a DMA puffere (amit leállítottam 1-re, 0-ra nem lehet sajnos). Egyéb esetekben nagyon jók ezek a dolgok (DMA lehet 4byte-os puffer is plusz a soros 2 byte-ja jó, de itt most várakozhatok). Biztos vagyok benne, hogy bennem a hiba, mert csak gondoltak az RS485-re...

A CPU elsőbbséget élvez a buszhasználat elérése terén a DMA-val szemben.
Ezért én nem kapcsolnám le a bemeneti adat pufferelést.

A DMA-t nagy mennyiségű adatok gyors átvitelére találták ki.
Ilyenkor nem jelentősen növeli az átviteli időt az utolsó Byte kézzel történő lekezelése a megszakításban.

Az én elképzelésem szerin azért van, elöl a megszakítás kérés, mert kel idő a megszakításba való belépéshez is. És mire odaér a vezérlés, hogy lekérdezze a DMA átvitel végét. Addigra már az nagyon kevés órajelen belül be is fog következni.

Szóval ez pontosan az átvitel gyorsítást szolgálja.