Úgy olvastam, hogy a csak a részletesen felsorolt típusokat kezeli. Nem használtam soha, sőt még az Arduino -t sem használtam.
A mellékletben a PICkit2 által kezelt típusokat felsoroló állomány. A lista bővíthető, a firmware és a kezelő program forrása letülthető, az MpLab 8 alatt beépített programozónak, nyomkövetőnek használható.

Na ezt te sem gondoltad komolyan!
Egy jól elkészített, formailag is áttekinthető, magas-szintű programnyelvvel én is szívesen dolgozok, még ha hardverpazarló, akkor is.
A C nyelv rettenetes katyvaszát legfeljebb az OMRON PLC-k fejlesztőszoftvere múlja fölül!
Én Commodore BASIC-al kezdtem, Később PLC-vel, majd megismerkedtem a PIC-ek világával assemblyben. Mikor úgy gondoltam, elég tűrhetően tudom már használni, megpróbálkoztam a C-vel.
A korábbi rendezett, átlátható nyelvek után nekem a C maga volt a káosz. Fel is adtam. Folytattam inkább az assemblyt.
Hp41C azt írta:"Mottó: Nem kell assembly ismeret a boldoguláshoz magas szintű nyelveken."
Én inkább azt mondom: Nem kell C annak, aki érti az assemblyt!

Nézz körül a mikrokontroller világban, 2017-et írunk Minden gyártó ingyen ad jó C fordítókat + periféria könyvtárakat. Az assembler tudás nem hátrány, sőt ,ez igaz, de egy összetett feladatnál már nagyon penge assembler programozónak kell lenned -vagy rengeteg idődnek-hogy megfogj egy mai, korszerű C fordítót.

A harverközeli, mikrokontrolleres programozás megköveteli a regiszterszintű ismereteket. Az, hogy néhány képletet egyszerűbben lehet megírni, nem sokat számít.
Az itt előforduló kérdések nagy része kifejezetten regiszterszintű problémákról szól. Ezekben az esetekben az assembly egyszerűbb, érthetőbb.

Ki kell ábrándítsalak!

Kivéve a Microchip. Az ingyenes XC8 csapnivaló, kapásból szinte mindenki jobb programot ír assemblyben. Egy assemblyben 16F628 -re megírt 2kszó hosszú programot átírva ingyenes c-re nem fér el egy 8kszó memóriával rendelkező típusba se (akkor még nem volt 16kszóval rendelkező típus...)
Az optimalizáló fordítóért meg fizetni kell típuscsaládonként (XC8, XC16, XC32 külön - külön).
A függvénykönyvtárról csak a C18 (18F-ekhez) és a Harmony -ról beszélhetünk, de minek. Olvass fórumokat.
Egyébként sem értem, hogy egy szűkös program memóriával, program stack -el rendelkező típuson minek eljárást hívni (paraméterrel), ha a beállítás egy-két utasításból megoldható.

Én még basic, majd pascal-al kezdtem anno, de ezen kívül még bele kóstoltam egyéb kódolásba is. Alapvetően azt tapasztaltam, hogy a C a legbarátibb közeg egy kezdőnek.
Assembler túl bonyolult és ha nem megfelelő a kommentelése, akkor órákat vagy napokat tölthet a visszafejtésével. Sokszor még, akkor is ha jó van kommentelve.

Nincs ellenemre egyik kódolási forma sem, de egy kezdőnek szerintem a C lesz a nyerő..
Ez előtt 10 évvel én is mást mondtam volna, de mostanra a C lett szerintem az első számú kódolási forma, amit illő mindenkinek megismernie..
A legalapabb meg az assembler, de ez nem feltétlen szükséges.. (persze van olyan projekt amihez csak ebben írtam a programot és nekem is csak segítségek ment, főként az utasítás készlet folytonos változása miatt)
Ez az én véleményem..

