Köszönöm! Igazából nem is küldeném sleep módba az avr-t, ezt csak példának írtam, mert 128kHz-ről tervezem járatni, ott pedig a mega328p adatlap szerint kb. 60uA-t vesz fel. Egy időjárásállomás adója lenne, ezért szeretném csökkenteni a fogyasztást. Még az jutott eszembe, hogy a stepup lekapcsolásával a szenzorok is lekapcsolhatóak, így egyszerűbb lesz az áramkör, nem kell külön lekapcsolni a szenzorokat, majd a stepup-ot. A konvertert pedig azért kapcsolnám le, mert mérés szerint terheletlenül ~1mA-t fogyaszt, ami jóval több az uC áramánál, kikapcsolva viszont nem tudtam áramot mérni, olyan kevés. (adatlap szerint kikapcsolva <1uA, bekapcsolva 19uA + az ellenállásosztón folyó áram) Aktív állapotban 100mA körülre becsülöm a fogyasztást, de ez csak néhány percenként lenne kb. 1mp, így az átlagos fogyasztás 1mA körül lenne. Ezt egy kis napelem (5V/120mA) fedezné borús időben is, napos időben pedig az akkut tölthetné rossz idő esetére.
Lehet egyszerűbb lenne pár havonta akkut cserélni benne, de szeretném önellátóvá tenni.

Az ellenállásosztóra "felülről" tehetsz egy zener diódát. Igaz, át kell méretezni emiatt az osztót meg mérni, számolni, de ezzel megspórolhatod ezt is. De egy jó táp IC-nek lágy (>300kOhm) osztó is elég lehet.

Önmagában avval nem zárod ki magad, hogy külső kristályról futó uC-ra szánt programot töltesz fel egy új procira.

Atmega328PB:
http://www.atmel.com/Images/Atmel-42397-8-bit-AVR-Microcontroller-A...ry.pdf

Érdemes elolvasni, hogy mi a 328P utódja. Kód szinten kompatibilis a chip a régivel.

- USB nincs (miért?)
- PDIP tokozás sincs (bár minden hobbista kész Arduino panelt vásárol manapság)
- a 32k nevetséges, 256k is súrolja a határt
- a 20 MHz határfrekvencia szintén nevetséges

A két SPI, I2C, UART, 5 timer az tuti, de az ESP32 lehet, ütősebbnek ígérkezik.

Sziasztok!
Víz alatt szeretnèk távolságot mèrni 20-30m ig. Mi ennek a legjobb módja?

Néhány napja gondoltam egy próbát megér és kiolvastam az ic-t. Alacsonyabb órajelen sikerült is. Szerintem múltkor túl magas órajelet használtam és bizonytalan volt a kommunikáció, ezért nem olvasta be utána, csak akkor még nem gondoltam erre. Egyébként a "hőkezelést" is kibírta, egyelőre hibátlanul működik.

Ez nem az utódja, hanem egy alváltozata, ami kapott touch cuccokhoz hardveres támogatást. Az utódok már évek óta kaphatóak és ATXMEGA-nak hívják őket...

Ultrahang, csak vízben is működő adó vevő kell hozzá.

Használni szeretném az atmega8L-ben lévő analóg komparátort, de az adatlapon nem értek egy dolgot. Atmega8L adatlap. A 236 ill 243. oldalon verziótól függően 20 vagy 40mV offset feszültséget ad meg, míg a 269, 299 oldalakon levő diagramokon még a legrosszabb esetre is 5mV körüli offsetet jelöl. Melyiknek hihetek, ha pedig mind a kettő adat igaz, akkor hogyan kell értelmezni?

Sziasztok!
Van egy átfolyásmérőm, ami literenként 10.000 impulzust ad le, a fogyasztás óránként kb 3L legrosszabb esetben. E mellé még lenne 3 megszakításos lábam, meg Timert is használnék és adatokat írnék egy kijelzőre. Mekkora órajelre lenne szükségem a megvalósításra?

