Néhány napja, itt a listán, Szilva említette, hogy van még PICkit2 klón kitje. De még olcsób volna, ha egy USB-re köthető PIC-et (PIC18F4550, vagy 2550) kérnél valakitől beégetett bootloaderrel.

Sajnos úgy látom, hogy nem csak a PIC-el vannak problémáid! Szellemi fogyatékos vagy?

Igen, hat anno a VELOOS-t mar nezegettem, erdekes munka. Mindazonaltal a 14 biteseken message (vagy mas neven esemeny vezerelt) RTOS-t sajnos nem lehet megvalositani igy erosen ketseges ennek a felhasznalhatosaga. Tulajdonkepp nem tobb, mint egy interrupt kezelo.

Nagyobb, 18F-es PIC-ekben is inkabb kooperativ utemezot alkamaznak annak egyszerusege es hatekonysaga miatt, igy igazi preemptiv RTOS-al csak ritkan talalkozni amiben kritikus hibak kezelese es dinamikus idokiosztas van parhuzamos szalfuttatasi lehetosegekkel, normalis message queue-val, pipeline-okkal, fifo-kal, mutexekkel es semaphorokkal. Viszont teny, hogy egyre nagyobb teljesitmenyu MCU-k vannak mar a piacon, igy terelodik a fejlesztes a magas szintu nyelvek es az RTOS-ok fele is - adott esetben jelentosen felgyorsithatja a fejlesztes sebesseget es lecsokkentheti a hibalehetosegek szamat is.

Az ilyen megjegyzéseket, erősen sértő mivoltuk miatt, a jövőben légy szíves mellőzni.
Köszönöm.

Csak ismételni tudom magam. Aki nem tud építeni egy halál egyszerű tökéletesen működő áramkört, az felejtse el ezt a témát! Az ajánlott égetők nem "kétségesek", mind kipróbáltak és működnek.
Hiába vesz magának valaki egy PK2-t attól még sík láma marad a témában, és nem fog túljutni a LED villogtatáson önerőből. De nekem 8

Rendben. Ha tudnád mekkora erőfeszítés volt így visszafogni magam, de majd privátban elintézem, ha szükséges.

Szerintem arra jók, hogy az amúgy is korlátos teljesítményt tovább csökkentsék. Egy komoly feladatot nem lehet vele megoldani, mert időzítési és erőforrás problémák lesznek. Én nem tartom sokra az egészet, de majd meglátom mire lesz jó.

Szerintem jó az égető választásod, annak ellenére, hogy ez tényleg egy alap kivitel, viszont minden rendben van vele. Ezzel majd be tudod égetni a PK2 klónt, ha elérsz odáig. Annyit változtass, hogy 7407-et építesz bele, és a programozót ahhoz kell majd beállítani(nem bonyi, majd segítünk).
Viszont a 16F84A helyett inkább egy 18F628A-t ajánlanék, vagy 16F690-es család körül érdemes keresgélni.
Ha a Z80-at kódoltad, akkor nem lesz gond a PIC-el, ez saját tapasztalat.

Thowra, Watt: hozzászólásaitokat töröltem, egyrészt nem tartoztak a témához, másrészt senki ne szítsa a feszültséget, abból csak a baj van.
Aki újrakezdi / folytatja, akár csak egy sorral is, gondolkodás nélkül warn-t kap.

Kedves modik!
A topic címe egyszer már meg lett változtatva, de nem segített, ezért leszedtétek. Természetesen nem a ti hibátok, és nem is a cím hibája.
A baj abból származik, hogy aki keveset keres és olvas, annak fogalma sincs, hogy a megtalált áramkör JDM ill. annak egy klónja. Én írtam egy cikket erről az oldalamon, de azt nem olvashatja mindenki ugyebár(sokszor az sem, akinek direkt ajánlom, vagy ha még is elolvassa, akkor nem biztos, hogy képes felfogni a lényeget. ). Sajnos nincs igazán jó megoldás, és ezzel nem azt akarom mondani, hogy szedjétek le a címet, csak a helyzet kilátástalanságát akartam felvetni.
Köszönöm!

Megértem és elfogadom a törlést is, de szeretném azt kinyílvánítani, hogy a szellemi fogyatékosság az nem szégyen, hanem egy állapot. Kérdésként tettem fel, mivel bármi lehetséges és toleránsnak kell lenni, ha véletlenül igaz...