Ld. unsafe C kód. A könyvtári sscanf() hajlandó minden figyelmeztetés nélkül túlírni az átadott tömböt.

Tökéletesen komolyan mondtam.
Egy kezdőről van szó akinél feltételezzük, hogy nem vagy csak felületesen ismer valamilyen program nyelvet.

Nyilván így is van és ezzel nem is szállnék szembe soha.., de itt igazából egy kezdőről van szó, akit nem elijeszteni akarunk, hanem megmutatni neki a programozás szépségét.
Ezt assemblerrel elég nehéz, de egy szép C kódot bárki képes könnyedén megírni aki persze akarja is.
Persze hozzátartozik, hogy az adott eszköz vagy projekt mit követel meg, mert például az utolsó SEGA flash kártya projektemnél nekem is assembler-t kellett használnom az M68K proci programjának megírásához. Ott ez szinte lekerülhetetlen volt. Nem is volt zökkenőmentes.

Idézet:
„Olvass fórumokat.”

Olvasok és köztudott, hogy a PIC C18-ig architektúrája miatt nem fekszik a C fordítóknak, de erről nem a C nyelv tehet. Ráadásul fizetős, ha elfogadható eredményt akar valaki.

Melyik topikban vagyunk? Egy kezdő nem a 24F, 32MZ -vel fog bibelődni.

Jogos! Mea culpa!

Manapság? Hát volt már rá pár példa... Volt is gond nem kicsi

Egy kezdő leginkább előregyártott boardokkal fog bíbelődni, és olyan példákkal, amiket ahhoz írtak meg. A legegyszerűbben hozzáférhető board pontosan az, ami benne van a pickit expressz csomagban, és programozóra is biztosan szüksége lesz (adtam a linkjét is fentebb). Abban a csomagban C nyelvű példákkal fog találkozni, C-ben kap azonnal szájbarágós környezeti példákat a pic-ekkel ismerkedni. Jó, én is tudom, hogy pár dolog fizetős XC terepen, de a régi C fordítók (az expressz csomagban is a régi C fordító van benne) és MLA-k ugyan úgy hozzáférhetőek, és a supportolt pic-ek sem vesztek még ki a piacról, azokhoz pedig az ingyenes fordítók is remekül teljesítenek (egyedül az optimalizáció van kitiltva, de anélkül még bőven életben lehet maradni). A kutya sem kényszerít senkit sem a Harmony-ra, sem az XC fordítókra, sem a 32mx-nél fejlettebb családokra.

De egyszerűsítsük le a kérdést. Javasolnod kell programnyelvet egy kezdőnek kezdeti support példákkal együtt, és ha olyat javasolsz, amivel élből csak a problémái lesznek kezdeti sikerélmény helyett, bevállalod, hogy se**bemicsodáljanak - védekezés nélkül Szóval mit javasolsz?

No, hogy témánál maradjunk nincs valakinek egy jó kis példa kódja C18-ra, AM2321-es pára és hőszenzorhoz?
Most vettem 2db-ot és gondoltam ki próbálnám.
Ha lesz egy kis időm készítek egy vezeték nélküli kis időjárás állomást.

Szerintem nem így kezdi a kezdő, én sem így kezdtem, de itt van kedvenc Zsomborunk példája is és sok más is. Megtetszik egy projekt és azt próbálja megcsinálni. Én is így voltam. Megláttam itt az Emule nixie órát, az volt az első PIC-es projektem. Persze ez csak egy sima utánépítés volt, de ez indított el az úton. A régi 16F, 18F típusok adatlapjai tele vannak minta rutinokkal, program részletekkel és az adott típusnál használható utasítások listájával, magyarázatokkal. Kétforintos kérdés: na vajon melyik nyelven?

