Mivel is szenvedsz, 87j90-nel? Az MCC18/h/pconfig.h állományban ehhez EAUSART_V6 típust írtak, ami elvileg két soros porttal rendelkező kategória.

Ugyanott az usart.h állományban deklarálja az eljárásokat és a makrókat. Ott az EUSART_V6 típusnak csak baud1USART()-ot definiálja. Ez nem tudom, hogy mire jó. Az EUSART_V7-nél baud2USART()-ot is deklarálnak.

Az Open2USART() függvényt is ugyanitt deklarálják (az usart.h-ban), s a forrásfájlok között (MCC18/src/pmc_common/USART) az u2open.c az EUSART_V6 típushoz is definiálja az Open2USART() fv-t.

Nem lehet, hogy olyan forrásállományból hivatkozol a függvényre, amelyhez nincs becsatolva az usart.h állomány? Ha több forrásállomány hivatkozik a soros portra, akkor mindegyikbe be kell csatolni.

Ezt a p18f87j90.h deklarálja.

A TCPIP WebVend App -el szenvedek.
A 87J60-nak két EUSART-ja van, ezt tudod. Hogy hivatkozhat olyan regiszterre, ami nem is létezik? Nem találom azt a h állományt, ahol ezt deklarálja úgy, hogy látható lenne, hogy melyik USART modulra hivatkozna. Mert azt el tudom képzelni, hogy felül hivatkozza a gyári hivatkozásokat, miért is ne, de egyelőre nem találom hol. Ezek a gyári demok, borzasztóak!

Ha csinálok egy külön projectet, simán lefordul az említett Open2USART.

A TXSTA-t valóban lefordítja a fordító(nem néztem mire), de ha megnézed a watch ablakban a regisztereket, nincs ilyen regiszter. Akkor mit is állítok be vele? (Utánanézek a p18F87J60-ban.)

Naa, azért ne essünk már túlzásokba, te is tudod hogy ez nem igaz. Az asm nem szükséges a pic hw működésének megértéséhez. Ugyanis teljesen mindegy, hogy egy regisztert úgy töltesz fel hogy pl PORTB=255; vagy movl akármi w reg, majd mov tökömtudjami portb.

Ugyanis nem az alu, és a gépi kódú parancsdekódolás megértése a cél, hanem a többi hw részegységé, és hogy ezek hogy kapcsolódnak a külvilághoz. Ez pedig elektronikai kérdés, nem pedig nyelvi. Sok kezdő meg csak fogja a fejét, ha ledvillogtatáson kívül valami mást is kéne csinálni, pl elosztani egymással két számot.

Szóval szerintem egy kezdő, ha nem ismer semmilyen programnyelvet, és valamit meg kell tanulni, jobban teszi ha nem az asm-el kezd. Annál átláthatatlanabb spagetti kód nincs is.

Nem téged akarlak meggyőzni, csak kicsit képviselem az ellenpólust, a "mindenáron asm, mert csak az a király" nézettel szemben.

Én az előbb más típust (87J90) néztem. Na,mindegy. A 87J60 viszont az EAUSART_V9 kategóriába tartozik. Ehhez is definiálva van az Open2USART() függvény a forrás szerint.

Ez idáig mind szép és igaz. De a PIC mikrovezérlőnek nem csak regiszterei vannak, hanem utasításai is, státuszbitjei is és hardveres veremtára. Ezeket már C-ből nem lehet kezelni, vagy megérteni (különösen ha az egy C utasítás több gépi utasításra fordul). Ezt is meg kell tanulni valamikor (nem feltétlenül a legelején). Már csak azért is, mert néha assembly betéteket kell használni, vagy a fordítónak a körmére kell nézni.

Azt, hogy mivel érdemez kezdeni, nem vitatom. Ízlés, hajlam és előképzettség dolga.

Persze, működik is, ha külön projectben használom. De az említett demóba illesztve nem fordul le, akkor sem, ha include-olom az usart.h-t. Máshol nem használja a demo forrása, mert nem használja a fordító függvényeit, hanem sajátokat írtak, de abban sem tudtam eddig kideríteni, hogy miképpen hivatkoznak a két EUSART modul közül az egyikre. Csatolom az általuk írt USART.C-t csak hogy lásd miről is beszélek.

Fő kérdés, minek TXSTA-t deklarálni a p18F87J60.h-ban, mikor nincs is ilyen regiszter?

Megnéztem a assembler listát, és a TXSTA a 0xFAC címre fordul, ami nem más, mint a PIC TXSTA1 regiszter címe. Nyílván ez így működik, de számomra zavaró, hogy kétféleképpen is lehet rá hivatkozni. Persze megértem, hogy a forrás hordozhatóságára jó hatással van, de nem sokat változtatna egy #if -ekkel amúgy is rogyásig zsúfolt demo program képén!

Hát ez elég jól meg van cifrázva! A HardwareProfile.h-ban például át van nevezve az összes soros portot kezelő függvény, mert enélkül szegény Microsoft magával sem kompatibilis!

Egyébként úgy tudom, hogy a PIC18 periféria könyvtárakban a számozatlan név az 1-es sorszámú eszközre vonatkozik.

