No, majd kipróbálom. Kicsit át kell dolgoznom, de jó lesz szerintem.

Köszi!

Hasonló logikai szintű funkciókkal 32 bit alatt nem kellene próbálkozni. Kell a ram is, meg az órajel is, 8 és 16 bit gyengécske hozzá.

PIC32 családot ajánlom. Legnagyobb előnye, hogy lehetőség van a programot RAM -ból futtatni.
Nem elég a folyamatnál a belépési pontot ill. a félbeszakítási pontot menteni, a kontroller állapotát is menteni kell: regiszterek beállításai, stack, stb.

A "legegyszerűbben" az nagyon relatív fogalom.
Ha van kéznél egy Arduino, egy 9 V-os elem, és egy NPN tranzisztor, akkor úgy is lehet, ahogy ennek az előadásvázlatnak a végén leírtam.

Letölthető (általam módosított) kód és mintapélda ezen a honlapon, a 2017. április 27-i előadás mellékleteiként található.

Ha nincs kéznél Arduino, akkor egy PICkit klón beszerzését tartom a "legegyszerűbb" útnak.

Klassz az előadássorozatod!

Sziasztok!

A segítségeteket szeretném kérni, egy 12f617 el kapcsolatban. A vezérlőt egy li ion akku táplálja meg, ami 4,2-3,7V ig változtatja a feszültségét. A probléma az lenne, hogy analog bemenetem is van. A tápfesszel a referencia feszültsèg is változik. Hogy ezt kikerüljem a belső 0,6V os referenciàt hasznàlnàm. Ha jól érzelmezem az adatlapot, akkor ez működőképes kell, hogy legyen. Persze az analog feszültséget, a 0,6 V os szintre osztom le fesz osztóval.
A kérdésem az lenne, hogy jól gondoltam amit építeni szeretnék?

Köszi!

A 0,6V-os referencia a komparátorhoz tartozik, nem az AD konverterhez.

Használj külső referencia feszültséget, más lehetőség nincs az adott kontrollerrel. 2,5 - 3 V közötti jó lehet. Pl.: Bővebben: Link.

Oké, köszi szépen.

Az A/D bemenetére a négy AN lábon kívül ki tudod választani a CVREF, a 0.6V-os és az 1.2V-os belső referencia feszültségeket is. Ezek közül bármelyiket lemérve vissza tudod számolni az aktuális tápfeszültséget, abból meg már az AN bemenet konkrét feszültségét is meg tudod határozni.

CVREF azaz comparator VREF. Nem AD VREF. AD VREF-nek nagyobbnak kell lenni mint 2 volt. 2.56 V Vref-nel az AD egy osztasa 2.5 mV. Konnyu szamolni vele. Tapot leosztani 2-vel, igy egy osztas 5 mV. Tehat Mert fesz: Ux = AD * 5 /1000. Igy a vegertek 5.12 V. Ez egy elem meresere maximalisan elegendo".

Üdv!
Szeretnék egy multiszenzoros hőmérő rendszert készíteni. 15-20 egymás mellett levő egyenként 100W infrafóliával fűtött fémlapok hőmérsékletét mérni és kapcsolgatni. Több koncepción gondolkodtam, a vezetékek száma és a kommunikáció miatt. Volt olyan, hogy mindegyibe rakok egy-egy vezérlőt és kivülről csak a hőfokot adom meg visszajelzés nélkül. Gondoltam wifi-s kommunikációra is. Végül az 5-6m kommunikációs kapcsolat a lehető legkevesebb ér mellett valamint a vezérlők minimalizálása miatt a 1-wire-es maxim csipekre jutott a választás.Ez elvileg elmegy a kívánt hosszon. Csinált-e már valaki hasonlót?
Kérdések:
- 15-20 szenzor esetén megbízható-e a 2 vezetékes táplálás, (VDD az adatvonalon)?
Ez nyilván összefügghet a lekérdezések sűrűségétől is.
- Sebesség: Az IIC a kábelhossz,árnyékolás miatt kiesett, vagy csak nagyon kis
sebességen ment volna. A 1-wire sebessége mennyire bírja ezeket?
Nem néztem még meg az összes típus adatlapját, hogy konkrétan melyik típus lenne legmegfelelőbb (18B20,18S20,1822...).
Kérdem akik már csináltak maximos hőmérőt.
1 szenzor lekérdezése gondolom nem eszik meg sok processzoridőt, 15-20 esetén is kellene még maradni a kimenetek ki-be kapcsolgatására,kijelző frissítésre, időzítésre, fel-le futás végrehajtására. Az IIC-hez vagyok hozzászokva, meg néha SPI vagy UART, nem tudom a 1-wire mit bír dróton.