Ez mondjuk tök igaz, de még is, ha valaki nem +20 akkor valszeg csak C-vel vagy valami hasonszőrű program nyelvel találkozott.
Az assembler szerintem túl bonyolult nyelv, persze meg lehet tanulni, de valószínűleg, ha azzal kezdtem volna, hamar kirostálódom ezen körből.
Könnyebb a logikáját megtanulni mint az assembler-ét.
Mikor az M64K-ra kellett írnom a progit még segítséggel is csak nehezen ment a fejlesztés.
Persze számít attól is, hogy ki melyiket érzi sajátjának, kinek mi a könnyebb.

Pl. nekem az irodalom csak nehezen vagy nem is megy, de a matek meg jól megy.
Valakinél meg pont az ellenkezője megy. egyén kérdése szerintem... Ettől független még mindig a C-t tartom könnyebnek és jobb választásnak, pedig tudom, hogy assemblerben optimalizáltabban lehet programozni.. Szubjektív ez nagyon és folyton belelépünk ebbe a csapdába.. Mindig döntetlen a vége

Egyre több fórumon olvasom, hogy ezt a lépést a Microchip (***...***) lekéste. Nagyon későn fordult a Hitech C felé, a C18 -at összegyúrta vele - nem lett igazán kezdőknek való. Közben más cégek pontosan ezt a rést célozták meg. Gondolok itt az Arduino, ST Nucleo, TI, NXP, stb fejlesztőkre. Azokon a kontrollereken (mások vélemény szerint) sokkal jobb a C fordító (kihasználhatja a valódi stack -ot). Az 32MZxxEC széria rekordot döntött az Errata hosszában, súlyosságában és tartósságában. A mostanság kiadott 32MM, 32MK sem áll jól az oszcillátorral...

Kicsi PIC -hez az assembly-t ajánlom. A feladat (led villogtatás) nagysága (512 .. 2k szó) nem nagyon kívánja a magasabb szintű nyelvet. Ha mégis kell egy szorzás/osztás azt a piclist oldalon megtalálja. Az is könnyen megvalósítható, ha egy feladat olyan adattípust igényel (40 vagy 80 bites egész szám), amit a magas szintű nyelv nem ismer. Frekvenciából periódusidő számítása lebegőpontos művelet nélkül. Érdemes átnézni a réges-régi 16C84 / 16F84 -es projekteket. Mit meg nem csináltak akkor, amikor még nem volt magas szintű nyelv és csak TMR0 és 1024 program szó volt a kontrollerben.
18F -ekhez a régi C18 -at, esetleg az MLA -jával.

Idézet:
„Az assembler szerintem túl bonyolult nyelv”

A 16F628A összesen 36 assembly utasítást ismer és egy egyszerűbb programban ennek a felét sem használja az ember, ez azért nem lehet annyira bonyolult. Egyébként itt olvastam valamikor az egyik kedvenc C-s történetemet: valaki PWM-mel foglalkozott és egy másvalaki mondta neki, hogy C-ben csak egy paramétert lehet állítani a hardveres modulnál, pedig van egy pár regiszter ami befolyásolja a jel milyenségét.

Idézet:
„Szubjektív ez nagyon és folyton belelépünk ebbe a csapdába.. Mindig döntetlen a vége”

Nem akarom mondani, hogy ezt most pont Te kezdted! Én csak annyit kérdeztem miért pont a C? Te keverted bele az assembly-t!

Ezt azért remélem nem gondoltad komolyan (mármint a hozzászólás végét). A C-vel sokkal többet szívhat az ember. Rengeteg include/header fájl, amik véletlenül sem kompatibilisek, pl. ha verziót váltasz. Egyszer ha kiír egy hibát, egy kezdő tuti nem fogja tudni mi van, mert káosz az egész. Assemblynél jó esetben van 1db include fájl, azt' csókolom. Ha ott hiba van, sokkal egyszerűbb kinyomozni az okát.
De egyébként én elismerem, hogy asm vs. C döntetlen. Van amiben az asm, van amiben a C jobb.
Azt, hogy kezdésként mit használ az ember, valószínűleg az is örök vitatéma, ugyanúgy mindkettőnek meg van az előnye/hátránya.
Bár én azért az asm-re szavazok.

