A fent dobott linken nem igazán látok project forrást, amit lehívhatnék, és lefordíthatnék saját gépen megnézni, mennyit eszik.

Gondolkodtam pic32mx695/795-re 10 vonalasan rákotött rmii-n pld dp83848 vagy ekvivalens, de már leesett a tantusz, hogy ha a net buffer ram nem külső eszközben van, akkor a pic saját ramját eszi a net, és az nem funny. Valószínűleg 624-est választok hozzá.

Ha te lefordítod a projectedet, ahogyan éppen van, nálad mennyi munka ram használatot ír ki a fordító? Fogtam az üzenetet a működés közbeni allokációról, de szerintem azokat már meg tudja csinálni a stack külső soros ramon is, és az én problémám csak a pic saját belső ramja.

Szép is lenne ha az említett mikrovezérlőről tudnád letölteni a kismillió forrást
Azt a microchip oldaláról kell Bővebben: Link
mellékeltem Lan8720-ra fordítva 2013-06-15 Tcpip54208

Értékeket köszi. Hány webkliens volt engedélyezve abban a projectben?

Passz, talán négy? nem módosítottam
ha felteszed, lesz itt egy help: .....\Microchip\Help\

Ugyan már megvan a megoldás, de azért leírom: MPLAB-X van winre, linuxra, mac-ra is. Én pl. linux alól használom.

Mplabx van mindenre, épp csak időnként sokkal több nyugtatóra lesz szükséged, mint amennyi még egészséges. Ha még nem tapasztaltad, örülj neki. Viszont készülj fel rá, hogy el fog múlni.

Mi a problémád az MPLABX-el?

Nem tudom a nyugatók milyen árban vannak mostanában, de a RAM és az SSD jobban megtérülő beruházás szerintem.

A megszakítás kritikusan befolyásolhatja az időzítésre érzékeny folyamatok eredményét.

Az MPLABX-et próbáltam High Sierra alól korábban, amikor a 44PIN demoboardot akartam használni, de valami bibi volt azzal is. Eddig ez a leghasználhatóbb szerintem, amit tegnap leírtam.

Biztosan bennem van a hiba, mindössze 43 éve foglalkozom a számítástechnika valamelyik ágával, megszámlálhatatlan típusú számítógépen igen sok programnyelven, rengeteg fejlesztő környezetben dolgoztam ez alatt az idő alatt. Ennek ellenére, nem sikerült megbarátkoznom az MPLabX-el. Egy projekt logikátlan könvtárszerkezetben épül fel, üres könyvtárakkal, és nagyon nehezen követhető hatású beállításokkal. Az MPLabX szinte minden új, századverziónyi változására újból és újból, (igaz egyre kevesebb lelkesedéssel) becsülettel nekiálltam, és kipróbáltam. Eljutottam oda, hogy inkább hanyagolom az újabb MicroChip kontrollereket, amiket nem támogat az MPLab 8.92 verzió. Annak is vannak hibái, de legalább kiismerhető, következetes.

Mindenkinek megvannak a maga szempontjai, ami alapján választ. Többször is nekifutottam a PIC-kelésnek, de többször is megálltam hosszú időre. Időközben nyugdíjas lettem, és mivel már nem "kötelező", hanyagolom a PiciPuha oprendszerét. Így maradt az MPLAB-X. Mivel lényegében nincs összehasonlítási alapom (amikor még winem is volt nem jutottam messzire - most sem igazán), ezért nem tudom eldönteni, mennyivel rosszabb, mint a régi MPLAB. Nekem hobbizásra megfelel. Memória persze kell neki bőven, főleg ha fut mellette a firefox megnyitott frászbukkal. De mióta felnyomtam a RAM-ot 8 gigára, ez sem gond.

Ami hibát konkrétan észrevettem, hogy a menet közbeni szintaktikai ellenőrzése hibázik. Jelez pár kielégítetlen hivatkozást, ami pedig létezik, és fordításkor nem is lesz hiba. Biztos valamit rosszul állítok be, de nekem csak akkor működik, ha a cpp-t írom be #include-al, nem a "h"-t. És hiába telepítem a régi (legacy) könyvtárakat a 32MX-hez az 1.43 utáni XC32-höz, nem találja. Bár gondolom, ez megint csak valami beállítás kérdése lenne, csak még nem jöttem rá. Az is eltartott egy ideig, míre sikerült összehoznom minden beállítást, hogy a saját include könyvtáramat lássa.

Valahogy minél bonyolultabb lesz egy fejlesztő környezet, annál több benne a baki, a működési hiba. Mennyivel tisztább volt, amikor a még a 80-as években szépen megírtam a programot az ahhoz kitalált nyomtatványon, majd magam lejukasztottam lyukkártyára. Kevesebb volt ez elütés, mintha leadtam lyukasztásra. Régi szép idők....

Da azért akkor is sikerült fordító hibába szaladnom az IBM Pliopt-jában, el is veszett miatta egy befizetett egy hetes vitorlás táborom.

Nem állítasz be semmit rosszul szimplán sz*r...
De egy nálam bevált egy dolog erre és csak build-lés közben felvillan és eltűnik a hiba.
Ha nagyon nem akar menni húzd újra az egészet, mindig segít
A másik amitől megőrül, folyamatosan fut valami object scanner szerű (vagy nem tudom, hogy hívják) ami a code completion-hoz kel, hogy lássa a már definiált objektumokat, ha több projekt meg van nyitva és a 2 projet source-jai között váltasz, megőrül.
Nekem ami erre be vált 1 projekt van csak megnyitva és az is main-nek van beállítva, valamint ha még is megőrülne újra indítom utána szokott menni.

Csak egy kicsit az X védelmében, nem foglalkoztam olyan sok µC-el, de a Silabs fejlesztő környezete eclipse-es az se egy egyszerű darab, meg használtam még a Keil-t az valamivel jobb mindkettőnél de nekem az se az igazi.
Én régóta reménykedek főleg mióta láttam ARM-hoz lehet a Visual Studio-t használni, hogy ez egyszer PIC-re is lesz.

Engem meg azért kerülget a hideg frász, mert már piacon van a pic32mz/da beépített 32 mega rammal ( Bővebben: Link ), és még csak nem is drága a panel. De hiába, ahhoz fejlesztői környezet is kell normális, anélkül semmit ér. Csak cpu + memória egyben ezernyi szoftveres hibával már létezik raspberry zero néven is (10 usd sincs az ára), és az se nagyon jó semmire. Pedig de jó lenne, ha végre open doksit kapna az a bcm szöcske..

Najó, befejeztem az álmodozást, mert az ébredés mindig fájdalmas

"Megőrülést" én nem tapasztaltam, ami nálam rossz benne, az következetesen rossz benne, olyan még nem volt, hogy meghülyül, leállítom, újraindítom, és jó. Még csak nem is fagyott. Az ugyan előfordult, hogy kicsit minden megállt, mert elfogyott a RAM, és a gép csesztette a winyón a virtuális memóriát. Bár az sem az MPLAB-X piszkálásakor volt, hanem a mellette futó firefox, a másik nagy memória zabagép piszkálása közben. De ez a 8 gigával megszűnt, és előtte a firefox/frászbuk önmagában is elég volt néha ehhez. A linux nem kifejezetten egy "húzd újra, és jó lesz" rendszer. Én Kubuntu 14.04 LTS-t használok, pedig az "ínyencek" szerint ez nem is egy jó linux.

Játszogattam már Arduino kártyákkal is, a hozzájuk tartozó fejlesztő környezettel. Az is olyan nagyjából cpp, kicsi, egyszerű, nekem szépen működött (szintén linux alatt). Aztán próbáltam az mpIDE környezetet is, az az Arduino mintára készült PIC-es panelekhez készült, forrás szinten Arduino kompatibilis környezet. De mióta nem önálló program, hanem beépül az Arduino fejlesztő környezetbe, azóta nekem nem működik rendesen.

Sziasztok!

System timert (1ms tickrate timer) szeretnék csinálni PIC32-re interrupt nélkül, költségesnek tartom, hogy 1ms-onként megszakítás hívjon a PIC egy változó növelése érdekében.
Ez a nagyon vázlat, mennyire lehet működőképes egy 500ms led-nél "async" delay-el működőképesnek tűnik, de 50 ms multiméteres freki mérésen ezzel a kóddal 9.53 Hz-et mértem timer 1ms megszakítással 9.8Hz-et, mindig ilyen kicsi "torzulás" lesz benne vagy ez attól függ típusú kérdés?
Kód:

Hali!
Nem teljesen világos mit csinál a programod, nem tudom mi az a _CP0... függvény...
Miért kell 1ms, ha 500ms-re van szükséged?
A picben vannak timerek, kettőt össze is foghatsz akkor az 32bites osztó+előosztó,
ezzel szerintem a kivánt időzítés megoldható, akár interruptosan, akár a timer int.flag ellenőrzésével, nem kell bűvészkedni.
Sokkal idő/erőforráspazarlóbb ha rendszeresen megnézed lejárt-e már a timer, ill hol tart a függvényed, mintha a beállított időben egyszer lefut a timer megszakítás...

Az 500ms csak tesztelés szempontjából van, én TickTimer-ként szoktam hivatkozni erre, lényege hogy legyen egy 1ms-enként növő változó amit bármikor bármilyen idő mérésére tudok használni async módon.

A PIC32-ben van egy core timer (32 bit) ami a CP0 (co-processor 0) ban található és CPU órajelén ketyeg a _CP0_GET_COUNT() a cp0defs.h ban van leírva annyit csinál, hogy lekéri a core timer pillanatnyi értékét.

Azért gondolom így, hogy ez erőforrás megtakarító, mert interrupt minden 1ms-enként keletkezik, na de ez csak akkor dolgozik ha lekérdezem, valóban ha folyamatosan lekérdezem nagyobb az erőforrás igénye mint két változót kivonogatni egymásból.
De például, én ezt csak 10 ms-onként hívom meg cirka 50-60 ciklus idő kell a függvénynek (stopwatch) akkor már 10 megszakítás, context save-et megspóroltam.
A másik fele, hogy ebből akkor egy us timert is na viszont us-enként megszakítani még 100MHz (most ennyin megy a PIC) is érdekes lenne.

