Tenyleg nem bantasbol, de eleg zavaros amit irtal. Szoval egy sajat keretrendszert szeretnel, ahol tokenizalt utasitasokat hajtanal vegre? Magyaran egy interpretert szeretnel irni?

0x40 -tol 0x70-ig toltesz fel? Miert SWAPF-et hasznalsz amugy es miert bitmintat a vegcim ellenorzeshez? Elegge nehezen atlathato igy az algoritmus.

Egy aprosag: Neha kiirod, hogy 'w' meg 'f', neha meg szamokat irsz oda. Legyen konzekvens, ugy ertem soha ne hasznalj szamot mert az sokkal nehezebben ertheto...

Oké, egy átgondolatlan zagyvalékot írtam. Így utólag szívesebben törölném ki

Szóval van az a bootloader. Kellene arról valami jól megcsiszolt fejtágító. Kotorászok az MC oldalakon, de valahogy csak mellébeszélést találok.

A bootloader egy olyan program, ami elfoglal a PIC memóriájából egy részt és lehetőséget ad arra, hogy soros vonalakon keresztül (USART, USB, Ethernet, stb. PIC kiépítéstől függően) módosítani lehessen a programot. Gyakorlatilag helyettesíthet egy égető áramkört, ha már benne van a PIC-ben. A program megírását, módosítását nem pótolja, viszont könnyen fel lehet tölteni a módosított programot, akár egy távoli céláramkörbe is, ha megvan a kapcsolat.
Egyébként én sem értem mit szeretnél, mert amit írsz, az kicsit operációs rendszerre emlékeztet. Egyébként az is létezik PIC-re, csak minek...

Nincs részletenkénti bővítés, de nem is fixen rögzített, hanem az egész alkalmazást lehet lecserélni vele.

Sokféle bootloader létezik, tehát előre célszerű rögzíteni, hogy milyen mikrovezérlőről és milyen kommunikációs lehetőségről van szó, honnan akarod letölteni a programot (soros vonal, USB, CAN, I2C stb.).

Ez az egész még csak elméleti szinten létezik, lehetőségeknek nézek utána jelenleg. Nem akartam bő lére ereszteni, de akkor most közkívánatra tessék.

Adva van egy ethernetes hálózati eszköz (van ip címe, elérhető, meg minden), amin működik rajta éppen az a program, ami. Fel van szerelve valahol egy nem túl hozzáférhető helyen. Tegyük fel, a programot módosítani kell. Ez egy karbantartás jellegű dolog. Normál esetben le kell szerelni a cuccost, hogy hozzáférhető legyen, újraprogramozni, felszerelni újra. Ezen gondoltam egyszerűsíteni.

Ha a bootloader segít abban, hogy az egészet ethernetről újraprogramozzam távolról hálózaton keresztül, akkor az egy jó pont neki. Legalább a sétát megspórólja nekem.

Kifinomultsági kérdés, hogy ezt a teljes "újraprogramozást" részemről működés közben akartam végrehajtani, a működési adatok és egyebek megzavarása nélkül. Ehhez olyan program modulok kellenek, amiket pluginok formájában tudok betölteni a memóriába, onnét végrehajtani / eltávolítani egyik pillanatról a másikra, sőt flash-be is lementeni őket, ha szükséges. És persze akkor a rendszer behúzás is igényelne egy kis kotorászást, mert ilyen programnál gyakorlatilag csak egy program mag van (afféle mini kernel), minden más modulárisan kell ráépüljön. A működés közbeni SW frissítésnek logikailag én nem ismerem másik módját.

Kezelhetőségi kérdés, hogy ha van is valami technika erre az újraprogramozásra kidolgozva, az egy windowsos program, amiben kézzel kell pötyörgészni, vagy egy parancssoros valami, amit scriptbe tehetek, és sok tucatjával is lehet automatizáltan végrehajtani. A grafikus programok tényleg igazán ízlésesek, meg minden, de azért az automatizálhatóság nekem lehet többet érne.

Hogy ennyire sült galambot kapjak a számba, azt nem is reméltem. Gondoltam utána lesek, fordítóprogram tud-e mondjuk 2-3 KByte fix szerkezetű kódblokkokat fordítani. Kellene a .hex file-ok szerkezeti leírása, hogy saját kézbe tudjam venni a lefordított állományokat. Megírom azokra én magam a letöltést, sőt pic oldalon a flashbe tárolást / visszatöltést is. Igazán örülök én a bootloadernek is, csak hát az ember mindig többet akar.

Szóval kb ennyi. Ha mindehhez van már valami support féle is, amit felhasználhatok, annak valóban örülnék. Van ilyen?

Szia!

Azt hiszem nem egészen érted a pic programozását. A pic egy szétválasztott program adat memóriával rendelkező kontroller (bár egyes típusokban a program memória elérhető adatterületként is.) A programozásakor a belső flash memóriáját kell beírni, átírni - sajnos egyes típusoknál elég korlátozott az újraírhatósága. Az adat memóriából közvetlenül nem tud programot futtatni.

