Szia.
Ilyen esetben az SD kártya felé ellenállásosztóval le kell osztani a PIC kimenetét, vagy más módszerrel illeszteni. Az SD kártyától a PIC felé pedig ellenőrizni kell, hogy elég lesz-e a PIC-nek a 3,3V, hogy logikai magasnak észlelje. Amelyik típusokat én használtam, azoknál a TTL bemeneteken 5V-os tápnál már 2V is magasnak számít, de Schmitt triggeres bemenetnél még nem (pl. pic18f2550 esetén 5V-os tápnál 4V a schmitt triggeres bemenetek felső billenőpontja). A hardveres SPI modul schmitt triggeres bemeneti puffert használ ennél a típusnál és gondolom sok másnál is, úgyhogy ilyen vegyes tápfeszültség mellett érdemes megvizsgálni az adott típus adatlapját a stabil és hibátlan működés érdekében (Az electrical characteristics fejezetben írnak ezekről). Amennyiben nincs komoly ok a vegyes tápfeszültség használatára, érdemes inkább azonos tápfeszültségről használni az egészet.
Megjegyzés: Nekem valamiért működött a hardveres SPI-vel is de ez csak szerencse kérdése lehetett, magyarázatot nem találtam rá.

Jelen esetben egy program működőképessége a probléma, nem a sebessége. Az XXXbits.YYY forma lehet hogy hosszabb/lassabb, de olvashatóbb és jobban megállapítható belőle hogy mit is csinál.
Ha már működik a program akkor tényleg lehet az általad leírt módokon optimalizálni, csak később már ne vidd át a forrásod egy olyan vezérlőre ahol esetleg az adott bitet máshová tették. Nem tudom a fordító miért nem szereti a btfsc/btfss utasításokat, azzal is lehetne rövidebbé és gyorsabbá tenni a kódot, ráadásul a W regisztert sem állítaná át.

Hali,
nyertél....
Valóban a USART adó megszakítása volt a ludas és úgy tűnik, hogy az alacsony prioritású megszakításoknál jelentkező problémáért is ez volt a felelős. Mondjuk még van egy-két olyan részlet ami nem teljesen úgy működik mint szeretném, de legalább már tudom, hogy a megszakításkezelés okozza a gondot.
Nagyon szépen köszönöm a segítséget.

Köszönöm a segítséget!
Egy 18F97J60-at néztem ki ezek után, ez elvileg 2.35V és 3.6V közötti tápfeszt igényel, ha jól értelmeztem az adatlapot, szóval mennie kell a dolognak.

Szia!
Mivel a perifériák felépítése a PIC családok között meglehetősen egyformák, ezért egy csomó kontrollerre sikeresen átvittem már ezeket a megoldásokat. Ha pedig, mondjuk az uart2 -re kell átvinni, a xxxbits.yyy -t is át kell írni - majdnem ugyanannyi fáredtság. Mosdjuk más gyártó eleve más felépítése miatt az ennyire HW közeni rutinok úgysem hordozhatók - márcsak a könyvtárak nevei és a bennük levő függvények nevei, paraméterezésük miatt sem.
Tényleges problámáról írok: Miért olyan hosszú egy C program, amikor ugyanazt csinálja, mint az assembly (16F1829 asm 3K, C bele sem fér a 8K -ba)??

Üdv. Valaki nem tud lcd-s sebességmérő programot 16F szériához? Vagy az sem baj ha más picre való csak lássam a program felépülését.

A sebességmérés két impulzus közötti idő mérésére vezethető le. Ezt a CCPx modul capture módjával szoktuk megoldani. Adatlapban megtalálod a hozzá tartozó regisztereket.
LCD-hez lehet találni kész projecteket, de meg is lehet írni, egy haladónak ez nem jelenthet problémát!

Milyen sebességet szeretnél mérni? Esetleg frekvencia-feszültség átalakítóval egy sima panelméter nem jó? Mivel mérnéd a sebességet?

Motorra lenne , ha lehetne egy pc ventillátor hall érzékelőjével mérném a sebességet belekalkulálva a kerék körátmérőjét.

