Sziasztok! Azért szeretném elindítani ezt a témát, mert a PIC kezdőknek fórumon gyakran ütköznek az assemly és egyébb programozással kapcsolatos nézetek. Jó lenne, ha az asm. problémák külön kerülnének. Legfőképpen azért, mert a vezérfonal az "Egyszerűen" kellene, hogy legyen. Sok fórumtárs tölt fel programrészleteket, melyekkel elakadt, és az esetek jelentős hányadában az elakadás oka, a túlkomplikált megoldásból adódó nehézkes áttekintés. Rendszerint egészen apró elírások ezek, melyek egy leegyszerűsített programban könnyen szemetszúrnak.
Hogy mire is gondolok egyszerűsítés alatt, arra álljon itt egy példa a fórumból ollózva:

Ugyanez leegyszerűsítve:

Szerintem nem kell új topic.

A programozás általában összetett, bonyolult folyamat.
Az áttekinthetőséget, az érthetőséget lehet javítani valamilyen programépítési alapelv követésével, vagy lehet optimalizálni futási időre, kódméretre, veremhasználatra és egyebekre. Hogy mikor melyik az egyszerű, az a konkrét esettől függ.
Szerintem ezek ilyen szinten jól megférnek egy helyen.

Ha nem is feltétlen az egyszerűség, de az assembly dolgokat tényleg jobb lenne különválasztani. Volt már korábban ebből elég vita a pic kezdőknek topicban.
Egyébiránt szerintem a kód egyszerűsítéséhez gyakorlat kell leginkább. Szerintem az első idézet eredeti szerzőjének sem az volt a célja, hogy jó hosszú legyen csak épp nem jutott eszébe a sokkal rövidebb megoldás. Lényeg a segítő szándék!

Mondjuk, ha már van C topic a PIC-eknek, akkor megérdemelné az ASM is. Csak a téma címe inkább legyen valami ilyesmi: "PIC programozás assemblyben". Az egyszerű szó itt szerintem hanyagolandó.

Pont erre gondoltam én is, csak lehet,nem jól fogalmaztam. A gyakorlottabb programozók sokat segíthetnek a kezdőknek. Nekem is jól jött volna néhány hónapja, mikor az első komolyabb programomat írtam karakteres LCD-re, ha egy tapasztaltabb programozó rávilágít, hogy van ennek egyszerűbb módja is. Azóta újraírtam a programot, és a 2000 soros progim 1150 sorra rövidült.
Ugyanis először még minden egyes karaktert egyesével vittem be, ma pedig már táblázattal dolgozom.

Én is helyesnek tartom a HW és SW szétválasztását. Főként azért, mert nagyon kevés olyan szakértő van, aki mindkettőhöz jól ért (itt a fórumon bizonyára több. De aki HW segítséget akar adni, annak végig kell nyálaznia és átugrania az unalmas SW kérdéseket, és viszont, azaz a SW szakértő meg a HW-t unja. A válaszok is keverednek, és a SW-hez oda nem illő HW eszmecserék helyet foglalnak a válaszkeresés folyamatában.

Egyébként magán a szoftveren belül is lennének elkülöníthető témakörök. A topiknyitóban említett - túlkomplikáltság okán szükséges - egyszerűsítés valójában a SW fejlesztés dilemájának egyik oldalát tükrözi. A dilema ténylegesen a következő:

1) A program legyen rövid (kevés programhelyet foglaljon)
2) A program legyen gyors (ha időkritikus a feladat)
3) Az algoritmus legyen áttekinthető
4) A program használjon minél kevesebb adatmemóriát

Ezek a feltételek gyakran egymásnak ellentmondanak. Egy ravaszul megírt tömör program sokszor áttekinhetetlenebb, mint egy hosszabb, és csak temérdek megjegyzés hozzácsatolásával érthető meg (így van ez a magunk által megírt trükkökkel, amelyet 1-2 hónap múltán már mi sem értünk!)

A gyorsaságot jelentős program es adatmemória felhasználásával lehet legtöbbször növelni. Ha az adatmemóriával takarékoskodunk, akkor az sokszor a programmemória rovására megy (pl bitcsoportokban tárolunk adattöredékeket). A programot meg esetenként úgy tudjuk tovább rövidíteni, hogy több adatot használunk.

Egy másik oldala az "egyszerűsítésnek" a SW dilemát félretéve, a processzor tudásának (utasításkészletének) alapos ismerete, illetve az abból kihozható ravasz trükkök elsajátítása. Kár, hogy nincs erre egy elkülönített, és egyre bővülő gyűjtemény. Ehelyett hagyatkozhatunk a hosszú évek alatt időnként agyunkba vágő ötletekre, illetve azok szájról-szájra megosztására a fórumokon.

Az algoritmus is fontos tényező. Akár egyszerűbb, akár bonyolultabb a feladat, ahhoz algoritmust kell kreálnunk. Gyakori, hogy több is van (bár csak egy jut az eszünkbe), és a fentiekben említett dilemák esetén nem mindegy melyiket választjuk (jó programozási példa erre a prímszámgenerálás számos módja).

Egy program az algoritmus és az adatszerkezet kettőssége. Ha nem vagyunk jártasak a feladathoz illő, hatékony adatszerkezet létrehozásában, akkor hiába jó az algoritmikus alkotókészségünk, nem mindig a leghatékonyabb a megoldásunk.

Utolsóként megjegyezném azt a témakört, ami tulajdonképpen megkérdőjelezhetné a HW és SW szétválasztását. Ez pedig a megtervezendő HW és a hozzá szükséges SW összehangolása. Ez csak ritkán történik meg, és csak az képes rá, aki mindkét oldalt jól ismeri. Az elmúlt évtizedekben nem egy esetben tapasztaltam a gyakorlatban azt, hogy egy jó HW-es a PIC I/O lehetőségeinek alapos ismerete mellet is, olyan áramkört tervezett, amely a szoftveresnek komoly többletfeladatot eredményezett. "Mentségére"(?) lehetett felhozni, hogy SW-es gyakorlata, szakértelme nagyon minimális volt. Néhány minimális áramköri plusszal (vagy máskor minusszal) egy sokkal hatékonyabb eredményt lehetett volna kihozni. Sajnos nem ritka, hogy egyes HW-esek a szaktudásuk bűvöletében mereven ellenállnak ezeknek az apró módosításnak (mert nem látják át a SW oldali könnyebbséget, és amit már megterveztek az csak úgy jó ahogy van(!?)). Még az sem ritka, hogy dilettánsként a SW-be igyekeznek beleszólni.

Valójában azonban ez az összehangolás HW téma. Mégpedig a HW tervezésének egy módja a SW oldal alapos ismeretével. Tehát nem a szoftveres topikba való.

Nagyon jók a meglátásaid. Élvezettel olvastam az írásodat. De egy kis helyesbítéssel élnék.
Nem a hardvert és a szoftvert akarom különválasztani, hanem az assemblyt minden mástól.
Egy jól megtervezett hardver, magában hordozza a szoftver leegyszerűsítésének lehetőségét is. Ám a PIC azért tud oly sok mindent, hogy ne kelljen bonyolult hardvert építeni. Némi kreativitással a hardver is leegyszerűsíthető. Néha már-már morbid mértékben. Erről szól az én robotos cikkem is.
Az én célom az, hogy egymást segítve, ki-ki a maga egyedi fejlesztését bedobva, szakítssunk a trendekkel. Mindenki előszeretettel hagyatkozik az "elődök" munkáira. (Úgy csináljuk, ahogy mások már megcsinálták, mert az már bizonyította, hogy működik.) Ezzel elnyomjuk saját kreativitásunkat.
Ezt neves gyártók is így csinálják.
Egy példa erre:
Nagyon sok külömböző márkájú elektromos kerékpár vezérlőt szedtem már szét.
Egy közös tulajdonsággal bírtak. Tele voltak pakolva alkatrészekkel, mint a déli busz utasokkal.
Azután a kezembe akadt egy névtelen kínai vezérlő. Az elkerülhetetlen alapalkatrészeken felűl (FET, ellenállás, kondi, stb.) mindössze 1db microcontrollert tartalmazott. Ezzel a minimális alkatrész mennyiséggel a következőt tudta:
Gázkaros üzem, pedelec üzem, fékkapcsoló érzékelés, elektromos fék, fékenergia visszatöltés, rükverc, tempomat, analógként kiadott valós sebességjel, lemerült akku figyelés.
Ezért fő törekvésem az egyszerűsítés. Minél egyszerűbb egy hardver, annál kevesebb a meghibásodási lehetősége. Ha ehhez még a szoftvert is sikerűl a legegyszerűbb formában elkészíteni, az a teljes boldogság.

