Fórum témák
» Több friss téma |
Kettő. Egyiken küldöd az adatot (TX), másikon fogadod (RX).
Sok helyen használhatod. Nemrég volt szó a HMI kijelzőkről itt a topic-ban, az is UART-tal kommunikál. De ezzel tudod a legkönnyebben a PIC-et a számítógéphez is kötni. Vagy nem ez volt a kérdés? 
De igen.
Az a kijelző engem is megihletett, úgyhogy érdekel ez az átviteli mód. Egyébként, miben jobb ez pl. az I2C-nél?
I2C-t még nem használtam, de szerintem nincs olyan, hogy "jobb".
Egyébként szerintem alapesetben ez a legegyszerűbb kommunikáció. Az 1-wire-től biztos egyszerűbb. Elektro.on: Igaz, ott a pont.  A hozzászólás módosítva: Máj 6, 2016
I2C -t még én sem használtam.
De az alapvető különbség az, hogy az I2C -nél van a master és több slave eszközt is fel lehet elvileg fűzni egy buszra.
Azért több eltérés is van, és nem ez az alapvető. Sebesség, max áthidalható távolság, Uart általában aszinkron IIC szinkron ,az órajel külön vezeték, azaz az adat a másik, vagyis egy időben csak egy irányba mehet a kommunikáció, stb.
Tiszta vizet a poharakba:
UART: aszinkron adatátvitel (nincs külön órajel vezeték), nagytávolságú, de nagyon lassú (~ms / bit) adatátvitelre. RS232 konverterrel pont-pont kapcsolat valósítható meg két eszköz között. RS485 -tel megoldható több készülék összekötése 2 vagy 4 veztékkel. I2C: már a neve is arra utal, hogy kártyán belüli kapcsolat megvalósítására készült. Külön órajel és külön adatvezetéket használ. Mind a kettő nyitott kollektoros meghajtású. 1-Wire: Egy vezetékes (és a föld) kommunikáció, aminél a vezeték a tápellátást is biztosíthatja. Lassú (8 .. 65 us / bit). A 1-Wire szabvány lehetővé teszi, hogy egy vezetékkel több eszközt is lehessen kezelni. Minden eszköz egy 64 bites egyedi azonosítóval rendelkezik (csere esetén a cím változást a program tudtára kell adni). Ha automatikus címfelderítést is meg kell valósítani a programozása a legbonyolultabb (64 mélységű, rekurzív eljárás). A hibadetektáláshoz CRC képző, ellenőrző rutint is kell írni.
Elvileg maga az internet is egy vezetékes. Ha az 1-Wire kommunikáció ilyen lassú, akkor az hogyan működik?
Idézet: „Elvileg maga az internet is egy vezetékes.” Inkább az Ethernet 10Mbit -es verziója, azzal a bizonyos BNC csatlakozókkal. A sok kontakthiba miatt mára már mindenki elfelejtette. Idézet: „Ha az 1-Wire kommunikáció ilyen lassú, akkor az hogyan működik?” Most tényleg csak én olvasom az adatlapokat????
Bocs, de nem gondoltam, hogy az internetnek is van adatlapja.
Mindjárt utána nézek.
Visszakérdeznék: Ha nem lenne a különböző megvalósításainak adatlapja, szabványa, leírása hogyan tudna az a rengeteg gyártó egymás termékeivel együttműködő eszközöket gyártani?
Gondolom, maga a működés van olyan formában leírva számukra, hogy abból ki lehessen fejleszteni egy eszközt.
Ilyen leírást szerettem volna én is beszerezni, mikor a DS1821-el szenvedtem. DE NINCS! Példaprogramok a DS 1820-hoz PIC16-ra. Az volt dömpingben. Illetve ugyanezen típushoz egy magyar nyelvű leírás. De abból is csak általánosságok derültek ki. Az időzítésekre és a jelalakokra vonatkozó leghasznosabb leírás a Wikipédián volt. Azt pedig már tényleg példaprogramokból kellett kimazsoláznom, hogy a biteket küldéskor, illetve fogadáskor jobbra, vagy balra kell léptetni. Egy értelmes, összefüggő, szájbarágós leírás sincs a témában. Ugyanez a bajom az I2C-vel is. Nem példaprogramok kellenek. Az csak egymás vak másolása. Még ha működik, akkor sem. Meg akarom érteni a felépítését, a működését. És ha ez már megvan, utána akarom használni. Amint egy oldallal korábban már írtam, mindenki, aki tanácsot adott az 1-Wire-el kapcsolatban, felhívta a figyelmemet a nagyon pontos időzítésekre. Miután sikerült megértenem a működését kiderült, sokkal rugalmasabb, mint azt legtöbben gondolják. Ha tudsz a kívánalmamnak megfelelő leírást I2C, SPI, UART vonatkozásában, és azt meg is osztod velem, nagyon szépen megköszönöm.
Hogyan lehetne a leghatékonyabban különböző portokon elhelyezkedő digitális be- vagy kimeneteket egy darab változóba bepakolni?
Pl. van 8 bemenetem ami összesen három különböző porton foglal helyet. Ezt szeretném egy 8 bites változóban kezelni. Pontosabban meghívni egy függvényt ami kiolvassa a bemeneteket és egy char típusú változóval térne vissza amiben a 8 bemeneten lévő értékek foglalnak helyet. C-ben programozok, de legjobb lenne talán in-line asm-ben egy gyors kód. Én ennyit tudtam csak kiötleni asm-ben:
Bár ez sem biztos hogy jó, rég nem programoztam assembly-ben. Van valami jobb ötlet ennél, ami gyorsabb?
Ilyesmire gondoltál?
Trükkös megoldás az ugrások elkerülésére.
Köszi. Ennél kevesebb utasítással igaz már nem lehet megcsinálni?
Én ezt a verziót használom (C18-al kicsit máshogy kell megadni a paramétereket, de kis módosítással azon is használható):
Még egy kicsit rövidíthetsz rajta.
Így kezded: MAIN CLRF BEMENETEk Ekkor a BCF sorokat elhagyhatod.
Tényleg, az úgy már egész gyors.
 A hozzászólás módosítva: Máj 6, 2016