Akkor, ha jól gondolom - 1 érzékelővel 1 fordulat másodpercenként az 1 Herz, 10 fordulat másodpercenként 10 Herz stb. Akkor mást nem kell tenned, mind számlálni a teljes köröket és összevetni azzal, 1 másodperc alatt mennyi kör volt (mennyi impulzus érkezett be). Ez egy resetehető számláló. A reset jelet 1 másodpercenként kell előállítani. A számláló értékét pedig kijelezni az LCD-n decimális értékben. Ez nem tűnik nagy feladatnak, vagy rosszul gondolom? Én ugyan nem PIC-et használok, de nem tűnik pilótavizsgás feladatnak. A mikrokontroller órajeléből az 1 sec előállítása sem bonyolult. A legnehezebb része, ha soros LCD-d van, annak a kódolása, de erre számtalan kész projekt létezik. Propellerrel (p8x32) az asztalomon lévő elemekből összedobálnám.

A múltkor tanulmányozott ventilátorban benne volt a szükséges alkatrészek helye ,egy SMD tranzisztor meg egy ellenállás beépítése után szépen adta a négyszögjelet.Ha nincs benne a szabályzó vezeték lehet egyszerűen pótolható.(vagy olyat kell választani ami tudja.(nem csak a forgást jelzi ,hanem jelet is ad)
Maga a mérés tényleg nagyon egyszerű,legtöbb PIC-ben a TIMMER1 számláló képes erre.A bemenetét külső jelre állítva ,már csak másodpercenként kiolvasod,majd törlöd.(ha nagyon pontos akarsz lenni ,akkor egy másik számlálóval kapuztatod a bemenetét)

Ez így nem lesz valami komfortos. Nagyon alacsony a frekvencia. Sokkal jobb lenne megmérni egy körülfordulás idejét. és abból számolni a sebességet.

Pontosan, én is ezt írtam le először. A dolog egy haladónak triviális. Nem csak a kérdésnek kellene haladónak lenni...

Jól van na ,lehet én vagyok a lassú ,de nekem már gyorsan forog,nem győzöm számolni,lehet a PIC ügyesebb...

MCP2200 USB-soros átalakítóval kapcsolatban van kérdésem, remélem, nem off ez itt. Maga az IC jól működik, IO vonalait használom, tehát nem USB-soros átalakításra kell. Viszont az egyik ügyfélnek az lenne az igénye, hogy több ilyet is csatlakoztatni kellene, viszont én úgy látom, hogy ennek az IC-nek a VendorID : ProductID párosa gyárilag van beégetve fixen. (Microchip igény esetén egyedit éget be, de ez nyilván kis tételnél nem működik) Van több IC kezelésére szolgáló függvény (GetNoOfDevices, SelectDevice, stb), próbálgattam, hát érdekes eredményeket adott. Szóval a kérdés az, hogy lehet MCP2200-ból egyszerre többet csatlakoztatni és külön vezérelni őket, vagy az azonos VID : PID miatt ez nem fog működni?

Szerintem működnie kellene annak, hogy több ugyanolyan VID : PID van a gépre egyidőben rákötve (nyilván külön host portok vagy hub kell hozzá), az USB-nek ezt kezelnie kell tudni, az egyedüli kérdés, hogy hogyan tudod azonosítani, hogy melyik melyik... Ha van összerakva egy (nekem nincs ilyenem), nézd meg, hogy nem mond-e valami gyári számot magáról a chip az USB paraméter blokkban - azt gondolnám, hogy van neki ilyenje. Vagy lehet az MCP2200 mögé kötött cucc soros protokolljába beépíteni valami azonosító adatot.

Szia! Régen jártál itt!
Megvan a forrása az átalakítónak? Ebben egyPIC18F14K50 van és ha jól sejtem egy CDC stack. A stack-ben bármit át lehet írni.

Egyébként ott van benne az adatlapban, hogy szabadon konfigurálható (8-9. oldal) az összes USB paraméter (VID, PID, gyártó és termék elnevezés, stb.), és bónuszként minden egyes példány egyedi gyári szám stringet tartalmaz kapásból, szóval még csak hozzájuk sem kell nyúlni, anélkül is azonosíthatóak.

Szia!

Az utóbbi években keveset fórumozok.
Azt tudom, hogy PIC a belseje, de annyira nem akarok belemélyedni, hogy átírjam a firmwaret.

Letöltöttem a legújabb drivert. Sajnos ezzel is gond volt, írták a verzióinfóban, hogy pont ezzel a funkcióval volt gond a korábbi driverrel. Most már szépen visszaadja a GetNoOfDevices függvény a csatlakoztatott eszközök számát, de a SelectDevice függvény valamiért még mindig nem változtat semmit. Elvileg a függvény paraméterében 0, 1, 2, ... hivással kellene kiválasztani, hogy melyik eszköz legyen aktív. Eddig akármilyen paraméterrel hívtam, mindig ugyanaz az eszköz volt aktív. Na még próbálkozok.

Egy idézet a Microchip fórumáról:

Ezekszerint muszáj lesz áttérni lassan az MplabX-re

Olvasd tovább. "Három hónap elég lesz áttérni Cortex-Mx architektúrára...

Nem ez a baj! Nem jó, tele van hibával, lassú mindt az állat(java). Valószínű nem fogok legújjabb PIC-eket használni...

Sajnos nekem is ez a bajom, hogy piszok lassú, és a Pickit3-al is tökéletlenkedik (tökéletlenkedett pár hónapja, amikor próbáltam).

Tiszteelt fórumlakók. Adott két PIC, I2C kapcsolattal, illetve van még a buszon egy másik IC is. Az egyik master módban megy, a másik slave módban. Az lenne aprobléma, hogy a slave PIC az harmadik IC-nek küldött adatot is veszi attól függetlenül, hogy más címre van állítva. Az igaz, hogy a küldött adat ugyanaz, de a cím nem. PIC C compilerben van írva a programja, be van állítva a cím, de hiába. Ha teljesen értlemetlen címet állítok be (amit a compiler még enged) akkor is veszi az adatot a slave PIC. Mit hagyhatok ki, vagy a címzést a programba is bele kell írni?

A slave PIC programja.

Ha nem CCS-ről lenne szó, azt mondanám, hogy az adott PIC címregiszterét és az SSP konfigurációját kell jól beállítani - az adatlapból ezek kiolvashatóak. Ill. címnek bizonyos értékek nem használhatóak (lásd I2C doksi), mivel azok különféle egyéb (pl. broadcast) célokra valók.
Hogy aztán ezeket CCS-ben hogy kell - azt a CCS fórumban kéne kérdezni.

Világos, de akkor ezekszerint ennek épp nem működnie kellene. Az a baj, hogy ez mindíg működik, ha értelmes címet adok meg, ha nem. Most éppen úgy van beállítva a dolog, hogy használható, de akkor is idegesít, hogy miért vesz minden adatot, mert szeretném finomítani, de így nem lehet.

Ha rossz címet adsz meg, az nem feltétlenül azt jelenti, hogy nem fog rá reagálni az IC, lehet az is az eredmény, hogy más címekre (mondjuk mindre) reagál. Nekem pl. sikerült ilyen címmel tesztelni anno, amikor először játszottam I2C-vel - én se olvastam doksit előtte.

Következő. Beüzelemtem egy némítás funkciót is amikor a legalsó hangerőértéknél lejjebb tekerem, akkor némítja az IC-t a kijelzőre pedig két középső vonalat ír ki. Működik is a dolog, de valamiért mindíg bevillan a nulla is amikor tekergetem, pedig nem kellene.



Most így néz ki, de ahány módon ez lehetséges, mindenhogyan megpróbáltam átugrasztani a nulla felett, de valamiért mindíg bevillan és biztos, hogy a nullával van gond, mert, ha kitörlöm akkor nem villan és persze nem is ír ki soha nullát. -79-ig megy le a számláló és úgy van megcsinálva, hogy ha 80-ra ér és az első karakter nyolcas, akkor 8 helyett vonalat jelezzen és a második is csak egy vonal legyen, ami egyébként nulla lenne ugye.