Hát mert tudom, hogy te assembleres vagy..
Amúgy tényleg én hoztam fel, de azt hittem ez egy tánc amire felkértél a kérdéseddel Benéztem, van ilyen ...

A hozzászólásom végét illetően a jelek szerint senki sem volt vevő a fekete humorra. Oké, felejtsük el. Bár hozzáfűzném, hogy a fentebbi hitvitát illetően nem én voltam az, aki elkezdte belekeverni a szezonba a "valami mást" is. És persze, hogy még a célzást se értették. Jellemző.

Aki éppen kezdő, bőven elég baja van azzal, hogy a pic egy mumus, és ezernyi rigolyája van, amire mind figyelni kell. Meg még az adatlap szerkezete is elég káosz kezdetben. Fogalmam sincs, hogyan gondolhatja bárki komolyan, hogy amíg kezdeti problémákra koncentrál valaki, éppen akkor még a programnyelv hitvitáira is kíváncsi lesz. Egy púp lesz a hátára, amit pokolba fog kívánni. Egyben akar majd kész példákat akármilyen nyelven, amiket apró lépésekben átalakíthat, és tojni fog magára a programnyelvre. Egyben halom sok kész support nincsen asm-hez, C-hez van. De cáfoljatok meg nyugodtan.

Ami meg az asm kontra C hitvitát illeti, van arra az irigységtípusra valami célirányos szó, "p"-vel kezdődik, nem ugrik be véletlenül valakinek?

perverz állat

Nem cáfolatként, de itt van egy példa. Ebből gyakorlatilag összehozható. Ráadásul itt még szépen el is van magyarázva. És a Bin-BCD koverzió

Nem azt írtam, hogy egyetlen egy példa sem létezik asm-ben, mert ott vannak például @Watt és @pocok régi cikkei is. Viszont ami asm-ben van írva, az minden apró funkció végett 15 oldal hosszú csak azért, mert annyira aprólékosan kell bánni az adattal folyton átpakolni az egyetlen akkumulátoron mindent, hogy szórakozhass a flagekkel, amikre ugró utasítást tehetsz - és társaik. Ki a fene akar azzal foglalkozni, amikor kezdőként előbb még a fejlesztői környezet kezelését, és nagy léptékben a pic-ek alapvető lehetőségeit tanulná meg? _Neki_ miért érné meg 120 oldalas asm kóddal foglalkozni egy féloldalas C program helyett?

Itt volt az ellenpélda nem is olyan régen. A "Mikro C és a 10F322 esete a PWM könyvtár" -ra gondolok. Ezt a hibát egy kezdő nem találja meg... Vagy amit a másik topikban írnak...


A C vagy más nyelvhez meg ott a több száz oldalas nyelv leírás (olyan kezdő, aki nem ismeri az a nyelvet) és ekkor még egy eljárást sem hívott meg. Hány oldal is a függvénykönyvtár leírása? Tudod-e mit végez el? Tudod-e, hogy mit tehetsz meg és mint nem? Itt a RMW hibákra gondolok. Pl.: szoftver I2C egy porton, a többi bitet a megszakítás is kezelné. Szóval ez is kitesz annyi elsőre elolvasva megérteni valót, mint amit a másiknál felsoroltál.
Adattípusok: Miért van az, hogy nem az az eredmény, amit vártam? Egy kezdőnek sok sok fejtörést okoz.