Köszönöm, hogy átnézted a rajzot, sejtettem, hogy megbízható lesz. A 16F84A mellett azért döntöttem, mert jó pár mintaprogramot találtam hozzá, jól kommentálva, s szerintem jó áron jutottam hozzá (483Ft). Illetve a 12F675 (341Ft), mert az analóg-digitális feldolgozás is nagyon érdekel. Fény és Hőmérő szondákat, meg hasonló detektorokat.
Remélem, mihamarabb beszámolhatok sikereimről.

Mindenkinek további szép napot: Action2K

Azt szoktuk ajánlani, hogy tanuláshoz, kisérletezéshez inkább soklábú chipet érdemes használni, mert nem bonyolultabb kezelni mint a kevés lábút, viszont van sok lába A kevesebb lábúakat inkább már a valamilyen céllal épített áramkörbe szokás használni. Persze nem kötelező, de én szereznék még egy 16F887-et is ezek mellé.

Éppen arra hoztam példát, hogy lehet... Ami nem megy, az a preemptív multitaszking. Az is csak azért nem megy, mert a hardveres stack-et nem lehet kiolvasni.

Remélhetőleg a helyzet rövidesen megváltozik, ugyanis az első negyedévre megígért "megújult" 14 bites PIC-ekben három új regiszter - stack pointer (SPTR), top of stack high (TOSH) és top of stack low (TOSL) - segítségével az immár 16 szintűre bővített stack kezelhető lesz.

A PIC18 esetében valóban elterjedtebb a kooperatív multitaszking, mivel a preemptivitásnak ára van: egy kontextusváltás esetén sokkal több dolgot kell elmenteni, ha a taszkváltás bármikor bekövetkezhet. Többek között a hardveres stack-et is, ehhez pedig túl szűken méri a RAM-ot ezekbe a processzorokba a Microchip. Igaz, a nagyobb példányokhoz (pl. PIC18F8722, PIC18F87J50, PIC18F97J60) illeszthető külső memória is...

Éppen ezért van preemptív RTOS PIC18-hoz is: pl. FreeRTOS, PICOS18 s a uC/OS-II is portolva van PIC18-ra.

{RTOS:}
Természetesen, hiszen végső soron minden program célja ez: a memória megtöltése és az erőforrások felhasználása.... No, de komolyra fordítva: arra azért természetesen ügyelnek a programírók, hogy konfigurálható és skálázható legyen a rendszer, tehát fölöslegesen ne fogyassza a memórát olyan rendszerszolgáltatás, amire nincs szükség az adott alkalmazásnál.

Az is természetes, hogy minden alkalmazás megírható RTOS nélkül is. Az viszont egyáltalán nem biztos, hogy az RTOS nélkül megírt program gazdaságosabban fog bánni az erőforrásokkal (legfeljebb majd máshol, mással történik a pazarlás), vagy hogy gyorabb, hatékonyabb, olcsóbb lesz a program elkészítése és későbbi bővítése vagy karbantartása. Ez tehát ugyanúgy egy megfontolandó döntés, mint az, hogy milyen PIC-et vagy milyen fejlesztőeszközt válasszak az adott feladathoz.

Idézet:
„Az elvüket viszont (bootloader, és USB-UART átalakító) hasznosítani lehetne a PIC-ek esetében is.”

Megmondom őszintén, nyuszi vagyok, és ilyet nem merek az AVR-es topicba írni, de az AVR USB-s megoldásai szvsz egy nagy rakás kaka. Az elmúlt hetekben kicsit beleástam magam a dologba, néztem a "gyári" kódokat és írtam én is egyészen alacsony, bit-szintű rutinkákat. De nagyon nem vagyok tőle elájulva, a PIC18F2550 család a beépített USB SIE-vel fényévekkel korrektebb mind hardver, mind szoftver oldalról. Hogy a teljesség igénye nélkül csak néhány dolgot felsoroljak, ami az AVR-ek USB kezelésében nem tetszik:

- a hardverben a vonalillesztések rendkívül esetlegesek, digitális kimenetekkel valósítják meg a differenciális vonalmeghajtást
- a szoftverben az USB vonalról tölrténő vétel nem differenciális módon, hanem csak az egyik vonal figyelésével történik
- a szoftverben vételi oldalon nincs idő arra, hogy CRC-t számoljon és ezzel ellenőrizze a vonali hibákat
- az adás is és a vétel is olyan szoros szoftverütemezéssel zajlik (gyakorlatilag utasításciklusokra lebontva kell kiszámolni), hogy muszáj a packetek vételekor és adásakor minden más tevékenységet felfüggeszteni, ezáltal fontos eseményekről csúszhat le a firmware
- a szoftverrel megvalósított AVR USB megoldások mind csak low speed kommunikációt tesznek lehetővé, és például a CDC class (amivel az USB/serial átalakítókat megvalósítják ezekben a projectekben) bulk transfert használna, de szabvány szerint a low speed kommunikációban ilyen nincs - emiatt némely oprendszereket, amik a szabványt szigorúan tartják meg kell patchelni vagy hackelni, hogy egyáltalán működjön az AVR-es low speed CDC