Bármilyen véleményt szívesen fogadok, még nem tudom mi vezérli majd, ha 8 bites elbírja akkor az lesz ASM-ben, ha nem, vagy később bővítem akkor 32-es lesz C-ben.

Ilyen rendszerhez jo lehet a DS18B20, mert minden IC rendelkezik egyedi 64 bites azonositoval. Tehat 2 vagy 3 vezeteken sok IC-t lehet kezelni. Sima 8 bites UC-vel kezelheto. 2 lab kell a vezerleshez. Egyeduli problema, hogy 1 IC converzios ideje eleg nagy. 93-750 ms, a felbontastol fuggoen.

Nálam 7 db ds18b20 volt a maximum (nem volt több itthon) esp8266 on (ez kb mindegy). 3,3V tápfeszültséggel.
Viszont rendes tehát nem parazita tápellátással. Pic re kötve kb 10 m es riasztókábelen megy egy már kb 5 éve, tehát szerintem a távolságot is bírja.

Sziasztok!

Ha van 2 PIC ( vagy akármi más) ami uarton kommunikál egymással, Akkor azzal megcsinálhatom ( valahogy azt) hogy egy USB/UART modul RX lábával ráakaszkodom a kommunikácio egyik RX/TX vagy akár mindkét száljára?
Csak monitorozás képpen! Hogy a PC-n láthassam milyen kommunikácio folyik?

Mondtam egy szóval is, hogy az lenne az AD VREF-je? Annyit mondtam, hogy az AD-t tápfeszültség referenciával használva meg tudod mérni ezeknek az értékét. Innen már visszaszámolható az aktuális tápfeszültség.

Ugye azt észben tartod, hogy az uart az nem ttl jelszint?

Ha uarton kommunikálnak amazok ketten, és tudod a kommunikáció sebességét és egyéb paramétereit (paritás és stop bitek, sw handshaking), akkor a ráolvasás működhet.

Ha a panelek egymás mellett vannak, normális az érintésvédelem rajtuk (biztonsági trafóval van leválasztva), akkor nyugodtan kerülhet a vezérlésük galvanikusan azonos rendszerbe, és egybedrótozhatod őket, ahogyan csak akarod. Fentebb már írták, hogy szenzor gyanánt van 1-wire cucc. A sebesség nem kellene, para legyen. Véges sebességű sima fűtőtestekről van szó, nem virgonc kölyök nyusziról Bőven elég oda a 8 bit is, ha a felhasználói beavatkozást meg tudod azon csinálni, mert elvileg vezérelni is kell tudni azon keresztül. Ha csak valami sima potmétert kötnél rá, vagy olyasmik, nem kell oda több. Ha mobil telefonra akarsz java programot távvezérléshez etherneten keresztül, ott esetleg elkezdődhet a gondolkodás, mi fér el 8 bitben, és mi nem.

Kis gyors segítség kellene:

USART megszakításban küldök az áramkörnek egy parancsot amivel a lock_bits_level_2 =0x7
Ekkor az if feltételben levő dolognak ami a main-ben van nem szabadna végrahajtódnia de mégis mintha semmi sem történne és ott a változó értéke mindig mintha nulla maradna.
Pedig ha USART ról visszaolvasom a lock_bits_level_2 értékét az szépen 0x7.
Miért van ez?



a változó deklaráziója ez:
uint16_t lock_bits_level_2=0;

A változó deklarációját módosítsd erre:

Köszönöm így már jó ez a rész.
Van 1-2 másik változó is ami gyanúsan hasonló probléma miatt nem megy akkor azokat is ítárom.
Viszont nem igazán értem ennek a működését hogy mi hol és hol nem tartja meg az értékét.
Az usart megszakításban kb 10-15 változó értékét tudom állítani és van ami látszólag gond nélkül megy. USART megszakításban átírom az értékét és a main-ben pedig azzal kalkulál.

Tehát akkor mik azokat amiket minkenképpen így deklaráljak és mik azok amiket hagyhatok?

Ha a fordítóprogramban be van kapcsolva az optimalizáció, akkor azt feltételezi, hogy egy változó értéke csak akkor fog megváltozni, ha értékadás bal oldalán szerepel (ez így logikus is, ezt kihasználva gyorsabb kódot tud létrehozni). Csak éppen ha a változó értéke az adott programszáltól függetlenül megszakításban, vagy a hardver által történik meg, arról nem tudhat az adott programszál. A volatile letiltja az adott változóra történő optimalizálást, így minden esetben újra beolvassa az aktuális értékét, lassabb programfutást eredményezve. Azokat a változókat kell ilyen módon definiálni, amik több programszálban is fel vannak használva. Ilyenek a megszakításban és azon kívül közösen használt változók, meg a perifériák memóriahivatkozásai.

