Fórum témák
» Több friss téma |
Valamint még egy dolog amit elfelejtettem írni.
Érdemes erősen körbe nézni Arduino tájékon is software example és "periféria board"-ok körében. Az sw example-ök érhetőek de, ha megismered a non blocking kódolást akkor rájössz, hogy mi a probléma velük. A perifériákhoz ebay-en egy rahedli panelt találsz fillérekért (Hőmérő, RTC, LED-Matrix, 7seg stb...).
Köszi a válaszokat!
 Tudom hogy létezik dugdosós próbapanel, csak egyszerűbb lett volna ha minden alkatrész ott van egy helyen, nem nekem kell külön beszerezni! De maradok szerintem a próbapanelnél! 
Tanuláshoz nem ajánlom a dugdosós próbapanelt, mert előbb-utóbb belezavarodsz a kontaktushibákba. Érdemes venni vagy készíteni legalább egy alappanelt.
A kontaktus hibák zöme elkerülhető, ha betartjuk az alábbiakat:
- 0.6 .. 0.8 mm átmérőnén vastagabb kivezetésekkel rendelkező alkatrészeket nem erőltetünk a panelbe. A kivezetéseire forrasszunk más alkatrészről levágott darabokat, - már forrasztott kivezetésű alkatrész nem használunk a panelban, - réz vezetékek helyett alkalmazzunk tömör felületkezelt réz vezetékeket, - az áramköröket nem hagyjuk megépítve hónapokig, évekig.
Ezeket esetleg érdemes megnézni: Easy PIC-40 kártyák
Üdv!
I2C PIC to PIC kommunikáció. Mivel egyedi ezért szeretném leegyszerűsíteni. Annyiból áll, hogy a slave lehúz egy lábat jelezve, hogy új adat van. A masternek erre kell reagálni. Kérdés: van-e valami kényszer amit hardver miatt be kell tartanom? Értem ezalatt, hogy mivel nem akarok írni csak olvasni a slave-t és csak egy slave van címküldés és parancsküldés mindenre ACK meg hasonlók helyett a master csak küld egy címet vagy csak egy ACK-ot, hogy készen áll a vételre a slave meg amint vette az ACK-ot elkezd küldeni. Elvileg nincs akadálya, de hátha valamit nem tudok. Persze egyszerűbb lenne SPI vagy UART, de a master mindkét SPI-je foglalt, az IIC meg gyorsabb mint az UART . A hozzászólás módosítva: Aug 20, 2018
A slave nem tud önállóan küldeni, mert a master adja az ütemjelet (órajel).
Ezzel tisztában vagyok, de ez miben korlátoz engem azon felül, hogy a masterban be kell állítanom a baud-ot?
1. Slave lehúzza a lábat, 2. Master kezdeményezi a start kondíciót és felkészül a vételre, ezzel együtt küldi az órajelet is nem? 3. Slave érzékel a Startot és küldi az adatot. (1byte) Elengedi a lábat. 4. Megjött az adat, master végrehajtja a Stop kondíciót. Ez az elképzelés. szerk: Nem tudom a plusz lábat nem lehetne-e kihagyni. A slave is tud Start kondíciót indítani nem? A hozzászólás módosítva: Aug 20, 2018
A slave-vel lehúzod bármelyik lábat,a masterrel nézed,hogy lehúzta -e,ha igen,akkor mehet a sima master-slave kommunikáció,nem kell túlgondolni
Nem akarom én túlgondolni. Inkább alágondolni
Ha a "sima master-slave" alatt a standard szerintire gondolsz, azt szeretném most elkerülni. Eddig nem volt szükségem slave rutinra így még nem írtam. Viszont emiatt most nem is szeretnék egy standard szerinti rutint írni ha nem muszáj, majd megírom máskor. Ha lehet, most egyszerűsítenék.
Szia!
Én két PIC közti kommunikációra mindíg 1-Wire-t használok. Ha a slave foglalt, az adatvonalat lehúzva tartja. Ha elengedi, a master akkor és olyan ütemben kérdezi le, ahogy akarja. Az átvitelt mindíg 16 MHz-n végeztetem, így elég gyors, de a slave protokolja úgy van megírva, hogy ha a masternek egyéb elfoglaltsága akad átvitel közben, (pl. megszakítás kérelem) akkor akár 1 byte átvitele közben is tarthat szünetet. Csak a bit átvitele közben nem.
Így meg nem sok értelme van az I2C használatának.
Bár így jobb lenne(nem próbáltam) 1: slave lehúzza az adatvonalat 2: slave elengedi az adatvonalat 3: master start 4: slave ack 5 fogadásra átállás 6 ha megjött az adat master stop. De ez akkor is furi.Inkább a masternek kellene lekérdeznie,hogy van -e új adat .Sonajkniz javaslatát követve,vagy bármely más 1-2 wire-s kommunikáció jobb lenne használni,így elkerülendő hibás átvitel,vagy bármilyen más gubanc.
Sziasztok!
Nem tudom valaki látta-e már nekem most tűnt fel és úgy láttam ide se került be mint téma. MPLAB Snap Szerintetek?
I2C-nél a slave csak a saját címére küldött parancsra reagál, így a masternek mindig kell címet küldeni. Ha nincs más a rendszerben, használhatsz pl. SPI-t. Ha csak fogadni szeretnél nem is kell kiküldeni semmit, azt a lábat nem kell használni. Ha kevés lábat szeretnél használni használhatod ugyan azt a lábat (pl. CLK) bemenetként, amire az IT jön, majd átkonfigurálod SPI-re, és beolvasod az adatot.
Nem láttam még, köszönöm az értesítést! Nem tűnik rossznak, bár egyelőre kevés ATmegát támogat. Úgy tűnik, hogy humánus áron lesz kapható.
A PicKit4 tudja programozni az Atmel cuccokat is jól látom?
Már miért csak a sajátjára reagálna? A szoftver határozza meg, hogy mire reagál. Bár ahogy ezt Tanszka is említette, nem I2C standard. Fogalmazhatunk úgy, hogy I2C vonalon végrehajtott egyedi kommunikáció. SPI-vel az a bajom, hogy a masteron mind2 foglalt, szoftvereset meg nem akarok, részben így is foglalkozik a master 3-4 dologgal és még nem tudom mit bővítek rajta. Mindenképpen hardverest akartam az meg csak az UART meg az IIC volt szabad.Ugyanezen ok miatt nem akartam 1-wire-t sem, bár sonajkniz kolléga megoldása elgondolkodtató. Még ezt át kell gondolnom, mert a slave meg folyamatosan RF jelet vesz és dekódol.
A cím egyezés vizsgálatát a hardver végzi. Ha nem talál cím egyezést, akkor semmilyen értesítést nem küld.
Pontosítsunk: A PICkit4 (a tervek szerint) tudni fogja az AVR -eket is programozni. Jelenleg (MpLabX 5.05) az AVR és a 8 bites PIC -ek zöme is csak sárga a Device Support állományban.
Idézet: „"Y" Yellow indicates preliminary, beta support, not production tested.”
Bár mondjuk én az M részéről először megcsináltam volna, hogy az MX-et is lehessen debuggolni és az egyéb problémákat javítottam volna minthogy új debugger és Atmel support.
De ez lehet csak azért van mert a PIC32Cx "matricázás" lesz. De a tervek szerint a PK4/ICD4/Snap használható lesz UART/SPI/I2C "terminál"-ként is, a "tervek" szerint...
A PICkit4 Device Support állományban jónéhány (de nem minden) PIC32 már zöld, azaz tesztelt.
A PIC24-ek esetén mi annak az oka, hogy a legegyszerűbb ASM kódot is 0x282 kódtól kezdi a programmemóriában? Elvileg 0x200 címen kellene indulnia. ASM-ben az ember nincs ahhoz hozzászokva, hogy nem azt látja a program memóriában, amit begépelt.
Pl. egy ilyen abszolút minimalista kód esetén is 0x200-0x281 közé betesz valami zagyvaságot, amit egyébként soha nem fog végrehajtani, mert a nulla címen van egy ugrás 0x282-re.
A hozzászólás módosítva: Aug 22, 2018
A megszakítási vektortábla.
Nekem itt még 0x0200 címen kezdődött.
Pontosítanom kell magamat: A 0x200 .. 0x282 közé az MpLab X az XC16 startup kódjának darabját linkeli be.
Bővebben: Link
Köszi!
Nagyon hasznos PIC24/dsPIC ismertetőt írtál! Még angol nyelven is nehéz igazán jó anyagokat találni.
Miért ne küldene? A start a címküldés előtt van. A startot észleli a hardver. Mi több a mastertől a slave felé már teszteltem is. A 32MX a master csak egy startot hajt végre a pic12 pedig simán reagál rá. Fordítva ez még nem sikerült, de még nem tudom, hogy a 12-esen nem sikerült jól beállítanom a startküldést, vagy a 32mx-en az észlelést. Épp ennek kiderítésén dolgozom.
|
Bejelentkezés
Hirdetés |
