Fórum témák

» Több friss téma
Fórum » PIC programozás assemblyben
 
Témaindító: sonajkniz, idő: Máj 30, 2015
Témakörök:
Lapozás: OK   20 / 32
(#) Hp41C válasza sonajkniz hozzászólására (») Nov 25, 2019 /
 
Arról lenne szó, hogy a valódi véletlen szám teljesen egyenletes eloszlással szolgáltatja a véletlen számokat egy megadott intervallumban. A Pseudo Random Number Generátor matematikailag "kutyaütő" ebben a tekintetben, hiszen egy meghatározott algoritmus szerint (azaz nem teljesen véletlenül - ahogy a nevében is van) adja azokat. De a legtöbb esetben a feladatokhoz elegendő egy "jó nagy ciklussal" rendelkező verzió ahhoz, hogy a szemlélő véletlennek lássa. Jelen esetben azt lehetne elkövetni, hogy a véletlen szám generátor indítását még változatosabbá lehetne tenni egy nem bekötött A/D csatorna alsó bitjelit felhasználva.
Rengeteg kód van a már belinkelt oldalakon és továbbiak is találhatók a random number genrator pic16 kérdéssel. AN544
A LED -ek villogásából nem fognak metemetikai következtetéseket levonni, ahol számítana ez a kis csalás.
(#) sonajkniz válasza Hp41C hozzászólására (») Nov 25, 2019 /
 
Nem is ez a lényeg. Mert ha valódi véletlenszámokat akarunk generálni, akkor fogni kell egy COMMODORE 64-est. Az ugyanis a SID csip fehérzaj generátorától kunyerálta a véletlenszámoz kellő alapot.
Jelen esetben a kérdező gombnyomással akarja a folyamatot újra és újra indítani. Ehhez pedig a legjobb alap, ha a PIC bekapcsolásától folyamatosan pörög a 16 bites számlálója, és a gomb lenyomásakor innen veszi a mintát. Néhány LED véletlenszerű villogtatásához
(#) sonajkniz hozzászólása Dec 19, 2019 /
 
Sziasztok!
Tudna valaki segíteni?
Vettem két eszközt. Egy ilyet, és egy ilyet.
Mindkettőnek jó terjengős adatlapja van, valamint a net tele van arduino példaprogramokkal és könyvtárakkal ezen eszközökhöz.
A gond csak az, hogy én PIC-et programozok és ráadásul assemblyben.
Azaz szükségem lenne arra az információra, hogy ezen eszközök milyen parancsokat kérnek, milyen formában kérnek és adnak adatokat, meg egyáltalán milyen sebességű a kommunikációjuk.
Sajna az adatlapokat olyanok számára készítették, akik vagy látnokok, vagy csak arduinoval foglalkoznak.
Egy olyan szintű adatlapra, leírásra lenne szükségem, mint a DS18B20-as hőmérséklet szenzoré.
Előre is köszönöm a segítséget.
(#) Massawa válasza sonajkniz hozzászólására (») Dec 20, 2019 /
 
ASMben meg kell irnod az I2Ckommunikacios protokollt. (vagy letölteni valahonnan),. Abban megtalalod a valaszokat.
(#) Peter65 válasza sonajkniz hozzászólására (») Dec 20, 2019 /
 
Szia!
Pedig ezekből az adatlapokból kell dolgoznod, és szerintem minden benne van.
Az elsőnek a TM1637 a vezérlő IC-je egyedi protokollal, ami az I2C-hez hasonló, de eltér attól. Az adatlap szerint max. 500kHz lehet a kommunikáció órajele. A másiknak az APDS-9960 a lelke, a szabványos I2C-t használja max. 400kHz-es órajellel (az adatlap feltételezi, hogy az I2C-t ismerjük).
Ha assemblyben dolgozunk, akkor mindent kézben tartunk, aminek vannak előnyei, de meg van az a hátránya, hogy az apró részleteket is nekünk kell kimazsolázni, ami bizony fárasztó és időigényes. A mai "instant" kultúrában nem annyira népszerű egy ilyen feladat. Hogy észszerű-e, azt neked kell eldöntened.
(#) Pali79 válasza Massawa hozzászólására (») Dec 20, 2019 /
 
A legtöbb PIC-ben van hardveres I2C, csak be kell állítani....
(#) Massawa válasza Pali79 hozzászólására (») Dec 20, 2019 /
 
PIC-kel mar regen nem foglalkoztam, de az AVR-hez nemreg irtam ilyen protokollt. Gondolom a PIChez is ugyanugy kell. A HW nem eleg, az csak jellemzöket garantalja.
(#) Pali79 válasza Massawa hozzászólására (») Dec 20, 2019 /
 
Idézet:
„A HW nem eleg, az csak jellemzöket garantalja.”
De, pont elég... Beállítod amiket kell, bedobod a bufferbe az adatot és már küldi is.
(#) Massawa válasza Pali79 hozzászólására (») Dec 20, 2019 /
 
Az AVR-ben is ott a HW megis vagy 100 soros protokoll kell, hogy megszolitsa az I2C. A makro utanna mar kezeli a kommunkaciot (cimeket, irast olvasast es a byteket). Csodalkoznek, ha PIC ezt alapbol tudna, de kizarni nem akarom. Az Arduinoban is eleg hosszu a wire.h protokoll.
A hozzászólás módosítva: Dec 20, 2019
(#) Pali79 válasza Massawa hozzászólására (») Dec 20, 2019 /
 
Idézet:
„Az AVR-ben is ott a HW megis vagy 100 soros protokoll kell, hogy megszolitsa az I2C.”

Nem értek az AVR-hez (sem) de emlékeim szerint I2C HW-t nem tartalmazó PIC-ek esetén a komplett SW kommunikációs rutin sincs 100 sor.
(#) sonajkniz hozzászólása Dec 20, 2019 /
 
Nem értem, mi köze a kérdésemnek az I2C-hez.
Parancsokra vár az eszköz. Mindkettő. De hogy mik ezek a parancsok, az nincs benne egyik adatlapjában sem.
Pl. a DS18B20-nál le van írva, hogy előszőr ki kell adni neki a 0XEE parancsot, amire elvégzi a mérést. Meg kell várni, míg végez, majd el kell küldeni a 0XAA parancsot, hogy kiadja az adatokat.
Itt is kell valami parancs, hogy épp a fényerőt akarom-e állítani, vagy a gombokat kérdezem le, vagy épp valamelyik karaktert módosítom. Ezeket nem találom sehol
(#) Massawa válasza sonajkniz hozzászólására (») Dec 20, 2019 /
 
Az egyik kütyü kimondottan I2C-t ker. SDA/SCL Azaz csak azon keresztül tudod megszolitani es lekerdezni. A masik egy mas protokollt ker. Ennyi.
A hozzászólás módosítva: Dec 20, 2019
(#) Pali79 válasza sonajkniz hozzászólására (») Dec 20, 2019 /
 
Pedig a HEsore oldalán lévő adatlapban, legalábbis a LED kijelzőjében benne van, a 4. oldalon kezdődik és nagyjából úgy van leírva mint a 2×16-os LCD kijelzőnél. Pl. az írás parancsa a7. bit 0, a 6. 1, 5-től 2-ig mindegy, az 1 és 0 bit 0. Ez az írás parancsa. Az olvasás ugyan ez csak az 1. bit 1.
A fényerő, gondolom a PWM kitöltésével állítható ennek a parancsa az 5. oldalon lévő táblázatban van: b'1000000' 1/16 kitöltés, b'1000001' 2/16 kitöltés, stb.
(#) Massawa válasza Pali79 hozzászólására (») Dec 20, 2019 /
 
Most telorol irok igy nem tudom megnezni, de eleg sokat szivtam az I2C-vel(idözites, stb) . Igaz, hogy intelligensebbre irtam. Különvalasztva a cimezest, irast olvasast es az adatbytekat. Igy ezekeg mar makro kezeli cim, RW, D1, D2 formaban
(#) usane válasza sonajkniz hozzászólására (») Dec 20, 2019 /
 
Ezekben is le van írva, csak nem ilyen egyértelműen. Belenéztem mindkettőbe, a kijelző nem olyan vészes, a szenzor egy kicsit kacifántosabb, de abban is le van írva minden. Ha tudsz angolul akkor összerakható. Segítenék összerakni, de most rengeteg melóm van. Ha nem olyan sürgős hétvégén összejöhet, ha addig nem bogozod ki.
(#) nedudgi hozzászólása Dec 20, 2019 /
 
Az I2C kommunikáció egyik buktatója az, hogy időnként a slave eszköz ACK helyett küldhet NAK-ot is, erre is fel kell készülni programban. A pontosabb részletekre nem emlékszem, hét éve lehetett a dolog, és azóta leszoktam az I2C perifériákról. Sajnos a projektek történetét már nem tudom rekonstruálni, minden lehetséges és lehetetlen esetet le kell kezelni a programban.
(#) Massawa válasza nedudgi hozzászólására (») Dec 20, 2019 /
 
Igy van, sajnos van benne egy sereg ilyen dolog es azt mind kezelni kell vagy megbizhatatlan lesz. Szerintem van valhol kesz I2C makro is a neten csak keresni kell. Mikor elkeszült az enyem masnap teljesen veletlenül egy keszet is talaltam.
(#) sonajkniz hozzászólása Jan 1, 2020 /
 
Sziasztok!

Először is boldog új évet mindenkinek.

Számomra megjött 2020 első sikerélménye. Sikerült működésre bírnom ezt a kijelzőt.
Csak szoftveres kommunikációval jött össze, mert elég ravasz a protokolja.
Auto increment módban használom, de a mellékelt ábra hibás. Viszont a "fixed address" ábra jó.
Az szerint küldve az adatokat szépen működik.

Köszönöm mindenkinek a segítséget!
(#) nemgyuri hozzászólása Ápr 2, 2020 /
 
Sziasztok! MPLAB szimulációban szeretnék adatokat bevinni soros portra. RCREG-et nem tudom írni, csak a TXREG-et. Próbáltam a az RB1-et "stimulálni", de semmi sem történt. Van valami módszer amivel tudnám tesztelni a soros kommunikációt? (Egyenlőre még nem fix a PIC tipusa, csak az, hogy legyen benne UART.)
(#) sonajkniz válasza nemgyuri hozzászólására (») Ápr 2, 2020 /
 
Idézet:
„Egyenlőre még nem fix a PIC tipusa, csak az, hogy legyen benne UART”

Minek?
Ha már assemblyben programozol, hatékonyabban működő rutint tudsz írni, mint a hardveres beépített kommunikációja.
Én még az I2C-t is szoftverből kezelem.
A hozzászólás módosítva: Ápr 2, 2020
(#) Hp41C válasza nemgyuri hozzászólására (») Ápr 2, 2020 /
 
Készíts egy szöveges állományt az alábbiak szerint
Sor(ok)ban írd le a "venni kívánt" adatok ASCII kódjait
pl.: 41 42 43 az "A" "B" "C" karaktereket adja meg.
Ezen kívül szerepelhet benne még a wait utasítás (különálló sorban).
pl.: wait 2 sec vagy wait 5 ms stb.
MpLab indítás a projecteddel:
1. Debugger / Stimulus menüpont
2. New Workbook (később lehet Open Workbook, ha már egyszer elmentetted )
3. Register injection fül
4. A legfelső fehér sorban a Reg/Var mezőjében az RCREG kiválasztása,
5. A Data Filename mezőben az előbb megszekesztett állomány betallózása,
6. Opcionális: Wrap mezőben a "Yes" azt jelenti, hogy az állomány végéről automatikusan az elejére ugrik és kezdi újból,
7. Format: Pkt,
8. Opcionális Save -- Mentés...,
9. Apply
Nem zárjuk be az ablakát.

Újrafordítás, az RCREG kiolvasásához töréspontot célszerű tenni.
Indítás. És láss csodát, amikor megáll a program az RCREG -ből (a fenti példánál maradva) az A betü kódját (0x41) lehet kiolvasni.
(#) Hp41C válasza sonajkniz hozzászólására (») Ápr 2, 2020 /
 
Idézet:
„Ha már assemblyben programozol, hatékonyabban működő rutint tudsz írni, mint a hardveres beépített kommunikációja.”

Nem vagyok benne biztos. Főleg nem az UART esetén, ahol programból várni a stat bitet elég időigényes.
(#) Pali79 válasza nemgyuri hozzászólására (») Ápr 2, 2020 /
 
(#) nedudgi válasza sonajkniz hozzászólására (») Ápr 2, 2020 /
 
Ezt értsük úgy, hogy hatékonyabb (gyorsabb, kisebb) soros vételi rutint tudsz írni, mint egy hardveres soros port? Működik duplex módban is?
(#) nemgyuri válasza Hp41C hozzászólására (») Ápr 2, 2020 /
 
Nagyon köszönöm! Majdnem így próbáltam csak mégsem - a karaktereket írtam nem a hex-et.
(#) nemgyuri válasza sonajkniz hozzászólására (») Ápr 2, 2020 /
 
Szia! Nekem most fontos, hogy a háttérben menjen a soros port kezelése...
(#) nemgyuri válasza Pali79 hozzászólására (») Ápr 2, 2020 /
 
Köszönöm, jó ez a videó...
(#) sonajkniz válasza nedudgi hozzászólására (») Ápr 2, 2020 /
 
A hardveres átvitel egyetlen előnyének az nevezhető, hogy megszakításbol tudod figyeltetni a start hitet, illetve az adat beérkezését, vagy elküldését. Így elvben, amíg az adat utazik, a proci csinálhat mást. Már legalábbis akkor, ha az adatátvitel alacsony sebességen történik, a proci meg nyélgázon megy.
De igazság szerint amit vesztessz a révén, korántsem nyered vissza a vámon. Mivel maga a megszakítás is hardver időt emészt fel, és ha más, mások is kiválthatnak megszakítását, akkor még ott vannak a vizsgálatok is, így még akár rosszabb is lehet a hardveres.
Azon eszközök esetén látom csak értelmét ahol nem 1 byte az átvitel, hanem megpakolható egy legalább 8 byteos puffer, és egyben elküldhető. A vétel pedig automatikus, szintén pufferbe.
Ilyen pl. a Nextion.
(#) sonajkniz válasza Hp41C hozzászólására (») Ápr 2, 2020 /
 
Idézet:
„programból várni a stat bitet elég időigényes”

A hardveres esetén a beérkezést muszály figyeld legalább megszakításból. A szoftveres esetén meg a startbitet figyeled megszakításból. 1 byteos adatátvitelnél nem látok érdemi különbséget. Lévén a hardveres kezelése (adat kivételes, átrakása, vétel nyugtázása) bonyolultabb.
(#) Hp41C válasza sonajkniz hozzászólására (») Ápr 2, 2020 /
 
Egy rendes uart vétel nem annyira egyszerű, hogy a satart bit lefutó élére várunk (akár programozottan, akár megszakításból), aztán 1.5 majd sorban 1 bitidővel mintát veszünk a vonalból. A jobbak majoritás szerint döntik el, hogy milyen szint is volt a vonalon, számolják a paritást, ellenőrzik a sopbit(ek)et. stb. Már a sokat szidott 16F -eken is két adatnak volt buffer a szóban forgó 16 bitesben pedig minden esetben van valamekkora buffer mindkét irányban. Néhány típusban az UART adás/vétel DMA -val is végezhető. Miért is lenne ez gyorsabb, kényelmesebb, mint a szoftver.

Ha programból vesszük a biteket mondjuk 38200 bit/s sebességgel, mekkora idő is áll rendelkezésre két bit "mintavétele" között (26 us). Hány utasítás végrehajtása elég? Egy több megszakítással terhelt kontrolleren hogyan befolyásolja a (mintát vevő kiszolgálónál magasabb szintű) megszakítás kiszolgálás a mintavételi idő pontpos betartását?

HW uart esetén talán elég a 260us/byte a tároláshoz.
A hozzászólás módosítva: Ápr 2, 2020
Következő: »»   20 / 32
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem