Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   1246 / 1318
(#) pajti2 válasza killbill hozzászólására (») Feb 20, 2017 /
 
És azt az esetet hogyan tudod stabilan érzékelni, hogy a processzek valamennyi lehetséges állapoton átmentek már?

Ha az alkalmazásba nem akarsz preemptive kernelt építeni, nincsen stack szabdalódás, a stack-et csak az alkalmazás egészére méretezed, és akkor akármekkora ráhagyást is követsz el, azt csak egyszer teszed meg. Mondjuk adsz a firmware egészének 10 kbyte-ot a 120 modulra összesen, és azt méricskélés nélkül is tudom, hogy nem fogja átlépni. Viszont ha 120 modulra egyesével akarom odaadni a 10k-t, az egy kicsit ciki lesz.
(#) Wezuv válasza killbill hozzászólására (») Feb 21, 2017 /
 
Idézet:
„Ugy, hogy egy megszakitas vagy egy masik futo process kuld neki signalt:”

Valószínű, csak fogalmazási zavaraim vannak, de ha egy process vár, akkor nem küldhető "neki" semmi, mert nem tudja ellenőrizni, mert egyik része sem fut. Ezért gondoltam és kérdeztem, hogy a szignálokat bizonyára a kernel dolgozza fel és ha azok rendben vannak, akkor indítja a várakozó processt. A kernelnek viszont tudnia kell, hogy a process mire vár, amit bizonyára a process fog átadni. Valamit nem jól értek?
Köszönöm a példát, maga az eljárás az világos, csak az nem, hogy melyik részhez tartozik (process, kernel)!

A verem alatt a hardveres stack-et értitek, ahová a szubrutin hívások, megszakítások esetén lerakódik a visszatérési cím és egyéb infók? Vagy a közös RAM területet, amit elosztasz a processek között?
(#) killbill válasza pajti2 hozzászólására (») Feb 21, 2017 /
 
Idézet:
„És azt az esetet hogyan tudod stabilan érzékelni, hogy a processzek valamennyi lehetséges állapoton átmentek már?”
Ha egyszeru a processz, akkor konnyen. Ha nagyon osszetett, akkor sehogy. De azert a stack fogyas nem olyan szelsoseges dolog, hacsak nem hasznalsz rekurziot. A tobbeves tapasztalat szerint 1k stack meg soha semminek nem kellett. En sem mericskelem, csak latom. Ha a sw megy orak ota, csinalt mar mindent, amit csinalnia kell, akkor eleg nagy valoszinuseggel allithatjuk, hogy sokkal tobb stack nem fog nekik kelleni, mint amennyit eddig elhasznaltak. Szoval tenyleg nem ertem, hogy mit akarsz. Van 6-8 processzem, mindegyik kap parszaz byte stack-et es nincs vele semmi baj. Plusz van az exception stack. Es ennek az egvilagon semmi koze nincs ahhoz, hogy preemptiv vagy kooperativ. Pont ugyanugy hasznaljak a stacket.
(#) killbill válasza Wezuv hozzászólására (») Feb 21, 2017 /
 
Idézet:
„Valószínű, csak fogalmazási zavaraim vannak, de ha egy process vár, akkor nem küldhető "neki" semmi, mert nem tudja ellenőrizni, mert egyik része sem fut.”
Nem ellenoriz a processz semmit. Pont ez a lenyeg, hogy nem az altalad megirt kod (process) csinalja a multitaskot, hanem a kernel. A kernel ellenoriz. Amikor meghivod a varakozast (EventWait() ), akkor abban megmondod a kernelnek, hogy mi(k)re varsz. Az EventWait() es EventPost() fuggvenyek a kernel reszei.
A stack az stack, igen az a stack (verem), ahova a processzor a regisztereket meg egyes processzorokon a visszateresi cimet menteni tudta. Mert pl. az ARM vagy a PIC32 is, ha jol emlekszem, alapbol csak egy regiszterbe teszi bele a visszateresi cimet szubrutin hivasakor, es ha a szubrutin nem hiv tovabbi szubrutint, akkor a vegen csak a regiszterben levo cimre ugrik vissza. Ezzel megsporol ket teljesen felesleges stack muveletet. Ha megis hiv szubrutint, akkor elmenti a stack-be ezt a regisztert.
(#) Wezuv válasza killbill hozzászólására (») Feb 21, 2017 /
 
Ha új processzt akarsz felvenni, akkor változtatni kell a kernelen, (pl. stack kiosztás beállítása, processz belépési cím, ilyesmi)? Vagy van valamilyen protokoll egy új processz regisztrálására, pl. a processz kér annyi stack-et amennyit jónak gondolsz?
(#) pajti2 válasza killbill hozzászólására (») Feb 21, 2017 /
 
Idézet:
„Van 6-8 processzem, mindegyik kap parszaz byte stack-et es nincs vele semmi baj. Plusz van az exception stack. Es ennek az egvilagon semmi koze nincs ahhoz, hogy preemptiv vagy kooperativ. Pont ugyanugy hasznaljak a stacket.”

Khm, a stack ugyanolyan használatát ugye te sem gondoltad komolyan? Szerintem egy kernel mag fejlesztés könnyítő eszköz, és erősen a megítélésének az alapja, hogy folyamatos fejlesztési logisztikában végső soron könnyít vagy nehezít rajta.

Kicsit tegyük tisztába a fogalmakat. Itt egy cikk is róla: What are “co-operative” and “pre-emptive” scheduling al...ithms?

Kooperatív kernelnél a vezérlés feladása "önkéntes", és ha jön is valami hw irq, a visszatérés mindig a beszakítási ponthoz tér vissza. Nem tud a verem összegubancolódni a taskok között, éppen azért lehet firmware egészére összefüggő közös stack, amit a C32 fordító önként is be fog állítani neked a teljes fel nem használt ram területére. Külön asm betétek sem kellenek a C programba, lehet homogén a forráskódod.

Preemptive kernelnél alkalmasint nem visszatérés van, hanem átváltás a taskok között erőszakos vezérlés elvétellel, és lévén olyankor a stack a taskok között kajak össze tudna gubancolódni, azért is kell külön verem. A regiszterek mentését is saját asm rutinnal kell csinálnod, a C32 fordító nem fog hozzá támogatást adni - nem tud. Egyesével kell a stack méretet adnod a moduloknak, a forráskódod nem lehet majd homogén C rutinok esetében.

Volt már eset valami japán autógyár vackával, amikor a firmware moduljainak elnézték a stack méretét, egymásra futottak, elkallódott az automata sebességváltó vezérlése, és a kocsi extrában gyorsítani kezdett. 4-en haltak meg.

Jelenleg éppen keresem, van-e a 32-es magokban stack limit regiszter cpu megszakítást generálni, ha a verem éppen túlcsordulna, és nem találom azt az adatlapot, ahol ír róla. Az legalább egy eszköz lehetne a verem használat kitesztelésére máshogyan is, mint hogy egyszer csak misztikus jelenségek kezdenek el történni.
(#) killbill válasza pajti2 hozzászólására (») Feb 21, 2017 /
 
Az teny, hogy a kooperativ kernelnel a megszakitasok ugyanoda ternek vissza, de a processz valtasok maskepp mukodnek. Egy kooperativ kernel eseten pontosan ugyanugy szukseg van minden processznek kulon stack-re. A processzek stack-je meg kell maradjon akkor is, amikor eppen masik processz fut. Ha csak egy kozos stack lenne, akkor ha az A processz betesz a stack-be 10 byte-ot, aztan atadja vezerlest (egy kernel hivassal) B processznek, aki szinten beletesz 20 byte-ot, aztan visszaadja a vezerlest az A processznek egy ujabb kernel hivassal (es itt a lenyeg, hogy nem returnnel), akkor az A processz altal latott stack megvaltozott, hiszen az SP 20 byte-tal arrebb van, mint amikor meghivta a kernelt. Ezert kell minden processznek sajat stack. Nem veletlen, hogy a processz valtast (context switch) a kernel vegzi, es ez joforman nem all masbol, mint a stack-ek cserelgetesebol. Gondold csak vegig.

A linkelt oldal elmeleti dolgokrol szol, szo nincs benne stack-rol. Amugy meg a fene meg is ette az egeszet, ha a stack pointert C fordito allitja be... A stack hasznaltsagot ugy lehet a legegyszerubben merni, hogy feltoltod a kijelolt stack teruletet egy bizonyos mintazattal, es kesobb megnezed, hogy ebbol mennyi valtozott meg. Ez nem egy 1000%-os megoldas, de sw-bol nem nagyon van mas modszer. Viszont arra tokeletes, hogy lasd, hogy a kodod a valo eletben mennyi stack-et fogyaszt es ez alapjan biztonsaggal tudjal neki stack-et allokalni.
(#) killbill válasza Wezuv hozzászólására (») Feb 21, 2017 /
 
Az altalam hasznalt kernel, az kb. 30 db C fuggveny meg egy 20 soros assembly rutin, ami a process valtast csinalja. A processzek stack-jeit te allokalod statikusan, es egy kernel hivassal inditod el az uj processzeket. A peldamban lathatod a BZ_ProcSpawn() hivast a ButtonsInit() fuggvenyben. Ennek a hivasnak atadod, a PID-et, ami a Process Identifier, azaz a processz azonosito, atadod, hogy melyik fuggveny legyen a processz es hogy hol van az altalad allokalt stack (vege). Az en kernelemben a PID-ek 0-tol szamozodnak, es egyben a processz prioritasat is meghatarozzak. Komolyabb, nagy kernelekben mint a Linux, ott a pid dinamikusan generalodik, de ott mondjuk egyszerre tobbszaz processz is fut, nalam meg altalaban 10 alatt.
(#) Wezuv válasza killbill hozzászólására (») Feb 21, 2017 /
 
Nekem tetszik a megoldás, a korlátai ellenére is. A stack egymásra csúszás veszélye elvben megvan, de szerintem is meg lehet határozni a minimum szükségest és azt növelni biztonságosra. Nem valószínű szerintem se, hogy egy program, ami "mindent" megcsinált a tesztek alatt, ami a feladata, egyszer csak többet kérne. A rekurzív függvényhívásokat, gondolom kerülöd, vagy korlátozod...

Viszont nem lehetne egy olyan megoldást használni, ami kidobná a processt, ha túllépné a keretét, majd újra indítaná? A hibát jelezné a kernel és pontosabban lehetne hangolni a méretet. Azért lehet, hogy atomreaktort (és autót) nem vezérelnék ilyen megoldással, de amúgy nem hiszem, hogy túl nagy veszélyt hordozna a megoldás. Egy sima egyszerű program futtatásakor is előfordulhat, hogy a stack túlcsordul és azt is meg kell oldani, akkor is, ha csak 8 mélységű...
A hozzászólás módosítva: Feb 21, 2017
(#) killbill válasza Wezuv hozzászólására (») Feb 21, 2017 /
 
Idézet:
„Nekem tetszik a megoldás, a korlátai ellenére is.”
Igazabol a semmihez kepset nincsenek korlatai. Maximum vonzatai mint peldaul a processzenkenti stack. De ezt leszamitva sokkal kenyelmesebb programozasi kornyezetet ad, mint ha neked kellene a feladatok kozott elosztani a processzor idot.
Idézet:
„A rekurzív függvényhívásokat, gondolom kerülöd, vagy korlátozod...”
Igen, a rekurzio ehes fajta, de ha tudom, hogy milyen melysegig fog menni, akkor azert saccolhato a fogyasztasa.
Idézet:
„Viszont nem lehetne egy olyan megoldást használni, ami kidobná a processt, ha túllépné a keretét, majd újra indítaná?”
Ha nincs HW-es tamogatasod (MMU), akkor nem lehet. A PIC16-ban hasznalatos SPLIM regiszter sem ad 100%-os biztonsagot, mert a stack-et a magasszintu nyelvek mint a C, nem csak push utasitassal irjak, hanem indirekt cimzessel is, amikor mondjuk a lokalis valtozokat kell elerni a stack-en.

Viszont a processzt ujbol elinditani felesleges, mert ha egyszer tulcsordult a stack-je, akkor ujbol ez lesz, akkor meg minek.

Sajnos ma mar vindozzal is vezerelnek atomreaktort, ugyhogy en mar epitem a betonbunkert. De a komoly rendszerek eseteben valoban erdekes kerdesek ezek az elore meghatarozhatatlan dolgok. Biztos vannak modszerek, amikkel egy adott program memoriaigenyet lehet szamolni, nem tudom. Nekem vannak sw-eim, amik evek ota mennek es soha nem volt veluk semmi akadas, pedig 24/7-ben mennek ezerszam (pl. EXIT lampak Auszrtaliaban).
(#) pajti2 válasza killbill hozzászólására (») Feb 21, 2017 /
 
Vannak mindenféle szolgáltatási lehetőségek és ajánlások kooperatív és preemptív környezethez, és bár nagyon butaságot nem akarok írni, de nem tudok olyan szolgáltatási lehetőségről egyik környezetben sem, hogy "A processz meghívja B processzt". Az elmélet ismeri az interprocessz kommunikációt, küldhető üzenet, de az nem "meghívás". Annak külön mechanizmusa van, ami azzal kezdődik, hogy az adott processznek előbb ki kell lépnie az üzenet aktivvá válásához, és a processz kilépéshez ajánlások tartoznak - mint például hogy kooperatív környezetben a processz kinullázni tartozik a stacket kilépésekor, és csak a heapen tarthat meg statikus elemeket, a stacken nem. Preemptív környezetben van olyan, hogy azokat az ajánlásokat "elavultnak" bélyegezték, és ott maradhat stack szemét is.

Az egy külön történet, hogy pic-nél nincs mmu, meg egy rakás egyéb dolog sem. A processzeket nem lehet majd egymástól garantáltan megvédeni, néhány szolgáltatást nem lehet majd kidolgozni a túlságosan korlátozott erőforrások miatt, és következményként még ajánlások közül is a szigorúbbakat kellene majd betartani a kényelmi lehetőségek hiánya miatt. Nem állítottam, hogy akár kooperatív magból fullextrás implementációt meg lehet majd csinálni pic-re, de azt állítom, hogy korlátozott implementációt nem lehetetlen kivitelezni közös veremmel sem. A preemptive mag az, ahol az jellemzőbben nem tud összejönni az ajánlások és folyamat szervezés elvi szinten eltérő sajátosságai miatt.

A stack mintázat jó ötlet, de valami cpu hardveres támogatás is kellene. Képzelj el folyamatos fejlesztési logisztikában egy harmony féle feketedoboz felhasználást, ahol verziók egymás után következő környezeteiben mindig külön tesztelned kell majd a verem felhasználást a már megírt modulokra is, mert sose tudhatod, hogy ami tegnap még volt valamilyen, holnapra mit művelnek vele a srácok. Minden alkalommal újra végig kell majd szórakozni ugyan azt minden modullal. Vajon szerinted sem agyfrász gondolat az egy kicsit sem? Kellene valami beépíthető védelem, ami garantálja, hogy vagy azért nem történik tévútra futó vezérlés, mert a verem elég nagy volt, vagy azért nem, mert egy cpu irq elkapja azt az eseményt, lejelenti valami debug perifériára, és resetbe rántja a firmware egészét. Talán folyamat elakadni fog majd valahol bizonyos adatok feldolgozása, de legalább adatintegritás sértést nem tud majd elkövetni az elkallódó vezérlés.
A hozzászólás módosítva: Feb 21, 2017
(#) killbill válasza pajti2 hozzászólására (») Feb 21, 2017 /
 
Idézet:
„de nem tudok olyan szolgáltatási lehetőségről egyik környezetben sem, hogy "A processz meghívja B processzt"”
Csak nagyon roviden, mert el kell mennem. En nem mondtam, hogy A processz meghivja B-t. Azt mondtam, hogy A process feladja a CPU-t egy kernel hivassal, es a kernel atadja a vezerlest B-nek. Es viszont. Sem kooperativ, sem preemptiv kernelt nem lehet csinalni egyetlen stack-kel. 20 eve programozok multitask-os kornyezetben, tudom, hogy mi az az IPC, es azt is, hogy hogyan mukodik egy ilyen kernel. Nem kivanok tovabb ezen ragodni.
Idézet:
„Az egy külön történet, hogy pic-nél nincs mmu”
A PIC32-ben speciel van MMU. Igaz, nem tud mindent, ami ide kellene, de van benne.
Idézet:
„Képzelj el folyamatos fejlesztési logisztikában egy harmony féle feketedoboz felhasználást”
Alapbol nem hasznalok masok altal irt kodot, kulonosen nem mikrocsip vagy mikroszoft kodot. Sajnos volt lehetosegem megtapasztalni mindkettot, es koszonom, soha tobbe nem szeretnek ilyesmihez hozzanyulni. Ha hasznalok idegen kodot, azok a batyam altal irt lib-ek. Ezekben megbizom, bar ezekben is elofordul hiba. Viszont a forras rendelkezesre all, hiszen GPL az egesz. Meg mondjuk benne vagyok a fejlesztesben is, van hozzaferesem a repohoz. A kernel is innen van, az egesz C konyvtar, meg meg 2 tonna egyeb hasznos fuggveny. Az olyan valtozoas meg eleg ritka, amitol egy egyszeru fuggveny az eddigi 12 helyett 432 byte stack-et hasznal. Persze az eselye nem nulla, ez igaz. Kulonosen nem a mikrocsipnel...
(#) Droot hozzászólása Feb 21, 2017 / 1
 
Jajj gyerekek ne mindig minden arról szóljon már hogy mindenki a saját dolgát próbálja "megvédeni", majd valaki úgyis mindig betámadja mert sajnos ez van, már azelőtt követtem a fórumot mielőtt beregisztráltam és nagyon régóta ez van! Basszus ez egy fórum! Mindenki a saját tapasztalatait osztja meg! Vannak itt okos emberek (attól még hogy valaki máshogy csinál valamit, vagy furcsát kérdez, lehet higy csak nincs ideje utánajárni más meg könyökből válaszol másban meg lehet hogy sokkal ügyesebb) akiktől nem keveset lehetne tanulni! A sok kóstolgatástól ezek az emberek fognak szépen elhúzni... ahogy egyszer majd én is. Sokatokkal azért jópárszor együtt dolgoztunk, kisegítettük egymást!
Van aki multitaskinget használ HW támogatás nélkül, van aki azt nem találja EGYÉRTELMŰEN az amúgy is ködös, "mikrocsippes" adatlapban hogy reset után a portlábak ki vagy bemenetek? Van aki harmony-val bünteti magát. És akkor? Ha neki ez kell? Ha neki ez a segítség? Biztos nem az hogy betámadjuk, hogy miért nem jó! Mindenkinek más a jó de ne hurrogjuk le egymást hanem inkább segítsük...és motiváljuk egymást! Már én is inkább szívok egy sort minthogy kérdezzek!
A hozzászólás módosítva: Feb 21, 2017
(#) Wezuv válasza killbill hozzászólására (») Feb 22, 2017 /
 
Megértem az idegenkedést a microchip kódoktól, de elég nehezen tudom elképzelni, hogy a harmony-ben felsorakoztatott drivereket meg tudnád írni. Korán sem becsüllek le, de egy HTTP szerver, egy host USB és had ne soroljam, driverek megírása olyan mennyiségű információt és időt igényel, amit nem hiszem, hogy rá lehetne szánni egy életből, főleg akkor nem, ha valami gyorsan kell. Ha a harmony driverek és systemek nem működnének jól záros időn belül, az egyenlő lesz a microchip és a PIC32 sorozat halálával szerintem. Hatalmas erőforrásokat fordítanak a fejlesztésre és láthatóak az eredmények. Igaz, hogy vannak hibák, de ezeket át lehet ugrani saját driverekkel, amik ugyan nem illeszkednek a harmony egészébe teljes kompatibilitással, de a célnak megfelel.

Egyébként most a SYS_TMR -el szívok, mert nem úgy működik, ahogy én gondolom, vagy ahogy a leírásokból én gondolnám. Ezért azon gondolkodom, hogy írok egy sajátot, ami lehet, hogy nem fog együtt működni a többi driverrel, de úgy fog működni, ahogy én akarom. Maga a MHC felülete jól menedzselhetővé teszi a saját kódokat is, nem látok kivetni valót a koncepción, legfeljebb más, mint amit eddig használtam, de könnyen meg lehet szokni a jót. Ha később kiforrja magát az egész, akkor majd nagyon jól lehet támaszkodni rá a fejlesztéseknél. Legalább is most így gondolom. Ha emlékszel, korábban szídtam, mert nem értettem az egész felépítést, szándékot, megvalósítást, de most már másképpen gondolom. De ez is megváltozhat, ha nagyon megszívatna netán. Fejlesztést még nem kezdenék benne, szerencsére most van időm "játszani" vele és majd meglátom mi lesz belőle, de jelenleg jónak tűnik...
A hozzászólás módosítva: Feb 22, 2017
(#) killbill válasza Wezuv hozzászólására (») Feb 22, 2017 /
 
Igazabol en ezt a harmonyt nem ismerem, gozom sincs, hogy ez micsoda, de nem is nagyon erdekel. De ekem eleve az a velemenyem ezekrol a mai IDE-krol, hogy ha mar a programozashoz eger kell, akkor ott valami nincs rendben. HTTP servert mar irtam, USB device-ot, mass storage driver-t szinten. Tehat a PC-n lattad a keszulekem SD kartyajat, es ebben az utolso bitig minden a sajat kodom volt. Ez ARM-en. Nem allitom, hogy meg tudnam irni az altalad emlitetteket, de nem kizart, hogy igen. Persze az ido egy komoly korlat, 10 programozo tobb evi munkajat nehez egyedul uberelni.

PIC-en en is a mikrocsip kodjat hasznaltam a nagyobb falatokhoz, de rengeteg idobe tellt megkeresni benne a hibakat. Javitottam az USB stack-juket, TCP/IP stack-juket, a mass storage drivert es meg par dolgot. De speciel a mikrocsip WiFi moduljaval vagy a mikrocsip kodjaval (sosem derult ki, hogy melyikkel) rengeteg problema volt. Azt vegul ugy oldottuk meg, hogy kihajitottuk a keszulekbol es tettunk bele mas gyartotol WiFi modult. Azota elegedettek a vevok. A modul maga nincs dokumentalva, ezert kenytelen vagy a mikrocsip kodot hasznalni hozza. Csak nem mukodik megbizhatoan. Es hajszal pontosan ugyanazt csinalja a WiFI moduljuk a TCP/IP stack-jukkel hasznalva, mint a Marantz NA6005 network audio lejatszo. Teljesen otletszeruen eldobalja a TCP kapcsolatokat, mikozben ping-elni lehet, tehat maga az alsoszintu WiFi kapcsolat jo. A lejatszoban egy mikrocsip JukeBox nevu valami van, amiben egy dual core 600+ MHz DSP van a WiFi, BT es Ethernet modul mellett. Legalabbis annakidejen ezt olvastam rola, most nem talalom ezeket a reszleteket a weboldalukon. Szoval be kellett vinnem a nappaliba az Ethernetet droton, hogy hasznalni tudjam a keszuleket. Termeszetesen az osszes tobbi eszkoz, laptopok, telefonok, minden tokeletesen mukodik, napokig lehet hibatlanul zenet hallgatni a server-rol WiFi-n keresztul, csak ez a mikrocsippes keszulek nem birkozik meg a feladattal. Es ezt 190.000 magyar forintert kapod meg a boltban...
(#) Wezuv válasza killbill hozzászólására (») Feb 22, 2017 /
 
Nekem sincs jó véleményem róluk, csak reménykedem, hogy javulnia kell a helyzetnek. Meglátjuk...
(#) pajti2 válasza killbill hozzászólására (») Feb 22, 2017 /
 
Bármelyikünk meg tudná írni azokat a drivereket még sokkal jobban is, mint az MC csinálta, ha meglennének a pic32mz doksijai - de nincsenek meg. Éppen a részletes doksik nem publikusak. Várhatóan nem is lesznek.

Kotorásztam lehetéges MC konkurenciák után a barkácsamatőr piacon, és talán a Renesas és az NXP vannak hozzá legjobb pozícióban, de egyenlőre rá se tojnak arra a piacra. Jó ideig csak nyelni lehet majd, és kihozni a harmony-ból a legtöbbet, amit lehet.
A hozzászólás módosítva: Feb 22, 2017
(#) killbill válasza pajti2 hozzászólására (») Feb 22, 2017 /
 
Idézet:
„Kotorásztam lehetéges MC konkurenciák után a barkácsamatőr piacon, és talán a Renesas és az NXP vannak hozzá legjobb pozícióban, de egyenlőre rá se tojnak arra a piacra.”
En NXP-ket hasznalok evek ota, igaz nem eppen a barkacsamator kategoriaban. De abban a kategoriaban is jo lehet. Miert ne? A PIC32 is TQFP tokozasu, sot van koztuk 0.4mm labtavolsagu is. A legtobb NXP is TQFP. A dokumentacio eleg siralmas, de legalabb van. Amit nem ir le az NXP doku, azt a legtobb modul eseteben (DMA, SSP, SD kartya, stb.) meg lehet szerezni az ARM-tol, mivel ezek a modulok az ARM ceg fejlesztesei ugyanugy, mint a processzor mag (ARM7, Cortex-M0, M3). A chip-ekkel vannak neha gondok. Van, hogy egy hiba csak egy ev elteltevel jelenik meg az errataban. Mint pl. az LPC1788 eseteben az Ethernet MII interface-e gyakorlatilag hasznalhatatlan, csak RMII-vel mukodik az Ethernet megbizhatoan. PC-s (ertsd vindoz) sw tamogatasat nem nagyon ismerem. De tudom, hogy van tobb lehetoseg is azoknak, akik ezeket a modern IDE-ket szeretik. Linux-on fejlesztek, egy szovegszerkesztovel (jEdit), GNU toolchain, UNIX utility-k (make es tarsai) es sajat gyartasu programozoval, ami egy FT232 meg egy 74HC125. Ezzel nagyon jol elvagyok, teljesen ingyenes az egesz. Persze oriasi segitseg a batyam fele ARM konyvtar, ami szinten ingyenesen elerheto barki szamara. Azon felul az ST ARM uC-k is eleg biztatoak.
(#) cross51 válasza killbill hozzászólására (») Feb 22, 2017 /
 
Ez már el tér a PIC-től azért off, de hogy említetted az ARM-os MCU-kat esetleg a Silabsos EFM32 esekkel van tapasztalatod? Ha van kíváncsi lennék a véleményedre.
(#) pajti2 válasza killbill hozzászólására (») Feb 22, 2017 /
 
Néztem az NXP doksikat. Nem viszik ám túlzásba a dokumentálást ők se

A bátyád driver könyvtárában akad usb client mass storage protokol filter is?
A hozzászólás módosítva: Feb 22, 2017
(#) killbill válasza cross51 hozzászólására (») Feb 22, 2017 /
 
Nem ismrem oket, nem hasznaltam sosem.
(#) killbill válasza pajti2 hozzászólására (») Feb 22, 2017 /
 
A batyam konyvtaraban nincsenek HW specifikus dolgok. Standarc C konyvtar, csak gyorsabb/kisebb, mint a GNU, teljes double/float konyvtar, gcc support fuggvenyek, amik gyorsabbak, mint az eredeti GNU fuggvenyek, kriptografiai fuggvenyek, (MD5, SHA, RC4, ilyesmik), mindefele bit manipulalo fuggvenyek (leading zero count, swap, ..) meg az emlitett kooperativ kernel. Es talan meg benne van a preemptiv is, nem tudom, de ha benne is van, az csak ARM7-re, mert eredetileg arra irta meg.
(#) pajti2 válasza killbill hozzászólására (») Feb 23, 2017 /
 
Időnként én is elfilozom rajta, hogyan lehetne rendezettebbé és "szabványosabbá" tenni nagyobb lélegzetvételű fejlesztéseket, akár eltérő kódolási stílusú modulokból is. Részemről az ms-dos példája jutott eszembe. Szilárd pont gyanánt szoftveres interrupt vektorok két oldalára felszervezni mind a kiszolgálókat, mind a kiszolgálást kérőket. Az ms-dos remekül elvolt mindenféle kernel szervezettség nélkül is, és abban a szervezettségben a real-time jelleget sem kell feladni.
(#) futlac hozzászólása Márc 3, 2017 /
 
Nulláról a robotokig - PIC Mikrovezérlők III részben szereplő assembly kódban írt programot szeretném használni PIC16F628-hoz. A két első soron kívül még hol kellene változtatni a programban?
A segítséget előre köszönöm: futlac
(#) Wezuv hozzászólása Márc 4, 2017 /
 
Speciális kérdésem lenne MPLAB X (Mplap Harmony Cofiguration) MHC-val kapcsolatban. Olyan fájlt szeretnék létrehozni a generáláskor, ami hasonlóan működik, mint az app.c vagy a main.c. Ezek úgy működnek, hogy ha a kód módosításra kerül bennük, akkor az MHC újbóli generálásakor nem akarja visszaírni az alap generálás szerintire, azaz csak legenerálja egyszer, utána már nem vizsgálja. Nekem csak olyan sikerült, amit minden generáláskor vissza akar írni a *.c.ftl szerinti tartalomra. Ez arra lenne jó, hogy egy alap keretet lehetne feltenni, amit a user tovább tud módosítani. Sokat kerestem, de nem találtam meg a módját, hátha valaki olvasott erről! Köszönöm!
(#) Attila86 hozzászólása Márc 5, 2017 /
 
Nem teljesen ide tartozik, de nem tudom hol lenne jobb helye a kérdésnek:
Összekötöttem SPI-al egy PIC-et és egy MPU9250-et (3 tengelyes giroszkóp, 3 tengelyes gyorsulásmérő és 3 tengelyes magnetométer). Engem igazából a megnetométer (iránytű) része érdekelne, ennek az adatait szeretném lekérni tőle. Itt van az IC adatlapja: Bővebben: Link és a register map: Bővebben: Link
Utóbbi pdf-ben a megnetométer regisztertérképét teljesen külön táblázatban írja (a 47. oldaltól). Ha jól értem akkor az MPU9250-be beleépítettek egy AK8963 nevű IC-t amely külön a magnetométer gyakorlatilag!?
A megnetométer a táblázatában sok olyan regiszter szerepel amelynek azonos címen van az MPU9250 regisztereivel. Például a 0x02 címen az AK8963-ban a "Status 1" nevű regiszter tartózkodik, az MPU9250-ben pedig a "Self test Z gyro" nevű regiszter.
Egyszerűen nem értem, hogyan lehet beszélgetni az IC magnetométer részével? Az MPU9250 részével elvileg tudok beszélgetni mert ha a 0x75-ös címet kiolvasom belőle ("Who I am" regiszter), akkor 0x71-et kapok vissza ahogyan azt az adatlap írja.
A hozzászólás módosítva: Márc 5, 2017
(#) Bakman válasza Attila86 hozzászólására (») Márc 5, 2017 /
 
23. oldal vége, 24. oldal eleje:
Idézet:
„Pass-Through Mode: Allows an external system processor to act as master and directly communicate to the external sensors connected to the auxiliary I2C bus pins (AUX_DA and AUX_CL). In this mode, the auxiliary I2C bus control logic (3rd party sensor interface block) of the MPU-9250 is disabled, and the auxiliary I2C pins AUX_DA and AUX_CL are connected to the main I2C bus through analog switches internally.
Pass-Through mode is useful for configuring the external sensors, or for keeping the MPU-9250 in a low-power mode when only the external sensors are used. In this mode, the system processor can still access MPU-9250 data through the I2C interface. Pass-Through mode is also used to access the AK8963 magnetometer directly from the host. In this configuration the slave address for the AK8963 is 0X0C or 12 decimal.”
A leírás szerint I2C kapcsolat fog kelleni.
(#) Attila86 válasza Bakman hozzászólására (») Márc 5, 2017 1 /
 
Köszönöm! Én ezt a szöveget nem találtam meg, viszont közben az adatlap 21 oldalán lévő blokk diagrammon feltűnt hogy az iránytű az IC-n belül csak az I2C-re van rákötve, az SPI-ra nem. Elég kreténül van kitalálva hogy az IC tud SPI-t is, de akkor gyakorlatilag csak giroszkóp és gyorsulásmérő lehet, iránytű nem.
(#) Attila86 hozzászólása Márc 6, 2017 /
 
Icserny!
Tudsz róla hogy az oldaladon a karakterkódolással van valami probléma? Már hetek óta nem jók az ékezetes karakterek.
(#) Elektro.on válasza Attila86 hozzászólására (») Márc 6, 2017 /
 
Nekem semmi baj nincs az ékezetekkel. Szerintem nálad lehet gond.
Következő: »»   1246 / 1318
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem