Ez pontosan az, amit mondtál neki, hogy csináljon!



Ez meg nem az, amit mondtál neki!



Azt a valahovát bizony meg is lehet nézni, hogy hol van, csak ehhez megint az adatlaphoz kell nyúlni!



Tévedésben vagy, a C18 pontosan azt csinálta, amit mondtál neki (az más kérdés, hogy amit mondtál neki, az úgy alapból hibás), míg a CCS bizonyos értelemben a saját feje után megy.



Meg arról sem, hogy nekem 43-as lábam van...

Miért nem jó a PORTD=valamivel?
Egyébként a komparátort kéne kikapcsolni talán az adatlap szerint, ezt még ki kell próbálni.

A feladat 45 különálló időzítést kell létrehozni. Eltérő időpillanatokban indulnak, és változó időkkel. Amit le kell időzíteni az a 10 ms-tól a 30 percig tart.

Mi nem világos ezen? Nézd már meg azt az asm listát, hogy hová tette a 0x12-t. Pontosan a PORTD regiszterbe tette, és te pontosan ezt mondtad neki. Az más, hogy te nem tudod, hogy ezzel mit csinálsz, de ezért ne a fordítót szidd! A szimulátor pedig pontosan azt mutatja, amit a hardveren is tapasztalnál.

Az eltérés - amit nem látsz - hogy a CCS egyrészt odaokoskodja, hogy nem a PORTD regiszterbe ír, hanem a LATD regiszterbe, (mert 18F-nél a kimenetek írását abba kell csinálni), de ettől még a szimulátor ugyanazt mutatná, mert egész PORT írásakor mindegy, hogy PORTx vagy LATx. A másik, hogy a CCS azt is odaokoskodja, hogy a komparátorokat letiltja, amikor a SET_TRIS_D()-t hívod, ezért látod azt, hogy a CCS kódjában a PORTD fel is veszi azt az értéket, míg a C18 kódjában nem. Egyszerűen azért, mert a C18-at senki sem kérte arra, hogy buzerálja a CMCON regisztert, így azt nemis bántja, ebből kifolyólag pedig a PORTD0..3 és 5 bitek nullának vannak olvasva.


Komolyan ennyire hülyének nézed a Microchipnél a fejlesztőket, hogy egy ilyen egyszerű kód nem működne?

Srácok, srácok! Nem szeretnék békebírót játszani, de ez a vita parttalan és a hozzá kapcsolódó hangnem pedig méltatlan hozzátok. Tudomásul kell venni, hogy a programnyelvek olyanok, mint a nők... Mindenkinek "bejön" valamelyik, de attól még, hogy nem mindenkinek ugyanaz, attól még az a nő is lehet szép... Szerintem mindet más mentalitású szakembernek találták ki, és ezt azért le is írják a cégek. A Microchip pl. feltételezi, hogy olyanok használjáj a C18-at, akik az assemblert jól ismerik, ahoz pedig hozzá tartozik az adatlapok jó ismerete. A CCS C szlogenje: "kezdőknek és profiknak" és ez látszik is a barátságosságán. A Hi-Tech C kifejezetten sok gyakorlattal rendelkező profiknak íródott. Nekem is a CCS C "jött be", független attól, hogy assemblert is használom és adatlapot is nézegetek, ha kell. Lehet szívni mindegyikkel eleget, én is szívtam a CCS C-vel (talán vannak, akik még emlékeznek rá) egy egyenlőségjel elől hiányzó SPACE miatt napokig... aztán mégis szeretem... Az ember felesége sem hibátlan, oszt mégis szeretjük, nem igaz?? Na, már úgy gondolom, hogy az enyémet csak én!!!

kipróbáltam, tényleg a komparátor zavart be utána a portd=xxx és LATD=xxx is jó lett.
Hát ezért jobb a CCS. Az eleve a LATD-t írta, és előtte valószínű kikapcsolta a komparátort is. Persze a C18 szó szerint azt csinálta amit mondtam, és ez is jó bizonyos szempontból. Na jó megtanulom ezt a C18-at. Nem olyan gáz, csak a helpje lehetne jobb.

-Én hetente négyszer teszem magamévá a feleségemet!
-Én hetente háromszor!
-Én hetente kétszer!
-Neked nincs is feleséged?!
-Ja, azt hittem a tiédről van szó

Na látod, ezért mondjuk azt, hogy asm-ben kell kezdeni és meg KELL tanulni az adatlapot használni, akkor nem lesznek ilyen amatőr hibák. Persze ha maradsz a CCS-nél, akkor sem jönne elő, de a gyári programok nem CCS-re jönnek ki, ezért kell ismerni a gyári fordítókat. A beépített függvények meg olyanok, amilyenek, megvannak a korlátaik: pl. ha soros porton nyolc biten adás mellett kilenc bites vételt akarsz, azt sem igazán tudod beállítani az előregyártott függvényekkel, az adatlap alapján pedig minden további nélkül megoldható.

Egyébként ez tényleg csak nézőpont kérdése. Végül is én azt mondtam neki, hogy a D porton legyen 0x12. Nem azt akartam ezzel mondani hogy D porton ha be van kapcsolva a komparátor akkor 0x10 legyen, és ha nincs bekapcsolva akkor 0x12. E szerint a nézőpont szerint a CCS jobban teljesített.
Az más kérdés, ha használni akarnám ezután a komparátort, akkor előbb azt vissza kéne kapcsolni, és ha azt kihagyom akkor meg azért tépném a hajam, hogy miért nem megy. Persze mondjuk ha valamit használni akarok az a normális hogy azt bekapcsolom, és nem bízom a szélre be van e kapcsolva, tehát a C18-ban és a CCS-ben is kiadnám a komparátor bekapcsolást.
Szóval a CCS barátságos és C megközelítésű (ezt írtam is egy lejjebbi hozzászólásban), azt csinálja amit mond neki az ember, és ehhez kiokoskodja amit kell, míg a C18-ról megállapítható, hogy hardver közeli, adatlap tanulmányozós, inkább szó szerint megcsinálja amit mond neki az ember, de hogy az eredmény mi lesz, az nagyban függ a vastól.
Mind a kettőnek megvan a maga előnye és hátránya, mindenki eldöntheti ezek után melyiket használja.

Üdv mindenkinek!
Megint csak tudatlannak érzem magam.....
Most kezdtem el a PIC-USB-vel szórakozni. Ott tartok, hogy a demo programok némi átalakítással már mennek.
Valami olyan programban gondolkodom, ami elfutkos magában, időnként méricskél egyet, és a mérés eredményét eltárolja egy külső eepromba. Ez még mennne is.
A gondom ott kezdődik, hogy azt kéne valahogy elérnem, hogy a kütyü induláskor ne keresse az USB-t. Ha le akarom kérdezni majd rádugom, és csak akkor kéne hogy csatlakozzon a CDC, ha végeztem lehúzom és a program megy tovább.
Na ezt nem tudtam elérni. A CCS demókból akartam faragni valami hasonlót, de nem igazán sikerült.
Igazság szerint azt sem tudom merre induljak el.
Segítsetek egy jól irányzott kezdő lökéssel!
Köszönöm!
W

Amit leírtál, ahhoz nemigazán van szükség megszakításra, elmegy az anélkül is.

Mintha lenne a CDC demóprogramban valami olyasmi #define, amivel azt lehet beállítani, hogy legyen olyan láb, amin keresztül induláskor az USB vezérlő jelenlétét figyeli. Vagy lehet, hogy az a C18-hoz adott demóban láttam?

