Tényleg félreértettelek, mert azt hittem, hogy a Hi-Tech fordítót használod, nem pedig a CCS-t. De mindegy, mert mi nemis ezekre gondoltunk itt, hanem a C18 fordítóra, ami a Microchip gyári fordítója a 18F picekhez. És ehhez vannak a Microchipnél példaprogramok, amikben van megszakításos USB kezelés.

Már ezt is letöltöttem, és nézegettem a kódokat, tehát most keresztbe állnak a szemeim Attól tartok akkor ezt meg kell tanulnom :/
A CCS Compilert nem bírom rászedni, hogy ne kapcsolja ki az interruptokat...

A CCS-t inkább felejtsd el, nemigazán találkoztam még olyannal, hogy komolyabb fejlesztéshez használnák...

Nem olyan vészes a Microchip usb csomagja, csak univerzális

Okés, köszönöm szépen mindenkinek, ráálltam a C18ra...

Mély levegő.

A CCS-nek saját USB kezelő driverei vannak, azzal kellett/lehetett volna próbálkozni.

A Microchip demója természetesen a Microchip C18 fordítóhoz készült...

A CCS saját USB kezelő driverét használtam, annyira ügyefogyott nem vagyok

Közben átnéztem, mert nem hagyott nyugodni, mi is lehet a probléma forrása, és úgy tűnik, hogy megtaláltam.
Legalábbis az usb_init() függvény meghívása után, nincsen interrupt kikapcsolás.
Másolom a kódot:




Elméletileg ennyi módosítás kellett, hogy működjön CCS alatt is az USB gond nélkül. (egyelőre ennyit tudok)

A gyakorlat azonban mást mutat, az usb_flush_out() függvény is hibát okoz, és ezzel nem tudok (egyelőre) mit kezdeni, ha a teljes tartalmat megjegyzésbe is teszem, már hibát jelez...

Folytatom a C18at

Nem valami olyan gond van, hogy valami függvény meg van hívva két helyről is, egyszer a főprogramból, máskor meg megszakításból és amikor egyszer benne van a függvényben, majd megszakításból ismét bemenne, akkor azt a CCS nem tudja lekezelni, és ezért van a hiba? Ez a reentrancy vagy valami hasonló nevű dolog, és a C18 ezt tudtommal tudja, a CCS viszont nem. De az is lehet, hogy valami dolgokat elpiszkál a nem előre tervezett végrehajtási sorrend miatt, és amiatt nem megy, és semmi köze a reentrancy-hoz.



Jól teszed

De re-entrancy... Már küzdöttem vele akkor is, mikor két megszakításban is szoroztam. ~ azóta azt már korrigáltam a főprogramban

Lehet, hogy békiben hagyom a CCS-t, aztán csak C18... Már kezdem kicsit kapisgálni, hogy is működik, meg pár dolog szimpatikus benne.

No mind1, ha netán sikerül meoldást találnom CCS-ben, akkor megosztom veletek

Köszi a figyelmet ^^

Az lenne a kérdésem, használ-e valaki HiTech C-t 16F és 18F PIC-ekhez. Én nemrég kezdtem el nézegetni, amikor a Microchip bejelentette, hogy felvásárolta a HITech-et, és ezentúl ez a fordító lesz az általuk hivatalosan támogatott megoldás a 16F-ekhez. Mivel most már létezik a PRO verziónak Lite üzemmódja, ezt használom, ehhez nem kell külön licensz.

Pár hete nekiálltam egy projektnek (frekvencia- periódus- és időmérő), ami 16F886-tal indult, aztán időközben 18F2620 került bele (a timerek kényelmesebb volta miatt). A 16F miatt kezdtem HiTech C-vel, a típusváltás miatt nem akartam fordítót is váltani, így maradtam a HiTech-nél a 18F mellett is. A készülék firmware-e a hétvégén nagyjából össze is állt.

Fejlesztés közben viszont volt pár érdekes tapasztalatom. Úgy tűnt, hogy mindegyik valamilyen módon a tömbök címzésével függ össze, mintha nem jól számolná ki a fordító az index(ek) alapján, hogy hol keresse a tömbelemet.

