Azt hiszem meg van a hiba nem 16F877 van benne mint a rajzon, hanem 16F1937 én ahhoz állítottam be mindent /igaz ezt nem írtam/.
Ennél viszont nem engedi a pickit2-őt használni.
Most hogyan tovább?

A 16F1937 -et vlóban nem támodatja az MpLab és a PICkit2 V2.61...
Pk2DeviceFile_1.62.14_mod6 letöltése, kibontása és a telepítési mappába másolása Pk2Devicefile.dat néven.
És a PICkit2 V2.61 máris tudja kezelni.

Taníts MESTER!

Azt észreveszed, hogy milyen ellentmondásokat írsz???

Idézet:
„a szorzásoknál osztásoknál feladtam”

Tehát nem tudtad leprogramozni.

Idézet:
„a tudást amit az assembly ad, azt kb. 10 perc alatt el lehet magyarázni a hallgatónak.”

Akkor most megy 10 perc alatt vagy sem??? Az ilyen feladatokat már a 90-es években, 16Cxx-en megoldották, persze assemblyben.

Így tudja programozni, de hogyan lehet fordítani rá ha az Mplab nem kezeli?

Fordítani tud rá már az MpLab 8.90 is, PICkit3 -mal tudja programozni és debuggolni is.
Ha lefordítod, akkor keletkezik egy hex állomány, amit a PICkit2 V2.61 -el be lehet programozni a pic -be.

Ha valakinek még a C -t (BASIC, Pascal, JAL, stb.) nyelvet is tanulnia kell, a magasabb szintű nyelven az indulás hosszabb lehet. Az XC free módban minősíthetetlen kódot generál, a full verzió 290000 Ft + Áfa.
Ha a feladatban szorozni / osztani kell, az nem tekinthető kezdő feladatnak. Itt nem az egész számmal való szorzással és kettő hatványával való osztásra gondolok. Kezdő feladatokhoz (led villogtatás, dobókocka, stb) egy nagyon rövidke (5-50 sor) assembly programot kell csak összeütni.
Haladóknak többször feltettem már ezt a gyűjteményt (csak egy jól megfogalmazott kereső kulcs kellett hozzá)...
Ezekből a rutinokból csináltam 48 bites egész osztást és szorzást assemblyben. De a 80, 88, 96, stb. bites sem jelentene akadályt... Vajon hogy nézne ki C -ben?
Hány, de hány assembly proigramban olvasható a tízes számrendszerbe váltás 10 hatványaival történő osztással (sorozatos levonásokkal elvégezve), pedig itt egy kis léptetéses megoldás is van...

Hp41C kolléga megadta a megoldást. Viszont, így a forrásba amit adtam, át kell írni az elején a PIC neveit.

Szeretnék most egy kis ötletet kérni a C (főleg az CX8 és C18) pártiaktól:
Az EEProm egy területén szeretném megoldani a parancskód -> belső funkció kód árkódolást.
Assembly -ben megy, mint a karikacsapás:

A TINDEX,... POWDNCOIL értékek egy .h állományban definiált konstansok.
Hogyan oldható meg az említett két fordítóprogrammal?

Szinte az egész programot át kell dolgozni a Midrange - Anhanced Midrange közötti különbségek miatt. Banváltás, más bank-ban levő regiszterek, eltérő regiszter és bit nevek miatt.

Uff, na ezt nem néztem...

