Húzd le azt a 18-ast egy 100k-val gnd-re. Az adatlap szerint rc7 üzemben cmos st, szivárgási áram 1 uA max. Az eusartot remélem nem piszkáltad. Nem kellene bekapcsolni.

Én is erre gondoltam. Próbáltam, de nem segített, sőt 47k-val is azzal sem ment.

Nos ma eljutottam odáig, hogy a teszt panelen a memória cím vezérlést a DPROT-ra kötöttem.
Azonnal fogadta a szekvenciákat.
Nem igazán értem egyelőre, hogy miért nem fogadja ha szétszórva a protok közt állítgatom a címvezetékeket.
Lehet a túl sok bit vezérlése instabillá teszi a PIC-et, vagy egyszerűen bezavarodik.
kb 55bit van vezérelve egyszerre. (memória 16 adat, 23cím és 7 vezérlő + 4 OLED, + 4 USB, + 1 LED)

Mi az a DPROT? Őőőő... D port?

Nem tudom pontosan hány eszköz van rajta. 4-5-nál nem több. A lekérdezés gyakoriságáról nincs információm. Nincs semmilyen időkritikus tevékenység. Igazából ki- és bemenetek lesznek. Nem időigényesek.

pajti2: Tudom, tudom, lehetne nagyobb pic-et választani. De tudod, "ez van a fiókban". Most még csak a teszt és kísérleti fázisban vagyok. Ha úgy alakul, hogy szükség lesz nagyobb memóriára, akkor természetesen váltok. (Találtam 16F-ből 2K ram-mal rendelkezőt. Az ehhez a feladathoz több mint elég. És ami lényeges dip tokozású.)

Talán csak valami elírás. Vagy valami le nem tiltott periféria használja az egyik lábat.
Esetleg LED-eket kötsz a címkimenetekre és állandó magas ill. alacsony szintet adsz ki. Látni fogod, ha valami nem stimmel.

Ez pl. nem okoz konfliktust?

29LV640-nél nem mert 21 fix címbit van.
És igen, D port akart lenni
Próbálom áttervezni a nyákot, hátha meg tudom oldani a címbitek kivezetését a D port-ra.
A maradék 6bit-et meg valahová kiosztom.

Simán megoldható 2 rétegen a teljes B és D port kivezetése.
Pár éve csináltam egy próbapanelt a 100 lábú PIC24HJ256GP210A mikrovezérlőhöz, ott az összes portot kivezettem oldalsó tüskesorokra. Természetesen minden tüskesoron rendezettek voltak a portok bitjei. Az a panel is 2 rétegű volt.

Láttad, PIC32MX795 bit és port szervezését?
Elég vacakul oldották meg.
Sajna itt nem elég, ha csak tüskékre rendezem kétoldalt portonként, itt be is kell kötni hiszen a kész hardver nyákján a memória meghatározza a szerveződést.
De osztok egy képet, hogy értsd.

Egyébként lehet sikerül megoldanom, de egy egy ilyen tervezés több napot is igénybe vesz már.. Elég nagy macera.
Egyelőre a D port fele van kivezetve, most jön a másik fele a problémásabb terület.

Biztos, hogy ott valami periféria közbeszól. Végig kell nézni melyik lábon mi van, de ahogy Zsora is írta LED-ekkel is tesztelheted. Csak egyszerűbb mint áttervezni a nyákot. Vagy legalábbis gyorsabb.

Nem zavarja be a pic-et, és egyébként sem tudsz 55 bitet _egyszerre_ vezérelni, lévén csak 32 bites az a pic. Valamit márpedig elprogramoztál, és a kimérésnél sem vetted észre.

Valamelyik pic családnál van olyan, hogy a B port egyes lábai open collectorosak, magasra nem tudnak meghúzni, külső ellenállás kell rájuk, de a 32-esnél nincs olyan.

Az általam mutatott panelen nem csak a tüskékre mennek ki a portok, hanem egy TSOP44 tokozású SRAM-ra is a teljes (16-bites) B és D port, ill. az E és F portok néhány bitje. Igaz én 0,5mm osztású TQFP100-as tokot használtam és több helyem is volt, viszont te meg (ahogy látom) vékonyabb vezetőket és kisebb viákat alkalmazol, tehát nem lehet gond. (A PIC24 és a PIC32 lábkiosztása nyagymértékben kompatibilis egymással.)
Egy jó stratégia vezetékezésnél: az egyik oldalon (többnyire) vízszintes, a másikon (többnyire)függőleges vezetőket használsz.

Akárcsak usane, én is azt javaslom hogy először a hiba okát derítsd fel, mert abból tanulsz. Viszont a teljes portok használata később csak előnyödre válik a könnyebb és gyorsabb vezérlés miatt.

Sziasztok!
Megosztanám veletek egy durva szívás történetét, hogy más már gondolhasson erre is, ne gyötrődjön rajta 7 órát, mint én.
Van egy saját tervezésű LCD meghajtó áramköröm, ami lekezel egy 2x16-os LCD-t, és egy 4x4-es gombmátrixot. Megnövelt sebességű 1-wire kommunikációval csatlakozik slave eszközként.
Első adatként megy neki egy kód, ami meghatározza az aktuális feladatát. Ezután mennek az adatok, majd egy FF, mint lezáró kód. A lezáró kód hatására az eszköz egy AA-t küld vissza nyugtázásként.
Eddig minden OK. Csakhogy, egy adatátírás során, amikor a kijelzőnek csak egy szakaszát kellett volna átírni, az adatküldési rutin ciklusba került, és bármit is küldtem a kijelzőre, belerondított, és az adás nem állt le.
Rövidre fogva: A master, tápfesz csökkenésre EEPROM-ba ment egy rakás adatot. Mint kiderült, az EEPROM egyik byteja hibás volt. Nem lehetett írni, csak olvasni. Ennek megfelelően a belőle kiolvasott érték az FF volt. Ezt küldte a master adatként, viszont a slave lezáró kódként kezelte. Így aztán a nyugtázás még akkor ment ki, amikor a master még javában adáson volt. Miután a hibás byteot kikerültem, minden működött szépen.
Ergo: Nem mindig a programban van a hiba.

A PIC32 portjai csak 16-bitesek. (A PIC32 lábkiosztás terén nagyban kompatibilis a PIC24/dsPIC33 családdal.)

Ezen már túl vagyok.
LED-eket tettem az adat portra aztán a Cím bitekre.
Tökéletesen működött, látszatra legalább is, mert a memória kezelésére nem volt alkalmas.
Mikor próbaként átdugtam a próbapanelen D portra a címzést, azonnal, a már megírt programmal, működött.
Szóval nem igen értettem, de arra a következtetésre jutottam, hogy a PIC-en szétszórt adatbitek nem voltak alkalmasak a címzésre.
Hogy pontosan miért azt nem tudom.
Most áttettem D protra a címzést fixen, a nyákot is átterveztem, most ellenőrzöm, hogy jó e, ha igen akkor még egy két teszt és mehet gyártásra.

Már csak a bejövő adatok kezelését kell megterveznem. Arra gondoltam, hogy timer-el figyelem a keret meglétét (3,5T). Ha teljesül a keret a vett csomagból az utolsó két bájtot leveszem (crc). Elvégzem a crc képzést (majd még azzal is lehet hogy lesz kérdésem). Ha az stimmel, akkor vizsgálom a címet, funkciót, adatokat. Ha minden jó elvégzem majd elkészítem a válasz üzenetet. Ha nem stimmel, hibakódot visszaküldöm.

Rendben, hogy így működik, de én a helyedben mindenképpen kideríteném a hiba okát. Nem nnézegettem a kódrészleteidet, meg adatlapot sem, de mivel csak kimenetet kell billegteetni nem valószínű, hogy a pic a hibás. Ahogy így visszaolvastam még a "tákolmányod" -breadboard vagy akármin is raktad össze- is lehet kontakthibás vagy hasonló.

Igazából nem jövök rá, miért nem működött.
Kontakt hiba biztosan nem volt, persze nincs olyan hogy tuti, de sokszor ellenőriztem.
Mindegy szerencsére megoldódott, 3hét töretlen törődés meghozta eredményét
Most már azt csinálja amit én akarok.

Sziasztok
Időmultiplexnél
1 sec alatt 50 frissítés egy kép.
5 képem van össz-vissz forciklusba hogy tudnám megírni??

Így nézne ki??

forciklus 20 ig
1kép 10ms
2kép 10ms
3kép 10ms
4kép 10ms
5kép 10ms

És ha 500 millisec el hogy kéne számolni????
Segítségeteket előre köszönöm.

Elég érthetetlen a kérdés.
Mit akarsz csinálni?