Egyetertek. Nagyon sokszor lattam olyat, hogy valaki egyszeruen modulokbol osszehajigal egy, altalaban C nyelvu programot. Es nem erti a mukodeset, de ugy-ahogy eldocog.
Azt alairom, hogy a leginkabb ido- es koltseghatekony megoldas ez. Nem lenyeges, hogy ertsd, csak mukodjon.
Ezen a hobbi listan szerintem eppen az lenne a lenyeg, hogy kifinomult megoldasokkal eljunk, hiszen a raforditott ido lenyegeben nem szamit. Lehetoseg van arra is, hogy megertsunk egyeszen lenyegtelennek tuno reszleteket.
Szemely szerint a hardvert es a szoftvert egyutt szoktam fejleszteni, en hajlando vagyok pl. vonalrajzolo algoritmust is kesziteni, szorzast/osztast bitforgatassal, stb. termeszetesen a PIC programozom hardveret es szoftveret is en csinaltam (PC assemblyben, masm32-ben). Igy keves meglepetes er, ha valami olyat szeretnek csinalni, ami nem hetkoznapi es mindenki csak szent borzongassal emlegeti, hogy 'dehat azt nem lehet'. Es csodalkoznak, esetleg veletlennek tartjak, ha megis sikerul.

Hmm, pont arra gondoltam, hogy mikor jön már a bbalázs, mert ő is nagyon vágja, és szereti az assemblyt. Most a skandi-s Májkit nyaggatom, de majd ide is sokszor benézek, csak mostanában kevés az időm. Hamarosan elkészül a fejlesztőkártyám, ami egy riasztó lesz, és azon fogok tanulni. Örülök ennek a topiknak. Még a Tóth Ferencet kéne idecsalni valahonnan, mert gondolom hp41c, meg a többi asm-es, törzsvendég lesz itten.

Üdv mindenkinek!

Nekem is van némi gondom a meglévő asm forrás kódokkal semmit nem értek belőle.
Ehhez kellene egy ASM utasítás magyarázat nem csak olyanra gondolok ami a pic adatlapjában van hanem az összképet illetően mert csak akkor lehet tudni valamit arról mit is akart elkövetni a fejlesztője és hogyan módosíthatom a saját igényemnek megfelelően.

Szóval még mindig nem tudok mögé látni miként gondolkodik a PIC.

Szerintem a mögöttes dolgokat sokszor nem is lehet elmagyarázni annyit tudok róla mit kel neki csinálni , és azt ,hogy nekem hogyan kéne csinálnia.

A kettő közti híd az ami hiányzik.

A Flow code al próbálkoztam de ahhoz egy más megértés szükséges.

Üdv simonsen!

Szia!
Nem állítom, hogy értem, mire gondolsz.
A PIC nem gondolkodik, csak utasításokat hajt végre. Ha asm.-ben programozol, akkor a te utasításaidat hajtja végre. Ha egyébb nyelveken progizol, és könyvtárakat használsz, akkor valóban nem látsz mögé, mit-miért tesz a PIC.
Bár nem egyszerű kiböngészni és megérteni mindent az adatlapról, de erre van ez a fórum is, hogy megkérdezük másoktól, amit nem tudunk, vagy nem értünk. De konkrétumot kell ahhoz kérdezni, hogy konkrét választ kapjunk.

Szia!

Egyszerű programokkal kell kezdeni, csak 1 LED bekapcsolása, majd be-ki, majd nyomógomb kezelés és így tovább...! Ha ott soronként megnézed, hogy mi történik a PIC regisztereivel ( pl. az MPLAB szimulátorában + adatlap + kapcsolási rajz, hogy mi mit okoz !), akkor "meg fog világosodni" ! Ne légy türelmetlen, mert első körben senki nem az anyatejjel gyűjtötte magába a hozzá szükséges tudást, viszont utána majd egyre jobban fog menni !!

A PIC csak azokat az utasításokat érti, amik az adatlapon is megtalálhatók, így azokat fontos részletesen megismerni és megérteni, mert csak abból tudsz építkezni.
A programozás lényege, hogy a konkrét feladatot megfogalmazod ezekkel az utasításokkal.
Alapvető, hogy pontosan értsd, hogy mit szeretnél, mivel, és hogyan. Mindezt úgy, hogy figyelembe veszed a PIC lehetőségeit és korlátait.
Ha valamelyik lehetőség, vagy korlát nem felel meg az elvárásoknak, másik PIC-et kell választani.

Ha egyértelmű, pontos, jól áttekinthető folyamatábrát készítesz róla, a munka jelentős része el is van végezve, kész a terv.
Már csak le kell írni a rendelkezésre álló utasításokkal.
Aztán jön a fordítás, hibakeresés, szükség szerinti javítás, futtatás.
Az MPLAB szimulátorával utasításonként nyomon követheted a PIC minden regiszterét, minden bitjét, futási idejét, stb.

