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.

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

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.

ASMben meg kell irnod az I2Ckommunikacios protokollt. (vagy letölteni valahonnan),. Abban megtalalod a valaszokat.

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.

A legtöbb PIC-ben van hardveres I2C, csak be kell állítani....

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.

De, pont elég... Beállítod amiket kell, bedobod a bufferbe az adatot és már küldi is.

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.

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.

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

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.

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.

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

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.

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.

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.

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!

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.)

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.

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.

Nem vagyok benne biztos. Főleg nem az UART esetén, ahol programból várni a stat bitet elég időigényes.

Valahogy így

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?

Nagyon köszönöm! Majdnem így próbáltam csak mégsem - a karaktereket írtam nem a hex-et.

Szia! Nekem most fontos, hogy a háttérben menjen a soros port kezelése...

Köszönöm, jó ez a videó...

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.

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.

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.