30 000 impulzus. Egy interrupt 12 órajel, számoljunk 15-tel, hogy maradjon egy kis tartalék. 30 000x15=450 000 óránként. Tehát 100KHz (vagy 128KHz a legkisebb sebesség)-ről is, vagy 1MHz-ről már simán mennie kellene. Én 16MHz-ről járatnám, ha nem elemes táplálású a szerkezeted. De az átfolyt víz mennyiségénél nem lehet hibázni, mert a hiba torlódik, és hosszabb mérés esetén nagy lesz az eltérés. Egy km/h kijelzésnél mindegy, hogy 10percenként kicsit kevesebbet mutat a műszer, de nálad vigyázni kell.

Üdv mindenkinek!

Segítségeteket szeretném kérni egy egyszerű kis programhoz.
Kitaláltam, hogy átalakítom a kerékpáromon a hátsó dinamós lámpát úgy, hogy legyen kicsit hosszabb állóhelyzeti világításom is.
A problémám, hogy AVR-hez és C-hez is hülye vagyok kissé.
Írtam, azaz összeollóztam több különböző kódból ezt:


Működhet ez így?
Lényege az lenne, hogy menet közben mikor az 1F-os kondi közel 5V-on van 4Hz-el villogjon a lámpa 50%-os kitöltéssel, mikor megállok és kezd merülni 4,8V alatt átálljon 10%-os kitöltésre.

Előre is köszönöm a segítséget!

Az áramkört gondold át újra.
A szuperkondenzátort egy ellenálláson keresztül töltsed, különben túlterheli a regulátorod (pl. egy 100Ohmos 1W-os már megteszi, és 50mA-ben maximalizálja a töltés áramát). Használj egy diódát (akár schottkyt is), amivel kikerülöd a töltéskor használt ellenállást ha a kondiról mennek a LED-ek.
A regulátornak adj egy rendes kondit is (adatlap szerint kell). A szuperkondi speciális dolog, nem váltja ki a hagyományos kondikat. A biztonság kedvéért betehetsz a regulátor kimenetétől a bemenete felé mutató diódát (nem ismerem ezt a regulátort de nem mind szereti ha a kimenet feszültsége nagyobb mint a bemeneté, kárt biztos nem okoz majd).
A teljesítmény LED-ek kibalanszolását is érdemes átgondolnod. Használj két ellenállást és kösd párhuzamosan a LED-eket (egy-egy pár kap egy ellenállást). Ne kösd össze őket keresztben mint most. Ennek oka, hogy a LED-ek hiába ugyanolyan gyártmányok azért nem ugyanolyan nyitófeszültséggel rendelkeznek majd. Ebből következik, hogy valamelyik LED-en sokkal nagyobb áram mehet keresztül mint a többin és ezért könnyen meghibásodhat. A balanszellenállások biztosítják, hogy amelyik páron nagyobb áram megy keresztül azon kissebb fesz. esik majd, így jóval közelebb hozza majd a LED-eken eső áramot egymáshoz.
A mosfet gate-je és a uC közé javasolt tenned egy 1k-s ellenállást. Ennek oka, hogy az a szegény kis mosfet mindenféle időjárásnak stb.-nek lesz kitéve. A mosfetek gyakori meghibásodási módja a gate összesülése valamelyik lábbal. Ha ez bekövetkezik, megpróbálhatja a LED-ek áramát az uC-n keresztül levezetni az áramkör és akkor viszi az uC-t is, ahelyett, hogy csak a mosfetet kellene cserélni.

100n-es kerámia szütő kondik hiányoznak!

Raknák a? C1, C2 mellé + a TINY GND <> VCC lábak közé!

