Szerintem ha már jó az algoritmus, minden ilyen hiba magára az enkóderre vezethető vissza. Bár mindig lehet bonyolítani a programot. : -) Meglassítottad kicsit ellenállással és kondenzátorral (RC-tagokkal) a két vonalat?

Már nem tudom módosítani az előző hozzászólást. Működik! Volt a programban várakozási idő a gombok miatt, meg idő volt az I2C kommunikáció is (RTC-ből idő lekérdezés), ezért lemaradt néhány a forgatásról. Köszönöm mindkettőtöknek.

Rendelj megszakitast az enkoder két jeléhez, hogy ne maradj le az élváltásokról

Ha step-dir rendszerű az enkóder és nem Gray-kód kimenettel bír, elégy egy megszakítás is, a step kimenetre.

Az élváltozás megszakítás helyett én időzítő megszakításból csináltam anno enkóder számlálást. Másodpercenként 10000 megszakítással nem tudtam olyan olyan sebességgel forgatni az enkódert amit ne tudott volna rendesen feldolgozni. Ezzel a módszerrel az érintkezők pergésével sem kellett foglalkoznom, mert ahhoz meg már elég ritka a mintavételezés. Emlékeim szerint 2% körüli processzoridőt használt fel így.

Na, akkor nem volt igazam. : -) De éppen nem volt több időm rá.

MPLAB x fejlesztőkörnyezet

Sziasztok!

MPLAB X-et használok.
Létezik-e arra megoldás, hogy a PIC programozásakor az EEPROM tartalom törlődjön, de ne FF, hanem 0 legyen minden byte?

Migration Guide 4.14 pont.

Áttanulmányoztam, és lefordíttattam a fordítóval, de így sem lettem okosabb.
Nem tudnád valahogy érthetően elmagyarázni, hogyan tudom beállítani az MPLAB-ban?

Szia!
Hátha ez segít:

DE: Segítségével a belső adat EEPROM-ban tudunk információt tárolni. Nincs implementálva minden mikrovezérlőben. 16-os család esetén a 2100h, míg 18-asnál az F00000h-nál kezdődik az EEPROM adatmemória.

Szintaxis: [címke] DE kifejezés [,kifejezés, …, kifejezés]
Példa: ORG 2100
DE ”Boci program”, '\n'

PSECT edata
DW 9700h
DW 'r', -48
DB 0xFE
DT "NULL"


Ekkor az EEPROM 0 címtől a 0x00, a 0x97, 0x42, 0xFE, 0x4E, 0x55, 0x4C, 0x4C sorozatnak kellene lennie. A programozáskor az EEProm területet is engedélyezni kell.

Ezt ide kellene beírni?

Nem, a forrásba. Fordítani hex -et, betölteni, programozni.
Ha fordítás nélkül szeretnéd egy PIC -ben az EEProm területet módosítani, akkor az MpLabX -ben található IPE programot használd, de ott is be kell állítani, hogy módosítható legyen a memóriában tárolt adat. Kiolvas, átír, programoz.

PIC-kos trükkök

Kicsit áthallásos a cím, nem véletlen. Assemby-ben az ember néha trükkös megoldásokat használ, máskor ennél is tovább megy, később meg csak vakarja a fejét, hogy mi is akar ez lenni. Az alábbi gyöngyszemre nemrég bukkantam. Csak érdekességnek mutatom, nem követendő példának.

PIC16-on a táblázat olvasás egy függvény hívás, a függvényen belül a táblázatban lévő pozícióra ugrás a PC direkt írásával történik, ahol egy RETLW visszatér a kívánt értékkel a függvényből, és mindezt mondjuk egy ciklusból hívjuk, hogy egy hullámformának megfelelő értéket küldjünk ki a B portra. (A táblázat pedig legyen 256 byte határra igazítva.)


Ezt meg lehet bolondítani annyival, hogy nem kell CALL a táblázat hivására és nem kell a GOTO loop sem.
azaz a ciklus 4 órajellel rövidebb lehet, mert a tábla olvasás RETLW-je fog a ciklus elejére ugrani:


A ciklus végén rácsorgunk a táblázatra, nincs CALL, majd a RETLW a loop-tól folytatja a programot.

A trükk az init részben van, ez még az elég kezdetleges PIC16F54-re íródott, ahol csak 2 szintű a hívási verem, az init rész ezt a két elemet feltölti egyszer úgy, hogy mindkét elemben a loop címe van, a táblából való visszatéréskor a felső címre tér vissza, majd az alsó címet a felsőbe másolja. Azaz továbbra is a loop címe lesz ott. így minden ciklusban maga a táblázat RETLW-je ugrik vissza a loop cimkére.

