Akkor még esetleg arra tudok gondolni, hogy a programban lehet rossz valami, pl. a számokat vagy betűket rosszul definiálta. Annyit tegyél meg, hogy a programban találsz egy ilyen sorral "put_number_in_W
" kezdődő programrészletet, nos a te bekötésed alapján ellenőrizd végig, hogy tényleg azoknak a számoknan/betűknek kell-e megjelenni a kijelzőn, ami a megjegyzésben van.

Ezt úgy teheted meg, hogy mint mondottam vala, azoknak a szegmenseknek kell aktívnak lenni, ahol a PIC kimenetén logikai nulla van. Tehát jelen esetben az
RB0-tól egészen az RB7 -es láb valamelyikén.

Vegyük például a "0"-t, a kapcsolásban szereplő kijelzőnek az a/b/c/d/e/f szegmenseknek kell világítani, ez azt jelenti, hogy az RB5 -ös láb kivételével -ugyanis a g szegmens ide csatlakozik-, mindegyiket 0 -ra kell állítani. Programban ez jónak tűnik.

Ezeken fussál végig szépen a te kijelződ adatlapja alapján, és nézzed meg (bár gondolom már sokszor megtetted), hogy tényleg oda kötöttél -e mindent, ahova kéne, nem volt véletlen figyelmetlenségi hiba. Remélem érthető voltam.

A PGM akkor érdekes, ha az alacsony feszültségű programozás engedélyezve van.

Amiről még nem esett szü, az a VUSB láb. Az hová van kötve? Ha Vdd-ről 5 V-tal megy a tápellátás, akkor enegedélyezni kell a belső LDO stabilizátort, és VUSB-re egy szűrőkondenzátort kell kötni. Egyes kapcsoláskon 470 nF-et látok, de az adatlap pontosan megmondja, hogy mi a regula.

Nem, nincs rákötve semmi az USB-re, azt nem is néztem. De teszek oda is egy kondit.

Ez nem az USB (az a D+, D- láb lenne), hanem a VUSB, a belső stabilizátor kimenete. Az adatlap szerint minimum 220 nF kell rá.

A konfigurációs bitek hogy vannak beállítva?

u.i.: az Interneten talált egyik alapkapcsolást mellékelem.

Passz, a progi nincs itt. Végignéztem adatlap, meg fórumok alapján, hogy minden fölös cuccot kikapcsoljak. Belső óráról hajtom. Azt a konfigbitet küldte át rosszul a PIC-be a Mikrobasic, pont ezért néztem át az egész config beállítást. Most tápom nincs hozzá.

Ezt én is láttam. De van itt a HE oldalán is egy teljes cikk róla.

Vusb PIN18: Internal USB 3.3V voltage regulator output. Vagy ez az USB más USB?

Nem "az USB más", hanem a Vusb-t ne keverjük össze az USB-vel! (lásd alább)

En nem ismerem kozelebbrol ezt a Mikrobasicet, de ugy erted annak van egy valami IDE felulete es azzal hajtod meg a programozot? A HEX-ben jol vannak meg a config-ek csak a letoltes kozben serul?



Low vagy full-speed-del csinalsz USB-t? Eleg stabil az a belso soci ehhez? En USB-s cuccokhoz mindik krsitalyt hasznalok, meg sem kisereltem massal...

Nem küldök-fogadok semmit USB felé. Nincs is rákötve semmi. Ez az IC volt kéznél.
A Mikrobasic csinál egy hexet, azt küldöm át PICKit2-vel. De még nem próbáltam ki kondikkal, stb. Majd beírom, mi lett.

Találtam tápot neki.

Kondi ott van a VDD VSS között MCLR 10K-t kapott, Vusb 470 nanot, és semmi. Már nem emlékszem, melyik progit tettem bele a végén, otthon fordítok egy új belső órára állítottat, és megnézem. Utána villogó kód feltöltése, aztán csak kiderül vmi.
Ha halott lenne a PIC, akkor nem menne a programozás sem verifyvel, ugye?

Közben ma sikerült a CAN-t bekonfigurálnom.
Szépen megy az üzenet küldés.
A következő feladat az a fogadás lesz, de oda már kelleni fog interupt is.
Majd kérdezek, ha abban is elakadok.