Látom kiszűrted a lényeget.
Beszéljétek rá nyugodtan továbbra is a kezdőket az assembly-re, 1-2 hónap múlva úgyis visszatérnek segítséget kérni a C-nyelvhez. LED villogtató szerű programokat gépi nyelven programozni 2015-ben...
És igen, 10-20 perc alatt el lehet magyarázni a mikrovezérlő utasítás készletét, meg azt hogyan épül fel a program. Ennyi bőven elég. De még ezekre sincs szükséged ha úgyis C-ben folytatod tovább. De azt nem mondtam, hogy egy olyan kezdőnek is el lehet aki az MCU felépítését sem tudja. De az sem éppen bonyolult, csak ti akarjátok túlbonyolítani nehogy más is belemerjen kezdeni a programozásba. Egy alap MCU ismeret bőven elég a kezdő lépésekhez. Sokáig én se mertem belekezdeni, mert hogy tudni kell a gépi nyelvet is hozzá meg mindent, aztán a mai napig nem használom az assembly-ben tanultakat. Lásd arduino: általános iskolások jobb programot írnák már mint itt egyesek úgy, hogy fogalmuk sincs az MCU belső felépítéséről, pláne meg az assembly-ről (nem, nem arduino-zok!). Nem azt mondom, hogy követendő példa, de akit komolyabban érdekel a dolog, az önszorgalomból úgyis megtanulja majd a többit is, de legalább sikerélménnyel kezd! De pont az egésztől a kedvet elvevő assembly-vel kezdeni a mai világban, egyszerűen butaság. És ma már azt se lehet mondani, hogy kevés a RAM azért kell az assembly. Én is csak akkor fogok visszatérni rá, ha nagyon gyors folyamathoz kell majd algoritmust írni (még eddig nem volt szükség rá).

Pali79: Szerintem nem írtam semmilyen ellentmondást. Ha nem értetted volna, én csak azt írtam, hogy bőven elég egy elméleti alap is assembly-ből. Ha tudni akarod, a 8 bites szorzás még ment, de mikor már lebegőpontos számokkal kellet volna számolni, akkor inkább hagytam a fenébe és C-ben leprogramoztam egy sorba az egészet. Ráadásul nincs annyi segítség assembly-hez mint C-hez, így kezdők részéről csak mazochistáknak ajánlott. Haladni kell a korral!

Idézet:
„"de hogyan lehet fordítani rá ha az Mplab nem kezeli?"”

Mondjuk MBLAB X?
Az igazamat ez is bizonyítja, hogy jany-nak második napja nem tudtok segítséget nyújtani, mert ragaszkodtok még az MPLAB régi verziójához is ami még az adott PIC-et sem támogatja. MPLAB X-szel és PicKit3-mal kevesebb gondja lenne (az utóbbit is értelmetlenül szidják). Nem hiába fejlesztik ezeket. Előbb utóbb úgyis mindenki váltani fog, addig meg szenvedjetek.

HP41C: Szerintem nem hosszabb, sőt! Mi anno az első pár órán lekavartuk gyakorlaton a C alapokat, a többi óra már mind csak a beépített függvényekről, tömbökről, mutatókról szólt, aminek nagy részét (függvényeket) szintén nem használom PIC programozáshoz, mert magam szeretem megírni azokat. Lásd a sprintf-fel sem voltam tisztában múlt héten, mert eddig saját függvénnyel oldottam meg az ilyeneket.
while, for, if, switch. Ezekből épülnek fel a programjaim ha a változókat, függvényeket, alapműveleteket nem említem. Csak néha van szükségem struktúra és srand-ra. Assembly-ben pl. fogalmam sincs hogy lehetne most tömböt létrehozni, pedig elég gyakori résztvevő egy programban.
Nem vagyok egy pro programozó, de assembly-vel a felénél sem tartanék mint ahol most vagyok.

És most azok értékeljenek negatívan akik C-ből áttértek assembly-re, DOS alatt programoznak és jelenleg is a Windows 10 100MB alatti RAM-ot igénylő verzióján dolgoznak.
Részemről ennyi. Bocs a hossza miatt.