Az init értelmetlen ugrabugrának tűnik, de nem az. A start-nál lévő CALL a loop cimét tesz a verembe tetejére, a következő CALL azért kell, hogy ezt a verem másik címére másolja és az új címet tegye a tetejére, majd onnan visszatéréskor a loop címe visszakerül a verem tejére is, és megmarad a második szinten is. A start-nál lévő CALL-ból nem térünk vissza, a visszatérési címünk szépen előkészítve mindkét verem szinten és ugrunk a loop-ra ...

Ezért különleges tudás a programozás (szaktudás) és szűkös a nyelvi kommunikációs csatorna:
szerintem csak egy másik programozó érti, amit írtál, a többieknek kínai magyarázatod.
A mai mikrovezérlőkben meg már nem szükséges ilyen trükköket bevetni a tárhely bősége, a verem mérete, a gyorsaság, stb miatt...
Nem egyedi eset, kívülállók ugyanilyen bambán néznek, ha olvasnak jogi szöveget, matematikai, fizikai, orvosi szövegeket, sőt, az idegen nyelvű leírások meg végképp kínaiak ...
Hasonló WTF (what a f.ck) történet 1999-ből a Quake program Fast inverse square root = 0x5F3759DF algoritmus ~ gyors inverz négyzetgyök = 1/ gyök x megoldása. Ez a forradalmi, szokatlan program tette lehetővé a valós sebességű, 3D térhatású mozgóképek (játékok) megjelenését:

float Q_rsqrt(float number)
{
long i;
float x2, y;
const float threehalfs = 1.5F;

x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

return y;
}
Itt a leírása, matematikai háttere, de azt is csak a matematikusok meg a programozók látják át.

Ez jópofa.
Bár erősen korlátozott hogy hol lehet ilyeneket használni, illetve ahogy HeZ is írta, ma már gyakorlatilag végtelen erőforrás áll rendelkezésre.
De amúgy ettől függetlenül, én is ragaszkodok a régi, 8-as verziójú MPLAB-hoz, illetve a nagyon új PIC-ekkel nem foglalkozom.
Viszont a 12F1840 nagy kedvencem. Van benne elég klassz indirekt címzés, akárcsak a nagyobb 18F szériában. Tehát végig bírsz olvasni egy táblát az adat/program memóriában úgy, hogy nem nyúlsz hozzá a pointerhez.
18F-nél erre van a POSTINC, POSTDEC.. stb. virtuális regiszterek, melyekkel a kiolvasás után (vagy előtt a PREINC-el) automatikusan lehet növelni/csökkenteni az FSR pointert.
Na ugyanez megvan a 12F1840-nél, csak máshogy kell használni.
Ráadásul a 12F1840-nél úgy ki lehet kerülni a bankolást, hogy létrehoztak egy virtuális, "lineáris" adatmemória területet, ami az összes bank GPR regisztercímeit tartalmazza folytatólagosan.

Szóval igen, megvannak ennek a területnek a szépségei, csak kell hozzá szem, ami meglátja.

Igen. De ez a szemlélet csak arra jó, hogy megtanuljunk pazarolni.
Páldául egy 2-3 LED-es villogóhoz egy SMD PIC10 is pazarlás, de ott legalább értelmet ad neki a nagyon kicsi méret. Viszont blokkos programozással ESP32-re csinálni meg, kb. plyan értelmetlen, mint a gyémántberakásos színarany telefontok. Csak hivalkodásra jó, hogy semmi sem számít.
Én csináltam már távirányítós kisautót wifi kapcsolattal. Lehetett volna adó és vevő oldalra is berakni 1-1 ESP32 S3-ast, de lehet úgy is, hogy egy PIC10 beolvas kép potit, ezt 1-wiren továbbítja egy ESP-01-nek, ami zárt (mac adress) alapú csatornán küldi egy másik ESP-01-nek, ami közvetlen meg tud vezérelni egy modelszervót és egy brusheles motor vezérlőt.
Itt már használom a magasabb szintű hardvert és a C programnyelvet, de csak az ésszerűsség határain belűl.

Valahol igazad van, de az baj, hogy amikor egy STM32G030F6P6 olcsóbb mint egy PIC10F322-I/P meggondolandó, hogy érdemes-e rengeteg időt felhasználva megküzdeni azon, hogy hogyan hogyan lehet az erősen csökkentett utasításkészletű 8 bites PIC-be cipőkanállal belevarázsolni az óhajtott feladatot elvégző programot (bármilyen elegánsan is hangzik azt utólag kijelenteni, hogy megoldottam).

Noha igaz amit írsz, de meglepődik az ember, ha utánanéz, hogy nem csak az ilyen cipőkanalas 8 bites, de még az ennél primitivebb 4 bites mikrokontrollereknek még mindig mekkora piaci részesedése van. Egy kenyérpiritó timer-nek bőven megteszi, és ha ezt factory programozottan szállítják meg méginkább kisebb költséget jelent.

