Mintha ellentmondana annak, hogy "hogy 12 órajelenként jöhet 1 jelváltás", persze egy ilyen enkóderhez nem kell ennyire érzékeny cucc. Biztosan PCINT-el, vagy időzítővel is ki lehet hozni, és a mostani, ATMega16-os megoldásom is optimalizálható lehetne hibamentesre. Nálam az a speciális helyzet van, hogy sűrű időzítő megszakításra nincs lehetőség, egy csomót számol, I2C-n kommunikál, stb. Az I2C-s részek úgy futnak hogy az enkóder megszakítások nem zavarják be, mert kvázi rövidek, 1-1 állapotváltozót billentenek át. A 2ms időzítő is csak a várakozó állásban fut le, amikor a proci tényleg semmit nem csinál. A számolásnál ADC, DAC konverziók, szorzók és ofszetek kellenek, az ADC eleve egy FIFO-ba megy és onnan átlagolódik hogy ne vibráljon, de még a kimenetre kötött konstans terhelő ellenállás (4.7k) miatt is kell egy áram beállítás ofszet. A visszajelzett (áramerősség) értéket is korrigálni kell a FIFO-ból átlagolt feszültségérték függvényében. Esküszöm, a következő cuccos áramgenerátoros nullterhelést kap!

> Mintha ellentmondana annak, hogy "hogy 12 órajelenként jöhet 1 jelváltás"

Nincs ellentmondás: ha prell van, és van emiatt hibás kiolvasás, akkor az lesz egy +1 és egy -1 számlálás és kész. De hiba nem lesz miatta. Mivel ahogy te is említetted a prell alatt csak egy jel prellez, tehát csak egy bit fog ide-oda billegni. És végül be fog állni a stabil értékre.

> Nálam az a speciális helyzet van, hogy sűrű időzítő megszakításra nincs lehetőség

Ezért kell worst case-re optimalizálni. Ha periodikusan fut minden, akkor biztos lehetsz benne, hogy legrosszabb esetben is le fog minden futni. Ha interrupttal, ami kintről jön, akkor sosem tudhatod mikor jön egyszerre túl sok interrupt. Mert a worst case úgyis be fog következni.

Ha ez egy kézzel állítható "poti", és a képernyőn mutatjuk a beállított értéket, akkor valószínűleg nem baj egy-két hiba, mert a user annyival többet csavar és kész.

Nem is ez az ág a problémás, hanem ha túl sok interrupt jön, mert csavargatja a user és emiatt leáll a szabályzás, ami az elsődleges feladata a gépnek! És mondjuk túl nagyra nő a feszültség, és leég valami. Nem ismerem a megvalósítást, csak tippelek, hogy elképzelhető ilyen hibaág. Ha periodikus a mintavétel, akkor semmi olyan nem fog a gépben történni, amit nem próbáltál ki a fejlesztés közben.

Nem fog leégni, a szabályozást analóg áramkör végzi! A két DAC nem a meghajtótranzisztort vezérli, hanem a lineáris szabályozó U és I alapjelét adja. Így le is fagyhat, vagy lehúzhatom a vezérlőkábelt, nem történik semmi. Illetve igen, a kimeneten egy relé csücsül, ami a vezérlőkábelen kapja az engedélyező jelet. Ha széthúzom, a relé megszakítja a táp kimenetét.

Már én is elgondolkodtam egy mintavételes szabályozón, de nem tápegységbe. Egy 100nA-100mA áramgenerátor paraméterezése sokkal egyszerűbb lenne, mint ilyen-olyan kapcsolásokkal, kiegyenlítőáramkörökkel megtoldani. Oda is két ADC kell (a sönt két oldalára), DAC talán egy is elég, vagy annyi, ahány söntöt akarok használni.

Egy másik verzióban nem I2C, hanem párhuzamos kimenetű ADC és szintén párhuzamos DAC lenne, mikrovezérlő helyett CPLD-vel. A CPLD-be SPI-n vagy I2C-n tölteném be a paramétereket. A CPLD-vel akár 100MHz-es (10ns reakcióidejű) szabályozó is építhető, lényegében az ADC lesz a szűk keresztmetszet.

Jól hangzik. Paraméterei mik lesznek? Kép van róla? Az alapjelet hardveres PWM-mel adja a mikrovezérlő? Vagy hogyan?

Az analóg dolgokhoz nagyon nem értek, úgyhogy ahhoz nem tudok hozzászólni, csak álmélkodni. A digitális szabályozásnak valóban a periódusidő lenne a problémája. Olyan gyors ADC-t csinálni nem könnyű.