Az & operátor bit szintű műveletet végez, (0x7 & 0x1)==1, ami boolean-ként kiértékelve igazat ad. Hogy értetted azt, hogy az if()-nek nem szabadna végrehajtódnia?

A pic nem sok szálas környezet, az a volatile maximum akkor lehet jelentős, ha azt a 16 bites változót egy interrupt alól is kezelni akarod, meg azon kívül is, és mindazt egy 8 bites pic-en akarod csinálni. 16 és 32 bites pic-eken a 16 bites változó töltése atomic művelet (feltéve persze, hogy a tárolása legalább 16 bit határon van, de optimalizációk végett jellemzően az teljesül).

Vitatkoznék:

A PIC16 -ot lehet kétszálas, a PIC18 -ot lehet háromszálas programmal működtetni. Azonban egy 8 bites változó kezelése is okozhat gondot, ha több szálból kezelik. A fordító nem garantáltan "helyben" változtatja meg a változó értékét. pl. a valtozo += kifejezés nem biztosan addwf valtozó,f utasításra fordul. Ezt a kezelést kényszeríti ki a volatile.
Nézzük az az esetet, amikor a valtozo = kifejezés vagy változo &= mask után közvetlenül jön a valtozó += masik_kifejezés vagy valtozó |= masik_kifejezés. Ekkor az első utasítás után a valtozo értéke már a WREG -ben lehet és ezt az optimalizáció ki is használhatja. Ha ezen két utasítás között a megszakítás megváltoztatja a valtozo értékét, akkor a második utasítás nem veszi azt figyelembe.

Azok a szálak nem tudom, milyen modellezések. A pic-ek nem hyperthread-esek, és nem több magosak.

Interrupt tud közbejönni. Elég a global interrupt enable bitet menteni / törölni / utána végrehajtani / helyreállítani. Pontosan azt hivatott csinálni a volatile olyan esetekben, amikor több darabban kezelne asm utasításokkal egy logikailag egybetartozó változó értéket (mint pld a 16 bites változók a 8 bites pic-eken).

Annyi lett volna a mondanivalóm, hogy 8 bites változónál is okozhat problémát, hogy a megszakítás(ok)ból is kezelünk nem volatile -nek deklarált változót. felhasználhatja, hogy a legutóbbi módosítás értéke más regiszterben már benne van, átmeneti értéket is tárolhat benne, ha a kifejezés kiértékelése ettől rövidebb lesz. Pontosan a XC8 esetében láttam rá példákat.

Szálkezelés nem csak többmagos rendszerek esetén létezik (bár ott van igazán értelme).
Alapvetően a szálak annyi előnnyel vannak a folyamatokkal szemben, hogy a szálak felhasználó szinten futnak, míg a folyamatok váltása kernel műveleteket is igénybe vesz, ami sokkal inkább erőforrásigényesebb. (Ez modern operációs rendszerek esetén érvényes.)

Ha szálkezelel, akkor tulajdonképpen a folyamat egyes részeit darabolod fel, és kiadod feldolgozásra. Egy processzoros rendszeren ennek annyi előnye van, hogy ha több folyamatot (vagy szálat) szeretnél futtatni, és látszólag egy időben szeretnéd futtatni őket, akkor a folyamatütemező ezt megoldja neked, szemben a "kötegelt" feldolgozással.

Ha olyasmi eset miatt aggódsz, hogy regiszterbe vetted a változó értékét, abban módosítod, és mielőtt kiírnád memória területre, akkor kapsz egy interruptot, olyasmitől nincs mit félni. Valójában csak utasítássorrendnyit változott a helyzet ahhoz képest, hogy az az interrupt talán egy kicsit később érkezik meg / vagy éppen sokkal előbb, és ha mindkét oldalon írod a 8 bites változót, annak a folyamatnak a "véleménye" lesz benne végül, amelyik később írt bele. De az program feature, és nem integritás hiba. Az integritás hiba az, ami ellen a volatile-nak védenie kell, folyamatszervezési sajátosságokkal bíbelódni szerintem nem fogja megtenni. Persze ha írsz egy példakódot xc8 alatt, és megnézed a list kimenetet a linkerről, mit fordított asm kód gyanánt, igazából akkor derül ki, hogy volatile vagy nélküle van-e bármi különbség.

Tapasztalatból írtam, amit írtam. Pontosan akkor vált egyértelművé, amikor megnéztem a fordított assembly kódot, hogy 8 bites változók esetében is kell a volatile, ha több "szálból" módosítjuk az értékét. Esetemben a nem volatile változó esetében egy utasítás végrehajtása során többször írt értéket a változóba. Akkor jelentkezett a probléma, amikor ezen utasítást alkotó utasítások között fogadott el megszakítást.

Persze hogy kell, alapszabály. Egyébként AVR fórum, fejléc, 1. pont.