Ha meglévő programról készítesz folyamatábrát, előtted van az a terv, ami alapján a program írója dolgozott.
Ez kell ahhoz, hogy minden részletet megérts, a program "mögé láss" és érdemben tudj rajta változtatni.

Sziasztok!
Ismeri valaki az AT24C16 típusjelű eepromot?
Hogyan kell ezt összekapcsolni egy PIC18-al és mi módon lehet írni- olvasni?

Szia!
Miért pont ez? Ha már PIC, miért nem a Microchip-nek valamelyik memóriája? Egyébként úgy látom I2C-n kommunikál.

Az alapfelállás az, hogy egyáltalán nem értek az adatkomunikációhoz. Megpróbáltam adatlapból kiókumlálni, hogy mit és hogyan, de nem jártam sikerrel.
Ezért kérném a segítsséget, lehetőleg példaprogrammal.

Én sem csináltam még ilyet, de talán ebből el tudsz indulni, igaz ez PIC16F-re van.

Köszi!
Bár elég macerás lessz kiszedni belőlük a lényeget, de megpróbálom.
Egyébbként néztem a chipcad-nél memóriákat. Van kínálat gazdagon.

Én már SW I2C-vel nem kezdenék, mivel a modernebbekben már mindben benne van a HW. Javaslom az Application Notes-ok olvasgatását (pl. AN979, bár az alap protokollal már ez sem foglalkozik), ezekhez példaprogram is van. De igazából jó dolog megérteni mit kell csinálnia, mert különben nem tudod mit miért csinál (ez főleg akkor okoz problémát, amikor nem működik ). Itt egy programrészlet., ebben semmi hibakezelés nincs, de lehet emiatt és a lineáris felépítés miatt talán egyszerűbb a lényeget megérteni.

Köszi neked is!
Megpróbálom megérteni belőle, hogyan működik, és mennyire tudom az elképzelésemnek megfelelően használni.

Milyen PIC-kel akarod használni? Ha még nem fix, akkor olyat válasz amiben van hardveres I2C modul. Bár ez ma már annyira alapfelszereltség. Ha van benne, akkor az adatot "csak" a bufferbe kell tölteni és már megy is a kommunikáció.

Eddig még csak 3 féle PIC-et használtam. Ezekből mind van több darabom. Szeretném ezek valamelyikével megoldani. PIC12F1480; PIC18F14K22 és PIK18F26K22

A 18F14K22-be van ilyen modul! Keresd meg az adatlapban! Elég részletesen le van írva a működése. Nagyjából szerintem passzol is Tamás által írt programrészhez.

Megnézem. Köszi!

Szia!
I2C-hez egy kis olvasmány: Bővebben: Link.

A Master Syncronous Serial Port (MSSP) modulnál keresd, és az SPI mód részt átugotva az I²C módot olvasd. Természetesen neked nem a Slave hanem a Master üzemmódja kell.

Szerintem kezd azzal, megérteni mit csinál a processzor.
A mikrovezérlő két részre osztható, magára a processzorra, a hozzá tartozó memóriákkal, valamint a perifériákra.
Az adatlapon lévő utasításokkal a processzort vezérled. Pl movwf adatokat mozgat.
Ha az mplab-ba egyesével kipróbálod látod hogy mit csinálnak. Ennél mélyebben akarod érteni, akkor az utasításokat már számként kell ábrázolnod. Atmel processzoroknál néha látszik ilyen ábrázolás is. A processzor tulajdonképpen beolvassa az utasítás által képviselt számot, és ennek megfelelően cselekszik a következő órajel(ek) alatt. Majd jön a következő utasítás (szám ) beolvasása.
A valódi számodra látható részt a perifériákon keresztül valósítja meg, de ez már nem tartozik szorosan a processzorhoz.Az kb csak annyit tud, kinyit egy megjelölt rekeszt (cím) , kivesz betesz valamit ( adat) , vagy az rekesz tartalmától (utasítás) függően egy másik ablakkal elköveti ugyanezt. Amit te látsz az a rekeszek belső élete. ( pl van olyan rekesz, ami ha egy bizonyos számot kap, akkor kigyújt egy lámpát), de ez már a rekesz belügye, a processzor erről nem tud.

Mindenkinek köszönöm a segítsséget. Remélem, ennyi anyaggal már el tudok indulni.
proba!
Jó dolgokat írtál, de sejtheted, ha már adatkomunikációval akarok foglalkozni, akkor az alapokon már túl vagyok. A segítő szándékot mindenesetre köszönöm.

Ahogy nézem lehet nem is neked szántam, bocsánat .