Az első nyűg egy kétdimenziós (const) stringtömbnél jelentkezett, és a jelenség olyan volt, mintha benne lenne egy kettes szorzó a sorindexnél: s[0][0], s[0][1],... elemek jól kerültek elő, de amikor s[1][0], s[1][1],... elemeket kellett volna elővenni, akkor rendre az s[2][0], s[2][1],... elemek kerültek elő, más sorindexnél is ugyanez volt a tapasztalat.

A másik problémát tegnap lokalizáltam: függvényen belül deklarált konstans tömbök (int, long) elemeit mintha egyáltalán nem találta volna meg, valami teljesen értelmetlen értéket vett elő. PICkit2-vel debugolva a tömb létrehozása után a változók ablakában jó értékeket láttam pedig. De ahol a program egy elemet használni akart, ott már hülyeséget szedett elő. A konstans tömböket kitettem a kód publikus részébe, a függvényeken kívülre, és rögtön meg is javult.

Más tapasztalt ilyen jellegű gondokat a HiTech C fordítóival?

(Megpróbálok majd összeütni olyan egyszerű kódokat, ahol a problémák konkrétan nyakon csíphetők.)

Én használom sokat a HiTech -et, de ilyet még nem tapasztaltam. Amúgy függvényekben nem nagyon használok lokális változókat, pláne nem tömböket. Mivel ezeket a C stack -ből kéne hogy lefoglalja (legalábbis PC-n így megy), az meg PIC -ekben nem nagyon van. Mekkorák ezek a kétdimenziós tömbök ? Nem lőttél túl az indexeléskor a határainál ? Gondolok itt arra, hogy ha definiálsz egy tömböt char akármi[10] -el, akkor ugye a tömbindex 0 - 9 lehet.

Rosszul tudom, hogy egy lokális változó(legyen az konstans) csak addig él, amíg a függvény be van töltve? Utána átadja a helyet a következő rutinok lokális változóinak, konstansainak. Így a konstans nem lesz valódi konstans. Ha globálisan hozod létre, akkor más a helyzet. A másik, hogy konstanst nem nagyon érdemes RAM területen létrehozni. Vagy nem is RAM területet jelöltél ki nekik?

Persze, az olyan lesz, hogy a fordító kódot generál a feltöltésére. Nyílván nagyon nem optimális a dolog, igazából csak azért tettem oda, mert csak abban a függvényben kívántam használni, és logikailag oda való lenne.

Amúgy a publikus konstansokat a ROM-ba tette, ezeket a lokális konstanstömböket pedig RAM-ba. Lépésenkénti nyomkövetésnél a függvénybe belépve még nem is voltak benne az értékek, a tömbdefiníciót átléptetve kerültek bele. Tehát biztos, hogy odagenerált hozzá egy inicializáló kódot is. Jó nagy pazarlás, de nem foglalkoztam (volna) vele, mert flash és RAM is van bőven a 18F2620-ban.

Nem, a túlcímzés szerintem teljesen kizárt. A stringtömbök a működési módokhoz tartozó kijelzéseket tartalmazták, pl. mondjuk egy 3x3-as tömbben volt a 3 üzemmódhoz tartozó 3-3-3 mérési tartományban kiírandó mértékegység. Az üzemmódot és a mérési tartományt nyomógombokkal globális változókban 0-2 tartományban, ciklikusan változtattam. A 0-s módnál jók voltak a kiírások, az 1-es módnál a 2-es módhoz tartozók jöttek elő, a 2-es módnál meg "memóriaszemét".

A tömböt egydimenzióssá téve, és az indexet kézzel számolva (mode*3+range) meg jó lett, ez is maradt a véglegesben. Egyébként az MPLAB-ból PK2-vel debugolva a watch ablakokban a tömböket jól mutatta, úgy nézett ki, minden elem a helyén van. Csak éppen a program futásakor mintha nem jól címzett volna.