Nos "MESTER"!
Akkor informálnálak.
Egy gépgyártó cégnél dolgozom, és többnyire PLC vezérléseket tervezek, szerelek és programozok. Azért kezdtem el a PIC-el foglalkozni, mert:
1. Némely géphez feleslegesen nagy tudással rendelkezik egy PLC.
2. Ahol nem kell ez a tudás, ott egy egyedi gyártású elektronikával gépenként 50-150 ezer forintot lehet megspórolni.
3. Néha nem elég gyors a PLC reagálása.
Ezzel vissza is tértünk, a "miért assembly" témakörhöz. Ugyanis, ha a PLC nem reagál elég gyorsan, akkor egy 8 bites PIC C-ben leprogramozva pláne lassú!
De akár a jelenlegi projektemen is elgondolkozhatsz, C-ben hogy csinálnád!
A vezérlés 5 gombot, 2 végállást, 1 potmétert, egy analóg pedált és egy encodert fogad.
Amit vezérel: 2 db frekvenciaváltó, amiből az egyik analóg jellel vezérelt. Valamint meghajt egy 128x64-es GLCD kijelzőt. A gép feladata: A gombok és a pedál álltal vezérelve egy komplett munkadarabot elkészítenek. Ezt a folyamatot a gép lememorizálja, eltárolja (többet is), majd automatán elvégzi a gyártást.
Részedről most jöhet az, hogy C-ben ezt sokkal hamarabb leprogramozod. Ami igaz, csakogy! A kijelző meghajtása még assemblyben is lassú folyamat, ezért az egész program annyjáig időkritikus.

Idézet:
„Mi anno az első pár órán lekavartuk gyakorlaton a C alapokat”

Most magadnak mondasz ellent.

1. bsf STATUS, RP0
2. clrf TRISB
3. bcf STATUS, RP0
4. clrw
5. ciklus:
6. movwf PORTB
7. addlw 1
8. goto ciklus

8 sor, soronként 1 perc = 8 perc alatt villog 8 led (1 led / perc )

Idézet:
„általános iskolások jobb programot írnák már mint itt egyesek”

Nézz át a C -s topikba, amikor jönnek a kérdések:
pl. (int) x = x * 5000/4096; és az (int) x= adcresult * (5000/4096); valamint az (int) x= (adcresult * 5000)/4096; problémáiról. Ugye csak sima C?

Idézet:
„MPLAB X-szel és PicKit3-mal kevesebb gondja lenne”

Miért tart abban a rendszerben egy fordítás sok sok percig? Miért olyan lassú a programozás és a nyomkövetés? Ja, lassú a gépem.... De miért megy mégis elfogadható sebességgel az MpLab 8? Honnan lehetne letölteni egy olyan fordítót, ami nem tölti maga alá a java -t. Most kb. 10 .. 12 Java verziónak kellene fent lennie a gépemen. Mire jó ez? Csak nehogy összeakadjanak, ahogy azt megtette az AVR Studió a VS2008 -cal...
Ahogy a matematikában, itt sincs királyi út.

Egy 8 Mbyte -os EEProm tartalmát szerettem volna megjeleníteni a C# -ban készült PICkit2 kezelő programmal (datagrid), de sajnos mind a 2GB memóriámat elhasználta...

Idézet:
„Az igazamat ez is bizonyítja, hogy jany-nak második napja nem tudtok segítséget nyújtani, mert ragaszkodtok még az MPLAB régi verziójához is ami még az adott PIC-et sem támogatja.”

Ez baromira nem bizonyít semmit! Ha nem láttad volna, most közölte, hogy nem is a PIC van a panelba, mint a kapcsolási rajzon. Ráadásul, nem az Mplab nem kezeli, hanem a PK2.
A C-nek is azért van sikere, ugyanúgy mint az Arduniónak, mert a programot már valaki megcsinálta, csak össze kell ollózni és örülni, mint majom a farkának, hogy mekkora ász vagyok, pedig fogalmam sincs róla, hogy tulajdonképpen mi is történik. "Értem én, hogy villanymotor, de mihajcsa???"

Amíg a feladat megoldására van elég memória, órajel, addig nincs gond, legfeljebb drágább lesz az a fejlesztés.
Én pár hónapja még elővettem egy régi számítógépemet. MS-DOS, 120MB merevlemez, 8MB RAM, 60MHz alatti processzorral. Pascal nyelven programoztam valamit, amit módosítani kellett. Ezzel szabad negatívan értékelni a hozzászólásodat?
Az a baj, hogy azt sem tudod, mi az amit nem tudsz.

Szia!

