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
Csinálsz hozzá egy megfelelő DIP-SO.. átalakítót.
Erre van egy csatlakozó a nyákon, amire rá tudod dugni a progamozót. Az reszeteli a mikrovezérlőt, berakja programozó módba, és feltölti rá a programot. Ezután újraindul, és már fut is a feltöltött program. ISP programozásnak hívják (In Circuit Programming).
Vagy rendelsz hozzá készen ebay-ről "fillérekért"...
Mi értelme van egy SMD IC-t egy DIP panelre ráforrasztani? Hiszen ezzel pont azt az előnyét veszted el, hogy kicsi. Gondolom nem néztél utána, hogy mi az az ISP csatlakozó, mert akkor nem keresnél mindenféle plusz nyákokat.
Ha pedig tönkremegy az AVR, amire nagyon-nagyon pici esélyt látok, akkor kiforrasztod. Az atmega328 pl. nem okoz túl nagy gondot, sima 25W-os pákával leszedem a mini pro nyákokról. A hozzászólás módosítva: Jan 8, 2016
Ebayen féláron 5 darabot küldenek...
Bővebben: Link Foglalat Foglalat működés közben (Miért nem írja ki jól az első linket?) A hozzászólás módosítva: Jan 8, 2016
Nem, nem néztem még utána, igazad van. Meglesem azt is.
Nem is építettem még semmit, programozni sem tudok, csak érdekel a dolog, olvasgatok, és ott akadtam el, hogy egy DIP tokozású AVR-t egy programozóba könnyedén bedugva csatlakoztatható, a program feltölthető, majd az AVR a saját készítésű nyákba forrasztva használatba vehető.(?) Az SMD-nél nyilván nem forrasztjuk rá a programozóra, forrasztjuk le onnan, majd forrasztjuk rá a saját nyákunkra.  De értem, hogy van más megoldás is, utánanézek - köszi.
Összefoglalom: Van 6db tüske a nyákon, amire csak rádugsz egy csatlakozót, a csatlakozó pedig a programozóba fut be, és így programozol. Ha készen vagy, lehúzód a programozó kábelt, és kész. 6db tüskének kell a plusz hely.
Hát ez így tényleg sokkal praktikusabb, igazad van!
Ezekkel az a baj, hogy csak 8 lábú smd-hez jók. A 28-as meg túl drága. Ezért én inkább maradok ennél:
A hozzászólás módosítva: Jan 8, 2016
Én anno 32 lábú QFP AVR-eket programoztam egy ILYENNEL.
Nem olcsó, de ipari célra kifejezetten jó megoldás, főleg ha utána SMD-beültetőgéppel kerül az IC a végleges helyére. Sajnos nincs képem róla, csak leírom mit használtam előtte: egy QFP-32 IC-t használó panelból építettem SMD programozót úgy, hogy az IC körül panelszéleket ragasztottam a panelra, hogy egy ATMega8 éppen beleférjen a négyzet alakú területre, és ne lötyögjön benne. Az aljára fúrtam egy kis lyukat, mert az IC néha beleragadt és nehéz volt "kiütni". A lyukon keresztül egy kis fogpiszkálóval egyből kijött. Később bekötöttem nagyfeszes programozót is, az 22 lábat(!!!) használ. Sajnos így már nem volt elég ujjal rányomni, egy kis présgéppel kellett az IC-t leszorítani. Na ezt váltotta fel a fenti cucc... A hozzászólás módosítva: Jan 8, 2016
Ezt miből csináltad?
Valahol már egyszer megtaláltam ezt,de fogalmam nincs,hogy hol.
Ez ok, de mi van ha már legyártottál pár száz nyákot és találsz egy programhibát? Ne adj isten később jön elő és az ügyfélnél kellene gyorsan firmware-t cserélni? Szerintem nem érdemes lespórolni a programozó csatit. Természetesen nem kell feltétlen tűs kivitelben gondolkodni, elég ha érintkező pontok vannak a nyákon (gyártáskor rugós tűs panellel utána gyorsan felprogramozható a nyák, illetve letesztelhető még, ami szükséges lehet további pontok beiktatásával).
Szia!
Az oldalamon megtalálod:Bővebben: Link
A cucc a megrendelő "műve", nem az enyém. Gondolom már tesztelték párszor és működött, ezért is rendeltek mindig több ezres darabszámot. Egyébként egy távirányító volt, ami akkora volt mint egy evőkanál, és nem fért rá 6 programozópont. Ennek talán nem kell firmware csere...
A legtöbb cuccon azért volt érintkezőtűs megoldás, de a tüskesort nem kellett beültetni. Az égetéshez készítettem egy rugóstüskés adaptert amivel gyerekjáték volt a művelet...
Szia. Szívesen megnézném ezt a távirányítót, ha publikus. Csak a nyákra gondoltam. Mit irányított?
Sajnos nem publikus, de nem kell semmi "rosszra" gondolni. Egy kis 40MHz-es tekercsantenna,
DIP-kapcsolósor, kristályoszcillátor, és persze egy ATMega8 volt rajta. A kiadott jel 13 bites, azt ismétli. Garázskapukhoz és projektorokhoz használják őket. A hozzászólás módosítva: Jan 9, 2016
Megértem, semmi gond. A tekercsantennáról kérdezhetek? Valami rezgőkör, amit be/kikapcsolt az AVR? Vagy valami spéci IC hajtotta az antennát? A vevő oldalon meg csak ezt a 40MHz-es jelet kapta meg a kapcsolás, majd dekódolta, hogy mikor van, mikor nincs jel, vagy valami komplikáltabb? Érdekesen hangzik.
Egy mezei ki/bekapcsolós fajta, természetesen. Konkrétan egy tranzisztoros kristályoszcillátor adja a 40.6MHz-et, ez megy a tekercsantennára. Az antenna tekercse és egy kis kondi LC-rezgőkört alkot. Erre jön egy kis SMD trimmerkondi, amivel rá lehet hangolni az antenna rezgőkörét az oszcillátorra. Ez spektrum analizátor nélkül lehetetlen vállalkozás, szerencsére kéznél volt egy.
A hozzászólás módosítva: Jan 9, 2016
Két kérdésem lenne:
1, Miért sír az Atmel Studio 7, hogy
Amikor a kód így kezdődik:
2, Ti melyik LCD library-t használjátok? Először Peter Fleury féle lcd.h-val kezdtem , de a negatív tizedes értéket nem tudtam kicsalni belőle. Aztán ez okosabbnak tűnt, de ez meg nem működik.
Valószínűleg a #define F_CPU 1000000UL az #include <util/delay.h> után van, és nem előtte.
Próbáld így:
Ahogy emlékszem az F_CPU-t nem így szokták C fájlban megadni.
Valahol a projektben állítod be az órát és ez automatikusan -DF_CPU=1000000 -ré konvertálódik. A hozzászólás módosítva: Jan 12, 2016
Így is megadhatja,vagy a Toolchain/Symbols-nál F_CPU=1000000UL formában.
Hooligan01: Ez az első sor. Ennél előrébb nem lehet írni
rolandgw: Ez lett a megoldás. Köszönöm. Persze ettől még nem értem a másik miért nem működik?! Az 16x2-es LCD meghajtására valami kipróbált library?
Mit nem ertesz? Nem az Atmel Studio sir, hanem a gcc, es azt mondja, hogy a delay.h forditasa kozben az F_CPU nincs definialva. Tehat elobb kell definialni, es csak aztan kovetkezhet a delay.h. Ezert kell az #include ele tenni. Ha az IDE magatol atadja a gcc-nek (C fordito) a
-DF_CPU=100000 parancssori opciot, akkor szinten jo lesz, mert mar a forrasszoveg (delay.h) olvasasa elott meg lesz definialva az F_CPU makro.
Mégegyszer: a
No, azt nem értem, hogy miért nem működött ezzel.
Bocsanat, mar latom, hogy ezt az eredeti postban is leirtad. De akkor mitol javult meg?
|
Bejelentkezés
Hirdetés |