Hát hirtelen ennyi jutott eszembe, de még korántsem vagyok profi a dologban, úgyhogy szerintem még fognak kiderülni "érdekes" dolgok.

Nem csak hogy kitem van, de van egy élesztett példányom is összerakva. Ugyanis amikor vettem alkatrészeket pár darab kithez, akkor szortírozás után össze is raktam egyet a kapott alkatrészekből, hogy lássam, minden rendben van-e velük.

Jó, jó, de hogy jön ez most ide? Az általam említett (és nagyrabecsült) projektekben FTDI USB-UART átalakítót használnak.

Ezek helyett egy PIC18(L)F2550, az ATmega helyett pedig egy PIC24HJ vagy dsPIC33FJ többek között azzal az előnnyel kecsegtetne, hogy a PIC18(L)F2550 az USB-soros konverzió mellett a programozás és a debugolás funkcióját is elláthatná. Hasonlóan ahhoz, ahogy az Explorer 16 kártyán a PIC18LF4550 csinálja, ha a megfelelő szoftvert rátölti az emberfia. Csak ez utóbbiban nem UART, hanem SPI összeköttetés van a kártyán belül...

Na, abbol a mondatombol lemaradt a MAS szo... epp azt akartam irni esemeny vezereltet lehet, de sem preemptiv, sem kooperativ utemezot nem lehet mivel ahogy irod nincs stack kezeles.

Az Enhanced-MidRange-et mar en is nezegettem, es nagyon tetszik! Nemcsak a stack kezelese jo annak, de sokmindent valtoztattak amitol jelentosen gyorsul a szoftver vegrehajtasi sebesseg, foleg ha magas szintu nyelveken tortenik a fejlesztes.

Amugy watt-nak igaza van abban, hogy eroforras pazarlas valamilyen szinten, en megertem a gondolkodas modjat, en is szeretem faragni a biteket es cipokanallal betolteni a firmware-t a feladatra alkalmatlannak itelt MCU-ba. De valoban ezek a magasabb szintu absztrakciok egyszerubbe teszik a szoftver tervezeset es mivel jonehany dolgot levesz a vallunkrol az OS ill egy magas szintu nyelv ezert kisebb az eselye a hibalehetosegnek is.

Ok, lehet, hogy nem volt jó a "címzett", és nem is konkrétan arra a projektre utaltam, mert azt nem is ismerem igazán. Viszont éppen az AVR-re írt szoftveres USB CDC cuccokat néztem a minap, amit egy sor projektben (többek között AVR-re épülő ISP programozókban is) előszeretettel használnak és ezt juttatta eszembe a felvetésed. Talán nem árt, ha a PIC-esek tábora is tudja, hogy a 18F2550-es családban elérhető USB-s lehetőségek tulajdonképpen mennyire korrektek.

Bocsi ,hogy felteszem ezt a kérdést: tönkremegy a PIC 16f628 A attól , hogy a kvarcot 22pF helyett 22nF dal kötöttem testre? ( a boltos csaj elnézte, vagy elértette, én meg nem néztem meg.)

Nem megy tönkre, egyszerűen nem rezeg be a kvarc. Csupán ennyi történik.

A hőmérős kiherélt asm kódot nem felejtettem el, csak a fiam megkapta a régi gépem, azon van, és most már nem megyek le bekapcsolni a gépet, mert alszik a gyerek. De holnap délután felküldöm.

Igen, a kihagyott szó miatt másként értettem...
Még egyet pontosítanék: kooperatív ütemezőt természetesen lehet csinálni, sőt, a Salvo (kereskedelmi), és az OSA (free) pont ezt csinálja. Ha belegondolsz: itt nem kell menteni a stack-et, hiszen a taszkok nem lesznek meglepetésszerűen félbeszakitva.

Köszi, akkor tovább keresem a hibát.Vagyis a Wand clock ( propell clock távirányitót építem) . Nem rezeg az oszci , már próbáltam legalább hat kristállyal ,rezonátorral.És persze 10- től 56 pF kondicserékkel.

