Köszi.
Magyar nyelven lilkneken ez megvan?
Legalább részben?

Magyarul csak az első van meg (az is részleges): Közepes teljesítményű PIC mikrovezérlők Felhasználói Kézikönyv

Köszi, kezdésnek ez kiváló lesz!

Sparkfun és hasonló breakout boardok kaphatóak valahol üzletben Budapesten? Már úgy értem Amerikából idáig az +két hét +posta. Valami kicsit gyorsabb megoldás jó lenne - akár webáruházon keresztül, de személyes átvétellel. A Sparkfun hivatalos disztribútorai között nem találtam az országon belül senkit sem - vagy legalábbis a weblapjukon nem jegyezték fel.

Nem hinném, hogy valaki pont az ő cuccaikat árulgatná, raktárról, anélkül, hogy a Sparkfun oldalára ne rakatta volna fel magát... ez nem hangzik annyira reális üzleti koncepciónak.
De ha megírod, hogy milyen breakout boardra gondoltál, lehet, hogy tudunk mondani fellelési helyeket.

Már eleve felforrasztva lenne jó SMD kivitelű alkatrészekkel breadboardhoz 1 soros lukacsolással, nem 90 fokos kivitelben jellemzően mindenféle csatlakozó aljzat. DB9, DB25, PS2, Audio jack stereo pld D5-ös, USB bármelyik B típus, microSD, tápfesz csatlakozók, sorkapcsok - jellegében ilyesmik.

Az SMD azért kell, mert a furatos alkatrészek mindig le szoktak lógni a panel alá - vannak rajtuk mindenféle mechanikai rögzítők, amik miatt folyton billegnek a breaden. A szurkás alkatrészekkel olyasmi gond is van folyton, hogy alul kilógnak a lábaik, és egy szurka boardon azért elég sűrűn vannak vezetékezések hosszában - ha felsértik a szigetelést, kész egy zárlat. A panel alsó részének tar simának kell lennie. A furatos nyákos breakout nem igazán szerencsés ötlet.

Ami éppen a Sparkot illeti, az sem baj, ha nem pont az ő cuccaik, mert akad azért ott elfuserált design bőségesen. Ahol az ő cuccaik megvannak, talán vannak egyebek is - és normálisabbak.

Ilyet nem nagyon láttam, üres panelt igen, amire mindenféle cuccokat fel lehet forrasztani (SOIC, TSSOP, QFP, meg hasonlók).
Én amúgy gyártottam magamnak a spéci cuccokhoz (SD slot, csatlakozók: DB9, RJ45, USB, RCA, stb.) ilyeneket, mint: Bővebben: Link

Tudtok ingyenesen letölthető programszimulátorokat?

pl. Az MPLAB szimulátora ( elég jó, csak kevésbé szemléletes, mint a Proteus ! )

Debug port jelleggel kellene felraknom egy pic-re egy szem Tx kimenetet. Visszafele kommunikáció nem lesz. Átlagos jelleggel elfogadható tud lenni csak egy 2 vezetékes rs232 a Tx és GND jelekkel? Vagy erősen javasolt odafigyelnem minden vezérlő jelre is, és szabályosan visszakötnöm az rts-cts, dtr-dsr jeleket, különben kellemetlenségeknek nézhetek elébe?

A dolog függ a sebességtől, ill. hogy a fogadó oldal micsoda. USB-soros átalakítóval fogadva, vagy rendes PC-s soros porton normál sebességgel (mondjuk <=38..115kbps) szerintem kényelmesen elegendő egy szál TX vezeték.

Jellemzően egy usb / serial átalakító lesz a túloldal, és nem terveztem 19200-nál nagyobb sebességre. Próbálok utána nézni, forgalomban lévő készülékeken mire szokták beállítani a debug portokat sebesség / handshaking kérdésekben, de éppen azokról valahogy kevéske infót találok csak. Nem tűnik kiforrottnak a felhozatal. Éppen debug portokról semmiféle kiforrott szokvány nem létezne? Még ha nem is szabvány, de legalább szokvány.

Szabvány? Ugyanmár...
A 9600bps 8/N/1 - no flowcontrol nevezhető alapértéknek, ha valaminek soros felülete van, és nem mondják meg, hogy milyen paraméterekkel, akkor ezzel próbálkoznék először.

Én is azon filoztam, csak félek, a 9600 nem lesz elég. No mind1, a kezdeti bizalmat megéri. Köszi a tippet.

Maga a PICKit2 38200 Baud -ig ad lehetőséget a soros (8n1) kommunikációra.

Ha kevés lesz, akkor majd feljebb tolod a sebességet...
Viszont úgy általánosságban vannak kihívások egy ilyen soros debug print megvalósításában...
Ha szinkron lesz a debug print, akkor jelentősen megváltoztatja a program futási sebességét (interruptban pl. eleve nem is használhatod), emiatt a külső események, perifériák aszinkron eseményei eltérő ponton érkeznek majd a normál működéshez képest - dolgok, amik működnek az egyik módban, nem működnek a másik módban.
Ha pufferelt, aszinkron debug printet akarsz csinálni, akkor meg nagy puffer fog kelleni (akkora, hogy egy PIC32 alatti modellben nem is lesz pár sornál többre elég RAM), ill. ha crash/reset/akármi van, akkor az utolsó üzenetek elvesznek.