A letöltött programrészleteket is a belső flash-ben kellene elhelyezni, a programrészlet csere egy teljes flash lap újraírását jelenti - megoldható.

Kivételt képeznek a külső memória illesztési lehetőséggel bíró típusok: pl. 18F96J60, 18F96J65, 18F97J60 - belső Ethernet illesztővel rendelkeznek. Itt lehetőség van külső flash ill. ram illesztésére is, amiből képesek programot is végrehajtani, a tartalmuk programból megváltoztatható.

A hex állomány Intel hex formátumú.

Szia!
Az lcd modulban a cgram-ba a pic eepromjából a 0-tol tölteném fel a 16 karaktert. Amúgy mivel mással nézzem meg, hogy a végcimet elérte-e? Mármint, hogy megvolt az utolsó adat is.
A w és f az fel sem tűnt, hogy néha számokat írok helyettük.
Elméletem szerint, beolvas egy adatot majd beírja az lcd-be, majd ujra olvas az eepromból és így tovább.
Sajnos néha túbonyolítok dolgokat. Sok pic könyvet átolvastam, és már viszonylag sok tudást is összegyűjtöttem a témában, de ugyebár ezt át kell vinni a gyakorlatba is...
Köszi

El tudom képzelni, hogy a módosító rutin maga a program része, annak átadsz adatot, ami a megadott helyre beírja azt. A módosítás alatt lévő területet eközben nem szabadna használni, csak a módosítás után lehetne visszaadni az engedélyt a terület használatára, azaz az új program kezdene futni ezután.

Ez a művelet igen gondos előkészületeket igényel a memória kiosztásban, hogy a változatlanul hagyott törzsprogram hivatkozásai ne sérüljenek. Esetleg egy ugrótáblával meg lehet oldani azt is, ha egy hivatkozás kezdőcíme megváltozna.

Mindez nagyon magas szintű programozási tudást igényel, és nagyon nagy munkát. Értelmét nem nagyon látom, hacsak az alkalmazás értéke nem hozható egy szintre a megoldás költségeivel.

Ezen az oldalon az "Ethernet bootloaders" szekcióban találsz olyat, amilyet szeretnél. Az ára hardvertől függően 50 - 200 USD.
Ezt szerintem most felejtsd el!

Hex formatot köszönöm. Memóriából úgy rémlik az összes pic32 tud végrehajtani is. Vásárolni nem áll szándékomban. És igen, könnyen lehet, az ötlet a kukában végzi. Az ötletek némelyike már csak olyan.

Ahhoz, hogy az ő elképzelése szerint működjön a dolog, nem elég egy bootloader, neki kell megírni egy olyan rutint, ami kezeli a program módosítási feladatokat a kapott adatok alapján, menedzselve a közben folyó program korlátozásait, mentéseit. Az igaz, hogy kiindulási alapnak jó a bootloader forrása!

A PIC32 felépítése lehetővé teszi, hogy RAM-ból fusson a program és a programmemóríát úgy olvassuk, mintha adatmemória volna, de a Harvard felépítésből fakadó előnyök ilyenkor elvesznek. Bővebben: Link

Ugye EE-cime-be ha 16 kerul, az 0x10, tehat B'0001 0000'. Namost ha megnezed a kododat, akkor elobb swapf-el a W-be B'0000 0001' kerul, majd ezt hasonlitod ossze B'10000111'-el... Magyaran 0x78 -nal fog ez talalkozni, mivel SWAPF elott az lenne B'0111 1000'.

Csupan ket sort kellene modositanod, hogy atlathato legyen (nagybetus utasitasok...):

Bocs, ezt a linket szerettem volna megadni az előző hozzászólásnál!

Szia!
Gondoltam swapf -el teszem be a w-be. Épp ezért "swap"-oltam át a xorlw-s adatot (10000111).
Ezekszerint tényleg belebonyolodtam.

Köszönöm szépen a javallatokat.

Köszönöm a linket, temérdek sok anyag van ott, amivel még nem is találkoztam :eek2:

Kellene nekem egy handy amatőr cuccos pic32 kísérletezéshez, és egyszerűen csak nem találok.

Valami "csupasz" panel kellene csak a legszükségesebb dolgokkal. Pld 5V-os táp csatlakozó (jack, 2.1mm-es), 3.3V-os stabkocka, pár szűrőkondi, ICSP tüskesor, a felforrasztott TQFP tok / üres QFN socket 64 pin 9x9mm-es, és pár szigetecske. Esetleg még egy max232-es a DB9-es csatival (én még ezt tenném fel). Mint anno a DV164121 panelja volt a pickit 2 debug express kit-ben.