Egy régi vicc jut eszembe, aminek a csattanója: Nem jól tetszik kérdezni....
Goooogle barátunk segít: Book of iButton Standards - Maxim THE I 2 C-Bus Specification Version 2.1 Az uart egy kicsit szerteágazóbb, de az "asynchronous serial communication standard" kérdésre a goooogle egy rakás dokumentumot ad. A kényes időzítésekről. Minden kommunikációnak van/lehet kétféle megvalósítása: 1 - a kontroller programból állítgatja a jeleket és figyeli a jelváltásokat, 2 - egy kis hardver modullal kezeli a kommunikációt, így mentesül a kritikus időzítésektől. Az első módszenél nincs addig gond, amíg egy időben csak egy folyamat zajlik, de amint más dologgal (az is lehet időkritikus) is foglalkoznia kell, előjönnek a problémák. A legtöbb PIC -ben van uart támogatás (hány, de hány programozott megoldás született azokra, amiben nincs 16C84), de az egyikban sincs 1-Wire. A másik dolog a megszakítás kezelése. A megszakítás lekezelése alatt a főprogram futása megszakad, idő telik el, ami alatt nem tudja figyelni a jeleket, lemaradhat lényeges döltések meghozataláról, beállítások elvégzéséről. Ezért többeknek kritikusnak tűnik a megvalósítás. Kicsit régebben, itt a fórumon tárgyáltuk ki, hogy a 1-Wire kommunikáció megszakítható a bites között is...
Ha kimenetet keszelsz így, nemkívánatos tüskék jelenhetnek meg amennyiben közvetlenül a PORT / LAT regiszterrel végzed a beállításokat. Inkább a memória egy rekeszében készítsd el a megfelelő mintázatot és onnan másold a PORT / LAT regiszterbe. Ez még a RMW hibától is megkímél...
Arra gondoltam én is, hogy ott már nem lenne jó.
De nem akar lefordulni.  Szintaktikai hiba, pedig én nem látok semmi hibát. Meg érdekes, hogy a függvényben létrehozott változót nem látja az asm programrészlet, csak ha globális változóként deklarálom. Az #asm #endasm direktívával meg végképp nem fordul le, nincs kiemelés sem. Ezért így próbálom, de nem jó:
Lehet függvényben sem működik...? Adatlap csak az if(), while(), for()-okra tér ki, hogy ezekben nem lehet használni. Mellesleg hogy is kell ezeket külön .asm fájlban tárolni és úgy hozzácsatolni a .c-hez?
Egy nyögvenyelősebb fejlesztés után mindig rá kell szánni egy kicsike időt, amíg leereszted a fáradt gőzt. Időnként látni kell valami szépet is. Gyönyörűen süt a nap, a középiskolák előtt a cicás friss tini lányok már egy szál semmiben flangálnak, eridj csajozni
De szép is lenne. Csakhogy a főnökeim még azt sem várják meg, hogy befejezzem az egyik projektet, mielőtt másikat adnának. A csajozásról meg csak annyit, hogy irgalmatlanul t...kön rúgna a feleségem, ha megpróbálnám.
C18:
XC8:
Példával nem sokra megyek így magyarázat nélkül. Minek oda az a 0x7f?
Az xc8 manual-jában is szerepel ez a 0x7f példaként, de nem találtam rá magyarázatot:
De nem fordul le így se. Kiszűrtem, hogy a BTFSC-ben lévő definícióval van a baja. Így le fordul:
Így meg nem:
Mellesleg nem szeretném minden sor előtt használni az asm(); funkciót.
Én azt találtam, hogy azért nem működik mert idézőjelek között szerepel és azt string-nek veszi az előfordító, ezért nem tudja behelyettesíteni.
Az #asm #endasm tagok között működnie kellene, de mégsem működik...
Ez mi akar lenni? "Book of iButton Standards - Maxim" Mert ha ezt szántad az 1-Wire dokumentációjának, ez az általam megfogalmazott leírás igény kapcsán csupán 158 oldal tömény mellébeszélés. Az I2C leírás már jóval többet mondó. Mármint azok számára, akik valamilyen iskolában már megtanulták az I2C alapjait, működését, konkrétan ilyen vonalon tanulnak és mozognak, valamint leállamvizsgáztak műszaki angolból. De egy hobbista majom, mint én, ebből ugyan nem tanul meg semmit. Össze - vissza csapong a témák között, nincs benne rendszer, és legfőképp pedig nem azzal kezd, hogy elmagyarázza mi is az az I2C. Pedig a 4. oldal elején még úgy tűnt, hogy lesz egy szép kerek leírás, de végül nem lett.
Többször hangsúlyozod az adatlap végigolvasását. Olvasgatom én szorgalmasan. Csakhogy mivel a PIC adatlapok rendszerében sem leltem még logikát, így bizonyos dolgokat nehezen, vagy egyáltalán nem találok meg. Pedig azok is jól indítanak. Előszőr rajz a PIC-ről és a lábak kiosztásáról, azután táblázat a lábak funkcióiról, de utána vége. Előszőr talán az utasításkészlettel és az utasítások leírásával kellene foglalkozni. Azután a regiszterek felsorolásával, és azok táblázataival. Így megkapjuk az alapot. De nem. Ezen dolgok a több századik oldalon vannak. Többnyire rendszertelenül. Amikor a PIC18F46K22-es D portjával szenvedtem, megírtad nekem, hogy azok már más tartományban lévő bankban vannak. Szuper. Később nekiveselkedtem az adatlapnak, de sehol nem leltem azt a leírást, amely megmondaná, hogy figyeljek oda a regiszterek tartózkodási helyére, mert ez és ez a tartomány másképp hívható meg. Pedig lehet, hogy ott van valahol az 575 oldal valamelyikén, csak épp nem a legelején, ahol lennie kellene. Épp azért van ez a fórum, hogy azok, akik iskolájuk, szakmájuk, sok éves tapasztalatuk vagy jó ötleteik alapján tudják, azok segítsék a kezdőket, a kevesebbet tudókat. Mármint ha van türelmük és kedvük hozzá. Köszönök minden eddigi,és ez utáni segítségedet, de ezzel most nem jutottam előrébb. Idézet: „Az xc8 manual-jában is szerepel ez a 0x7f példaként, de nem találtam rá magyarázatot:” Nézd meg a PIC16 család utasítás kódolásában a field regiszter elérését. Az utasításkód alsó 7 bitje határozza meg a field regiszter címét. Hogy 128 resiztrenél több van a PIC16 -ban? Az alsó 7 bithez hozzáteszi a STATUS RP1 és RP0 bank kiválasztó bitejelt és ezzel meg is van a 9 bites RAM cím. A továbbfejelesztett 16F1xxx családban már 32 bank lehet, itt az alsó 7 bithez a BSR regiszter 5 bitjét használják a cím előállítására. A regiszterek címe tehát 9 ill. 12 bites, de az utasítás közvetlenül csak az alsó 7 bitet tartalmazza. Azért alkalmazzák az "& 0x7F" -et, hogy a felső bitek eltünjenek, ne okozzanak figyelmeztetést. Idézet: „asm("BTFSC PORTB, 2");” A C nyelv kisbetű - nagybetű érzékeny. Idézet: „Mellesleg nem szeretném minden sor előtt használni az asm(); funkciót.” Sajnos ez nem szeretet kérdése, csak így fogadja el a fordító. Másik lehetőség egy asm állomány felvétele a projectbe... Idézet: „Ez mi akar lenni? "Book of iButton Standards - Maxim" Mert ha ezt szántad az 1-Wire dokumentációjának, ez az általam megfogalmazott leírás igény kapcsán csupán 158 oldal tömény mellébeszélés.” Érdekes módon a 4. fejezet részeinek címei: 1-Wire (TM) Interface - Timing, 1-Wire Interface - Electrical... Ez alapján készítettem el a ROM felderítő rutinomat, kíválóan működik... Az I- button tulajdonképen egy 1-Wire memória egy kis tápellátással, rf adatátvitellel. Idézet: „Az I2C leírás már jóval többet mondó...Pedig a 4. oldal elején még úgy tűnt, hogy lesz egy szép kerek leírás, de végül nem lett.” Ez maga a Philips által kiadott dokumentáció. Lapozz a 8. oldalra... Idézet: „Pedig azok is jól indítanak. Előszőr rajz a PIC-ről és a lábak kiosztásáról, azután táblázat a lábak funkcióiról, de utána vége.” Az adatlapok szerkesztéséről: Az információkat (sajnos) a gyakorlottabb felhasználók igényei szerinti sorrendban adják meg. Egy rutinos felhasználót általában a lábkiosztások (tokozás típusával változhat) és a lábak funkciója érdeklik. Aztán a jelszintek, áramok, időzítések, stb. Rengeteg adatlapban az elektromos adatok is elől vannak. MCP4922 Ezután jönnek a részletesebb leírások. Egyes gyártóknál az adatlap csak utal a család részletes elírására (ld. PIC32). Az utasításkészlet nekik már nem fontos, tudják... A PIC16F, 18F családban még minden típusnál az adatlap tartalmazza a teljes utasításkészlet részletes leírását, másoknál külön dokumentum... A Microchip adatlapokban a tartalomjegyzék megjeleníthető, segítségével egyből a megfelelő fejezetre lehet ugrani (Regiszterek -> Memory Organization / Data Memory Organization) Idézet: „Amikor a PIC18F46K22-es D portjával szenvedtem...” Nekem sem volt más forrásom, csak az adatlap 5-5 ábrája: Idézet: „Note 1: Addresses F38h through F5Fh are also used by SFRs, but are not part of the Access RAM. Users must always use the complete address or load the proper BSR value to access these registers.” Magyarul: Az F38h -tól F5Fh -ig terjedő címeket is elfogllaják a speciális célú regiszterek, de ez a tartomány nem része az ACCESS BANK -nak. A felhasználónak mindig a teljes címet kell használnia vagy a BSR regisztert kell helye értékkel feltöltenie, hogy elérje ezeket a regisztereket. Idézet: „...valamint leállamvizsgáztak műszaki angolból....” Nekem sincs érettségim sem nyelvvizsgám angolból. Sőt amikor suliba jártam még oroszt kellett tanulnom. Az angol nyelvű dokumentációvan még csak-csak meg lehet bírkózni. Valaki érti a mellékelt Microchip PIC adatlapját? Eddig még olvashatók voltak az alkatrészek dokumentációi, de az újabbak között egyre gyakrabban fordulnak elő csak kínai, csak japán nyelűek.... A hozzászólás módosítva: Máj 7, 2016
Köszi, ezt majd megemésztem, de ettől még nem fordul le.
Hogy jön ide a kisbetű, nagybetű? Mindkét változatot nagybetűvel írtam a manuálban található példák alapján, de a 2. hozzászólásomban írt hiba miatt nem működik ha #define tagot használok. Márpedig #define nélkül nem fogom használni. Hi-Tech C-ben nem volt problémám az in-line asm-mel de ez az xc8 a manuálban ajánlott #asm #endasm direktívákat sem ismeri. Most próbáltam, egyedül úgy működik ha így definiálok minden bemenetet:
Nem a legszebb megoldás, de ez van. Illetve még így is lefordította:
De, hogy működik-e azt még nem próbáltam. Vagy tudsz jobb megoldást? A hozzászólás módosítva: Máj 7, 2016
|
Bejelentkezés
Hirdetés |