Az alapjel analóg, ami a tápegység szabályozó részére megy, mint változtatható referenciafeszültség. Az ADC csak arra kell, hogy a feszültség-és áramértékeket a digitális kijelzőn meg lehessen jeleníteni, illetve hiba esetén a mikrovezérlő beavatkozhat a kimenő relé lekapcsolásával. Majd rakok fel képet is. Az egész lényege, hogy a tápegység és a vezérlő-megjelenítő rész is egymástól független modulokként tudjanak létezni. A tápegység be lesz építve egy tesztelő állomásba, ahol a processzor rész a tesztprogram által vezérelt paramétereket fogja neki küldeni. Az enkóderes-kijelzős panel lényegében azért készült, hogy az értékeket könnyedén tudjam változtatni és megjeleníteni, ezzel a tápegység működését tesztelni. Lehetséges hogy ezt is továbbfejlesztem egy kicsit, így önálló termékként, digitális labortáp is készülhet belőle. Egy másik fejlesztési irány a kapcsolóüzemű előfokozat, amivel a hatásfokot lehet megnövelni.

A paraméterek lemaradtak: 0-30V (10mV div), 0-3A (1mA div). A következő verzió analóg része optimalizálva lesz, így képes lesz 40V és 4A előállítására. Ezzel a 12 bites A/D és D/A konverterek teljes spektruma ki lesz használva. Apropó, konverterek: jelenleg 2-2 MCP4725 és MCP3221, a következőben egyetlen AD5593R lesz. Az IC a referencia IC-t is kiváltja, a maradék 4 csatorna funkcióját még kitalálom. Az enkóderes részen nincs mit változtatni, azt a táp gyors és pontos élesztése, bekalibrálása érdekében készítettem.

Üdv.
Egy attiny85 AVR-el lenne problémám.
PB4 és PB1-re menne PWM felváltva.
A PB1 rendesen működik de amikor be kapcsol a PB4 fele akkora fordulattal megy mint a PB1 és rángat a motor.
A két kivezetés sosem aktív együtt.
Ha kiszedem az AVR és próbapanelba próbálom akkor ez pont fordítva van PB4 rendesen működik amíg a PB1 villog.

Próbáltam az előosztót változtatni de ha növelem még rosszabb.
AVR nélkül működik a többi rész max fordulaton.

Gondolom a kódba van a hiba.
Mitől lehet ez a probléma?

Pár apróság nekem sántít, persze ettől még működhet. Ha 16MHz-ről járatod akkor stabil 5V-os tápfesz kell, táplábak közelében legalább 100nF-os kerámia kondival hidegítve (nálam 220n-1u).
ADC0-t használsz (gondolom potihoz), ezért a RESET-et már a fuse biteknél tiltani kell, ennek minden hátrányát figyelembe véve természetesen használható és újraprogramozható a cucc.
A PB4 portlábként használata miatt feltételezem, a 16MHz-t vagy külső TTL jelszintet adó oszcillátorról szeded, vagy a PLL-t konfigurálod fel (FUSE LO=0xC1 HI=0xD4 EXT=0xFF).
Utóbbi esetben PB3 is szabad lenne a potibemenethez, hacsak nem tartogatod valami másra.

Ami szerintem hiba: a két időzítő órajele. "CS01" és "CS10" beállítása a két időzítőnél nem ad azonos órajelet, az egyik nem oszt, a másik 8-al oszt. Persze a PLL miatt lehet hogy én tévedek.
A másik hiba hogy nem látom, hol szinkronizálod össze a két időzítő előosztóját?
Az időzítők elindítása UTÁN a GTCCR-be kell írni:
A WGM00-t sem tudom hova tenni, ez alapból osztja a 0. időzítő "hasznos" órajelét.
Az is zavar engem, hogy az OCR1C-t nem állítod be. 255 alapesetben, de azért kimérném, ténylegesen mennyivel oszt.

Ahogy én csinálnám, ha mindenképp tiny85-öt kellene használni:
Egyrészt elgondolkodnék, jó lenne-e 8MHz-es CPU órajel, ez esetben a PLL nem kavarja meg
az időzítők órajelforrását. Mindenképp egyetlen időzítőt használnék a szinkronban tartás végett.
PB1+PB4 maradna, ha az 1-es időzítőt használnám (OC1A+OC1B), ez esetben a frekvencia is variálható az OCR1C beállításával. 0. időzítővel PB0+PB1 (OC0A,OC0B), fix frekivel.
Utóbbi esetben 16MHz-es kristályt is rá lehetne kötni, hiszen PB3+PB4 szabad marad.
PB2-re mindkét esetben mehetne a potméter, nem kell a RESET-et használni, és egyszerű áramköri megoldásokkal ISP-programozás is lehetségessé válna motorindítás nélkül. Gondolom nem ez a cél, hiszen eredetileg a RESET-et használod ami eleve kizárja az ISP-t...