Amiket találok, már programozóval egybeépített / előre programozott integrált boardok, amik biztos sokmindenre jók, csak éppen olyasmihez nem, amit nulláról magam akarok végig csiszolni.

Valaki esetleg találkozott ilyesmivel? Esetleg saját maga gyártott ilyesmit? Vagy hasonlót?

Néhány a kínálatból:
- CUI32 Bővebben: Link
- Olimex PIC32MX340F512 kártya (ez a monosx.hu címen is kapható).
- PIC32 64pin on a DIP
- USB 32-Bit Whacker PIC32MX795 kártya
- PIC32 Development Demo Board (Ezt azért tettem hátra, mert utálatos módon nincsenek kivezetve a PIC lábai!)

A SWAPF akkor lenne celszeru, ha a STATUS regiszterben a Z bitet nem szeretnenk ha elrontana, de itt most ez lenyegtelen hisz az XORLW amugy is beallitja ezt nekunk. Akkor pedig mar ne bonyolitsuk a dolgokat

SWAPF-nek pl fontos szerepe van a megszakitas kezelesben a kontextus vissza allitasaban...

icserny:
Köszönöm, a PIC32MX340F512 kártya pont jó lesz.


Más.

C30 Lite paraméterezés. Rá kellene venni a fordítót, hogy dobjon lista állományt. Elvileg a preprocesszorja asm kódot csinál a C programból. Azt listába dobatni se lenne vele utolsó. De legalább egy .map-ot, ha mást nem. Nézem az MC leírást róla (van users guide pdf a compilerről), végig szedtem a listát a kapcsolókról, és nem találok ilyen beállítási lehetőséget. Tényleg nem tud ilyet? Vagy én szúrok el valamit?

Vagy, ha kísérletezni akarsz, bread board próbapanelt kedvező áron rendelhetsz (72/326529). Nekem is ma hozta a postás, pénteken rendeltem.

Van egy totál méretes dugaszpanelom, de az pdip-es pic-ekhez van. QFN / TQFP tokozáshoz már smd nyák kell, és nem lehet megúszni a forrasztást sem.

GNU fordítóknál -S opcióval leállítja a fordítást az assembly meghívása előtt. Az .s állományok az assembly forrásfájlok. Ha pedig az assembler kimenetéről akarsz listát, akkor valószínűleg az assembler opcióit kell megnézni.

A Microchip fórumán azt írják, hogy egy sikeres fordítás után parancssorból használható az alábbi megoldás:

Mielőtt kitárgyaljuk a C30 paraméterezlését, a PIC32F -ekhez nem a C32 kell? A C30 a PIC24F illetve a dsPIC30F -ekhez való.

Na ja... Én már rég nem tudom követni mi is itt a cél, főleg egy kezdő topicban mindez...

Az észrevétel különben jogos. De most még csak a C -> gépikód gyártási lépésnél tartok.

Előszedtem egy c30-as projectet, amit az unalomig szanszét gyűrtem már. Ezt a lépést itt fogom végig tesztelni. Itt jóval kevesebb a hibalehetőség, mint egy új környezetben.

Egyébként c30 vagy c32, amennyire fel tudtam mérni, egyik sem tud stand-alone modult fordítani relokálási táblázattal. Ez valahogy nem gyakorlat még pic32-nél sem. Pedig bizony lehetne.

watt:
A fordító problémáival vacakolni egyébként tipikus kezdő probléma. Egyáltalán nem baj, ha mindenki, aki erre jár, fejébe vési, hogy a grafikus ablakok mögött hogyan is zajlik egy fordítás. Tuti, hogy arról mindenki hajlamos megfeledkezni.

A PicKit2-höz adtak egy demopanelt. A benne lévő program a CD-n is mellékelve van, .asm fájlban.
A 887-esre az MPLAB azt írja kiválasztás után, hogy nincs hozzá compiler. Gondoltam, én ezt kipróbálom. A gyári .asm-et betöltöttem az MPLAB-ba QuickBild-del lefordítottam .hex-be. A fájl kívülről teljesen azonos a gyárival, de fájlkezelővel összehasonlítottam és talált köztük két bit eltérést. Egyelőre még nem írtam át a 887-be, de kíváncsi vagyok, okoz-e problémát. Továbbiakra most nincs időm, de majd felteszem mindkét .hex fájlt, hogy lássátok az eltérést.

Az máshoz sincs, külön kell telepíteni. De ha nem C nyelven programozol, akkor nem is kell. Assembler viszont települ az MPLAB-hoz (minden Microchip mikrovezérlőhöz).

Ha az eltérés a HEX állományok végén van, akkor nagy valószínűséggel a konfigurációs bitek beállításában van különbség. Hogy ez számít-e, az attól függ, hogy melyik bitről van szó...

Szerintem érdemes egy neked megfelelő konfigurációs beállítást kiizzadni (itt is kérhetsz hozzá segítséget, tanácsot), s a jövőben minden hasonló program elejére automatikusan betenni.