Visszatértünk oda, hogy mi van, ha megszakítás nélkül töltöd fel a táblázatott FF-ekkel együtt, ahová az kell. Az táblát pedig egy #pragma utáni eeprom cím terület beállításával indíthatnád. Nekem nem tette még máshová a változóimat, ha megadtam a kezdő címet.

Rengeteg féle módszert kipróbáltam már.... Ld. melléklet.
Az a baj, hogy a fordító nem enged meg műveletet a #pragma címének megadásakor.

Részemről befejezve. Egyébként is csak azért hoztam (ismét) fel, hogy van olyan feladat, ami nem vagy nagyon nehezen vitelezhető ki magas szintű nyelven a beépített korlátozások miatt.

Az XC8 eeprom kezelése egyenesen siralmas...

Érdekes, nem vettem eddig észre, hogy a pragma étékadásában nem lehet műveletet végezni. Két egész számot sem enged meg összeadni, pedig ez elég alap dolog lenne.

Ez a problémám megoldódott, ha valakit érdekel a kérdés, jelezze, leírom...

Már csak a digitális lábnyomod miatt is érdemes leírni...

Hasznosabb, ha valakit érdekel is, mert ha csak ideírom, elvész. A keresőt nem sokan szeretik használni. Meg aztán ez nem blog...

Engem érdekel a megoldás.
Nevetni fogsz de számtalanszor kerestem már vissza innen a saját beírásaimból és cikkeimből az éppen szükséges információt. Már csak ezért is érdemes leírni...

Velemis volt már, hogy saját írásomat kerestem, mert emlékeztem rá, hogy megosztottam másokkal is a megoldást, de idő közben elfelejtettem.

Ebben van valami, én is jártam már így.
Tehát a hivatkozott kérdésem röviden az volt, hogy miért nem kér, vagy ha kér, miért nem kap IP-t a DHCP szervertől(router) a DHCP kliens a Harmony stack-ben. Az ok prózai volt. Alapértelmezésben nincs beállítva MAC cím és javaslat se nagyon található. Úgy gondoltam mindegy milyet állítok be, hát nem. Amit beállítottam: A1-00-00-00-00-A1. Ez nem tetszett a T-Link routernek, de nem szólt semmit, mert az alap beállított IP-vel működött a HTTP, de csak belső hálóról.
A nyűgje akkor derült ki, amikor be akartam állítani a routeren, hogy fix IP-t osszon ki az ismert MAC címhez. A MAC megadásakor jelezte, hogy ez nem megfelelő cím. Adtam egy hasraütött 01-05-09-EC-01-08 címet a stack-ben és azonnal kiosztódott az IP és a Forward virtuális szerver beállítása után kintről is elérhető lett a HTTP szerver.

Még 1 dolog érdekelne, ha meg lehetne PIC el oldani
hogy egy kommunikációs csatornán programozható feszültséget érhessek el
5-11V ig vagyis a LOGIC-1 fesz értékét a beavatkozás előtt lemérje és korrigálja le/fel
a programozott szintre.
Analog input/ AD concverter /Vref mire figyeljek, amivel a szintet mérni lehet ?
és amivel egy mosfetet lehetne vezérelni ?
Kössz

Wiki lap a MAC address-ről

A második MAC-ed is rossz. Ha még nem akadtál bele, majd fogsz. Wiki-n nézz rá arra a cikkre. A MAC address legfelső byte-jának legalsó bitje szabályozza az uni / multi cast address-t. Unicast MAC esetén annak a bitnek nullának kell lennie. Emberi nyelven a MAC address legfelső byte-ja kötelezően páros szám. Írd át, és jobb lesz. Ha azzal megvagy, az eggyel magasabb bitre is ránézhetsz. Ha hasraütve találtál ki MAC-et, állítsd locally administered-re.

Szóval összefoglalóan van egy hibásan működő pragma az xc8 alatt. Szerintem van az xc8 alatt még sokkal több hiba is.

Köszi!

Sajnos ez nem hiba, hanem tulajdonság... Javítása sem várható....

Sziasztok!

PIC32MZ2048EFG064-vel szeretnék TFT kijelzőt vezérelni. Még csak a tervek készülnek. Egy ilyen kijelzővel.
A kérdés az lenne, hogy mivel lenne gyorsabb a vezérlése 8bites PMD-vel vagy 16 bites adatküldéssel, de az "software-sen" lenne vezérelve adott port lábakkal?

Gondolom PMP-t akarál írni. Az RBport jöhetne szóba, de lehet, hogy nem lenne gyorsabb, mint a 8bites PMP, ha kihasználod a vezérlő vonalait is. Ellenben ez egy kicsi pixelszámú kijelző, elég nagy megjelenítési sebességet el lehet érni, talán nem lesz vele gond. De javaslnám inkább a 100lábút a 16bites PMP-vel, az lenne a korrekt.

Köszönöm!

Igen a PMP-re gondoltam, a 100 lábúba is gondoltkoztam, de nem tudtam, hogy használhatom-e, most beleegyeztek(akinek fejlesztem), úgyhogy lesz a 100 lábú.

Minden tisztelettel kérném az urakat, hogy maradjunk a téma címénél.
Köszönöm!

Üdv mindenkinek!

Segítségre lenne szükségem.
A következő program módosításával illetve lefordításával lenne problémám.
Egy külföldi weboldalon találtam a programot illetve a hozzá tartozó kapcsolást. Az egész egy peltier modul szabályozása. Az eredeti program jól működik, viszont nem látja el azt a feladatot amit szeretném, hogy elláson. Az előre beállított hőmérsékletet nem lehet módosítani, csak a program változtatásával majd újra fordításával.
Egy fórumtársunk segítségével (hálás köszönet érte) módosítottam a programon, hogy 2 nyomógomb segítségével lehessen változtatni a kívánt hőmérséklet.
Nem túlzottan értek a basichez, esetleg ha valaki esetleg tudna rá vetni egy pillantást, hogy így működni fog-e, illetve ha igen akkor le tudná nekem fordítani, akkor örök hálám üldözni fogja