Meg! Ezt hívják microchippéknél segítségnek!
A C még amúgy sem a legerősebb oldalm, de még ilyen csavarásokkal is meg kell küzdenem!
Arra is gondoltam, hogy létrehoztak egy teljesen egyedi hivatkozási felületet, amiből kizárták a fordító eredeti függvényeit, ezért nem működik az usart.h. Gondolhatod, hogy akkor hogyan lehet ráültetni a felhasználó programrészeit, ha már itt elakadok, hogy nem tudok portot nyitni. Persze most nekiállok és kézzel megnyitom, remélem úgy működik, más nem én is megírom a saját kezelőket!

Szerintem nem ennyire tragikus a helyzet, fogd fel úgy, hogy ez egy hardver absztrakciós réteg! Talán pont ezeknek a definícióknak a módosításával (vagy új kártya definiálásával) lehet oda irányítani a ki/bemenetet, ahová szeretnéd. A PIC24 esetében például láthatóan a második soros portra irányítja a hivatkozásokat, mert az Explorer 16 kártyán a második soros port van kivezetve a kártyáról.

PIC18 SPI könyvtáraknál nagyobb zöldségeket is láttam (most az SPI-t gyötröm):
- Bizonyos (egyszerű) feladatokra makrókat definiál az spi.h
- a forrásfájlokban ezeket törli, majd függvényeket definiál ugyanezzel a névvel. Így a lib állományokban függvények vannak.
- Igen ám, de amikor alkalmazást fordítok, újra definiálódnak a makrók, így az alkalmazás azokat használja, hiába vannak ugyanezen néven függvények a lib-ben.

Sajnos nem túl jó véleménnyel vagyok a gyártó "műveiről". Most sem pozitív irányba mozdul, bárhogy is próbálom felfogni a dolgokat.
Például nem értem miért kell egybegyúrni mindent. Miért nincs egy szűz egy csomag átvitelére alkalmas Stack, ami nincs egyedi megoldásokkal teletömve? Túl nagy kérés biztos...

Én tapasztaltam olyat is, hogy az application Maestro és egyéb kiadott ap. notes-ok tartalmaznak olyan kódrészletet ami még biztosan sosem fordult le senkinek !
Annak sem aki írta...Ugyanis a 0 el van írva O betűre.
Akik ezeket írják egy laborban ülnek !
1 soros kódra függvényt írni ???
A megadott példák a való világban általában nem használhatók. Különösen a kommunikáció esetén.
Tanulásra viszont jók !
Az USARTOpen 2 oldal kód és ez egy valós alkalmazásban max. 4 sor és tized annyi kód méret. Nem beszélve a hiba kezelésről és TimeOut-okról illetve egyéb gyíkokról !
Én is írtam anno prepoc számításokat a baud-ra.
Minden adatlap megadja különböző kombinációkat és a hibákat is...akkor meg minek görcsölni.

Én olyat találtam régebben az Ethernet stack-ben, hogy az LCD kezelő négy bites módban biztosan nem volt üzemképes. Már nem emlékszem, hogy mi volt pontosan, de az biztos, hogy hibás volt...

Nem is ilyenekre gondoltam, hanem pl mikor a CCS C egy egyszeru output fuggvenylen elkezdi piszkalgatni a TRIS-t, illetve mikor a C-hez olyan API-k tartoznak amikkel ugye LCD-t, PWM-et, USB-t stb lehet hasznalni. Igaz, hogy ezekkel pillanatok alatt fel lehet epiteni egy szep alkalmazast, azonban ha valami nem ugy jon ossze akkor bizony kell az a tudas, hogy miert nem csinalja azt amit csinalnia kellene. Es akkor ott johetnek compiler hibaktol kezdve library hianyossagokon keresztul ilyen aprosagok is amiket a fordito elrejt, pl a mar emlitett TRIS piszkalgatas vagy fuggveny prologue-epilogue mellekhatasai, vagy pl konfiguracios mizeriak mint pl C18 ahol mar nem mindegy hogy enhanced vagy standard modba kapcsolja az ember az MCU-t, vagy, hogy egy nem reentrans fuggvenyt meghivunk megszakitasbol stb...

Igen, meg lehet tanulni, hogyan tedd átláthatatlan katyvasszá a forrásodat, és hogyan nem szabad felépíteni egy programot.

Szerintem az a gond, hogy mi úgy állunk hozzá a dologhoz, hogy a firmware az a hardver része, és eszünkbe sem jut, hogy esetleg másik hardveren fusson ugyanaz a kód vagy kódrészlet, vagy másik a fordítóval is lefordítható legyen. Sokan viszont hisznek a kódhordozásban és emiatt van az, hogy ilyenek lesznek a kódok, hiszen így a forrást tele kell pakolni feltételes fordítói direktívákkal...

Én meg közben rájöttem, hogy én a TCPIP Demo App-ból indultam ki annakidején, elnézést kérek a félrevezetésért