Ha megy a fogadás is, akkor van kedved megosztani velünk valamilyen formában az alapkapcsolást, és valami alap kódot?

Jut eszembe: Ki is igerte az ECAN cikket?

Remélem nem én voltam...

A Microchip oldalán van egy rakás Application Note CAN témakörben. Még CAN buszos bootloader is található (AN247)! Ha nem fog a fék az autóban, még van egy esély: röptében lecseréled a firmware-t!

Egyenlőre a kód nem túl bonyolult. A SID-t a DLC és az adatbájtokat sima movlw és movwf parancsokkal rakom be. A BSR-t a 15-ös bankra állítottam. Ott van a CAN is. Ha pedig meghívok valamilyen késleltető rutint, aminek a változói a cblock 000h címtől indulnak, akkor csak egy 0-át biggyeztek az utasítás után.
Az érdekes az az volt, hogy amíg nem csatlakoztattam az RX lábra is a transcievert, addig error framek jelentek meg a vonalon.
Ja és ASM-ben írom a kódot, mert egyenlőre a C-s függvényeket nincs kedvem megtanulni. Nem túl bonyolult a C nyelv, de inkább az ASM-et erőltetem.

[OFF]

Ugy erted ropteben mikozben az auto harmat pordul a levegoben?

Amugy ez egy erdekes tema lenne raakaszkodni az autora es par dolgot monitorozni es vezerelni -- pl uuugy szeretnem azt a vacak ABS-t egyszer kikapcsolni De ez mar nem ide valo tema, ugyhogy ha majd elkezdek ilyenekkel foglalkozni atmegyek a CAN Miertek Hogyanokba

Idézet:
„pl uuugy szeretnem azt a vacak ABS-t egyszer kikapcsolni”

Rokon elsőgenerációs Lagunajaban saját biztosítéka volt az ABS-nek...

Ha az ABS-t ki akarod kapcsolni, azt CAN-en keresztül nem tudod. Raksz egy kapcsolót az egyik kerékjeladóra. Ha szakadást érzékel a vezérlő úgyis kikapcsolja ezt a funkciót. Hogy ne tűnjön off-nak, a kapcsolót csináld meg PIC-el. Figyeli, hogy volt-e portb változás, interrupt, és ott egy tranyó meghúzza a relét

Feltöltöttem a belső órás kódot rá, semmi. Vmikor hajnalbantöltök rá vmi asm-ből fordított villogós cuccot, ha akkor se megy.....

Hello mindenki!

potyo, még egyszer nagyon köszi a múltkori linkért!! Nagyon sokat segített. (Itt)

Végre sikerült megcsinálnom a PS/2-es billentyűzet kiolvasást 16F877A I/P-s PIC-re!!

Éppen most próbálkozok a parancs küldéssel. :S Az a gondom, hogy ha mondjuk 0xFF-et (reset) küldök akkor az megy. A 0xEE (echo) is megy. De ha mondjuk azt küldöm el, hogy 0xED (LED-ek beállítása) akkor csak valamiféle hiba üzenetet (0xF8) - vagyis gondolom, hogy azt - küld vissza a billentyűzet 0xFA helyett ami az ACK. :S Azért csak gondolom mert nem találok róla semmit. :S Parancsként egy beállításhoz van hozzárendelve de ez a billentyűzet küldi vissza. :S

Bővebben: Itt

Nem tudjátok, hogy mi lehet a gond? Egyszerűen nem tudok rájönni. Már próbáltam átírni a kódot is mert arra gondoltam, hogy esetleg fordítva vannak a bit-ek de úgy sem lett jó. :S A paritás bit biztosan jó vagy legalább is nem számít mert mind a 3 esetben ugyan az lesz.

Köszönöm a válaszokat előre is és elnézést, hogy ezzel zargatlak itt titeket de nagyon idegesít, hogy nem bírok rájönni. :S

Bye!

Az említett oldalon nekem a jelszintek nem voltak egyértelműek, hogy mikor mit kell csinálni küldéskor. Egymás fölé vannak az élek rajzolva, és nem tudtam, hogy most előbb melyik élet kell megcsinálnia a kontrollernek. Itt szebben le vannak rajzolva a jelek: Link