PIC24FJ256GB106 oscillátor beállításaiba keveredtem kicsit bele ...
Jól értelmezem-e a dolgokat?
- Használhatok külső kvarcot közvetlenül max 32MHz (XT, HS, EC beállítás)
- Használahatom a külső kvarcot PLL-en keresztül, leosztom 4MHz-re, amiből csinál 96MHz-t, abból 48-at az USB-nek, és 4, 8, 16, vagy 32-őt a CPU-nak.
- Használhatom a 8MHz belső oscillátort (leoszva 8MHz-31.25kHz)
- Secundery Oscillator közvetlenül

Sziasztok. Normális dolog, hogy a fordító ezt fordítja?
Sima int változóban lévő adatot szeretném rotálni jobbra. 0xFFFE-ből 0xFFFF lesz. Szerintem nem ezt kellene fordítania.

Jaj. Nem szóltam. Már megint én voltam a hülye.

A 32mhz kvarc kicsit szokatlannak tűnik, de ha az adatlapja írja, hogy elbír annyit, akkor használhatod. 8mhz-es kvarcokat szoktam látni átlag. De amúgy jellemzően igen, amiket leírtál vakon is stimmelnek.

4 mondat a lényeg, de csak ha az első felétől a 3.-ig, jó lesz?

- EC PLL módban akár 48MHz-es külső jelforrást (oszcillátor) is használhatsz, bár PLL mellett ez elég felesleges.
- XT módban max. 10MHz-es, XT PLL módban pedig max. 8MHz-es kvarcot akaszthatsz a PIC-re.
- LPRC módban 31kHz-es belső jelforrásod van.
A többi amit írtál (HS, HS PLL, EC, FRC, SOSC mód) az stimmel.

A 32 millihertz az tényleg elég szokatlan.

kriszrap: Az ellen nem véd!

Srácok, PIC32MX795-ös MCU-ra írnék egy programocskát.
A program lényege, hogy CDC-n keresztül fogadjon egy long típusú adatot, amit küldés előtt szét is kapok 3byte-ra, majd át küldöm PIC-nek. (USB CDC)
A következőképen történik:
PC küldi az adatot amely: 22410
Ezt küldés előtt eldarabolja, így: 0x00, 0x57, 0x8A, majd átküldi.
PIC fogadja az adatot majd vissza alakítja, így:

1. // A beérkezett adatok: 22410
2. USB_In_Buffer[2] = 0x00;
3. USB_In_Buffer[1] = 0x57;
4. USB_In_Buffer[0] = 0x8A;
5.  
6. //Tároló változó:
7. unsigned long DataSizePC = 0;
8. DataSizePC = USB_In_Buffer[2];
9. DataSizePC = DataSizePC<<8 | USB_In_Buffer[1];
10. DataSizePC = DataSizePC<<8 | USB_In_Buffer[0];

Ez a művelet szépen meg is valósult 8bit-es MCU-n. (18F442)
De most ezen a 32-es PIC-en valamiért a következő eredményeket kapom:
Mindegyik byte-ot megvizsgáltam külön-külön is:

1. USB_In_Buffer[2] = 0x00;    // ez jó eredménye 0x00
2. USB_In_Buffer[1] = 0x57;    // Ez is jó, eredménye 0x57
3. USB_In_Buffer[0] = 0x8A;    // Na és itt a gond, eredménye -118

Emiatt a -118 miatt teljesen használhatatlan, de nem tudom miért hozza ezt az értéket.
Típus módosítókat már mind kipróbáltam, nem javít az eredményen.

Ami még érdekes, hogy ha, 16bit feletti az érték, tehát 65536 vagy ennél nagyobb akkor az eredmény helyes, de ha ez alatt van akkor hibás az adat.
Mi a véleményetek a dologról?

Nem törlöm a bejegyzést, álljon itt tanulságként.
A USB_In_Buffer előjeles volt és ezért hozott hibás eredményt.
Nem vettem korábban észre, csak amikor beküldtem a bejegyzést és vissza olvastam amit írtam gondolkodtam el hirtelen, hogy azt még nem ellenőriztem.
Most már jó..

Üdv a klubban. 6-7 hozzászólással korábban én is ebbe a hibába estem. Int változót tologattam egyel jobbra. Nem értettem, hogy a fordító miért azt fordítja amit. Közben rájöttem én is, hogy azért, mert előjeles.

Mert okosan gondolkodik. A negatív számnak a legfelső bitje 1, ha a következő bit nulla lenne és eltolod balra (megszorzod kettővel) pozitív szám lenne belőle, ezért ilyenkor a legfelső bitet mindig 1-re állítja.
Látom meglett a hiba .