Most elbizonytalanítottál, miután nem látom át teljesen, hogy mi más a két forrás között, így nem tudom mit várhatok a WebVend App -tól. Lehet, elkezdem előről. Nem hiszem egyébként, hogy sokat veszítettem, mert rengeteg dolog kezd tisztulni, ahogy dobálok ki mindazt, ami eltakarja az erdőben a fát!

A hordozhatóság egyértelműen a szándékuk, de ezzel pont nem azt érik el, hogy az ismerkedő átlássa a feladatot, ami amúgy is elég kacifántos, de még gyomlálja ki a PIC feltételes fordítások elágazásait is. Tényleg az MPLAB nem támogat olyasmit, hogy követhető lenne a feltételes fordítások útvonala, esetleg lépésenként, vagy pontoknál megállítva? Még ilyet nem csináltam, elnézést, ha triviális dolgot kérdezek!

Szisztok egy c programot írok és többszintű menürendszerre lenne szükségem amit utólag könnyen módosíthatok , de nem tudom ezt honnét tudnám elsajátítani vagy valami magyarázós példát találni hozzá, vagy könyvet v valamit.
Ha valakinek nem nagy fáradtság segíthetne ebben.
Válaszokat előre is köszönöm!

Egy pici segítség kiindulásnak: Bővebben: Link

Sajnos az Open2USART problémám nem oldódott meg, aki tud kérem segítsen, mert nem értem mitől van a csatolt képen látható hiba! Köszönöm!

Szia,

En ezt az infot leltem csak fel (azt irjak, hogy esetleg ujabb PIC-ekkel meg lehetnek lemaradasok, meg lehet nincs teljesen kesz a tamogatoi konyvtar...)



Bővebben: Link

A gond ott van, hogy egy másik projectben tökéletesen működik, csak ebben a TCPIP Demo App ban nem. Mit állíthattak be, hogy nem működnek a gyári C18 headerek? Egyébként nem csak az Open nem működik, semmi, amit az usart.h ír le. Nem vesz róla tudomást a fordító, hogy beincludeolom. Elérési utak rendben, stb. Nem tudom mit lehet beállítani, hogy ez így működjön.

Nem lehet olyan, hogy az a fájl olyannal kezdődik, hogy
?

Ezesetben ha már valahol van definiálva az USART_H, akkor ebből a fájlból nem vesz ki semmit.

A main.c -be tettem az include-t, ott nem láttam ilyet. Próbáld ki te is, ha nem gond! Megvan a forrás ugye?

Korábban kérdeztem futólag, hogy lehet-e fordítás közben, vagy után követni az #if-ek által vezérelt fordítási útvonalat?

Amugy nekem ugy tunik, hogy a linker akad ki, mintha nem lenne a projecthez rendelve az az object file vagy library file, ami ezt a fuggvenyt tartalmazna. Nem tudom melyikben lehet, majd megprobalom elo idezni a jelenseget, vagy leforditani a kododat este.

Van olyan forditoi kornyezet ahol lehet "#warning" -okat meg "#pragma message" -eket betenni, es akkor az uzenetekbol latod, de azt hiszem a C18 csak a standard "#error"-t tamogatja. pl:



A gond csupan az, hogy ilyenkor a forditas megall, tehat ha arra hasznaljuk ezt, hogy megnezzuk merre kodorog az IF-ek kozott, akkor utana azt ki kell onnan szedni, hogy tovabb fordulhasson...

A masik lehetoseg, hogy a preprocesszor kimenetet megnezzuk, ami eleg faradsagos lehet -- C18-ban most nem is emlekszem general-e ilyen kodot ill hogyan, de ha nem akkor egy GNU preprocesszorral (GPP) is lehetne eppenseggel ezt a reszet leszimulalni. De ha mar azt hasznalod akkor a #warning es #pragma message is kell mukodjon!





Tehat ha fent van a gcc-t linuxon vagy pl mingw-vel windows-on, akkor:



es akkor kapsz egy test.txt-t ami a #define-ek, #if-ek es egyeb makrok kibontasat tartalmazza (valoszinuleg eleg nagy lesz a file mivel beinkludalsz mindenfelet ami beinkludal meg mas mindenfelet, ami beinkludal.... stb stb stb )

Nade, ha:



mondasz neki, akkor meg leforditja de nem szerkeszzti meg es meg csak assembly kodot sem general, azonban laltni fogod a #warning ill. #pragma message cuccokat...

Ez jól hangzik, és biztosan működik is, de van egy kis baj vele a jelen helyzetben. Ezt a Stack-et nem én írtam, és utólag mindenhová betenni jeleket elég gáz. Most úgy oldom meg, hogy ccc=bbb; sorokat szúrok be, ahol kíváncsi vagyok, hogy befordul-e. Persze ez is leállítja a fordítást, ha ráfut, de legalább látom amit kell.
Én arra gondoltam, hogy esetleg van egy lista, esetleg lépésenkénti fordítás lehetőség, amin követhető a fordítás menete, de ezek szerint nincs. Azért köszi az ötleteket, hasznosak lesznek!

Az jó lenne, ha meg tudnád nézni, mert az a gyanúm, hogy más gyári függvény sem használható, de ezt még nem próbáltam...