Sajnos ez sem hozott semmi eredményt.

Valami olyasmit akar mondani a proteus hogy nem találja a forráskódot.

Köszönöm mindenkinek, megoldódott. A hiba oka az AVDD és az AVSS lábak szabadon hagyása volt. Ugyan nem értem hogy ha beállítom hogy Vdd Vss legyen a referencia, akkor miért kell bekötni, de ez már csak ilyen... lényeg hogy megy...
simpi! Köszönöm a segítséget! Ami a proteus témát illeti, amikor a kérdést feltettem, még abban a hitben voltam hogy valami konfigurációs dolog lesz a hunyó, ezért került ebbe a topickba. Most hogy a hiba kiderült a PIC miértek hogyanok-ban lenne a helye, de ha tudtam volna hogy mi a baj oda tettem volna.... vagy meg sem kérdezem.
Ami az u? -et illeti az azért maradt benne, mert cserélgettem az MCUT (más típussal ment), de ez a proteust nagyon nem zavarja ha nincs ütközés.
A power-t azért kellett paraméterezni, mert a másik szimulációban két tápot használ, 3.3 és 5V, így meg kell neki adni hogy melyik legyen.

Úgy, hogy alapbanban minden cuccnak aminek van hidden pinje a tápnak a VCC/VDD-t adja.

Heló Mindenkinek!

Programozással kapcsolatban szeretném kérni a segítségeteket. Egy időzítős áramkörön dolgozgatok, aminek egy DS1302 adná az RTC részét. Microchip C18-ban tudok C programokat írni, illetve ebben írtam már meg a programom teljes egészét. Az RTC-t nem tudtam működésre bírni saját kóddal, ezért a neten keresgetve találtam CCS-ben írt kódot, nagyon hasonlót ahhoz, amit Topi tett közzé egyik cikkében. És itt a gondom, hogy tudnám a kettőt összefésülni úgy, hogy ne kelljen átírnom a CCS kódot C18 fordítóra. (Egyébként már megpróbáltam, szerintem jó a kód, de mégsem tudom kezelni az RTC-t.)
Van erre valami fordítási lehetőség, hogy az RTC-t kezelő függvényállomány CCS-ben íródjon, a törzsprogram pedig C18-ban?
Válaszotokat köszönöm!

ui.: Ezt a kérdést feltettem egy másik topicban is, nem tudom hova illene jobban, így előre is elnézést kérek azoktól akiket zavarna ez.

Röviden: sehogy.

Köszi!
Azért gondoltam erre a lehetőségre, mert arról hallottam hogy Assembly és C források működnek együtt. De akkor még ügyeskednem kell a saját kódommal.

Az tuti, hogy a Microchip C fordítójával nem fogsz eredményt elérni CCS forrással. És viszont: a CCS nem fogja a Microchip C fordítóhoz gyártott forrást lefordítani; ők ketten kölcsönösen nem kompatibilisek.
Az, hogy a két C fordító eredményét valahogy összelinkelni - ezt nem tartom lehetetlennek, de ebben nem hiszek. Ehhez kéne valami megegyezés, hogy pl. függvények hogy hívják egymást, paramétereket hogy adnak át, meg ehhez hasonlók. Ilyen nincs, továbbá ha csinált is volna a Microchip ilyen platformhasználati kiskátét, akkor se hinném el, hogy a CCS majd pont ezt fogja betartani - ha már a C szabvány alaptípusokról szóló kitételeit is letojták, na akkor mit várhatunk...

Igen, ezekben teljesen igazad van, én is pont ezeken gondolkodtam, hogy még ha az object fájlok meglennének, utána valahogy össze kellene linkelni őket, de akkor ott a baj hogy hogyan nevezzük nevén a gyereket (függvények, változók)...
Akkor marad a további próbálkozás a DS1302 lelkivilágának megértésével...

Köszi a segítséget!

Szoval azert nem egy tul bonyolult az a driver, hogy ne lehetne atirni masik C-re. Talan az elso 3-4 fvenyt kellene atirni, es a tobbiben is 1-2 sort. Siman bitbillegtetos kezelessel csinalja a DS1302 irasat, olvasasat. Amugy eleg nehez tobbfele C-bol forditott object fileket osszefesulni, mert a valtozo atadas, a SW stack es mas dolgok erosen forditofuggoek.

Valóban nem lenne bonyolult, meg átolvasgattam már az IC adatlapját is, de nem tudok értelmes adatokat kiszedni az IC-ből. Nem tudom hogy a beírásnál van a hiba, vagy csak a visszaolvasásnál, de nem működik a dolog.

Hogy lehetne egy ilyesmi "struktúrát" csinálni és fordítási időben már adatokkal feltölteni?



Tehát olyasmi kellene, hogy példa kedvéért négyelemű tömb, aminek az elemei struktúrák, és a struktúra mezői is tömbök. Valahogy úgy használnám, hogy
Természetesen a nev és az ertek nevű mezők minden struktúrában ugyanakkorák lennének. A lényeg az lenne, hogy már fordítási időben ez az egész létrehozható legyen, és hogy a kódmemóriában lehessen tárolni.

Szerintem így, a "const rom"-ra nekem valamiért rinyált a fordító.

Köszönöm, tökéletes. XC32 is kicsit problémázik, hogy char * helyett const char *-ot adok át az LCD kiíró függvénynek, de működik.