Nyilvan ez is attol fug hogyan van a rendszer kialakitva. Amit eddig lattam olyan volt, hogy minden ami megakasztotta volna a folyamatot adaja a vezerlest - pl Win31 vagy a regi MacOS a 9-esig bezarolag. Tehat ha egy varakozasi fuggvenyt meghiv, hogy varjon 3 mp-et akkor az nem all ott 3 mp-ig, hanem addig atkapcsol mas taszkokra es mikor letelt a 3 mp akkor ujra aktv taszkka valik. Igy hirtelen nem tudom hogyan lehetne ezt a problemat megoldani, hacsak nem szoftveresn megvalositott stack-kel ill ha nem reentrans ill multi threades akkor elegendo egy fix RAM terulet valami pseudo stack szeru megoldassal. Tehat a varakozo fuggvenynel beszur egy olyat, hogy a visszateresi cimet manualisan letarolja valahol (PCLATH+PCL), majd mikor vissza kell terni akkor onnan szedi ki az OS - persze ugyanigy az egesz contextet oda teszi. Hmm, eddig erre nem is gondoltam Bocs, hogy hangosan gondolkodom

Tudom, hogy viccesen írtad, de azért ez akkor sem igaz. Egy program a cél érdekében kihasználja az erőforrásokat. Ezzel szemben egy oprendszer úgy használ erőforrást, hogy közben nem a célt szolgálja, hanem a célt szolgáló programok futását.
Ezt a tevékenység csak úgy fér bele a képbe, ha jelentősen több az erőforrás a szükségesnél.
Aztán ahogy növekszik az erőforrás az eszközök fejlődésével, úgy egyre jobban hízik az oprendszer is, elég csak a PC-kre gondolni. Ördögi kör. El lehet képzelni mit tudna egy mai PC, ha az XT-k programozási fogásaival fejlesztenének!


Nem csak a memória a szűkös. Egy oprendszer a folyamatos management miatt jelentős időt elvesz a programoktól. Én ezt tartom pazarlásnak.

Bevallom nem próbáltam még egyet se, de ígérem ha lesz időm megnézem mit lehet velük kezdeni és mennyi időt vesznek el a programtól.

Erre mondtam, hogy a nem RTOS-sal készült programoknál is elveszíted azt az időt. Hiszen pl.a státuszgépes megoldásnál is le kell tárolni, hogy az egyes folyamatok hol tartanak, aztán folytatásnál meg kell nézni, hogy most akkor hol folytassuk, egyszóval eben guba...

Egyébként azt, hogy 10-20 miliszekundumos időszeletenként a taszkváltásra "elpazarlunk " párszáz utasításciklust (ami frekvenciától függően 0,4 - 0,04 ms), megfizethető ár azért, hogy a státuszgép nyűgjeitől megszabaduljunk. S kérdés, hogy egy olyan program, mint pl. a PICDEM HPC Explorer kártya demója nem pazarol-e el kétszer (vagy töbször) ennyi időt a millió if utasításával és a státuszt tároló változók tojózásával? S akkor az még nem is preemptív rendszer...

Nem vitatom, hogy oprendszer nélkül is lehet rossz programot írni!

Itt igazandibol szerintem arrol van szo, hogy az OS azert csinal is valamit, nem csak malmozik Fontos szerepe lehet a dinamikus eroforras kezelesben is, szinkronizalasban is, es ugy altalaban az aszinkron esemenyek / folyamatok kezeleseben. Ha nincs OS ezeket mind "kezzel" kellene megvalositani, ami ugyanugy elvesz eroforrasokat az "igazi feladat" elol.

Itt a kerdes inkabb az, hogy mennyire altalanosan vannak ezek a rutinok megirva egy RTOS eseteben - ugye egy celspecifikus megoldas mindig jobban kihasznalja az eroforrasokat mint egy olyan ami "minden eshetosegre" fel van keszitve. A masik resz amit figyelembe lehet venni, hogy ha ezeket mindig minden alkalommal a fejlesztonek kellene megirnia - ugye, hogy a celnak legyen specifikalva - akkor mennyi idot veszit el a fejlesztes soran ill. mekkora hibalehetoseggel kell ilyenkor szamolni, szemben a mar tobbezer felhasznalo altal egyenkent tobb tiz vagy szaz projecten tesztelt megoldassal.

Köszönöm, ezt jól megfogalmaztad! Én ezt úgy szoktam a mindennapok dolgaira vetíteni, hogy az ami mindenre jó, nem jó semmire.