Az eredeti


a módosított



Köszönöm előre is!

A program jónak tűnik, de a kapcs rajzból semmit sem látunk, nem tudjuk biztosra mondani, hogy jó lesz. A gomb bekötése az, amit még ne szúrj el, különben nem fog működni. A a fel / le gombokat a porta.4-5 lábakra kösd be, tápfesz felé legyenek a pic láb felől, és legyen 0v-ra lehúzó ellenállás azokon a pic lábakon alapból, 10k körül bármi.

Egyébként kicsit illetlen programot egészben bekoppantani, ilyesminek nem a haladó topicban a helye, van kezdő pic topic is.

Köszönöm szépen a segítséget és elnézést az illetlenségért, számomra ez már bonyolult progi, tekintve, hogy nem értek hozzá.
Akkor a további kérdéseimet a kezdő topicban teszem fel.

Sziasztok!
Mi lehet a különbség egy 18F14K50 és egy 18F14K22 I2C modulja között? A dolgot bonyolítja, hogy a K50-et C18, a K22-t XC8 alatt fordítottam. A K22 SCL lábán meg se jelenik a jel ha olvasom(RCEN=1), csak, ha írom (SSPBUF=X). Ugyanazokat az I2C rutinokat használom, amit a C18.
Természetesen a K50 hibátlanul működik.
Köszi!

Szerintem hardveresen semmi, jellemzően ugyan az a technológiai generáció. Viszont te nem a hardvert kezeled, hanem valamilyen fordító környezeten keresztül fordítasz c -> asm, és lehet, az xc8-ban még vannak hibák, mint például a regiszter pozíció el van írva. Valaki a kezdő-n éppen beleakadt egy .gld elírásba. Az xc8 környezetét én nem ismerem, sosem használtam, de ha elkezdesz belekotorni az #include láncolatba, ott meg kell lennie a bűnösnek. Esetleg kezdetben azt is kipróbálhatod, hogy kinyisszantasz egy totál egyszerű részletet, és azt asm-ben írod meg. A regisztert is nem névvel címzed, hanem megnézed a pozíció címét a pic doksijában. Gyártasz hozzá valami nyúlfarknyi kis programot, ami pic alapinit, periféria alapinit, és adat kiküldés. Ha úgy sem hajlandó működni, akkor nem a fordító a bűnös, hanem hardver hibád van. Asm progi írása helyett esetleg segítség lehet maga a fordító is. A régi C fordító toolchain-jét be lehetett paraméterezni asm list file generálására, és ott az asm program szövegesen. A regiszter címeket abban is ellenőrizheted az adatlaphoz képest. Persze az XC-nél nem tudom, hogyan lehet olyasmire rávenni.

Köszi a választ! Az MPLAB X mcc18 alap beállításaival volt gond. Azt is meg tudtam csinálni, hogy K50-re MPLAB-al és X el, de C18 alatt fordítottam, még sem lett egyforma a hex és nem is működött az X alatt fordított firmware. A beállításoknál az mcc18 alatt resetáltam, majd újra beállítottam a header eléréseket. Változást csak a Generated Command Line alatt láttam, de a program futni kezdett. Még nem tudom pontosan az okot, mert nincs időm keresgélni. Valószínű, hogy az XC8 alatt is csak ezt kellene megtenni, de most már átforrasztottam a PIC-et. (A K22-őt nem kezeli a C18...) Köszi mégegyszer!

Nem tudom átírni XC8-ra ami C18 alatt jól fut. Csak az I2C nem megy, ahogy a korábbiakban leírtam. A C18-al is el tudtam érni, hogy ne menjen, de igazából nem tudom mi okozta, azt pláne nem, hogy az XC8 alatt mit kellene másképpen beállítanom. Ami biztos, hogy jó az órajel, az időzítések és a port funkciók (LCD megy, USART megy, IO megy).

Úgy tűnik nem áll be az RCEN... ?

Most írjam le újra?

Nem a kóddal van a baj és nem az include-okkal. Annyit csináltam, hogy módosítottam az optimalizációs beállításokon, beállítottam a speed és a debug opciót. Ekkor nem fért el a kód, ami nem meglepő. Kivettem a speed-et és láss csodát elindult. Gondoltam megvan, biztosan a debug opció miatt volt. Kivettem, lefordítottam és ment. Azaz most minden ugyanúgy van beállítva, mint amit a project készítésénél feldob és még is megy. Van még egy project, amin nem végeztem el a módosításokat, az nem fut most sem. Itt valami MPLAB X hiba van, amit nem hiszem, hogy meg lehet érteni. A C18-al is mókolnom kellett k50-nél (c18 opciók reset), hogy működjön, úgyhogy nem fordító hiba. XC8-nál nem segített a reset, ott módosítani kellett a beállításokon és vissza. Valamit rosszul hoz létre az MPLX a project megnyitásakor. A fura az, hogy csak az I2C-re volt hatással...

A beépített függvéyeket használod? Ha igen akkor miért?
Habár én nemrégiben írtam át egy 18f14k50 MC által írt firmet pic24-re.
Igaz csak a regisztereket írtam át, de gond nélkül megy az i2c.
Elég fura ez az oda-vissza reseteléses hibaelhárítás, de való igaz, hogy az X-nek még vannak hibái.

Nem. Ez a kód már régi, csak váltottam K50-ről K22-re(egy lábbal több kellett.). Valóban fura, de szerencsére működik.