Vagy rosszul gondolom és a túl spórolni akarásom vissza üt is inkább árt mint használ?

Ne felejtsd el hogy a változóid túlcsordulnak adott idő után, ezt nem látom lekezelve, unsigned int pikkpakk túlcsordul.
Na én is tanultam valamit, ezt a core timert még nem láttam, nézem az adatlapot 32mx795...
a kereső 1 találatot ad "core timer"-re, nem bőbeszédű csak az int flag-ot mutatja, semmi részletezés miez/hogy működik. Majd rákeresek még, nem rossz dolog, esp8266 procinál már láttam, használtam (ott is belátható időn belül túlcsordul)

Reference Manual-ban kicsit bővebben beszélnek róla.

Itt is van azt a _CP0_COMPARE-el lehet beállítani, hol generáljon megszakítást.

Felesleges kezelgetni a túlcsordulást 2^32 ms (cirka 1000 óra, ha jól számoltam) 2^32 us is cirka 1 óra.
Másrészről ha unsigned-ként kezeled, (jelenlegi tick)5 (előző tick) 4294967285 és 5 - 4294967285 = 16.
És egy időzítést így (fapados) csinálok meg ahol a különbség adja az eltelt időt

Van egy regiszter a pic32-es családban - minden tagnál - a cp0,9. 32 bites, fixen az órajel felével számol, ha túlcsordul, szimplán nulláz. Ha elég gyors egy program főciklus, a legcélszerűbb azt csinálni, hogy mindig nézni új kiolvasásnál, a kapott érték kisebb-e, mint az előzőleg olvasott, és ha igen, akkor tudni lehet, hogy nullázott. Olyankor növelni egy másik 32 bites számlálót, és van egy 64 bites gépórád, ami 80 mhz esetén 25 nsec lépésekben számol 14613 éven keresztül. A 32 bites regiszter 107 másodpercenként fordul át, szerintem az idő alatt elvárható a főciklus lefutása, illetve hogy ha nem is jár le, akkor is, legalább 106 másodpercenként egyszer a főciklus valamelyik lépésén csak rá lehetne kukkantani arra a számlálóra, és lekezelni a túlcsordulást. Ha máshogy nem, külön timer megszakításból. Részemről megbízható gépóra forrásnak tartom. Még egy pici olvasnivaló róla: DS61113E-page 2-24

Én ez alapján csináltam: core timer

Sziasztok!

MpLab X alatt xc16 fordítónál hogyan lehet kikapcsolni szelektíven a warning-okat ?! Kicsit unom már, hogy egy egy fordításnál úgy kell kivadásznom a hibát a sok warning közül! Tudom, kézenfekvőnek tűnne a warningokat megszüntetni...de ez a fordító azért is kiabál, ha levegőt veszek, tehát más javaslatra vagyok kíváncsi...

Másik kérdésem érdekesebbnek tűnik...

Létrehozok két egyforma típusú struktúrát, majd egyszerű értékadással próbálom egyiket a másikkal egyenlővé tenni. Ekkor ugye alapban a fordító legenerálná a kódot, ami végigmegy a struktúra elemein, és elvégzi az egészet a háttérben. Ez működik is jól...egészen addig, míg a másolandó struktúrát meghatározott címre nem teszem a programmemóriában. Ettől kezdve valami "internal compiler error" hibával leáll a fordító. Lejjebb még ezt is írja


Mi lehet az oka, illetve mit lehet ezzel kezdeni ?

Hali!
C32-ben: Bővebben: Link 19.oldal
Valószinűleg megtalálod az xc16 hasonló doksiban.
De jótanács, a warning nem véletlenül van, illik megszüntetni, ill. helyből úgy írni a progit.
Gondolom különböző tipusú változóknál kapsz warning-ot, be kell írni a változók elé kényszerkonverziót, jobb a békesség...

Hali! Valahol "átváltozik pointeresre" a struktúra és ott már nem működik...
Használj memóriamásolást a pointerek között, memcpy rémlik, és sizeof....
szerintem...

Persze...jobb...de mit kezdjek pl az ilyen típusú figyelmeztetésekkel:

Nyilván azért csináltam ezt, mert ezt szeretném! Totál felesleges erre figyelmeztetnie...

Egyébként a C32 eléggé más, mint az xc32, pláne xc16. Sajnos xc16 alatt más kell..., ha egyáltalán lehet benne ilyet csinálni...

Nyilván azt szeretném ezzel elkerülni, hogy ne nekem kelljen forráskódból megoldani a másolást! Ha nem találok rá értelmes megoldást, akkor ez marad...de nagyon nem szeretném...elég nagy a struktúra

Ha jól csalódom van #undef, amit a #define előtt használhatsz.
De miért nem használsz más nevet, ha nem tetszik a "gyári" tartalma?