Nem tudom, hogy egy nyelven beszélünk-e, de a bootloader az, amit nem te írsz, és fixen benn lakik a memóriában. A firmware (vagy az alkalmazói program pedig az, ami te írsz, beleértve az inicializáló részt is. Ez, avgy ennek részei nem tölthetők a bootloader területére, mert az védett terület. A bootloader is - ha van esze - foggal-körömmel védi a saját területét a gondatlan felülírások ellen, figyelmen kívül hagyja azokat a kódrészeket, amelyekkel felülírná magát.

Döntsd el tehát, hogy bootloadert (is) akarsz fejleszteni/kiegészíteni, vagy csak alkalmazást?

Egy nyelvet beszélünk, és a booltloader fejlesztéssel (pontosabban a programomba való integrálásával) vannak problémáim.
Van egy tökéletesen működő 18F -re assembly-ben írt CAN bootloader saját protokollal + firmware amiket én írtam + saját PC-s program hozzá amit kollégám. Ezt a bootloadert próbálom jól megírni C -ben, 30F kontrollerre, hogy ugyan azt a CAN protokollt és PC-s progit használhassuk mint a 18F nél.
A CAN protokollt a bootloader és a firmware is használja.
Minden programrész külön-külön jól működik: Programmeória írás-ellenőrzés, CAN kommunikáció, stb. csak az egy egységbe szervezéssel van problémám.
Amit fent idéztél az csak ötletelés, lehet hogy butaság. A célja az lett volna az ötletnek:
Ez jelen (csekély) tudásom szerint csak úgy oldható hogy a bootloader tartalmazza az inicializáló részt is, és a CAN is protokollt is (ami nem probléma).
Erre keresek megoldást, és az én ötleteimre várom a kritikákat/alternatívákat.
Ha ennek fényében olvasod vissza a hozzászólásaimat, talán jobban érthető.

A probléma lényege, hogy a bootloader, és a "rendes" program nem igazán lehetnek átfedésben. Azaz ők ketten két független program. Akkor is, ha ugyanaz a kód belekerül mindkettőbe.
Ennek megfelelően egyszer el kell készíteni a bootloadert - mint kerek egészet, ami aztán képes legyen a "rendes" program számára szánt területet komplett lecserélni.

És ettől tök függetlenül el kell készíteni a "rendes" programot, akinek annyi köze van a bootloaderhez, hogy meg kell oldani, hogy a bootloader indulása után a vezérlést átadja neki, és ennyi.

Ez két független projekt, két független forráskód, két független linker script, és a végeredmény, amit be kell égetni a flashbe, az is két független kód lesz. Először beégeted a bootloadert a programozóval, majd a bootloaderen keresztül a programodat a neki szánt területre.

Annak mi akadályát látod, hogy a "rendes" program a bootloader területén lévő függvényt meghívjon? Pl.: CAN kezelés? Mert assemblyben ez simán ment, van vagy 10 ilyen szubrutinom.
Az világos hogy fordítva nem történhet.

Nem akadályát látom, hanem szimplán "ellenjavallt".

Két problémát kell megugrani: hogyan linkeled a össze kódokat - erre jó lehet, ha csinálsz egy jump table-t, amit fix címre raksz, utána pedig a programban ezekre a fix címekre kell ugrani. Ezt persze kézzel kell megcsinálnod, a fordító ebben nem sokat tud segíteni.
A másik, hogy hogyan egyezteted össze a bootloader és a "rendes" program kódjával szembeni ellentmondó igényeket: megváltoztathatatlanság vs frissíthetőség; kicsi, egyszerű, célirányos kompakt kód vs mindentudó, teljes funkcionalitás.

Az általam ismert bootloaderek önállő, a firmware-től független programok. Pazarlásnak tűnik, de pl. az USB kezelés emiatt duplán van benne a mikrovezérlő memóriájában. Szerintem neked is ezt az utat kellene követni.

Rendben, köszönöm mindkettőtöknek a segítséget. Ezek tükrében folytatom.

Sziasztok.
Küzdök a C30 mintaprogramjaival, túl kezdő vagyok még hozzá.
Például a következő sor:

const DRV_SPI_INIT_DATA SPI_Init_Data = {SST25_SPI_CHANNEL, 3, 6, 0, 1, 1, 0};

Vagy hiányolom a [] jeleket, vagy nagyon nem értem.
A másik, hogy ha egy kissé elburjánzott include állomány környékén van egy hivatkozás a *pInitData mutatóra, hogy tudom megtalálni a pInitData változót, amire mutat?
A CTRL-SHIFT F nem hozott eredményt.

Köszi

A DRV_SPI_INIT_DATA típus egy typedef struct, egy ilyen típusú változó inicializálásához kapcsos zárójelek között lehet felsorolni az egyes mezőkbe pakolandó értékeket. Hova kéne ide [] jel?

const DRV_SPI_INIT_DATA [SPI_Init_Data] = {SST25_SPI_CHANNEL, 3, 6, 0, 1, 1, 0};
^ ^
Én így gondoltam.
Miből kell tudnom, hogy ez typedef struct?
Kifejtenéd.
Ahol olvastam eddig róla, ott ezt a két kulcsszót mindig kiírták a deklarációs részben.
Amit írsz, annak alapján ez egy init tömböt tenne le a programmemóriába, amiben ezek az értékek vannak definiálva, a {} belül?
Ha jól értem.
Vagy hozzárendeli a DRV_SPI_INIT_DATA structhoz a SPI_Init_Data konstanst, aminek az értékei vannak a {} között?

Ez egy változó definiálása, inicializálással.
Az SPI_Init_Data a definiált változó neve. A const DRV_SPI_INIT_DATA a típusa. A kapcsos zárójelben levő értékek kerülnek a változóba értékként. Hasonlóan ehhez a sorhoz:


Megkeresed az include fájlokban. A fenti sorból csak annyit lehet tudni, hogy a DRV_SPI_INIT_DATA, az valami típus, mégpedig vagy tömb vagy struktúra, mivel ezeket lehet kapcsos zárójeles kifejezéssel inicializálni.

De ez már közel sem PIC programozásról szól, hanem alapvető C dolgokról.

Köszönöm.
Akkor keresgélek, hasonlóan a pointeres kérdésemhez.
Mint említettem, kezdő vagyok a PIC C30-hoz.
Ezért keresgélek az alapvető kérdésekben.
A Microchip példaprogramjai közel sem a könnyen emészthető kategóriába tartoznak.

Javaslom, használj olyan fejlesztőkörnyezetet amiben könnyű keresni. Akár ugrálni is lehet a fügvényekbe, definekbe és tipusokba. Ez az adatturkászás hihetetlen időt tud igénybe venni és ezen sok időt tudsz spórolni. Sokszor az embert csak az érdekli, hogy az adat honnan hova megy. Pl függvényhívás állít változót, az hol van olvasva, ott mi hivódik és a többi.

A microchip példaprogramjai elég nehezen emészthető olvasmány. Még jó hogy van benne komment. A konfiguráció különösen nagy odafigyelést igényel, hogy az ember megfejtse. Ráádásul szét van bombázva a kód a különböző PIC családokhoz való feltételes fordításokkal. Szerencsére a Microchip még szépen programoz, láttam ennél emészthetetlenebb kodokat.

Ebből azt a téves következtetést vontam le, hogy a C-hez konkrétan értesz, csak ehhez a C fordítóhoz nem.

Ha rám hallgatsz, akkor nem a PIC-en próbálod megtanulni a C programozási nyelvet, mivel minimum egy nagyságrenddel nehezebb, mint mondjuk bármilyen PC-s C fordítón. A PIC-kel C-ben akkor van értelme próbálkozni, ha a C már megy rendesen.


Nem véletlen. Mert azok nem arra vannak, hogy azokon tanuljál meg C-ben programozni.

Én sem, de nem is tudom, hogy hol láttál ilyet, s mi volt a DRV_SPI_INIT_DATA típus definíciója?

Nem mutathat pInitData változóra, mert pInitData a mutató neve. A *pInitData pedig az a tartalom, amire a pInitData mutat.



Természetesen a mutató által megcímzett típust, az adat változó típusát, vagy az utolsó sorban megadott konstans típusát egyeztetni kell!

elnézést, ha félreérthető voltam.
PIC programozással 20 éve foglalkozok, assembly, majd basic.
De most egy olyan feladat jött, ami 24F processzort igényel, ahhoz pedig csak C van.
Kénytelen vagyok küzdeni vele, pontosan tudom, hogy ovodás szintű kérdéseket teszek fel, valamint azzal is tisztában voltam, hogy pont a típusdeklarációkon fogok elcsúszni.
Nem hobby project, valamint nem akarom világmegváltva én megírni a perifériakezelést.
Ez viszont a példaprogramok nyálazásával jár, meg tanulással.
Köszönöm mindenkinek a segítséget és nézzétek el, ha további hasonló alapkérdéseim lesznek.
Vagy ajálnjatok egy olyan fórumot, ahol nem gond ez a szint. De a tanulást mindenkinek ele kell kezdeni valahol.

A honlapomon található PIC-kwik projektet láttad már? Igaz, hogy az főleg PIC24H-ra koncentrál, de PIC24F-hez is haszonnal tanulmányozható.

Igen, már nézegetem...
Köszönöm.
Nekem elsősorban most tényleg a C megoldásokra kell figyelnem, arra pedig a te oldalad is kiváló.
A processzorközeli dolgok, hardverfelépítésben, szemléletben nincs gond.
Úgyhogy tanulok.

Nem csak C van, lehet azt assembly-ben is programozni. Az más kérdés, hogy érdemes-e. Pl. I2C vagy SPI interfész használatát simán össze lehet dobni assembly-ben, de egy TCP/IP stacket biztosan nem akarnék.

Ebben az esetben a gyári függvénykönyvtárat leszel kénytelen használni. Az pedig nem fog úgy menni, hogy nem tudsz "C-ül". A gyári függvénykönyvtár kialakításánál nyilván kihasználták a C adta lehetőségeket (pointerek, struktúrák, C-s makrók ezerrel), az ezekre épülő példaprogramokat sem igazán fogod tudni megérteni így, pláne nem a saját igényeid szerint módosítani. És akkor arról a részről nem is beszéltem, hogy a példaprogramok a lehető legritkább esetben korrekt, teljes programok... Tehát pont az nincs bennük, amiből a C-t meg lehetne tanulni jól. Általában csak a függvénykönyvtár elemeinek felhasználását mutatják be, de a többi körítést, sallangot (pl. hibakezelések) el szokták hagyni vagy nagyolni.

Továbbra is tartom, hogy ha ezt komolyan gondolod, akkor előbb a C nyelvvel ismerkedj össze alaposabban, és erre nem a PIC a nyerő platform, hanem a számítógéped.

Pedig ez történik és jó részt már megy a dolog.
Grafikus modult azért nem kezdenék assemblyben, de a touch és a video már megy.
Pontosan tudom, hogy nem ez a legkönnyebb út, de jelenleg ez van...
A tegnapi segítséged már át is lendített, ahogy ezt megértettem, egy csomó minden a helyére került és megy az SPI-s eeprom.
Egyébként assembly: Azt ültetném le 18 és 24 közé programozni felváltva, aki átnevezte az ugyanolyan használatú utasításokat másfajta mnemonikra...

Szia!

Ha felhasználod őket egy nem hobby projectben, át kell nézni / tisztázni kell a használat feltételeit.

Szia!

Idézet:
„Azt ültetném le 18 és 24 közé programozni felváltva”

Akkor javaslom mélyülj el a PIC32MX assembly nyelvű programozásában is.

Megnéztem.
A gyári könyvtár GNU
Felhasználható.

Kösz... azért teljesen nem vagyok mazochista...

Szia!

Nem biztos, hogy csak a jogi következményekre gondolt !

Steve

Sziasztok!
Egy kis segítséget szeretnék kérni PIC16f886+lcd+ds18b20 projektben.
Szeretném használni a watchdogot a programomban, mert hát biztos ami biztos.
Viszont elég érdekes anomáliákat kaptam.
Szóval ha használom a watchdogot és nem törlöm sehol akkor elvileg újra kellene indulnia a PIC-nek. Ezzel együtt az lcd-nek is. A program elejére írtam egy kis üdvözlő programocskát, hogy tisztán látható legyen, ha a PIC resetelt. Emellett figyeltetem a TO regiszter értékét is, mert ha watchdog újraindítás történt, akkor ennek az értéke 0 lesz.
Végeredmény az, hogyha "rövid a programom", tehát mondjuk csak lcd-re kiiratok valamit, akkor ugyan újraindul a PIC (látszik, hogy a háttérvilágítás egy pillanatra kikapcsol), de nem ugrik bele abba a feltételbe, hogy ha TO=0, akkor pl írja ki hogy watchdog újraindítás.
Ha hosszú a program (mérek hőmérsékletet, még átlagolok is, stb...), akkor meg nem is indul újra.
Ha debugolok, akkor sem. Megnéztem a WATCH menüben a regiszterek értékeit, TO bit végig 1-es.(?????????)
Ha szimulációban nézem, akkor a watchdog idő lejárta után szépen kiírja, hogy watchdog megszakítás volt, blablabla....A szimulációs futtatáskor is megnéztem a status regiszter értékét, ott szépen TO 0 értéket vesz fel.
Csatolom a forráskódot, elég hosszú, mert menü is van benne. Előre is köszönöm!

Sziasztok! Valaki segítsen!
Napok óta próbálok egy PIC24F ADC-t életre kelteni (A0-A4) de nem megy.
A cél az lenne hogy 5 bemenetet scannelne, és a beolvasott értékeket változókba mentené az interruptban amit később ki tudok olvasni.
Az ADC beállítása

és az interrupt

Proteusban figyelve az ADC mintha működne, mert az AD1CON1.SAMP bitje folyamatosan változik, de az ADC1BUFx regiszterekbe nem kerül semmi.
Mit rontok el???? (PIC24FJ128GA010 25MHz)

A kérdés STORNO, a probléma megoldódott.
Valaki megtenné hoyg törli?

Ha nem nagy gond, nem törölném, viszont a hiba oka és megoldása érdekelne. (Hátha más is belefut, vagy tudja hasznosítani a kódod...)

Valószínűleg hibás a konfigurálás. Például nem látom, hogy AD1CON2-be beírtad volna a pásztázandó csatornák számát, pontosabban a (nchannel - 1) << 2 kifejezés értékét.
A honlapomról az adc7scan1.c vagy adc7scan2.c mintapéldákat nézd meg!