Köszönöm az észrevételeket!
Az LP2950 bírja így, sőt ha az adatlapját megnézed 100mA-es áramgenerátorként használható. LED-ek pedig 5630-as teljesítmény power led-ek amik bírják a 2,5V-os is külön-külön, szóval ezeket nem féltem (50mA körül lesznek hajtva a 150mA-es ledek). 100nF-os kondikat természetesen berakok szűrésnek, nem jelöltem külön kis x7r smd-k mennek a lábak közé..
Gate-ellenállást először még beleterveztem aztán elhagytam mikor láttam mindenki kispórolja. Megfogadom, visszateszem.

Elsődlegesen a program miatt írtam működhet-e, mert abban nagyon nem vagyok otthon.

AVR nélkül ez lenne kb ugyanerre a célra egy működő megoldás:
Bővebben: Link

Hmm, csak épp ha nem használsz áramkorlátozó ellenállást akkor legalább fél percig nem lesz világításod (ha kisült állapotból indul a szuperkondi), mivel teljes gőzzel azon lesz a regulátor, hogy azt töltse és ezért Vcc az uC minimum feszültsége alatt lesz... Persze a LED-ek nyitófeszét is el kell érni ezért lehet még tovább ez lesz a helyzet.

Valóban ez a helyzet, jelenleg is így használom csak még attiny és szaggatás nélkül folyamatos üzemben. Panelben lakom és mire kiérek a kb. 50m-es parkoló végére már szépen világít. Úgy gondolom, ha benne lesz a szaggatás 10%-os kitöltéssel akkor ez az idő ill. távolság is arányosan csökkenni fog. Eddig se zavart, kb 2 éve így megy, viszont a folyamatos világítás kevésbé feltűnő az autósoknak, mint a villogás.

> már évek óta kaphatóak és ATXMEGA-nak hívják őket...

Nem tűnnek versenyképesnek az XMEGA-k. Az ATxmega256A3BU-t néztem meg, Ebay-en 4500-ért már kapható. Csak 256k flash van benne, max 32 MHz, 8 bit.

Ár/teljesítmény arányban sehol sincs sem az STM32, sem az ESP-hez képest.

Egyre inkább érthető, hogy miért kellett eladni az Atmelt. Nem tartotta a lépést a többi gyártóval.
Jelenleg még húz a cég, de jelentős fejlesztések nélkül kérdéses, hogy mi lesz vele.

Az Stm32-t a Sam-el kellene összehasonlítani nem az Xmega-val.Szerintem a kép mutatja,hogy miért bútoroztak össze a Microchip-el

Visszavonva. A SAM valóban normális széria, a kornak megfelelő képességekkel.

Ha nagy teljesítmény kell, akkor manapság tényleg ARM-ot (vagy vmilyen 32bites cuccot) érdemes használni. Egy 8 bites mikrónál nem hiszem, hogy túl gyakran van igény arra, hogy megtöltsünk 256kB-ot (persze tele lehet szemetelni betűtípusokkal meg hasonlókkal, de azért nem ez a jellemző).
Viszont tény, hogy továbbra is könnyebb 8 bites mikrókat programozni mint 32 biteseket.

Sokkal fair-ebb összehasonlítani mondjuk a ATXMEGA D családot egy ATMega328p-vel. Kb. egy éve vettem 10db ATXMEGA128D3-ast 700Ft+ÁFA / db körüli áron (épp akciózták a tme-n). Kb. ennyibe kerül legális forrásból egy 328p is.
Ez tartalmaz 5db 16 bites timert (egy 16bitesből lehet csinálni 2db 8 bitest, két 16bitesből egy 32bitest) a másik 2db 8 bites és 1 db 16biteséhez képest.
18db PWM kimenet vs 6db.
Magasabb órajel. Event rendszer. DMA kezelés (<- ez nagyon tuti dolog).
Menetközben konfigurálható órajel, nincs többé hibás fuse beállításból eredő szívás.
12bites ADC vs 10bites.
3 USART vs 1.
2 SPI vs 1.
Az I/O-k sokkal többféleképp konfigurálhatóak.
Sokkal többféle jelformálási mód (PWM, pattern, stb.)
Sorolhatnám még. Az A család ennél is jóval többet tud, viszont megkérik az árát, ha nincs rá szükség minek feleslegesen jóval drágább uC-t venni.

