Fórum témák
» Több friss téma |
Ezt olvastad? "To boot into the main program RA3 (PIC18F1XK50) or RB4 (PIC18FXX5X) must be 1 and EEPROM at address 255 must be 170."
Ha jól értem, az alkalmazás HEX állományában kellene lenni EEPROM-ba írásnak is.
Tehát programozás közben 1 nek kell lennie vagy az RA3 nak vagy az RB4-nek és az eepromba külön be kell írnom a 255. címre a 170 et? És akkor menni fog?
Hát igazán nagyon szépen köszönöm icserny úr. Beírtam a 0xaa-t az EEPROM-ba és megy. További jó programozást mindenkinek.
Igazad volt! Megy a belső óra rendesen! De a külsőről hajtott Timer1 megszakítás az indulás után 5-6 másodperccel jön először. Az normális?
Egyébként nem is engedi lefordítani , hibát ír :
Nézegesd meg az AN849-ben az ábrákat, lehet rossz értékű kondit használsz.
Idézet: Wireshark-kal nézni és értelmezni kellene a csomagokat! Bővebben: wireshark.org „Nekem valami ötlet ?”
Valami nem gömbölyű azzal a forrással, próbálj meg visszatérni az eredetileg letöltött forráshoz. Nem tudom, milyen módosítást végeztél rajta, de belekeveredett egy csomó .html elem.
Ha minden igaz 33 pF van mellette, az általad javasolt doksi ezt írja, a 18F14K22 adatlapja meg 27 pF-ot. Lehet kicserélem majd. Köszi!
Az eredeti forrással is ez az eredmény fordításkor. Mplab+ HI-TECH ANSI C compiler
De igazából ez csak egy dolog , hogy ez se jó , de az eredeti hex fájl se . A hozzászólás módosítva: Márc 25, 2015
Idézet: Ez nagyon aranyos! A letöltött csomag neve pedig 1351339727_pic_16f877a__8mh_mikroc_pic.rar, azaz a Mikroelektronika MikroC fordítójához készült. A honlapon látható fénykép szerint pedig a hardver Mikroelektronika kártyáiból van összedugva. Neked is ilyen kártyáid vannak, vagy a hardver sem azonos? „Mplab+ HI-TECH ANSI C compiler”
Sziasztok!
Előre szólok, hogy nem kimondottan PIC-hez kötött a kérdésem, de nem találtam job topic-ot és szerintem ide is bele illik. Jelenleg egy komplexebb szoftver (OSEK operációs rendszerrel megáldva egy 16 bites Renesas mikrovezérlőn) egyik modulján dolgozok emellett még van egy SPI modul is amely kicsit túl van bonyolítva, ami miatt nem valósidejű az adattovábbítás, ami annyit jelent, hogy az írás/olvasás függvények meghívása és az adatküldés/fogadás vége között kb 2ms telik el. A modult (vagyis azon belül egy függvényt) amelyen dolgozok 25ms-onként hívja meg az op rendszer és ebben a függvényben kellene adatokat küldeni/fogadni SPI-n keresztül egy LED drivernek/től. Mivel pl. az olvasási eredményt nem azonnal kapom meg, hanem csak a következő ciklusban így egymás után nem is tudok több adatot küldeni vagy fogadni, csak minden ciklusban egyet-egyet ami kicsit idegesítő, mert pl a LED driver egy regiszterét ha módosítani akarom akkor először ki kell olvasni, majd a kiolvasott adatot módosítani aztán visszaírni. Ennek a LED drivernek van egy LATCH bemenete is amit minden 16 beléptetett bit (regiszter cím + adat) után aktiválni kell, természetesen ezt csak írásnál. Kérdésem az lenne, hogy hogyan lehetne megoldani praktikusan az adatok írását/olvasását hogy egy függvény (pl egy másik modulból) ami adatot akar kiolvasni az valamilyen módon kapja is meg még akkor is ha kicsit később... Én sajnos nem boldogulok sehogy vele. Jelenleg ott tartok, hogy egy nagy 40 bájtos bufferben eltárolom az összes küldeni kívánt konfigurációs adatot majd periódikusan (minden 25ms-ban) kiküldöm. Ha kis idővel később más adatot akarok küldeni akkor csak módosítom a buffer adott részét, beállítom a hozzá tartozó indexet majd küldöm megint periódikusan... Ez működik is szépen írásnál, viszont az olvasást nem tudom, hogy oldjam meg, hogy minden szinkronban legyen :/ Előre is köszönöm a tanácsokat
Nem , nekem csak 1 db pic-em van és egy enc modulom. Mellékeltem képen.
MikroC-ben is ugyan azokat a hibákat dobja ki , mint Hi-tech-nél egyébként. Megnéztem wireshark-al nem látni semmi adatot az enc felől. Ip scannerel is néztem , az se találta meg . Most az eredeti letöltött hex fájl van beleégetve , de semmi. A hozzászólás módosítva: Márc 26, 2015
A breadboart alsó kék sávaja és a felső kék sávja össze van kötve vezetékkel? És a piros a pirossal? Maga a breadboard nem köti össze őket.
Igen , tápot kap mind a 2 oldalon, mellékeltem hogy is néz ki .
- Az mclr láb is fel van húzva 3.3V -ra , 10K ellenálláson keresztül , amint az látszik is a képen. - Az oszcillátorhoz pedig HS van beállítva , mert 8 MHZ. - Az enc CS lába pedig 3.3V ra felhúzva , szintén 10K ellenállással. Szerk: Rámértem , az a 3.3V pontosabban 3.28V. Nem tudom ez mennyit számít. Az égető pedig amivel beégettem a hex fájlt egy Icsp k150 - es A hozzászólás módosítva: Márc 26, 2015
Az nem lenne baj, annyival is elmegy a pic. Viszont nem ártana bele egy led és valahol a program közepén, végén bekapcsolni, hogy lásd, fut egyáltalán a program.
Na ez jó ötlet , az a bajom ezzel , hogy mikroc ben fordításkor nincs hex fájl. Én rontottam el valamit , vagy egyébként sincs?
Megoldódott a probléma 5V kellett a picnek , nem 3.3. Estére összekészítek mindent és csinálok róla egy kapcsolási rajzot .. Hátha jól jön még majd valakinek ..
Egy kép a fordító ablakáról sok információt adna, miért nem keletkezik hex állomány...
Sziasztok!
Több helyen is olvastam, legutóbb pár sorral feljebb, hogy az mclr lábat fel kell húzni magas jelszintre. Ha nem akarom reset célokra használni, sőt semmilyen célra, nem elegendő ha a config beállításoknál átállítom sima bemenetre, és hagyom lebegni?
Lehetni lehet, kikapcsolhatod, de ha nem kell semmire akkor jobb ha felhúzod.
Már működik. De most mikor beleégetném a picbe a hex fájlt azt írja ki , hogy : fuse error 0x2007
Ez mi ? (ICSP K150 programozó ) A hozzászólás módosítva: Márc 26, 2015
A mikroC fordításkor ezt a hibaüzenetet adja :
Idézet: „0 1501 Specified search path does not exist: 'D:\P\# Electronique #\_uC-WEB_\# PIC 16F877A (8MHz) + ENC28J60 Mini Web Server #'” Idézet: „0 1501 Specified search path does not exist: 'D:\P\# Electronique #\_uC-WEB_\Serial Ethernet Examples MikroElektronika\Serial Ethernet Examples for PIC\mikroC PRO for PIC\HTTPServer_Example'” Hiányzik neki egy fájl , de ez nincs benne a letöltött rarr fájlba. Ötlet esetleg? A hozzászólás módosítva: Márc 26, 2015
Mellékeltem egy képet , hogy mik hiányoznak. Így ezek nélkül nem is tudom módosítani a forrást.
Valakinek lenne ötlete , hogy mi is ez , hogy lehetne orvosolni ?
Én nem látok hiányzó fájlokat. Inkább az a probléma hogy a projekt olyan elérési útvonalakat definiál, amelyek nálad biztosan nincsenek (lásd a httpserver_example.mcppi állományban).
Ezekkel kellene tenni valamit, de ebben csak az tud segíteni, aki ismeri a MikroC-t.
Sziasztok!
Valaki meg tudná mondani miért í ki hibát az Mplab? Van egy minta projektem C18-ban a bootloader-hez. Ha ugyanazt létrehozom ugyanúgy a mappájában van a linker script file is akkor is ezt írja ki: Error - processor types do not agree across all input files. Errors : 1 Link step failed.
Értelek. Igazából próbáltam kitörölni is az útvonalakat , de az a baj , így a 38 kb -os hex fájlból, csak 9 kb-s lesz. Működésképtelen.
Idézet: „Error - processor types do not agree across all input files.” Az MpLab -ban beállított processzor típus nem egyezik meg valamelyik állományban megadottal. Talán pont a linker script -belivel... |
Bejelentkezés
Hirdetés |