Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Most már én nem tudom, hogy jó helyre írtam-e a hozzászólásomat? Ez nem a PIC - Miértek, hogyanok téma? Egy ARM cpu nem egy DIP8, DIP28 tokban kapható. Persze azoknak is van előnyük és hátrányuk...
Watt: Ott a honlapon van egy Where to buy gomb, arról a lapról közvetlenül lehet rendeni. Nem próbáltam még. A hozzászólás módosítva: Nov 6, 2012
Tudok olcsobbat. Veszel 4 $-os PIC24HJxxx IC-t es megirod ra a coproci FW-t.
 Mivelhogy ok is ezt csinaltak.
Attól függ, hány kell és milyen sürgős. Ha 1-2 darab kell és/vagy kevés idő van rá, akkor venni kell. Ha viszont sok kell vagy van rá sok idő, akkor érdemes nekiállni fejleszteni.
Juteszembe, olyan kóddal/projekttel nem találkozott valaki, hogy egy pl. 14 lábú kontroller, ami karakteres LCD-t hajt meg, önmaga elintézi az LCD inicializálását, és a fő kontroller számára I2C vagy SPI perifériaként kezelhető pl. egyszerűen memóriaként? Amiket látok ebayen ilyen soros-párhuzamos átalakítókat LCD-hez, azok tipikusan sima portbővítő ic-k, ahol továbbra is a kontrollernek kell foglalkoznia az LCD időzítéseivel, nem tudja csak egyszerűen kitolni a buszon az adatot, aztán a többit lerendezi az lcd modul. Ráadásul egyes esetekben még drágábbak is, mint maga az LCD... Itt van az oldalon Topi kapcsolása az aszinkron soros portosról, valami ilyesmire gondolok csak I2C vagy SPI buszra. Bár gondolom Topi is azért csinálta ezt, mert nem talált készen. A hozzászólás módosítva: Nov 6, 2012
Egy 16F684-be belefer talan a LCD meghajtas, es a I2C slave. Persze ezt is meg kell irni, de csak egyszer. Olcsobb mint keszen megvenni. De valahol lattam hasonlot, de TTL UART-on. Itt is van egy de nem PIC hanem 'LS176 segitsegevel. Mondjuk ez nem az amit Te keresel. En csinaltam ilyen UART-os kijelzot valamikor 16F690 volt az agya. Ez TTL szinten soros vonalon kommunikalt a masik procival, es 3 gombot is kezelt.
A hozzászólás módosítva: Nov 6, 2012
Én csináltam ilyet, egyelőre dugdosós panelen van/volt csak összerakva (azaz csak kb. 95%-ban tekinthető késznek), mivel amire akartam használni, az a projekt egyelőre holdba került. Nem 14-lábú, hanem 16f887 (ilyen volt itthon), és nem csak a kijelzőt hajtja meg, hanem tud PWM-mel kontrasztot is állítani, a Cvref kimenetével meg egy MCP6001/2-vel háttérvilágítást szabályozni, ill. gombok is köthetőek rá.
A koncepció az volt, hogy az előlapra került őkelme, és csak a tápok (külön egy 5V neki, meg egy stabilizálatlan a sok mA-nyi háttérvilágításnak), és az I2C megy bele, minden mást ő megold. Kevés gombnál végülis egy 28-lábú is bőven elég, a program talán 2KW körül lehet, szóval kisebb modellbe is bele kéne férnie, viszont nagy kijelzőnél (nekem 4x20 kell) nem nagyon fér el kevés memóriában.
Én 1kw programmemóriát is elégnek saccolok hozzá. Esetleg a RAM lehet kevés, de végülis 4x20-as kijelző az 80 karakter, marad 48 bájt szabad memória, az szerintem elég lenne, mivel ennek semmi más dolga nem lenne. 16F1826 jónak is tűnik, van benne I2C és SPI is, van elég lába is. Na majd ha nagyon unatkozom, nekiállok
Szia!
Egyrészt a 16F1826 2kw program és 256 byte RAM memóriával rendelkezik, másrészt két lépcsőben lehet lábkompatibilis, azonos családba tartozó típusra cserélni: 16F1827 (4kw/384 byte RAM), 16F1847 8kw/1k ram. Továbbá a 16F1459 négy csatornán is fogadhatná az adatokat (SPI, I2C, UART, USB). Másrészt az I2C slave megoldások nem egységesek (ld. AN734 appnote). Ez a dokumentum nem tartalmazzaí még az advanced midrange család tulajdonságait. A fenti típusok nyomkövetéséhez PICKit3 / ICD3 kellene, egy 16F88 (4kw/384 byte) egy PICKit2 -vel is működne.
Gondot okoz, hogy az MPLAB nem támogatja a PICkit2 készüléket az újabb PIC32 mikrovezérlők programozásához és nyomkövetéséhez. A programozáson még esetleg segíthet a DevFile Editor, de a nyomkövetésen nem.
Ezen a honlapon azonban egy alternatív lehetőséget hirdetnek, miszerint az ejtagproxy programon keresztül a GNU GDB segítségével végezhetünk nyomkövetést. A támogatott eszközök listáján a PICkit2 is szerepel. A mintapéldában egy ChipKit Max32 (PIC32MX795F512L) szerepel. Írják, hogy lassú a kommunikáció, de ha nincs más, ez is megteszi...
Sziasztok!
Megépítettem ezt a kapcsolást http://www.andrewhazelden.com/blog/2010/11/digital-poi-spinning-per...splay/ csak egy olyan problémába ütköztem, hogy nincs 18f2685 kéznél csak 18f2550. Sajnos én nem tudok programot írni meg módosítani. Ez a két pic nagyon hasonló még a bekötése is ugyanaz, nem lehetne átírni a programot 2550-esre, Valaki meg tudná ezt nekem csinálni persze ha lehetséges. Köszönöm szépen. A hozzászólás módosítva: Nov 10, 2012
Korábban már foglalkoztam az pic explorer 16 panellel. Most ismét elő vettem. Már egészen elfejeltettem, hogy is voltak a dolgok ezzel a panellel. A fórumban talált leírást, hogy lehet pic kit 2 vel programozni. A panelon levő 4550 –s picre rátöltöttem már a bootlodert. Az eredeti hex kóddal az LCD – n nem jelenik meg semmi. Majd rátöltöttem icserny által felötlött lcd4bit.hex file –t, ekkor a kijelzőn egy két betűt látszódót és az egyik led villogót.
Ezután megpróbálkoztam még egyszer a gyári kóddal, de semmi. Van valakinek valami ötlete, mi lehet ez? Talán tönkre ment volna az LCD? Idézet: Ez sem lehetetlen, mert nekem tönkrement. De akkor tök zavaros minta jelent meg a kijelzőn...„Talán tönkre ment volna az LCD?” Csinálj alaposabb és szisztematikusabb teszteket!
annyit elfelejtettem még, hogy csak teli szegmenseket látok. Sajnos csak multiméterem van, ezzel megpróbálok valamit méricskélni. Oszcilloszkópom nincs.
Milyen jellegű tesztre gondoltál?
A programokat eltoltad 0x1000 kezdőcímre? A bootloader konfigurációs beállításait veszed figyelembe az áramkör kapcsolásánál és az LCD időzítéseinél?
sziasztok,
hogyan tudnék usb-s kommunikációt összehozni a legegyszerűbben pic24fj128ga010-ra? előre is köszönöm.
Milyen USB kommunikációt? Host/device, HID/CDC/egyéb?
Explorer16 kártyád van, vagy valami más? Idézet: Azzal ellenőrizd a kijelző kontrasztját vezérlő feszültséget! „Sajnos csak multiméterem van”
Sziasztok!
Megnyitott a ChipCad Web Áruház.
SPI adatátvitelt csinálnék 18F26J11 en. Menne is a dolog, ha nem bonyolódtam volna bele a BF "buffer üres" jelzőbit vizsgálatába. A doksi szerint egyértelmű a dolog: ha SSPxSTAT
A nem írható BF bit reset utánn értéke fixen 1. Eddig rendben, de nekem csak akkor működik az SPI, ha BF=0 ra értelmezem a Receive complete állapotot, egyébként végtelen BF ellenőrző ciklus fut. (most késleltő ciklusokakt tettem bele, míg a buffer kiürül....) Tovább zavaró, hogy az PIC18F67j50 adatlapján SSPxSTAT regiszterben minden bit 0 értékű, pedig gondolom ugyanaz a modul szerepel mindkettőben. Ja és igen, az Errata nem ír semmit erről. A hozzászólás módosítva: Nov 12, 2012
Nálam így néz ki az adatküldés/fogadás. Egyes típusoknál (pl. 18f4550) kifejezetten ellenjavalt a BF bit vizsgálata. A 18f26j11-hez nég nem volt szerencsém, tehát nem tudm, hogy mennyire mérvadó az ajánlás erre a típusra.
A PIC18F4550 Errata szerint az átvitel végét jelző BF bitet nem szabad közvetlenül vizsgálni, ezért helyette a programmegszakítás jelzőbitet vizsgáljuk. Szintén az Errata ajánlja, hogy adatküldés előtt olvassuk ki az SSPBUF regisztert, ami egyúttal törli a BF bitet. Ha elmulasztjuk a BF bit törlését, akkor a következő beolvasott adat nem másolódik át az SSPBUF regiszterbe!
Lassan már nemcsak az adott típus Errata -ja lesz kötelező olvasmány, hanem az összes! Módosítottam a programot, kiválóan működik! Köszi! Nálam az SSPBUF regisztert nem kellet olvasni BF törléséhez. SSPBUF -t enélkül is tudom írni.
A dolog azért fura, mert arra gondoltam, hogy maga az MSSP modul már jól kidolgozott megoldás, amit csak átemelnek egyik típusból a másikba, és ebből adódóan új és váratlan hibák nem keletkeznek. A hozzászólás módosítva: Nov 12, 2012
Az USB témát most már biztos, hogy körbe kell járom alaposabbal ...
30 I/O port állapotát szeretném változtatni gyakori rendszerességgel, és havi egy alkalommal pedig 6 bájt adatot szeretnék közölni a processzorral PC-ről. Az áramkört én építem, jelenleg még dugaszolós verziónál tartok.
Én nem bíznám rá az ilyen fleladatokat a PC-re és az USB-re. Ilyen hosszú távon nem megbízható. Szakad az USB időnként a Win dolgai miatt, még a HID-is, bár az nem annyira jellemző. Ez csak arra való, hogy rácsatlakozz, monitorozz, beállíts, minden mást a hardver kell, hogy végezzen egymás között...
Meg lehetne próbálni közbeiktatni egy köztes "gépet", pl. a fillérekért kapható TP-link WR-703N routert openwrt oprendszerrel, az hátha stabilabb. A PC pedig etherneten vagy Wifin csatlakozhatna hozzá.
Idézet: Akkor hogy vagy miért jön a képbe a PIC24FJ128GA010, ami sem USB-hez, sem dugaszolós próbapanelhoz sem fejlesztéshez (kicsi az újraprogramozhatósági szám) nem alkalmas? „Az áramkört én építem, jelenleg még dugaszolós verziónál tartok.”
Esetleg egy PIC87J60, de nem biztos, hogy kell a LAN. Lehet, hogy elég egy 18F2550, amivel néha felcsatlakozik a PC-re, megnéz, módosít alapjelet ha kell és ha van egyáltalán alapjel. Az a kevés adat mehet egy SD-re, amit néha ki lehet olvasni és a kommunikáció lehet RS485 a hardverek között, ha egyáltalán lesz ilyen egység.
Nem ismerjük, hogy az adat honnan származik, mi a feladat stb. De az biztos, hogy PC-re és USB-re nem szabad szabályzást, vezérlést, adatgyűjtést bízni, maximum monitorozást, alapjelek megadását.
No megint meggyűlt a bajom az PIC18F26J11 el. Most az USART interruptja nem akat működni. Amit simán tudok használni az a Timer0 és 1 alacsony és magas prioritása, de az USART2 Low megszakítása nem akar generálódni. A TX ág rendben, szkópon látom a PIC bemenetére érkező soros jelet mégsem történik semmi... Az interrupt ágban lévő LED vizuális megjelenítése lenne a várt eseménynek...
A hozzászólás módosítva: Nov 13, 2012
Szia!
Azt hiszen többször leírtam: - Hibakezelés: Ha egyszer egy keretezési vagy ráfutási hiba lesz, akkor többet nem vesz az UART. Le kell tiltani, ki kell olvasni a vett karaktert és újra engedélyezni kell. - Nem szabad megvárni, míg az adó elkészül, mert a vevő is vehet ez alatt az idő alatt egy karaktert és máris kész a ráfutás. A megoldás egy fifo nyújt, a vevő beleteszi a vett karattert engedélyzi az adási megszakítást és visszatér. Az adási megszakítás mindaddig tiltva van, míg nincs adni való, ha van adni való, akko kiveszi a fifo -ból és átadja az uartnak, megnézi, hogy van-e még adni való, amennyiben nincs letiltja az adási megszakítás kérést.
[off][Ha egyszer egy keretezési vagy ráfutási hiba lesz, akkor többet nem vesz az UART. Le kell tiltani, ki kell olvasni a vett karaktert és újra engedélyezni kell.
/off] Igen, ez az OERR: Overrun Error bit vizsgálatával történik meg. A dolog ismerős, de én azt várom, hogy legalább az első karaktert elfogadja az interruptba. Keretezési hiba azért nem lehet, mert a PIC18F által adott kaktert tökéletesen felismeri a PC adott 9600,8,1,None beállítással, adáskor pedig természetesen ugyanezeket ezeket is használja. Ráfutási hiba pedig azért nem, mert kézzel adom a uP -nak egyesével a karaktereket, ezidő alatt bőven lehetősége van kiolvasni. Idézet: „- Nem szabad megvárni, míg az adó elkészül, mert a vevő is vehet ez alatt az idő alatt egy karaktert és máris kész a ráfutás. ” Ezt pedig nem is értem. Elvileg külön - külön regiszterből történik az adás - vétel (TXREGx, RCREG) ezután hogy értelmezel ráfutást? Idézet: „A megoldás egy fifo nyújt, a vevő beleteszi a vett karattert engedélyzi az adási megszakítást és visszatér. Az adási megszakítás mindaddig tiltva van, míg nincs adni való, ha van adni való, akko kiveszi a fifo -ból és átadja az uartnak, megnézi, hogy van-e még adni való, amennyiben nincs letiltja az adási megszakítás kérést. ” A fentieket nem értem pontosan. FIFO a hardver része, de itt a blokkséma szerint csak 1 mélységű ez. Rsézleteznéd mire gondoltál? A hozzászólás módosítva: Nov 13, 2012
|
Bejelentkezés
Hirdetés |