Miért lenne könnyebb? Inkább nehezebb, mert van egy csomó megkötés, amitől nem halad az ember: 8 meg 16 bites timerek, szemben a 32 bitessel, nehezen elérhető const szegmens C-ben, 32 bites valtozok használata macerás, lassú, stb... Az, hogy a perifériák általában bonyolultabbak egy 32 bites uC-ben, az igaz. 2016 van, szerintem a 8 bites uC-k idejének már rég le kellett volna járnia. Semmi nem indokolja a használatukat. Nem is értem, hogy hogyan lehet eladni annyit belőlük.

Talán azért mert a legtöbb feladat - amire 8bites mikrót használnak - viszonylag egyszerű. Egy könnyebb problémára hamarabb megírja az ember a programot, mint amennyi ideig tart összerakni a toolchain-t egy ARM-ra (tudom, hogy túloztam picit , nekem is van kedvenc ARM családom, amire kész van a szokásos RTOS+HAL kombóm [STM32F103] ).

Ez nem a 32 bites architektúra hibája. A 8-bites AVR rendszerek kiforrottak teljesen, rengeteg a példa, egyszerű a fordítás,... A toolchain tényleg szoppantyú, de pár évvel ezelőtt AVR alatt sem volt más a helyzet.

Mindkét esetben C-ben (C++-ban) kódolsz gondolom, nem assemlbly-ben, viszont 32 bites rendszeren talán kevesebb szívás van int túlcsordulás miatt. Nem szívsz azzal, hogy 2k RAM-ba beférj, nem kell izgulni, hogy túlcsordul-e a stack, ha túl sok puffered van,...

Többet lehet valódi programozással foglalkozni, kevesebbet ügyeskedéssel.

Szerintem a világ abba az irányba fog elmenni, hogy csinálsz egy weboldalt egy mikrovezérlőn, ott frissíthetsz szoftvert, konfigurálhatsz, azzal irányíthatsz redőnyt, riasztót, öntöző berendezést...

Éppen nézegettem a 10 éves Paradox riasztórendszeremet, 16-os billentyűzeten kell programozni, kijelző nélkül. Egy weblap és wifi segítségével mindez azért más lenne, ráadásul manapság bagó mindez...

A 8 bites AVR nem való webszervernek. Kicsi memória, nincs wifi,...

Azért ne sajnáld le őket. Sok minden kihozható belőlük.

Ez pl. egy ATXMEGA128A1U-n futó projekt debug módban (internetóra pár extra funkcióval). Wifi-n keresztül tölti le az időt, illetve egy saját családi fórumról a friss képeket (amelyeket aztán SD kártyán tárol). USB-n keresztül konfigurálható. Interneten keresztül pedig cserélhető a firmware, illetve van egy audio interfésze is. Nincs még teljesen kész, lehet soha nem is lesz, mert gondolkodom rajta, hogy továbbfejlesztem és kap egy internetrádiós részt is (aztán szaporítom és kap a család is belőle pár darabot).

video

Nagyon sokszor talalkozom azzal, hogy mindenre ugyanazt hasznaljak, mert nem ismernek mas tipust, felnek valtani, nem kepesek felmerni a feladat nagysagat. En par eve NXP uC-ket hasznalok (M0, M3), de most majd egy projektben STM-et kell. Nem felek tole, van adatlap, olvasni tudok, mi baj tortenhet? (Azon kivul, hogy meg kell irnom kb. 40 oldal header file-t...)
A toolchain meg egy olyan dolog, hogy avr-hez ./configure --tartget=avr-elf..., ARM-hez meg ./configure --tartget=arm-eabi... kezdodik a parancssor, amivel leforditod a gcc-t. Hajszalpontosan ugyanaz AVR-re, mint ARM-re vagy m68k-ra. Ugyanazt a gcc-t kell leforditani mindegyikhez. Legalabb is a C fordito, assembler, linker, objcopy es a tobbiek eseteben. Linux-on. A programozo az mar mas kerdes. Abbol nekem mindig sajat tervezesu/gyartasu volt. De peldaul a legtobb ARM alapu uC-hez eleg egy egyszeru sorosvonal, mert a legtobben van egy bootloader ROM-ban. Tehat meg egyszerubb is hozza programozot csinalni, mint az AVR-hez.