Hogyan lehet ujraprogramozni, ha letildod a RESET-et? (Nekem eddig még nem sikerült.

Itt van egy leírás például: https://www.instructables.com/id/HV-Rescue-Simple/

A RESET lábra kell egy rövid ideig tartó 12V tüskét tenni, azzal lehet programozó módba hozni a csippet. A legtöbb olcsó programozó nem tudja ezt, de nem kunszt csinálni, csak egy high side switch kell hozzá és egy 12V táp, amiről jelentős áramot nem veszünk le, úgyhogy bármi jó. A legtöbbünknek gondolom van labortápja, vagy valami akksija, arról a legegyszerűbb.

Disclaimer: Még sosem csináltam ilyet, nem kellett eddig.

Ezt ismerem, de még soha nem sikerült - igaz, hogy eddig csak 2x probáltam a Dragonnal.

STK500 (gyári), illetve a "teljes funkciós" utánépített verziók. Én már építettem ATMega8535-el,
lemásolva a gyári kapcsolási rajzát. Igazolom, működik!
A másik ami működik, az a TPI (ATTiny10) vs. AVRISP-mkII. A RESET-re optót tettem: aktív (LO) állapotban 12V-ra húzza az IC RESET lábát. Utánépített mkII-vel (is) működik.

A Dragon egyik konstrukciós hibája pont ez a rész. Ha nem megy a HV az még a jobbik eset,
más esetben le szokott égni. A mindenki által megépíthető "fusebit doctor" csak törölni tud,
de már ez is óriási segítség, egy rossz program vagy fuse bit után az IC menthetővé válik.

A HV (égetés/törlés) csak önmagában álló IC-vel működik, beépítve bizonytalan. Fejlesztés alatt lévő konstrukció vagy kis széria esetén inkább nagyobb IC-t választok, a RESET láb felhasználása leginkább (tesztelt) szériatermék esetén lehet hasznos. Fejlesztésnél, nem kipróbált szériatermék esetén többet árt mint használ.

Sajnos nekem mind a két IC SMD egy panelon van, lehet, hogy ezért nem ment. Ha majd lesz több egyszer összeszedem öket és majd megkérlek, hogy töröld a fusebitet.
Kösz!

Köszönöm a segítséget.
Az órajelet lejjebb állítottam valamennyivel jobb de még fennáll a hiba.
PB3 és PB0 foglaltak.
Gondolkoztam még az attiny13A de hibát ír.
Törlésnél és olvasásnál minden Ok.
kép
Ha nem akarok adatot ráírni akkor is elfogadja.
De ha már csak egy üres kódot akarok azt se tudok .
kép2

Lenne egy régi égetőm 12V ról működik.

kép3

Egy ilyennel újra lehet írni ha resset láb használva volt?

Visszatérve az attiny85a ra
amit át írtam:



Próbáltam a CS változtatni vagy a WGM-et de ezektől csak rosszabb lett.

AVR Fusebit Doctor
Ez a válaszom az újraprogramozásra, ha még nincs 12V-os égetőd. Ez ugyan nem programozza fel, de elvégzi az IC törlését, a RESET lábat újraaktiválja eredeti funkciója betöltésére. Én át is terveztem és rengeteget építettem belőle, a saját verziómba 8 lábas IC foglalat is került. Azt most nem tudom feltölteni, de a fenti linken is használható megoldást találsz.

PB2 is foglalt? Ha még fejlesztés alatt áll és nincs több láb, javasolt nagyobb IC-n fejleszteni, pl. ATTiny26! Őskövület, de a megfelelő részek ebben is megtalálhatót. Amúgy szabad megkérdeznem, a két PWM mit csinál?

Még annyi, hogy ha felváltva működik a két PWM, akkor - gondolom - az egyiket mindig kikapcsolod. Ha az OCRxB beállításával kapcsolod ki, akkor 1-1 időzítőimpulzus erejére még így is be fog kapcsolni, teljes nyugalmi állapot nem lesz! A PWM-et ki/bekapcsolni a COMxB1:0 bitekk nullára állításával lehet.

Köszönöm.
Átraktam OC0B és OC0A-ra.
Ha ADC bemenet nélkül használom és OCR0A és OCR0B nek egy stabil értéket állítok be akkor működik mondjuk nem tudom miért de max fényerővel világít a led és ha kap egy jelet PB3 vagy PB4 re akkor arra csökken amire be van állítva az OCR.
Ha használom az ADC bemenetet akkor olyan 2,5V -tól lefelé meg kezd "remegni" a led a fényerejét változtatja de itt is max fényerővel világít addig ameddig nem kap PB3 vagy PB4 jelet .
Mintha a COM0A1 és COM0B1 nem kapcsolna ki.
Ha OCR. 255 - re állítom akkor kicsapolnak.
A remegés meg gondolom az ADC átalakítással lesz valami.

Közel jársz a megoldáshoz. A lényeg, hogy modulonként érdemes felépíteni minden AVR-es programot, bármennyire is macera, meg "ezerszervótmá". Minden áramkör más és más.

Esetedben az ADC-t bezavarja a PWM-es lábak villogtatása. Erre megoldás, ha szűröd az ADC bemenetét: hardver ÉS szoftver szinten. Hardveresen a legegyszerűbb egy-egy 100nF-os kondi az ADC bemenet(ek) és a föld közé, és feltételezem hogy a táplábak közelében is van legalább kettő. A szoftver szűrés AVR esetén szinte kötelező: vegyél valami "kettőhatványa" mennyiségű mintát, add össze majd shift-eléssel oszd le!

És igen, ez a rész ami nálad problémás: minden ADC mintavételezéskor kiértékelés is van:
beállítod a PWM-et, számlálót, stb. Mire a PWM körbeér, csinálsz több száz konverziót!
Nem az a baj hogy párszáz konverzió lemegy egy PWM-es kör alatt! A baj az, hogy minden konverzióra jut egy kiértékelés ami így keményen ugrálni fog. Még akkor is ha nincs PWM.

Összefoglalva: csinálj annyi konverziót amennyi jólesik, ezeket átlagold le, és értékeld ki a programmal! Legalább egy PWM-kör fusson le mire kiértékelsz, ennél sűrűbben felesleges!

Jó tudni, hogy egyes PWM módokban az OCR regiszterek módosítása nem kerül át azonnal a "valódi komparátorba" ("update OCRxn at ..." rész). Ilyenkor le kell mennie egy körnek, mire az OCR regiszterbe írt érték "bekerül" a komparátorba! Ezért is felesleges egy körben százszor módosítani!

Azt is érdemes tudni, hogy zajos környezetben az ADC még átlagolva sem fog "rendes 0" értéket kiadni, ezért a "teljes kikapcsolás" köszöbértékét egy magasabb értéken (2-4) kell meghúzni.

Szia, szoftveres átlagolás helyett használt már valaki medián középértékkel ADC szürést? Vagy túlzatosan erőforrásigényes és nem alkalmazzák ilyen kis MCU -nál? Ugye a kapott értékek sorbarendezése a macera, viszont páratlan számu mintavételezésnél még osztani sem kell. Szerintem jobb lenne mint az átlagolás mivel a nagy "kilengések" nem zavarnának be az eredménybe mint a sima átlagolásnál. Lehet meg is próbálom

Jó trükk lehet még, ha szinkronizálod a PWM-mel az ADC-t. Akkor ha van is zavaró hatás, mindig hasonló lesz, és így nem lesz belőle ugráló hiba. Ugye mivel periódikus gerjesztésű a rendszer, ezért a zavarok is periódikusak lesznek. Emellé jöhet még az átlagolás, ritkább frissítés és hiszterézis. Úgy már tökéletes lesz.

Érzésre azt mondanám, hogy simán belefér a CPU idejébe egy ilyen implementáció, csak ki kell próbálni mi sül ki belőle.

Hátha itt lesznek ötletek a motorok vezérlésére:

A probléma leirása itt van:

Léptetö motorok.

Módosítottam rajta ahogy írtad.
Sikerült is nincs az a hiba ami eddig volt (részben).


Ezt bővebben kifejtenéd kérlek:
"Összefoglalva: csinálj annyi konverziót amennyi jólesik, ezeket átlagold le, és értékeld ki a programmal! Legalább egy PWM-kör fusson le mire kiértékelsz, ennél sűrűbben felesleges!"

Szia! Sikerült végül megoldani a problémádat? Nekem Atmega 128-nál csinálja ezt, úgy hogy eddig működött.

Helló.
Szeretnék egy függvényt meghívni, aminek átadhatok egy karaktert, vagy akár egy sztringet is, a függvénynek pedig tudnia kellene, hogy 1 karakterről van szó, vagy sztringről.
Meghívás így néz ki:

meghiv('F'); vagy meghiv("szoveg");

A meghiv függvény így néz ki:


Sztringgel működik, karakterrel sajnos nem.
Köszi.

Próbálkoztam kicsit, a meghiv("F") viszont működik. Tehát ilyenkor char helyett sztring-et küldök. Jó ez így? Pl. az Serial.print függvények automatikusan felismerik az adatot, hasonlót szeretnék én is.

Amit te keresel, azt függvény overloadingnak nevezik (pff, magyarul nem tudom ).
Itt találsz példákat:
https://www.tutorialspoint.com/cplusplus/cpp_overloading.htm

Köszönöm!

Két függvényt kell írnod hozzá. Az egyiket char típusú paraméterrel, a másikat pedig char * paraméterrel. Elméletileg csak C++ -ban működik, sima C-ben nem.

Függvény túlterhelés a kifejezés magyar megfelelője.

Ez inkabb csak forditas mint megfeleles