De térjünk vissza a hobbira, a 10F-nek is megvan a helye, ha SOT tokban extrém kis hely áll rendelkezésre, minimális fogyasztás szeretnénk, vagy nagyon primitiv a feladat. a végtelen erőforrás meg sosem végtelen, mindig van az a feladat ami kiahasználja, pl. FFT. És lehet erősebb kontrollert taláni erre a feladatra is, de hobbi esetén más szempontok vannak. Néhány db készülék esetén az nem számit igazán, hogy egyik picit olcsóbb, ha például a másikhoz már meg van fejlesztői tudás és környezet, programozó/debugger HW. Leszoktam a 8 bites PIC-ekről és az assembly-ről, de néha egy egy kisebb feladatra előszedem, mert gyakran egyszerűbb és gyorsabb egy meglévő programot módosítani, összeollózni, újrahasznosítani, mint újra kezdeni nulláról másik architektúrán. Próbálom a faladathoz választani az eszközt, és új architektúrát csak akkor bevetni ha a meglévő készlettel nem reális a megvalósíthatóság.

Egyetértek.
Az viszont tényleg szomorú, hogy ahogy megy az idő, rohamosan emelkednek a PIC árak.
Pont a napokban néztem 18F2520-at, mondom veszek belőle. ChipCAD-nél nincs is raktáron, mouser-nél is nettó 2500Ft körül van.
A benjami által említett STM32G030F6P6 meg kb. 1/6 áron van.
Bár, az új PIC-ek közt is vannak ilyen olcsók.
Én egyébként azért ragaszkodok még a 8 bites PIC-ekhez, mert assembly-ben relatíve egyszerű őket programozni, és atomi szinten kézben lehet tartani a dolgokat.
Egy ARM-nél már gondolom az asm felejtős, C-ben meg ki vagy szolgáltatva a fordítónak.
Anno amikor próbáltam a C fordítókat PIC-re, ebből lett elegem. Írtam egy progit, aztán a következő verziójú C fordító már nem akart függvényeket felismerni, hibákat dobott. .stb. Aztán találja meg az ember az okát...
Persze használtam én is ESP32-t, VSCode-al, nagyon jól lehet magas szintű feladatokat csinálni vele. De amihez nem indokolt, arra ott a PIC.

PIC12F1840
PIC18F25K20

Egyforma tokozást, technológiát illene összehasonlítani. Be kell látni, hogy a DIP tokozás iránt már nincs akkora kereslet, így drágább. Ezenkívül az 5V -os technológia is kezd kimenni a divatból, a 3.3V-os széria sokkal olcsóbb.

Én éppen a szándékosan butított ingyenes verziós C fordítók miatt fordultam el a PIC-től (megjegyzem, hogy egyáltalán nem bántam meg, mert egy másik világ nyílt ki cserébe). Azt még elnéztem volna, hogy az optimalizálást nem tudták az ingyenes verziók, de amikor feleslegesen a működést nem megváltoztató plusz utasításokat szúrtak be, kizárólag azért, hogy a kód nagyobb és lassabb legyen, azt már nem vette be a gyomrom. Pedig egy ideig ott volt a gépemen egy C nyelv feltelepítése előtti MPLAB-ot is tartalmazó virtuális oprendszer háttértár képfájlja, amire ugye bármikor tudok egy 60 napig működő próbaverziót feltelepíteni, de ezt akkor is nevetségesnek tartottam. Az ARM-re meg ott van a teljesen ingyenes teljes értékű GCC fordító.

Ezt nem értem. Miért jobb az, ha szigorúan 3,3V-on dolgozik valami, mint amikor 2,5V-tól 5,5V-ig vígan elvan? Plusz nem értem, mitől lesz az olcsóbb? A gyártástechnológia ugyan az. vagy nem?
Nem a fejlesztési költségek, és a felhasználási darabszám határozzák meg az eladási árat?

Gondolom a fogyasztás, sebesség optimalizáláshoz van köze. Az 5V-os mikrovezérlők kisebb sebességről ugye lassabbak. Mindenesetre elég kellemetlen, hogy feszültség konverterekre van szükség ha az 5V-ost össze akarom kötni a 3,3V-sal.

Valóban az eladott darabszám nagyban meghatározza az árat, de van más szempont is. Egyrészt a 3,3v-os magok terjedtek el és ez az irány, az 5V-os rendszerek elavulnak (persze van kivétel is, mivel az 5V-os rendszerek kevésbé érzékenyek a zavarokra). Így a 3,3V-os procik eladott darabszáma lényegesen nagyobb, mint az 5V-osok. De van egy másik lényeges tényező, mégpedig az egy szilicium korongon (wafer) elhelyezhető magok (die) száma. Az 5V-os tranzisztorok nagyobbak, így több helyet foglalnak el, valamint az I/O portjaik is több tranzisztorból állnak (level-shifter miatt). Így az egész mag nagyobb, kevesebb mag fér el egyetlen lapon (dies/wafer). Márpedig a wafer költség technológiától függően 30%-50% a chip előállítási árának.