Azért ha egy kicsit okosabban programozol akor nem kell kivárni 46us időket, az egész LCD írás karakternként akár 1us lehet.

Mitől lenne drágább? Egy Cortex M0 is olcsóbb már mint egy 8 bites.

Idézet:
„A C-nek is azért van sikere, ugyanúgy mint az Arduniónak, mert a programot már valaki megcsinálta, csak össze kell ollózni és örülni, mint majom a farkának, hogy mekkora ász vagyok, pedig fogalmam sincs róla, hogy tulajdonképpen mi is történik.”

Palikám ebben a formában ez így elég nagy ökörség.

No! Fejtsd ki! Én szívesen tanulok.

Miért??? Kinek van arról fogalma, hogy mi történik mondjuk egy Microelectronika C függvénykönyvtári 1-Wire, UART kezelő függvényben? Mit okoz, ha engedélyezem a megszakítást? Avagy elrontja-e a kritikus időzítésemet, mert letiltja a megszakítást? Okoz-e RMW problámát, ha más kimenettel egy portra használom? Folyhat-e a UART vétel, ha meghívtam az UART adási rutint? Lesz-e rafutás hibám? stb, stb. Ezeregy kérdés.
Sajnos a könyvtári függvények forrása nem nyilvános.
Persze megírhatom a saját C könyvtári függvényimet, de azokhoz annyi információra van szükségem, mint assembly -ben.

Nem figyeltél!
GLCD kijelző!

Ez fél képernyőn egy sor kiírása. Azaz 64 byte.
Ebből van 16, plussz a járulékos részek.
Ez több mint 16000 utasítássor 4MHz mellett.
Legjobb esetben is 0,016sec.
Szerintem ez nem túl gyors, magasabb frekin meg már leáll a kijelző.
Mivel ez mellett még encodert kell figyelni, analóg jelet digitalizálni, és linealizációt számolni,
így muszály 16MHz-n pörgetnem a procit, viszont a kijelzőt ugyanezen a sebességen kell tartani. Tehát csak az egyébb feladatok lesznek gyorsabbak. Ezért írtam, hogy csúnyán időkritikus.

Apám, mint a gyerekek. Eléritek, hogy ezt i letiltják mint a multkor a kapcsitápos topikot. Hogy mindkét oldalnak igaza legyen, C könyebb mint az ASM, nem is azért szoktuk ajánlani az ASM-t hanem mert jobban megérthető belőle a PIC működése. Általában én is C párti vagyok, az időm fontos,de...
Mint János irta időkritikus programot csak ASM-ben lehet irni.
Másik, hogy némely c forditó olyan szemetet forrdit, hogy néha nálam is elgurul a gyogyszer és megirom inkább ASM-ben. Vita lezárva.

A kontroller ára egy tényező. Térfogat, energiaigény és még kismillió más tényező jöhet szóba.

Eme szerkezet egy 20MHz -es 16F886 -tal az alábbi feladatokat végzi el:
- A rezgő kar kezdő pozíciójának figyelése, az adatok igencsak kötött időzítéssel történő kiírása a LED vezérlő portra,
- Idő számítása. Így önmagában nem egy neház feladat. Azonban a dátumot is számolja, továbbá a ISO hét sorszámot, a hét napját a dátumból (JDN), a Húsvét napját az évszámból. Ezek már igencsak számításigényes feladatok.
- Az idő kijelzése számtalan formában. A kiválasztott kijelzési módnak megfelelő rajzolat számítása. pl. 9 alapú számrendszerre való átszámítás...
- RS232 kapcsolat a PC -vel folyamatos adatforgalommal 19200 Bauddal,
- Infravörös távirányító dekódolása (Philips RC5).
- DCF77 dekódolás.
És még mindig malmozik a kontroller.... Assembly -ben elkövetett csaknem 8 kszó program...
XC8 -cal free módban fordítva 32..64 Kszó is kevés lenne....

Komoly!
Igencsak tetszett a cikk.

Pontosan! De nem mindegy, hogy minden aprósággal regényt írsz, vagy az azzal amit muszáj.

Így talán jobb.

Mi a jobb?