Természetesen megvannak a programozást egységesítő és könnyítő elemek,
de nem csak mikrokontroller létezik a világon (ARM, Intel akármi, stb). Mindegyikre használhatsz ASM-ot. Csak éppen az egyikre ASM-A-t, a másikra meg ASM-B-t.

Valójában a szintaxis a fordító sdk-hoz tartozik. A proci csak annyiban korlát, hogy kötött az utasítás készlet (az ideal assembly-t leszámítva, de arról a perverzióról itt több szó ne essék), és hogy az adott utasításhoz hány paraméter kell. De a szintaktika attól teljesen független. Akár implicit paraméterezést is használhat egy fordító, pld elhagyott elemek default helyettesítése.

Olyan programot nem fogsz találni ami egy Intel Core i7 ASM-ot áttesz neked PICf676-ra.
De egy nüansznyi dologból túlságosan szerteágaztunk (szerintem itt mindenki tudja mitől döglött meg az a légy).

Jé, de érdekes dolgot találtam: CP/M MAC Macro Assembler Language Manual and Applications Guide
Ami a legmeglepőbb benne a direktíváknak (org, equ, db, dw, if - else - endif, page, title) ugyan azok a nevei, mint a MpLab assembly -ben, sőt még ugyan arra a célra is szolgálnak.
Ez csak egy kiragadott példa, de a többi kontrollerével is elboldogul a programozó, ha egyet - kettőt (abszolut kód - relokálható kód) megismert. (MASM, A51, stb) Persze az adott kontroller, mikroprocesszor utasításkészletének, felépítésének (regiszterek, címzési módok, stb) ismerete nélkülözhetetlen az utasítások megértéséhez. Az essembler programban az utasításaok értelmezése és a kód generálása csak egy kis részlet.

Sziasztok!

Hogyan tudnék portot váltani program futása alatt? Már lefordítani sem engedi. Pic18f26k20.

Mit jelent az?

Mi a hibaüzenet?

A kódból nem látszik?
Az IN1-et a pic másik lábára akarom áttenni.

Ez így nem működik úgy, ahogy szeretnéd. A #define hatására a fordítás hátralevő részére az IN1 kifelyezés PORTA,0 -t jelent. A végrehajtás sorrendjétől függetlenül.

Duplicate label ("IN1" or redefining symbol that cannot be redefined)

Létezik az #undefine is, bár nem tudom pontosan mire is szeretnéd használni.

Ok. Értem, csak nem tudtam hogy a sorrend nem számít.
Úgy gondoltam hátha úgy lehet váltani mint ahogy a kimenetből bemenetet csinálni, és fordítva.

Olyasmire, mint mit ír vissza a C fordító?

Persze ott még nincsenek kezelve a ki/bemenet állítások, ha van adc, az sem, de a szintaktika talán látszik.

Sziasztok!
Elkezdtem kicsit jobban gondolkodni a watchdogon. Az egyszerűség kedvéért vegyük a 16F szériát. Itt a STATUS regiszterben lehet figyelni, hogy watchdog miatt történt-e reset vagy sem.
Feltételezzük, hogy a PIC-en futó program tökéletesen van megírva, tehát nem tud watchdog reset kialakulni hibás programfutás miatt. Ilyen esetben watchdog reset csak valamilyen külső zavar hatására következhet be. Külső zavar esetében a következő dolgok történhetnek:
-A zavar nem okoz rendellenes működést, ilyenkor örülünk.
-A zavar módosítja a PC értékét de a többi regisztert nem, így nem fog a WDT törlődni, bekövetkezik a reset. Megvizsgálva a program elején, hogy watchdog reset történt a főciklusra ugorhatunk és mivel a RAM nem sérült így zavartalanul folytatódhat a program.
Eddig ezek voltak a jó esetek, de mi van akkor ha:
-A PC-vel együtt a RAM is módosul, ilyenkor reset után nem fog helyesen működni a program. Esetleg megvizsgálható a program elején néhány regiszter, amibe még "normál" bekapcsoláskor valamilyen értéket töltöttünk, hogy megváltoztak-e. De ilyenkor is előfordulhat, hogy ez a néhány regiszter nem módosult, de a többi igen, bár ennek elég kevés lehet a valószínűsége. De ebben az esetben sem tud ott folytatódni a program, ahol abbamaradt, de legalább megtudjuk a hiba tényét...
-A PC értéke nem módosul, de a RAM értéke igen. Ezt ugyanúgy lehetne vizsgálni, mint az előző esetben, csak itt a főciklusba kellene tenni a regisztervizsgálatot, ez azért fogyasztaná az értékes processzoridőt.
-Csak a PC értéke módosul, de úgy hogy pont rá tud futni a CLRWDT utasításra.

