Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
Amíg fogalmunk nincs, milyen szinten ismeri a témát!
Ötletezni sem tudunk, hogy mit képes megvalósítani? Ezért kellet volna látni a próbálkozását, mivel a felvetett téma megoldása eléggé egyszerű feladat lenne! Ja és a kérésem nem hozzád szólt! 
Nos, a konkrét probléma a következő:
Van egy útkereszteződéses nyákom. A forgalom irányítását már megcsináltam. A panelon van két gomb, ami a vonat érkezését és távozását szimbolizálja. Megnyomom a bal gombot, jön a vonat. Ha jobb oldalit nyomom meg, elmegy. Viszont amikor nyomom a jobb oldali gombot, röngtön bemegy a vonat jön jobbról részbe. Sem delay-t sem while-t nem használhatok, mert a timer1 megszakításban vizsgálom, hogy jön-e vonat. Viszont akkor is működnie kell, ha először a jobb oldali gombot nyomom le. Így csináltam a balról jobbra irányt:
Szerintem kellene még vizsgálni, hogy milyen irányba megy a vonat.
Ezt esetleg meg tudnád állapítani ha, vizsgálod, hogy a sin pálya melyik oldala van GND-n? Vagy az ellenkező oldali első gombnyomást úgy értelmezni, hogy elment a vonat. És csak a következő nyomás jelzi az érkezést. Minden féle képen tudni kellene, hogy éppen merre halad a vonatod? A hozzászólás módosítva: Márc 30, 2018
Nincs definiálva, hogy tudni kell az irányt.
Csak annyi, hogy egyik gombal érkezik, másikkal elmegy. Bármelyik irányból érkezhet, bármikor.
Így próbáld:
Vagy a villogást is külön vizsgáld:
A hozzászólás módosítva: Márc 30, 2018
Az ilyen viselkedés lassan elveszi a kedvem az egész fórumtól!
Mi önzetlenül segítőkészek vagyunk! Utána a delikvens önzően eltitkolja a megoldást! És gyorsan eltűnik a balfenéken!  
Milyen viselkedés?
Megköszöntem a segítséget. Az, hogy esetleg más úton oldottam meg, miért gond? Egyébként a megoldásom, hogy a gomb lenyomott idejét vizsgálom. Ha tovább nyomom 100ms-nál, belép... Rövidebbre pedig kilép.
Az volt a feltételed, hogy nem lehet sehól várakozni!
Így pedig várakozol a gomb megnyomásától az elengedéséig, közben még időt mérsz? Szerintem a legrosszabb megoldás.
Elírtam. Nincs 100 ms. Csak kb 20ms. Egyébként a kikötés az volt, hogy delay-t mint függvényt nem használhatok. For-al oldottam meg a várakozást. Lényeg, hogy a tanár fogadja el így.
A hozzászólás módosítva: Ápr 1, 2018
És elfogadta? Csak mert egy for cikluson belül várakozni, az ugyanúgy busy wait, mint a delay()...
Az édes mindegy, hogy minek nevezed a várakozást!
A lényeg, hogy megállítod vele a program futását. És ezért nem tudod időben észlelni, lekezelni ha máshól történik valami.
Igen, nem volt úgy jó. Most timer1 isrben számolok. Így megy időben más is. Szerintem így már jónak kell lennie.
Házi kész. Köszönöm a segítséget. A hozzászólás módosítva: Ápr 1, 2018
Üdvözletem!
Tudnátok mutatni/ajánlani olyan projektet, ami egy SPI/I2C grafikus kijelzőt használ attiny44 procival? Tehát az lenne a lényeg, hogy beleférjen egy egyszerű program, a 4KB -os programtárba. Maximum pár láb állapotát kellene HIGH/LOW szintre állítani (két analogRead, egy analogWrite és pár digitalRead / digitalWrite lenne benne), és mellé egy kis grafikus színes kijelzőn kiírni pár konstans szöveget, és változót. Nincs szükség az összes színárnyalatra, az is elég volna, ha a fő színek mennének (RGB). Én (igaz arduino IDE -vel) hiába próbáltam, a legkissebb programméret is körülbelül 10KB. A hozzászólás módosítva: Ápr 12, 2018
Vagy ha már itt tartunk, akár olyam megoldás is érdekelne, hogyan lehet felhasználni külső soros EEPROM -ot adattárként. Tehát ha egy lefordított *HEX nem fér be a belső adattárba, akkor megoldható -e úgy "szétvágni" a programot, hogy az első fele a proci belső adattárjába kerüljön, a maradék része pedig a külsőbe. De akár az is jó lenne, ha a belső tárolóba csak valami kis program futna, ami megoldja, hogy a külső EEPROM -ból tudjon egy nagyobb programot futtatni, ami a belső tárba nem fér bele...
1 Adatot tudsz tárolni a külső EEPROMban, programot nem.
2 Miért nem választasz a feladathoz jobban illő (nagyobb) mikrokontrollert?
Mert ebből hirtelen van itt kettő, és gondoltam felhasználom az egyiket...
Grafikus kijelzőt ne akarj 4kB-os mikrokontrollerrel kezelni, még egy tisztességes betűtípus sem fér bele. 16kB (de inkább 32kB) a minimum, amivel érdemes nekifutni.
Pedig Kovidivi szerint bizony bele fér az, ahogy ő számolta, bőven volna még hely másra is.
Azt nem tudom mennyire helytálló a számítása. Mindenesetre ha valóban úgy van ahogy állítja, akkor bizony más eszi a háttértárat, nem a karakterkészlet...
Itt a bizonyíték. Minden betű 5byte-ot foglal. Minden karaktert kézzel készítettem. Ha 16000 byte lenne egy egész karakter készlet, még ma sem lennék kész. A fontkészlet feldolgozását egyéni függvény végzi a LED-mátrix kijelzőkre, és scrollozódik oldalra a szöveg, ha hosszabb, mint a kijelző.
Jól van, elhiszem én amit írtál a méretről, de már a második ember jön nekem azzal,
hogy "elvileg" még a karakterkészlet sem fér be 4KB -ba. Egyébként én megértetem a matematikai levezetést is, azért tételeztem fel, hogy bizony más eszi meg a helyet, de kezdem azt érezni, hogy ezzel mások sincsenek tisztában... Amúgy megpróbáltam ez alapján elindulni, és megpróbáltam lefordítani az említett LED villogtatót, de hibaüzenettel megáll. Idézet: „ > "make.exe" all -------- 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. Compiling C: main.c avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst -std=gnu99 -MMD -MP -MF .dep/main.o.d main.c -o main.o main.c:8: warning: function declaration isn't a prototype main.c:25: fatal error: opening dependency file .dep/main.o.d: No such file or directory compilation terminated. make.exe: *** [main.o] Error 1 > Process Exit Code: 2 > Time Taken: 00:00 ” Most meg valami main.o kell neki, pedig erről szó sem volt a leírásban...  A win kereső szerint az egész háttértáramon sehol nincs main.o... A hozzászólás módosítva: Ápr 13, 2018
Sajnos mi elvesztettük a fonalat! Miről is van szó pontosan, melyik program, link van?
Legutóbb, még ha jól emlékszem attyny48-asra írt programról beszéltél. Ami memória spórolás miatt televolt assembler kóddal. Most pedig mmcu=atmega16-ra fordítanád? Ami eleve hiba, mert nem egyeznek a regiszter nevek a kettő között. main.c:25. sorban: fatal error: keresd a hibát. main.objektet a fordító állítja elő, ha sikerül neki! A hozzászólás módosítva: Ápr 13, 2018
Előző hozzászólásomban ott a link.
Most nem a proci a lényeg, csak a példaprogramot (LED villogó) akartam lefordítani, hogy lássam, hogy rendben működik a programers notepad és a WinAVR, mert még nem használtam...
A 25 -ös sörban pedig már csak a záró kapcsos zárójel van... A hozzászólás módosítva: Ápr 13, 2018
Az utolsó } jel után még nyomjál 1 entert.
Egyébként érdekes, mert ha az elejéről a fügvénydeklarációt kikommenteltem, és csak az int main(void)
részt hagyom benne, persze a két fügvényhívást innen is kikommenteltem, a hiba kb ugyanaz, nem találja a main.o fájlt... De egyébként a konkrét hiba.: "main.c:25: fatal error: opening dependency file .dep/main.o.d: No such file or directory" tehát elvileg egy dep/ mappában kellene lenni ennek a fájlnak, de ilyen mappa sincs amúgy... A hozzászólás módosítva: Ápr 15, 2018
Sziasztok!
Tanácsotokat kérem, mielőtt kidobom a panelt. Van egy panelem, amiben Atmega1284 ketyeg. Elkészítettem hozzá egy progit (egy bldc vezérlőt írtam, de ez most mellékes), és betöltöttem rá. Atmel studio+Dragon isp betöltő. Idáig rendben is mentek a dolgok. Kis módosítást szerettem volna a programban. Ezt szerettem volna betölteni, de szerencsétlen módon az Atmel Studio megállt valamiért, majd újraindította magát. A probléma az, hogy innentől kezdve nem tudom rátölteni a processzorra az új verziót, sem a fuse biteket érem el. Talán elérhetem, hogy a processzort párhuzamos módban is be tudjam programozni, vagy legalább egy teljes chip tudjak elvégezni. Érdemes próbálkozni/kínlódni, hogy bevezetékezzem a párhuzamos égetést, vagy dobjam ki a panelt, mert reménytelen a dolog? Z. |
Bejelentkezés
Hirdetés |