Szoktatok breaden építkezni? 8MHz-es kristályt ha breadbe belebökök pic mellé, mennyire fogja elhangolni a rakás parazita kapacitás? Legalábbis amit a kvarc adatlapok siránkoznak pico faradokról, az a break tüskéinek erdejében kicsit viccesnek ható gondolat. Nekem sajna nincs oszcilloszkópom megmérni az eredményt.

Teljesen jól használható az a dugdosóson. Azért lehetőleg közvetlenül a PIC mellé kéne berakni.

Hali!
Van egy C18-ban írt program, mely több féle fájlból tevődik össze ((CDC cikk), (program forrás). A "system\interrupt" mappában lévő fájlokat behúztam a projektbe, mert megszakítást akarok használni. De ha deklarálok egy változót, és pl. a "main"-ben használom, akkor a fordító úgy látja, mintha nem lenne deklarálva a "main"-ben a változó. Pedig a Watch ablak szerint ott van a változó. Hogy kéne helyesen deklarálni a változót?
Ha a "main"-ben deklarálom a változót, akkor meg az interruptban nem látja a fordító.
Túl van nekem bonyolítva ez a C... nem hiába maradtam az asm-nél.

Még egy kérdés. Ezt az interrupt.c fájlt nem kell include-olni?
Elfelejtettem írni, MPLAB C18-ban van a projekt.

Nem a deklarációval, hanem a hivatkozással van baj. Ha az interrupt.c állományban változókat deklarálsz, akkor egy interrupt.h fejléc állományt is hozz létre, amelyben pedig extern előtaggal szerepelnek ugyanezen deklarációk, s ezt be kell csatolni a main.c-be, ha hivatkozni akarsz a változókra.

Példa: részlet az akarmi.c állományból


Részlet az akarmi.h fejléc állományból


Ha main.c-be becsatolod az akarmi.h fejléc állományt, akkor eléred a változókat.

Nagy tévedés! A bonyodalom nem a C miatt van, hanem amiatt, hogy az összelinkelhetőség érdekében kapcsolatot kell teremteni a különálló fordítási egységek között (változó és függvénydeklarációk vonatkozásában). Assembly esetén is hasonló a helyzet...

Rendes helyeken a .c állományokat nem csatolják be, hanem felveszik a projektbe. Becsatolni a .h fejléc állományokat kell.

Először is köszönöm a választ!
Este azon gondolkoztam, hogy mi az az előtag, amit a változó elé kell írni (extern), de nem jutott eszembe. Viszont megcsináltam ahogy írtad, de így se jó, ezt írja:

A "rotary_direction" a változó.
A main.c-ben csak az interrupt.h van includeolva. Egyébként jónak tűnik a program, mert belép a megszakításba amikor kell.. csak ha deklarálom a változókat, akkor nem fordul le ezzel a hibával.

Igazából nem kellene annyira szigorúra venni a figurát, hogy "rendes hely"-et minősítünk. Az oldschool main.c-n keresztül beincludeolni mindent project építési elv immáron vagy fél évszázados múltra tekinthet vissza, és még mind a mai napig jelen van. Mplab projectet építeni rövid távon könnyebben járható út. Viszont hogy rendesebb is lenne, arra maximum a hobby időmet tenném fel, de a pénzemet már nem, a fejemet meg pláne nem.

Közben úgy néz ki sikerült jól deklarálni, legalábbis nem kiabál a fordító.
Van még egy user.c és user.h fájl, ha azokban deklaráltam úgy, ahogy leírtad, akkor nem ír ki hibát. Ja és a megszakítást a main.c-ben intézem.

Milyen jó lenne látni ezeket a részleteket...

Lehet kissé kusza lesz, de leírom:
Szóval ez van a "user.c" fájlban:


Ez a "user.h" fájlban:
extern unsigned char rotary_event;
extern unsigned char rotary_direction;

Ez a "main.c" fájlban:
.
.
.

.
.
.

.
.
.

Tudom, hogy van ilyen gyakorlat, de az is közismert, hogy miért komolytalan ez a megközelítés.
1. A forráskód fordítási egységekbe szervezése teszi lehetővé, hogy ne kelljen a Make/Build kiadásakor mindig mindent újrafordítani. (a relokálható tárgykód révén)
2. A forráskód fordítási egységekbe történő szervezése teszi lehetővé az előrefordított programkönyvtárak használatát (statikus vagy dinamikus becsatolással).
3. A forráskód fordítási egységekbe szervezése teszi lehetővé azt, hogy az alkalmazás egyes részeit más-más programnyelven írjuk.

Mindez nem C és főleg nem MPLAB sajátosság, hiszen assembly szinten, vagy más programnyelveknél is hasonló megközelítést használnak. Ezért van külön linker program.

Ha mindent egy main.c forrásba csatolunk be, akkor az egésznek keresztbe teszünk.

Először nekem is furcsa volt az extern használata, ma már nagyon tetszik és öröm használni, főleg ha utólag kell globálissá tenni, vagy visszavonni lokálissá egy változót és nem kell a main-ban kotorászni-e miatt. Meg kell szokni a jót is.

Meg, bizony! Engem eleinte a sok, látszólag fölösleges fejléc állomány zavart. Ma már kicsit másképp látom a világot.