Mennyire gyakori, hogy zavar esetén a PC-vel együtt a RAM is módosul? Ha nagyobb a valószínűsége, hogy csak a PC "kószál el", akkor ennek milyen áramköri kialakítás az oka? Mindenféle tapasztalat, elmélet érdekel mikrokontrollerekre ható zavarokkal kapcsolatban, remélem másokat is.
Nyilván tökéletesen hibamentességet nem lehet elérni, de azért egy erős megbízhatósági szintet jó lenne elérni. Például, ha elindítok egy órát, akkor az újrabeállítgatás nélkül 5 év múlva is helyesen mutassa az időt/dátumot.(figyelmen kívül hagyva az órajelforrás pontatlanságát).

A pic-ek nem annyira szeszélyes jószágok, hogy gondolnak egyet, és elkószálnak a regisztereik majálist ünnepelni, meg mittudomén

Konkrétan milyen természetű zavarok miatt aggódsz? Talán bedobod az egész áramkört egy lavórnyi sós vízbe? Vagy a csernobili atommáglyára hajítod? Vagy mégis mit készül művelni a szerencsétlennel?

Szia
Szerintem, ha a PC elkószál akkor nem elhanyagolható valószínűséggel inkonzisztens adatok maradnak. De elkószálás nem fordulhat elő jól megtervezett áramkörnél. Ha mégis, ilyenkor egy normál áramkör mondjuk "kifagy". Ha innen a WDT hozza vissza akkor az olyan Vis Major, hogy gyakorlatiag újra kell építened minden konfigurációt. Hiszen pont azért használsz WDT-t, hogy a készülék mindig életképes legyen, nem hagyatkozhatsz "talán sértetlen" RAM-ra.
A WDT szerintem pont SW hiba ellen véd: pl. nem gondoltál arra, hogy 1000 évben egyszer jobbról és balról is jön Interrupt és egymásra várnak.
Viszont a felvetés jogos, jó lenne tudni ki mennyi elkószálást tapasztalt. Bármilyen okból is.
Mondjuk nekem eddig egyetlen élő PIC nem fagyott ki ismeretlen okok miatt.

Én csak a tapasztalatomat tudom megosztani: épített már jópár éve egy nixie csöves órát egy itteni cikk alapján. A pontossága a saját 20 MHz-es kvarccával nyilván nem valami jó, de a kapcsolásban lévő RTC időnkénti kiolvasásával nagyon jól működik. Ráadásul még DCF épes is a szerkezet, így nincs semmi gondja. Bár nálam nincs DCF vevő rajta csak az RTC-t olvassa ki néha és azzal a legpontosabb óra a lakásban, pedig van egy pár.

Azért nem kell ahhoz atommáglya, hogy egy digitális hálózat "elkószáljon". Mert tulajdonképpen a PIC egy programozható szinkron sorrendi hálózat. Tehát tárolókból épül fel, a tárolók pedig különböző logikai kapuk összekapcsolásai, melyekben visszacsatolás is található. Ez azt jelenti, ha például egy visszacsatoló ágon egy pillanatra is megváltozik a logikai szint valamilyen zavar miatt, akkor a tároló kimenete is megváltozhat, de ez nem csak egy pillanatra, hanem tartósan. Na, ilyenkor történik az elkószálás. A zavarok sokféleségéről itt van egy cikk: Bővebben: Link
Én is tapasztaltam már, hogy egy hálózati tápellátású PIC mellett, ha bekapcsoltam egy böszme trafót, akkor megbolondult a PIC. Persze normális szűréssel lehet ez ellen védekezni.
Egy egyszerű példa, ha például autóba kell beszerelni valamit, ott a gyújtásrendszer egy elég jelentős zavarforrás.

Egy programot úgy kell megírni, hogy minden lehetőségre helyesen működjön, ezért számolni kell az interruptokkal is, nem fordulhat elő olyan lehetőség, hogy ez hibát okoz. Az más kérdés, hogy a Windowsban a kék halált is általában interrupt hiba okoz, de azt inkább nem keverném a mikrokontrollerekhez.
Csatoltam egy részletet a PIC mikrovezérlők alkalmazástechnikája könyvből, itt is írják hogy külön kell vizsgálni hogy sérült-e a RAM vagy nem.
Ezért merült fel bennem, hogy a PC elkószálásának nagyobb lehet a valószínűsége, mint a RAM hibának.
A watchdog ezért szerintem abban az esetben tökéletes, ha olyan a hardver, hogy abszolút jeladó adja a jeleket(például potméter). Ilyenkor nem gond, ha módosult a RAM, mert a főciklusban újra megtudja nézni a potméter helyzetét, például egy fordulatszám vezérlés esetén, a potméter helyzete alapján állítjuk a PWM-et. De ha potméter helyett inkrementális jeladót használunk, akkor az RAM módosulás esetén már szívás.

