Fórum témák
» Több friss téma |
C18-ban egy .LST -t lehet generaltatni amiben a generalt ASM kod van benne -- merthogy normalisan a C binaris filet csinal, ill C18-ban (es mas embedded forditoknal is) a binaris HEX reprezentaciojat tartalmazo file.
Nem emlekszem most, hogy hol lehet bekapcsolni, de konyen lehet alapertelmezesben megvan, csak meg kell keresned a project knyvtaradban... HEX-bol vissza forditast cska vegszukseg eseten javallok! Abban ugyanis hianyozni fog nehany info ami a kod konnyebb megerteset segiti ill. ha az eredeti C forrassal szeretned osszevetni... Idézet: Alapértelmezésben megvan, csak letiltani lehet az MPLINK linkernek adott /d vagy /w opcióval. Utóbbit a "Supress COD-file generation" opció bejelölése is automatikusan beszúrja a parancssorba. „Nem emlekszem most, hogy hol lehet bekapcsolni, de konyen lehet alapertelmezesben megvan”
Egy kis segítséget kérnék a hozzá értőktől.
Van egy 4x20 karakteres kijelzőm és hozzá egy USB-s modul külön, benne egy 16F54-es. Van egy demo szoftver benne, ami kiír pár sort. Mellékelem, de segítséget szeretnék kérni, mert lehet, hogy hibás a forrás, vagy mplab beállítási gond, de nem igazán fordítja le. (az is lehet, hogy a forráshoz szarul csináltam meg a projektet.) Kezdő vagyok. Csak meg akartam érteni a forrást, de így hogy gond van nem igazán van siker élmény. köszi.
Nincsen azon USB modul, csak az 5 V-ot kapja USB-ről. A lefordításhoz nem ártana tudni, hogy milyen fordító melyik változatához készült.
Mellesleg ez az áramkör így milyen célt szolgálna, mire akarod használni?
Mellékeltem az adatlapot, de sok infót nem tudok meg belőle.
Egyenlőre csak gyakorolni szeretném az LCD -t szöveg kiiratást. konkrét eszköz még nincs amibe beépíthetném, vagyis majd a laminátorba. annak meg van itt hex.
A HI-TECH C compiler for PIC10/12/16 MCUs Version 9.71a-val lefordult. Bővebben: Link
Sziasztok! Kis kihagyás után újra sikerült elővennem a pic-et. Próbálgatnám a C18-at. De csak addig jutottam, hogy kapok egy hibaüzit. Nem tudok sehogy tovább lépni, kérnék egy kis segítséget!
A roppant bonyolult kód:
És az mplab baja: "Error - processor types do not agree across all input files." Azt értem, hogy valamelyik fájl nem az adott procihoz tartozik, de csak a 18f4550.lkr van hozzá csapva. Előre is köszönöm a segítséget!
Nem árt, ha a Configure->Select Device alatt is kiválasztod a 18F4550-et.
Ki van ott is.
Hoppá! Meg van! A linker script volt 4450, ezer bocsi!
Üdv mindenkinek!
Olyan valakit keresek aki PIC - USB kommunikációra kész programot írna. Konkrétan ezt a kapcsolatot kellene stabillá és életképessé tenni , a pic tudjon adatot küldeni a pc-re amit az feldolgoz /HID is jó vagy spec pc-progi. access Port direktbe FT ic nélkül/ A munkát nem ingyen kérem! Konkrétumot pm.-ben mondok.
Nézd, ez itt szakmai fórum. Ha meg akarod tanulni, akkor ingyen segítünk (kész USB CDC kommunikációs példákat találsz pl. a PICCOLO projekt mintaprogramjai között is).
Ha pedig mással akarod megcsináltatni, akkor az nem ide való, hanem az Apróhirdetés rovatban légy szíves közzétenni a felhívást!
Mindkettő érdekel. Szívesen tanulok, köszönöm a biztatást! Ha sikerült kicsit elmélyednem benne és van kiszemelt PIc akkor jelentkezem!
USB-s kategóriában talán a PIC18F4550 a legelterjedtebb, sok példát találsz hozzá.
Ma és tegnap megint felbosszantott a microchip. Nem elég hogy felvásárolták a Hi-Techet... Az új 16F es fordító is 18F es szintaktika felé mozdul, lesz itt unionba ágyazott bitmegnevezés dögivel, lehet gépelni a 25 karakteres bit megnevezéseket, meg fél képernyőt elfoglaló konfig makrókat. Az is kiverte a biztosítékot, hogy meg írtam volna nekik a fórumba egy-két hibát (mindjárt írom), de kitörölték a fórumból "remek" termékük visszajelzéseivel foglalkozó topicot.
Tegnap meg az dühített fel, hogy kiadnak egy 18F es procit, amihez 10 oldalas hibajegyzék tartozik, hogy miben tér-el, működik rosszul a gyári leíráshoz képest. Ha ilyen hulladékot sikerült gyártani, és tudnak is róla, akkor mi a túróért dobják piacra ?! A másik meg hogy írnak egy új elcseszett fordítót az elcseszett dokumentáció alapján. Ami persze olyan kódot fordít emiatt, ami a valóságban nem működik. Hab a tortán, hogy ha már gyártják a hulladékot mind hw és mind sw szinten, legalább a saját hibajegyzéküket vennék figyelembe. ![]()
A hosszu nevekkel nincs semmi gond: Van code completion, azt kell hasznalni. Ami miatt egyre tobben hasznaljak, mert igy a kod "onmagat kommentalja". Jobb, mint az 1 betus valtozo nevek es az AVR-es PORTB &= 0x34; stilus velemenyem szerint...
A forum kitorlessel kapcsolatban nem tudom mi lehetett, de mostanaban sok valtozast csinaltak a forumon (nem itt! A Microchipnel!). A jol mukodo content managert lecsereltek egy hasznalhatatlan vacakra -- lehet ilyenekbol is adodik, hogy eltunnek forum bejegyzesek? Nekem epp az ellenkezoje volt amug a tapasztalatom, ezelott kifejezetten tetszett, hogy nem szedik le a negativ megjegyzeseket. hanem megirjak a problema megoldasat. Pl PIKkit3 szidalmakat is eleg komolyan vettek... Amugy meg szerintem a hibajegyzek kifejezetten jo! Nem tudom melyik tiusrol beszelsz, azt mikor hoztak ki es mikor fedeztek fel, hogy az adatlapban nem jol irtak le valamit, vagy hogy a szilikonon hiba van... De azt azert mindenki tudja, hogy tokeletes termek nem letezik. Ez igaz szoftverre, hardverre, kenyerre es udito italra is! Viszont a hibakkal jo tisztaban lenni tehat ugy tudunk ellene tenni valamit.
Hát nem tudom, nálam az autocomplete nem igazán működik. Beírom hogy INTCONbits. erre felhoz két lehetőséget: .u29 .u30. És ha enterrel elfogadom valamelyiket akkor INTCONbits..u29 lesz az eredmény. Két pont, szánalmas. INTCONbits.TMR0IE -t meg sehogy nem tudom autocomple-el beírni.
Azt elfogadom, hogy nincs tökéletes termék, de azért van az a pont ahol, selejtnek kell nyilvánítani. A másik meg, hogy miután kiderült a hiba, villámgyorsan kéne igazítani a fordítón nem ?
Milyen hibak ezek amugy? Amugy csak ugy halkan jegyzem meg a Microchip mindig is eleg rossz volt Szoftver fejlesztesbol, es sajnos AppNote-jaik sem mindig vannak a toppon. Viszont a PIC-ek eleg jok szerintem, tehat chip gyartoknak bevaltak.
pl láttam olyan hibát, hogy AD konverternél egy eléggé pontos időzítéssel meg kell szakítani a konverziót a vége előtt, mert különben magától nem ér véget. Ez szerintem kimeríti a nem működő chip fogalmát.
Konkrétan nekem 18F6622 -vel van bajom, hogy az új compiler nem hajlandó CONFIG3L -t programozni engedni, mert szerinte olyan nincs, pedig van. Szeretem persze én is a piceket, de ezek a hibák elég bosszantóak. Főleg ha az előző compilerrel még működött. Azután a C18 féle konfigolást (#pragma config) próbálnám megkerülni a __PROG_CONFIG(CONFIG3L, xxxx); makróval, de itt meg a xxx helyén nem írhatom bináris formában amit szeretnék. Nem fogadja el csak decimális alakban. Azután a 9.64 es fordító mellé felpakolt 9.63 teljesen összezavarja, nem lehet váltani a kettő fordító között normálisan. Na mindegy, régen nem ilyen volt, igaz akkor még csak 12, 16F -ekkel foglalkoztam, és azokból is a régebbi típusokkal.
Ez nem az a hiba ami volt regen, hogy ha nem tetted le sleep-be akkor nem mukodott jol? Marmint ha a GO bitet figyelted... ha fix idozitessel csinaltad vagy ezzel a sleep trukkel akkor mukodott... na mindegy, lehet nem ugyanaz.
A 18F6622-vel kapcsolatban: A header file-t nem lege egyszeruen csak attenni a regibol az ujba? Vagy lehet a library (is) kellene? Valahol mintha olvastam volna ehhez hasonlo panaszt, de hol? ![]() ![]()
Itt is volt már erről szó, én is azt gondolom, hogy elég lenne a header fájlt áttenni. Na de valamit említett akkor lidi, hogy ez valami új tipus, amihez nincs régifajta header fájl?
Igen, az egy olyan pic az volt. Félő amúgy hogy nem lehet áttenni egyszerűen a header file-t. Mivel a régi konfig makrókat sem fogadja el, lehet hogy van benne egyéb, aminek változott a szintaktikája. De végülis lehet hogy kipróbálom. Azt azért nem gondoltátok volna ti sem hogy a 16F -est is átalakítják nem ? Bár annyi logika van benne, hogy legalább egységesítésre törekszenek.
Idézet: „Azt azért nem gondoltátok volna ti sem hogy a 16F -est is átalakítják nem ? Bár annyi logika van benne, hogy legalább egységesítésre törekszenek.” Gondolom egyszerubb ugy a kesobbiekben a kod konyvtarakat karban tartani, appNote-okat megirni, usernek is komyebb egyik vagy masik MCU-rol atternie mivel kevesebb atirast igenyel, ha (majdnem) minden ugyanaz... Idézet: Bizony nem. Sőt, máig nem értem, hogy mi értelme volt, amikor ott vannak a PIC18-ak.... „Azt azért nem gondoltátok volna ti sem hogy a 16F -est is átalakítják nem ?”
Hát igen, nem gondoltam volna, és még én is ezt írtam valamikor régebben. Mondjuk az egységesítés az jó dolog, csakhát ezzel sok régi projekt alól kiveszik a fordítót. Jobb lenne megtartani a régi módszert legalább a régi chipeknél, és valami define-al lehetővé tenni a használatát...
Na most tök hülyén érzem magam. Most nem találom azt a fórumot, ahol erről volt szó. (mármint hogy a 16F -es fordító is átalakul mplabos stílusra ) Most vagy benéztem valamit, és keltem csak itt a pánikot feleslegesen, vagy a Hi-tech fórumán a work in progress részben olvastam, amit mostanra levettek. (vagy csak halandó nem férhet hozzá, legalábbis nekem "acces denied" et ír, egy google cache ből előkotort linkre )
![]()
Nem néztél be semmit, mert amikor erről itt szó volt, én is letöltöttem a próbaverziót. De még béta verziónak is nagyon gyengének találtam (némely esetben triviális programokra is csak azt a hibajelzést írta ki, hogy nem tud kódot generálni), úgyhogy kb. 10 perc után le is szedtem gyorsan.
Sziasztok!
Vásároltam egy PICkit 2-t. Mivel P16F887-et tartalmaz, ezért csak a HItec C fordítóval tudom programozni. Illetve tudnám, ha rájönnék mi a baj. Elvileg mindent szabályosan csinálok. Mindent feltelepítettem. A Kónya könyv 3. kiadásából a 18.5-ös mintaprogramot akarom megcsinálni (a legelső program). Ha valaki érte a PiCkit 2 - Hitec-es C fordítóhoz annak részletesen leírnám mit csinálok és esetleg meg tudná mondani mi lehet a probléma. Valószínüleg valami egyszerű dolog lehet. A PIC16F887-et lehet használni más C fordítóval is? Köszi Feri
Idézet: Hát persze! Például a MikroC fordítóval. Pont a PIC16F887 programozásáról szól Milan Verle "PIC Microcontrollers - Programming in C" c. könyve (ami a Mikroelektronika honlapján szabadon olvasható).„A PIC16F887-et lehet használni más C fordítóval is?” De biztosan van még féltucat C fordító, ami használható. De a HiTech C a Microchip által hivatalosan támogatott fordító, tehát nem érdemes félrelökni csak azért, mert nem sikerült az első félórában zöldágra vergődni vele! |
Bejelentkezés
Hirdetés |