A megszakítás az sajnos kell, mert egy külső triggerrel kell indítani funkciókat.
Jelenleg ott tartok, hogy amíg az USB nincs rádugva, a főprogram sem indul el.
(közben kipróbáltam, a timer megszakítás már megy, talán menni fog a többi is, de a főprogram az el nem indul...
Van valami láb amit egy osztón keresztül kell a PIC-re kötni, de hogy mire való az nem derül ki sehol a demokból.

BOCSESZ! Elbénááztam, megy a főprogram! Alakul ez....

Akkor a kérdés tisztázva.
Megy a cucc, rádugom az USB-t minden frankó. Lehúzom, ,ajd újra rádugom és nincs COM port...

Ez alapján még mindig nem kell megszakítás. Elég a főprogramból figyelni az INTxIF bitet, és ha bebillent, akkor nullázni, meg megcsinálni, amit kell.

Lehúzás és visszadugás között mennyit vársz? Egy 10 másodpercet várj legalább!

Jóreggelt!
Megpróbálom, de az este már felborultam, attól is szenvedtem annyit.
Délután gőzerővel kísérletezek tovább....

Sziasztok!
CCS-ben, hogyan tudom letiltani az USART-ot egy 877-nél? Szeretném az RC6 és RC7-et digital I/O-ként használni, de sehol nem találom a megoldást. (PIC wizard esetén ha kiveszem az RS232 kommunikácót, nem ír a headerbe semmit sem).

Szia!

(Most jön az, hogy a CCS-t használók nem nézik az adatlapot... )

Alapból a sorosportot engedélyező SPEN bit 0, ami a soros portot tiltja. Tehát, ha nem írsz a headerbe ilyet : #use rs232(baud=.... ,akkor nem is lesz bekapcsolva.

Néztem a reference manualt és 877 adatlapját is. Nos, ha nincs a headerben semmi, akkor (sem) nem tudom elérni a fent említett 2 bitet. (Nem véletlenül írtam az üres headert.)

A puding próbája az evés...
Mindjárt leszimulálom, mert ezt nem fogom...

Nem használok 16F877-et, de ezzel sem megy máshogy! A mellékelt kis programmal teszteltem, mind a kettő elérhető. Valami más gond van.

Sziasztok

Nekem is volt hasonló nyűgöm a 877-el. Azt vettem észre, hogy a CCS fordítók verziója befolyásolja a működést. Én úgy oldottam meg, hogy :
#use fast_io(x) , hogy ne forgassa önállan az io művelet előtt a TRIS tartalmát, a TRIS regiszter beállítása, és nem használtam a #use rs232 -t a header-ben.
A v4.038 CCS jól csinálta, a 4.088 -al még ezt nem próbáltam.

Lehet, hogy függ a fordító verziójától. :nemtudom:

#use fast_io(x) használatával egyébként is helyet lehet spórolni...

Igaz. Bár ha megfigyeled a kódot, a FAST_IO esetén is írja a TRIS regisztert néha. Pl. : mielőtt kiviszi az adatot az USART-ra. A napokban vettem észre egy 18F452-esen, mi több a soros HW adó ellenére, ha RS485-re írsz, akkor az enable vonal miatt ciklusban bevárja a putc() míg kibillegnek a bitek. Ez sajna felborította az ütemezésemet. Csak saját adó-vevő blokkokkal tudtam rendesen megoldani a problémát.

Köszönöm.
Lehet itt van a kutya elásva?

(Játszok vele, hátha...)

Hát, vagy ott, vagy nem, mert továbbra is azt mondom, a #use fast_io nélkül is mennie kellene, mint ahogy a teszt program is megy, ha az a sor nincs benne.

Bocsánat, én vagyok a hülye...
Bent maradt a forrásomban a C port byte-os kezelése... Én meg nézegettem, hogy miért 0 mindíg a kimenete? Nekem is lehetne annyi eszem, hogy leszimulálom szoftverben/hardverben... Mégegyszer köszönöm a segítséget és bocsi!

Bizonyos szempontból szerencse, hogy így történt, nem a fordító hibája, mert különben a fan-ok kaptak volna még egy :boxer:
Ebben a melegben lehet, hogy mással kellene foglalkoznunk: :pias:
Üdv!

Valószínű, hogy igazad van, ( :pias: ) de akkor azok meg nem mi lennénk...

Bizony igazad van! Már annyira kész vagyok a melegtől, hogy a próbapanelon a kimenetet direkbe a tápfeszre kötöttem... (Persze az LCD-re akartam. Még szerencse, hogy a PIC kibírta!) Ez már a második hülyeségem volt. Talán egy kicsit szüneteltetni kéne a fejlesztést...? :wilting:

Idézet:
„Talán egy kicsit szüneteltetni kéne a fejlesztést...?”

Az semmiképpen sem jó megoldás, hiszen más nem fejleszt helyettünk. Inkább sűrű hidegvizes borogatást alkalmazni főleg a fejre, arcra, tarkóra