Szia! Csak a típuseltérés miatt. Próbáld módosítani a függvényben a típust.

A függvény char* paramétert vár, ez jelentheti azt, hogy a függvény módosítani akarja a pointer által mutatott területet (bár kiiratásnál ez nem hiszem, hogy szükséges). Ha const char* típust adsz a függvény nem tudja módosítani a tartalmat, hibás működéshez vezethet(említetted hogy ilyen probléma itt nincs). Globális változók kezdőértéke mindig a kódban kerül elmentésre, ha kitörlöd a const kulcsszavat nem fog a RAM igény megnőni és eltűnik a tipushiba is.
P.S: arra oda kell figyelni, hogy az így létrejött változó ne szerepeljen értékadás bal oldalán, mert akkor létrejön a memóriában(RAM) is.

Arra gondolok, hogy akkor meg azért problémázna, ha char *-ot adok át const char * helyett. De lehet, hogy nem, majd kipróbálom.

Ez érdekesen hangzik. Ezt is kipróbálom, lehet, hogy tényleg lényegtelen oda a const kulcsszó.

Ha más char* -ként hívja, akkor ugyanott vagy. Ha nem hosszú, akkor két függvény, vagy egy konverziós függvényt közétenni... De tényleg lehet, hogy nem kell a const... Volt már, hogy nem foglalkoztam a fordító nyavajgásával, jól működik most is.

PIC32, ezeknél minden memóriaterület látszódik egy közös területen, szóval két függvényre biztosan nincs szükség. Csak a fordítót kell rávenni, hogy ne csináljon semmi jelzést a kérdéses sorokra.

Nem kéne, hogy problémázzon. Ez gcc, ez nem szokott hülyéskedni

Próbáltad hívásnál (char*) -al castolni? Akkor eltűnik a warning szerintem.

Azt nem, viszont átírtam a kiíró függvényt, hogy const char *-ot várjon és így nincs warning.

A tipuskonverzió önmagában jó megoldás, eltünteti a fordító figyelmeztetését, viszont muszáj meggyőződni arról, hogy a működést ez nem befolyásolja.
Én ezért szoktam kerülni a cast-olást ha olyan függvényről van szó amit nem én írtam.

Sziasztok!
Egy egyszerű kérdésem lenne: High-Tech C-ben egy integer típusú változó x. bitjére hogy lehet hivatkozni?
Meg ha erre valaki valamit mondana, megköszönném.

Illetve még egy olyan kérdésem is lenne, hogy ez a C 18 Compiler minden PIC-nél működik? Mert engem ez a HIGH-TECH C egy kicsit idegesít, hogy sok függvényt nem ismer.
16F-es PIC-ről lenne szó.

C18 mint a neve is mondja, csak a 18F chipekre fordít

Változó x. bitjére attól függ, hogy mit akarsz vele csinálni.
Pl. ha meg akarod nézni, hogy egy vagy nulla az x. bit. Ha egyesre akarod állítani, akkor ha nullázni, akkor ha ellentétesre akarod állítani, akkor

Lehet csinálni union-t, és akkor el lehet nevezni az egyes bitjeit is a változónak és akkor lehet bitenként hivatkozni rá, a fordító megoldja a többit.

És végül nem High-Tech, hanem Hi-Tech

Köszi!
Most hogy mondod tényleg Hi-Tech, pedig Vasárnap még jól írtam. ... de ott van az már.
Sejtettem, hogy csak 18F-esre.

Igazából arra lenne szükségem, hogy a változó x. bitjét átpakoljam a 10 bites PWM regiszter 0. és 1. bitjébe. Azt hittem van egyszerűbb is mint ez a tologatás, mert elég sok olyat láttam forráskódokba, hogy "."-tal választják el (pl. variable.4), de persze nekem nem működött. Igaz, hogy inkább TRISx-re, meg PORTx-re csinálták.

Az az uninon az hogy is van?


Ezt a sort kell folytatni 7-ig (1 byte-nál)? Vagy egyszerűbben is lehet?

Habár lehet mégsem jó a kód mivel így elég sok változó kellene, mindegy már nem javítom ki. Esetleg a feltételek után var = 1, var = 2, var = 4.... ami jobb megoldás lenne.

Na utána néztem ennek az unionnak a Kónya féle könyvben szerencsére van rá példa, viszont nem biztos, hogy teljesen jól értelmeztem.
Azt szeretném most csinálni, hogy lenne egy FLAG nevű 8-bites változóm aminek az egyes bitjeit szeretném írni és olvasni és 0-akat és 1-eseket false-sal és true-val helyettesíteni.
Eddig ennyire jutottam ami le is fordul csak nem tudom, hogy fog-e működni rendesen:


A másik megoldás ugyanez csak struktúrával:


És az lenne még a kérdés, hogy mi a különbség a 2 kód között, illetve mit vesz a fordító alapértelmezettnek ha a változók után nem írom oda, hogy 1 bites változóról van szó (":1")?

Ez a "C-s" hagyományos megoldás:



Általában szokás akarni egyben is kezelni a biteket (mondjuk az egész byte-ot akarod másolni), arra meg ez a módi dívik:

Köszi szépen! Akkor lényegében az enyém is működne. A define viszont tényleg egyszerűbb, nekem is eszembe juthatott volna. Gondolom akkor ezzel a módszerrel azt is könnyedén már meg tudom csinálni, hogy egy float vagy int típusú változót küldjek ki a soros portra.

*