Egyébként úgy csináltam annakidején, hogy egy-egy 10k ellenálláson keresztül felvettem hangkártyával az adat és az órajelvezetéken futó jeleket ezzel a progival: Link, és így ki tudtam elemezni, hogy azok a jelek futnak-e a vezetékeken, amik kellene, hogy fussanak. Egyszerűen bekötöttem a hangkártya line-in bemenetébe a két jelet, katt a progiban a record-ra, és utána nagyíthatod tetszés szerint, hogy át tudd vizsgálni. Jótanács: vedd le a gépen a hangerőt, a line-in csatorna bemenőjét meg tedd maximumra

Hali!

Én ígértem az ECAN cikket. Kifújtam magam az elmúlt két napban. Most vagy két napig még javítgatom a kódot, Jövő héten hétfőn állok neki, csak előtte még kellene valami jó diagramm szerkesztő program, a folyamatábrákhoz. Tudtok valamit? Aki azt mondja hogy Word azt megölöm...

A PIC18-as ECANhoz. Abszolute nem javaslom hogy félig-meddig összerakott áramkörrel kezd el csinálni. Az ECAN modul a PIC-en belül kb egy plusz proci a bonyolultságát nézve. Mind az RX, mind a TX lábakat azért kell bekötni, mert a Slave (bár ECAN-ba olyan nincs is) küldözgeti vissza az ACK (Nyugta, vétel, vége) jeleket. Ezek hiányában a Master hibákat detektál.

"0" szintet azért mértél mert az ECAN buszon az "L" a domináns érték, tehát nagyrészt mindig L van, főleg ha éppen nincs adás.

Szóval írom a cikket na. Egyenlőre szövegszerkesztőben aztán a többi meg majd kiderül.

[OFF]

DIA-t nezted mar?

Alul az external linkeknel ott a home page-e meg par mas hasznos anyag...

Köszi a tippet.

Az oldal nagy embereihez lenne kérdésem a PIC-es ECAN cikkel kapcsolatban.
A program olyan hogy nagyon univerzális. Még arra is figyel hogy egy vagy két ECAN modul van e a PIC-ben. A címzés, és az adatáramlás benne teljesen autonóm, ha egyszer beindul, tulajdonképpen nem is kell már figyelni rá. Ezeknél az okoknál fogva a program illetve az elgondolás elég komplex, azaz sok ábrát és magyarázatot igényel. Mennyire gond az ha a terjedelme forráskód nélkül lesz vagy 20 oldal? Úgy értem gépelt A4...

Én foglalkoztam a CAN-el. Szóval szerintem nekem válaszoltál.
Ha minden jól van beállítva, akkor High szinten, azaz alapértelmezetten recesiveben van a CAN volnal. Ha nem így lenne, akkor nem lenne értelme a start bitnek, ami dominans lesz.
A CAN azért nem ment nekem először, mert nem volt jó konfigolva. A helyes konfig eltalálása után a TX lábon elkezdte nyomni az error frameket. Innen tudtam, hogy mostmár lassan működni fog a ketyere.
Amint hozzácsatlakoztattam a berendezéshez, azonnal tudtam parancsokat osztogatni.
Mostmár csak a vétel van hátra, amit a jövőhéten fogok átnézni.

Ismételten NAGYON KÖSZI!!!

Nem tudom, hogy hogy fogom tudni meghálálni.

Végre sikerült megcsinálni és már majdnem tökéletes csak egy gond van. A parancsok elmennek és kapok választ is mégpedig azt, hogy ACK. Ha ez megvan akkor elvileg nekem még küldenem kéne egy argumentum bájt-ot azaz egy olyan bájt-ot amibe benne van az információ ahhoz, hogy melyik LED-eket kapcsolja be a billentyűzet.

De azt nem tudom, hogy ez is úgy néz ki mint egy rendes bájt vagyis 11 bit-es vagy pedig csak simán 8-as azaz külön kell kezelni?

Ugyanúgy küldöd, mint az előző bájtot, tehát 11 bit. Ha jól emlékszem, arra is válaszold ACK-val, de ez nem biztos.

Nekem nem gond, ha hosszú. Mostanában úgysincs időm valaminek komolyabban nekiállni, legalább lesz mit olvasnom