Én is építettem már nixie-s órát, én DS32KHZ-t használtam órajelforrásnak. Áramszünet nélkül ment félévet és végig tökéletes volt, pedig abban még a watchdogot sem kapcsoltam be.
Igaz nem kezdtem el mellette egy tesla tekercset működtetni.

Inkább a beírt program "megmaradásával" lehet gond. Az újabb típusokban ellenőrzést is alkalmaznak a programtár rekeszeire. Volt egy kísérlet a 16C koszakban is: PIC16C64x, PIC16C66x Bővebben: Link Zord körülmények között az EEPorm tár felejthet. Ha a program kiolvasása már bizonytalan, akkor eltérülhet a program.

Lehet éppen miszticizálni a pic-ek zavarérzékenységéről, ahogyan a hótalppettyes zöldsárgalábú gezemicék eljövetelében is lehet hinni - de tényleg nem tudom hova tenni a témát. Az összes létező zavar, ami a gyakorlatban tényleg előfordul, az aránytalan többségben tápfeszültség ingadozásra vezethető vissza (néha olyasmi is becsúszik, mint egy félig leragasztott eprom memória, ami "szivárog", stb). Ha éppen gyártani akarsz valahova zavarokat, épp csak hagyd ki a nagy méretű puffer kondit a tápkörből, véletlenül se tegyél elé diódát visszafelé zárni (pld régebbi gépjárműelektronikában), és a pic tápfesz lábaihoz is ne 100 nanofaradot rakj párhuzamosan feszültséget stabilizálni, hanem 100 nanohenry-t sorosan áramot stabilizálni ( ). Hidd el, hogy annyi már elég lesz. Fog neked olyan misztikus zavarokat produkálni, hogy ihaj!

Épp tegnap volt egy hasonló sztorim. Készítettem egy számlálót 12 digites 7 szegmenses kijelzéssel. A kérés az volt, hogy legyen egy indítógomb amivel elindítható a számlálás, ez indítja a Timer1-et. A programot breadboard-on teszteltem két napig, minden rendben működött. A felprogramozott PIC-et elküldtem postán, majd jelentkezett az illető, hogy az egyik digit és a start gomb nem működik. Elhozta a komplett cuccot, újraprogramoztam a PIC-et az eredeti programmal és egyből működött minden. Az érdekes az volt, hogy a start gomb bemente kimenetként működött és lehúzta az ellenás után GND-re. Először azt hittem, hogy az ellenállat lett szakadt.

Sziasztok!


Építettem egy webszervert már enc28j60 -al és PIC18f4520-al. Most szereztem egy esp8266 wifi modult , le akarom cserélni az enc vezérlőt erre.

Tud valaki hozzá egy kapcsolási rajzot , hogy hogy kell ezt összekötni PIC-el?

Ugyanúgy, ahogy az Arduinoval. Például: link
Egyébként az ESP8266 modul PIC nélkül mit nem tud?

Azért van pár dolog.

Tehát akkor az rx és tx lábakat a pic tx és rx lábaira kötöm és ennyi? Több helyen láttam hogy lecserélik róla az alap firmware-t , én nem cseréltem le , gyári van rajta.Ilyenem van (Link)

Egy sample mikroC-s programot esetleg tudnál linkelni , nagyon megköszönném

Itt a modul témája, tele hasznos információkkal: Bővebben: Link.

Ezt már átnéztem , nincs benne példa program. Viszont most találtam egyet , de nem írja át a wifi ssid-t

Csatoltam a beégetett fájlokat , van egy ilyen sor benne :



De nem ez a neve mikor tápot adok neki , tehát nem adja át az adatot neki, kérdés miért?

A pic : 18f4520
Az RC7 és RC6 - os lábaira van kötve az esp rx és tx lábai.

Első lépésként inkább egy USB - UART átalakítóval próbálkozz, azonnal látszik az eredmény, fényévekkel gyorsabban lehet így kipróbálni a modult, mit tud.