Biztos vagyok benne, hogy ez is közrejátszik abban, hogy még mindig sok helyen 8 bites mikrókat látni (magam is láttam olyan projektet, ahol igencsak jól jött volna ha inkább 32bites arm-ot épít be a jóember).

Toolchain alatt nem csak a gyártói header-eket értettem. Ha az ember nem akar mindent nulláról elkészíteni, ami a bonyolultabb vas mellett jóval nagyobb munka mint egy 8bitesen, akkor valamilyen HAL-t használ (pl. alap CMSIS, vagy vmi fejlettebb). Az ARM-ok nagyobb teljesítménye lehetővé teszi, hogy Runtime OS-t használjunk és így jóval bonyolultabb feladatokat is elegánsabban, megbízhatóbban írjunk meg. Ezt is össze kell hoznunk valahogy a meglévő könyvtárakkal. ChibiOS-t ezért szeretem, mert alapból van hozzá STM32-vel működő HAL is. Ha ezekre rájön az ember és összehozza a számára szimpatikus munkakörnyezetet, akkor utána már jól megy a programozás, viszont egy 8biteshez képest azért szerintem jóval nehezebb elindulni.

Felreertes van kozottunk. En tool chain alatt azokat a sw-eket ertem, amik ahhoz kellenek, hogy a forrasbol legyen valami, ami fut a targeten. C fordito, assembler, linker, debugger. Ebbe a linkent konyvtarak is beletartozhatnak, bar en nem szamitom ide oket, debuggert meg nem hasznalok.

Minel tobbet irsz meg magadnak, annal biztosabb lehetsz benne, hogy jo lesz a vegeredmeny. En nem vagyok akkora mazochista, de a batyam a teljes standard C konyvtarat megirta arm-re (meg AVR-re is) es en azt hasznalom. Free, open source, es mivel maganak csinalta, meg van csinalva rendesen. Ezen felul megcsinalta a C support konyvtarakat is, ami kisebb es gyorsabb lett, mint az eredeti GNU (pl. float muveletek). Annakidejen z80-on is azzal dolgoztunk, amit megcsinaltunk magunknak. Es ennek megvan az a nagy elonye, hogy tisztaban vagy azzal, amit csinalsz. De teny, hogy ezeket megirni az sok idobe telik, de megeri.

Volt szerencsem kinlodni egy kenyszermunkahelyen pic-ekkel vindozon mplab alatt es ott nem fizettek volna meg ezt a plusz munkat, mondvan, hogy eddig is jo volt nekik a gyari. Irto rossz volt ugy dolgozni, hogy az osszes uC regiszternek valami semmitmondo T2PC es hasonlo neve van, semmit nem tudsz, hogy mit miert csinal, mit hova tesz a linker es meg eszmeletlenul lassu is, raadasul a C optimalizacioert fizetni kell. Azert a batyam AVR kernel-et bevittem es portoltam dsPIC-re, mert nehez lett volna nelkule haladni.

A Runtime OS az szerintem Real-time akart lenni (RTOS), de ahhoz nem kell 32 bites ARM. Már 1996-ban real time kernelt hasznaltam a 8 bites HC11-en es kesobb az AVR-en is. Nem egy nagy ordongosseg, viszont ahogy mondod, a feladatot sokkal szebben es konnyebben lehet megoldani.