Finomítsunk egy kicsit a megközelítésen:
Kezdő társunk az alábbi típusokba sorolható projektekkel találkozhat:
- Ez a projekt tetszik és változatlanul megépítem:
Általában csak a hex tölthető le, a forrás nem, illetve a letöltött forrás hibás vagy nem a hex -beli programot fordíthatjuk belőle. Nem kérdés a fordító, bármi is lehetett.
- Ez a projekt tetszik és módosítva építem meg:
Ha a letöltött forrás hibátlan és az elvárásoknak megfelelően működik, nagy szerencse. A módosításhoz természetesen az eredeti fordítót kellene használni. Csakhogy a magas szintű nyelvek fordítóiért fizetni kell, így nem lehet ajánlani. Persze sok lehetőséget ad a net, de azokat nem nevezném ajánlhatónak. Megvásárlás még korainak tartom, lehet, hogy nem is fog tetszeni a Microchip PIC és átnyergel más típusra. Tegyük fel, a módosítás elvégezhető az ingyenes verzióval. Egyértelmű, hogy azt kell használni.
- Most már eleget építettem mások projektjeit, saját fejlesztést szeretnék:
Lépésről lépésre kell elindulni: LED villogtatás, nyomógomb kezelés, számláló, A/D kezelés, stb.
Ennél áttekinthetőbb programot nehéz írni 16F628 -ra (6 sor az egész, mint az őskőkori történelemkönyv):

Mit kellett ehhez elolvasni? Csak az adatlapot... Hiszen az a C, BASIC, Pascal, stb esetében is el kellett (volna) olvasni. Az utasítások leírása is benne van mindegyikben (kivéve a PIC32). Milyen header -t is kell "includálni"? A kontroller nevével megegyezőt. De ha leírom

akkor fordul header nélkül is. Ja, hogy egy kicsit gyos - Számtlan delay generáló program letölthető a PIC -hez.
Hány, de hány ilyen forrással találkoztam. Még a cblock direktíváig sem jutott el egyes források szerzője.
- Már írtam LED villogtatót, jöhet valami más:
Nos itt vetődik fel a fordító milyensége. Egyrészt a feladattól, másrészt a hozzáállástól függ.
Sokat kell számolni vagy inkább csak pakolgatni kell az adatokat.
- Kinéztem egy magas szintű nyelven írt forrással rendelkező projektet, módosítanám, de nem úgy működik, ahogy várom vagy így már nem fér bele a kontrollerbe vagy a fordító korlátjába:
Kelepce...
- 16F887 -en megírt programom csak 50% -ig használja ki a programtárat, de nem lehet a programot bővíteni.
A program két eljárást tartalmaz: a megszakításkezelőt és a főprogramot. Miért nem lehet további funkciókat beleírni? Egyes fordítók szerint semelyik eljárás nem lehet 2 kszó -nál hosszabb - igen az ugrások miatt. Fel kell darabolni, hogy más lapokra is át tudjon tenni kódot a fordító. Kinek jutna eszébe???

Szerintem pont ez a program, aminél nem jön ki a C nagyobb tudása. Itt csak a portokat kell billegtetni, beolvasni. C-ben gyakorlatilag ugyanazt a logikát kell megvalósítani: portokat írni- olvasni.

Aliexpress-ről vásároltam PIC-Kit 3 klónt. MPLAB-X alatt hibátlanul működik, megy a nyomkövetés is ( legalábbis az álltalam eddig használt típusoknál: 16F887, 18F4550, 24FJ256GB106).

Kedves Hp41C
Sikerült igy ahogy mutattad:

Nagyon köszönöm de miért volt ez hiba hogy set_duty-t használtam?? Mi volt a probléma valójában??

Sziasztok!
Köszönöm a rengeteg tanácsot mindenkinek.

Szia Hp41C!

Bármelyik megoldás szóba jöhet. Amit felvázoltam feladatot BCD kódra SN7447-el már megcsináltam. Gondoltam arra. hogy GAL-lal csinálom meg de azt hiszem, hogy az már idejétmúlt.

Szimpatikus nekem az általad felvázoltakból mindegyik. A kombinációs hálozat azért, mert elő folrdulhat, hogy a későbbiekben kell még logikai vezérlést csinálnom, amikor ez jól jöhetne.
A másik kettő, meg a tanulás miatt.

Köszönöm

Zoli