Sziasztok! Hátha valaki tud segélni! Sok éve programozon ASM-ben, most ráálltam a c-re, már megy is, de csak a c30-ban tudok dolgozni, a c18 nem akar fordítani, állandóan a projectnév.o nevü file kellene neki. Honnan adjak? Napok óta szenvedek, nem bírok vele. Elérési utakat beállítottam(szerintem) a Hi-tech sem akar működni, float-számoknál hülyeségeket ír ki. Naon kéne 18-asokat progiznom, segéljen valaki ha tud!
Köszi előre is.

Csatoltam két képet. Nézd meg, hogy neked mi van itt beállítva!

Helló!

A float számok használatához be kell fordítani a math.h és a float.h fájlokat a forráskód elején.
A másik problémádra sajnos nem tudom a megoldást de lehet hogy másnak segítene, ha bemásolnád a pontos hibaüzenetet.

üdv brejti

A forrásmappát kivéve stimmel. De majd pár fotóval illusztrálom. Addig is köszi.

Úgy érted hogy #include ?

Másképpen is lehet..?

Igen. Én a programokat mindíg a
#include stdio.h
#include stdlib.h
#include string.h
#include stddef.h
#include < math.h
#include float.h kezdem. Mindegy hogy mennyi header fájlt teszel bele, úgyis csak azokat a kódrészleteket fordítja be ami kell neki.

üdv brejti>

Szebben #include < stdio.h > lenne, de már nem tudtam módosítani a hsz-t.

Használd a kód gombot és az elején egészíts ki a [ code =c ] -re.

PIC-et programozok C nyelven es elakadtam.

unsigned int analog2a(unsigned int dval)
{
float rd;
rd=(dval * 1 )/0.4;
return((unsigned int)(rd+0.5));
}

is=analog2a(convertanalog(2));

sprintf(is_s,"I: %02u.%01uA",is/1000,is%1000);

Aramot merek egy sonttel, olyan formaban szeretnem a sztringbe beirni a mert aramot hogy: 00.0A

Mit rontottam el?

Hogy érted hogy használd a kód gombot?

Bár nem neked írták, de úgy, hogy amikor kódrészletet szúrsz be, akkor azt jelöld ki, majd kattints rá a Kód feliratú gombra. Ekkor a kódod {code} és {/code} közé kerül (persze szögletes zárójelekkel), és így az oldal megjelenítésekor szépen formázva lesz, mint ahogy a kódszerkesztőben is volt. Ha C kódot szúrsz be, akkor egészítsd ki, hogy {code=c} legyen, ha asm kódot szúrsz be, akkor pedig {code=asm} legyen. Azthiszem az asm az alapértelmezett, ha nem írsz oda semmit.

Megtiszteltetés lett volna megtudni, hogy mégis milyen PIC-ről és milyen C-ről van szó, s nem utolsósorban azt, hogy tulajdonképpen mi a probléma.

Esetleg erről van szó?

Jelenleg ezt írja ki az LCD-re: 00.00A nem kell ilyen pontosan, elég egy tized pontossággal: 00.0A.

Értem, kösz. Igazán azt hiszem a C18 lenne egyszerűbb, ez először kéri a "c018i.o! file-t. Azt +adtam neki, akkor viszont "elso" nevű project esetén kéri az "elso.o" file-t, amit szerintem neki kellene +alkotni. Vagy talán az előfordító csinál ilyet, amit aztán a fordító nem talál... Tudom, aztán kialakul majd minden, de bele kellene rázódni. Kónya könyvben nincs utalás rá. Az a helyzet, hogy írtam egy komplett 3 tengelyes CNC cvezérlő assembli progit 16f887-re ami 2300 soros (+szenvedtem vele de működik) csak kevés a portom, és ezt írnám át c-ben, 18F6680 procira, ez már asm-ben sok meló. Nektek gyerekesnek tűnik a problémám, de sajnos nem bírok vele. Amúgy ASM-ben rengeteg megírt progim van, az automata méréshatárváltós frekimérőtől a liftem vezérléséig, CNC léptetőmotorvezérlő , stb kb 300 progi, ebben tudok segélni ha kell, de most én vagyok a veremben, és nincs veremmutató

Arról neked kell gondoskodni, hogy a tizedesek helyén kiíratott szám 0 és 9 közé eső értékű legyen. Ezért javasoltam a maradék 100-zal történő osztását.