Hát ez sem segített, hiába küldök reset parancsot.

Potyo az előző oldalon a kódba belepillantottál?

Az USB CDC mellett próbáltam nem megszakításosban megírni a progit, de sokat hibázott. Még így is gond van, amikor enumerál(milyen szép szó! ), mert eközben többször előfordul, hogy az 50K-val folyó adatcsere az RS485 vonalon sérül(Természetesen nem huzogatja az ember állandóan ki-be az USB-s dugót, de akkor is)! USART low megszakításban van, mert különben meg az USB nem képes bedetektálni(az High-ben van)! Van hibás vételt számláló ciklus a vétel lekezelésénél, ami alaphelyzetbe állítja a kommunikáció azon részét, így nincs nagy gond.

Nem látom be egyébként, hogy nem megszakításos kezelésnél jobban áttekinthető lenne a folyamat. Ahol nincs időkritikus rész az USART kezelés mellett, ott nem feltétlenül szükséges, de ott is azt használom, mert nagyon kényelmes. Gyakorlatilag azt csinálok a megadott számú bájt beérkezéséig, amit akarok. A bájt letárolása nagyon kicsi idő, mivel a megszakításkor a bájt már az USART bufferben van. Tehát csak annyi, hogy letárol RAM-ba, számláló növel, ellenőriz, hogy elérte-e a megfelelő értéket, majd kilép. Ha négyszögjellel ábrázolnám az idő arányokat, akkor lekezeléséhez szükséges idő csak egy tüske lenne a két bájt beérkezése között eltelt időhöz képest, igen nagy távolságokban.

Egyébként nekem a legnagyobb gondot az okozta, hogy egy félig átjött csomag esetében, hogyan vegyem észre időben, hogy nem jött meg amit vártam.
Nálam a kommunikációt a Központ indítja az a Master(9bites adás, 8bites vétel). Egy fpPollinot küld a soron következő Slave-nek. A megcímzett Slave vagy fpPollinggal válaszol(8bites adás, 9bites vétel), vagy ha van várakozó kérése, akkor azt küldi el. Ez a fej szintű kommunikációs adatcsere 10bájtba befér, amiben a CRC-is benne van(igaz jelenleg a CRC még nincs lekezelve).
A Központ fpPolling csomag úgy néz ki, hogy Cím, fpPolling, Nyugta ha van, néhány tartalék bájt, CRC, fpPoll_Vége. A CÍM és az fpPoll_Vége esetében a 9.bit 1. Minden Slave veszi az adást(mind a 10bájtot). Az első 9.bit megszakítást okoz náluk, az utolsó visszont nem. Az utolsó 9.bit jel állítja vissza náluk a 9.bitre való megszakítást. Így az esetleges Master-megcímzett Slave közötti további adatforgalomra érzéketlenek maradnak.

Az fpPollingra az EgyszerűSlave válasz csomag úgy néz ki, hogy Cím(saját címe), fpPolling, STATUS1, STATUS2, MértHőfok, HőfokSP, Néhány tartalék bájt, CRC.
A válasz mindig 8 bites és szintén 10bájtos(Slave nem tud címezni, csak kivételes esetben pl. PC_USB_MMC_RS485 panel a TFT panel felé, de ahhoz előtte megszakításban(INT1) vonalat kell kérnie a Központtól).

A Központ természetesen indíthat nem fpPolling paranccsal is adatforgalmat(Adatlekérés, kapcsolók állapotának változtatása, alapjelek átküldése stb.), és a Slave is válaszolhat nem fpPollinggal. Az fpPolling akkor megy ki, ha nincs más esemény, és csak a Slavek állapotát akarom lekérdezni. Esetleg még annyi, hogy a soros vonalon semmiféle biztonsági adat nem fut, a biztonsági érzékelők mind közvetlenül vezetékkel vannak bekötve a Központba. Nem bízom annyira a soros porban. Viszont pl. a szürkület érzékelő, kinti hőfok, kinti kapunyitó, szoba Slavek, Cirkó vezérlő, Óra kijelzők, TFT panel stb, mind az RS485 szálon lógnak, sőt kis tápigény esetén az UTP két-két szálán megy a 12V is. Lassan összeáll a rendszer... Jó móka!

Épp ezt akartam írni, hogyha nem szükséges, akkor én nem eröltetem a megszakításokat. Csak olyannál használom, ahol fontos, hogy gyorsan le legyen az esemény reagálva. Persze ez a főprogramtól is függ, de kijelző multiplexelése, vagy USART nem kényes a kiszolgálásra. Eleve két bájt várakozhat az RCREG-ben, és még a harmadik fogadása is folyamatban lehet.

Jah, ez picit sablonos lett, pc és pic között oké, de rs485-ön még vannak címek is. Kisebb eltérések vannak még, mikor-mit csinálok, de az alapséma az előbbi szokott lenni.

A putcUSART után még meg kéne várni, míg kimegy az adat, aztán lekapcsolni az adást.

Oh, hát én teljesen másképp oldom meg ezeket.

Nem használok megszakításokat szinte soha. Ez most sokkoló lehet sokaknak, de ha megnéztek egy USB fw-t, akkor ott sincs, mégis sokmindenre odafigyelnek. Általában kézbentarthatóbb progikat lehet írni megszakítások nélkül. A perifériákat felkonfigurálom és csak a megszakításjelző (IF) biteket figyelem. (polling) Ennek az az előnye, hogy majd én szólok, ha kiszolgálható a megszakítás, nem magától ugrik oda, ráadásul a lekérdezés sorrendje meghatározza a prioritást is. Kicsit más szemléletet igyénel ez a programozási stílus...

Sych byteal kezdem az adást, 0x55, utána jön CMD byte, ez általában 1db, max 2, de ez fix, utána paraméterek száma PARAMCOUNT, utána paramcount számú paraméter, utána datacout, és utána datacount számú data byte, végén checksum. Elég precizen ki lehet számítani, hogy mennyi idő alatt kell beérkezni az adatoknak, hiszen asszinkron kommunikáció, tehát elindítok egy timer és a bejövő adatokat figyelő ciklusban figyelem a timer IF bitjét is. Ha bebillen, akkor gáz van.

Tömören ennyi.

Egyetértünk!
NickE megmondhatja a miértet is...

Én a második verziót preferálom. Az elsőben ha véletlenül nem jön meg az adat, akkor ottragad a program. Persze ez kivédhető, de egyszerűbb a megszakítási rutinban egy-egy static változóban tárolni, hogy hány bájtot várunk és hány jött eddig. Ha a kettő kiegyenlítődik, akkor megvan az összes adat, elvégezzük a megfelelő műveletet, és nullázzuk a változókat.


Az említett kódban a két felső sort meg kellene cserélni (vagy a felsőt átmásolni a második alá is). De hogy miért, azt nem árulom el.

Na szo..

Az egyik verzióban a megszakítás után nem lépek ki a lekezelésből, hanem megvárom a pl. 10bájtot(előre tudom mindig mekkora csomag fog jönni), ezeket letárolom(RAM), majd beállítok egy jelzőt, hogy kész a vétel és kilépek a lekezelő rutinból

A másik, hogy veszek egy bájtot, növelek egy számlálót, és kilépek a megszakításból. Várom a következő bájt beérkezését követő megszakítást és ezt ismétlem. Amikor a számláló eléri a 10-et(vagy a várt bájtak megfelelő számosságot), akkor beállítom a vétel kész jelzőt.

Ez utóbbit azért tartom jobbnak, mert két bájt beékezése között rengeteg gépiciklus lefuthat, ellenben az első verzióval, ahol a 10, vagy több(64) adat beérkezése alatt a pogram fő szál megáll.

Van esetleg valami más megközelítés?


Lenne egy találós kérdésem is:
Mi a hiba ebben a kódrészletben?



Az Adás és Vétel vonalak egy RS485 vonalmeghajtó IC engedélyező lábait vezérlik.
A kódrészlet egy jelsorozat utolsó karakterét mutatja.
Ezzel szívtam néhány órát, mert nem akart menni a kommunikáció. (Persze így kiemelve sokkal egyszerűbb, nekem több száz sorban kellett megtalálnom! )

Így mikrokontrollerrel még sosem csináltam,de kisgépek buszára lógatva simán lehet írni ezeket a tokokat,(nem kell epromégető)..csak sebesség gondra tudok tippelni ezalapján.

Igaz,ott is 1Mhz-es a buszsebesség,pontosabban két MHz-nek felel meg,mert az 1Mhz-es órajel mindkét félperiódusa egy teljes buszciklus.

Az első a video chip olvasása (vagy ram frissítése),a második a CPU buszciklusa.

Viszont ott a vezérlőjelek és buszvezetékek tekintetében _egyszerre_ történnek a dolgok,vagy legalábbis nagyon gyorsan!

Nem tellik el 20-30ns amig a CS aktív lesz a címvonalak beállása után,gyakorlatilag a címdekóder késleltetése korlátozza csak a CS aktiválódását....ez 10-15ns..

Az RW pedig már a meghajtott címvonalakkal egyidőben azonnal L szintű,a buszciklus első pár nanoszekundumától,ha a CPU írni szeretne az adott címre.

Mindeféle hangkártya varázslatnál egyszerűbb,ha "ciklikussá" teszem a folyamatot,tehát a PIC végtelen ciklusban ismétli a műveletet.
Akkor a 4csatornás szkópon a valódi időket látom mind a 4jelre,hasonlóan mint egy logikai analizátoron.

(igaz csak 4 jelet tudok figyelni egyszerre és csak az egyikre tudok indítani,bonyolult feltételekre csak nehezen,(esetleg külső logikával)).

Köszi!
Az előző oldal alján megtalálod a kódot.

Igen, küldj. Ha nem kell, akkor sem árt.

Úgy nézem én is, hogy így kellene csinálni.

Az adatlap alapján nem kell. Közben eszembe jutott, hogy amit az előbb írtam, az csak a törlésre igaz (adatlapban Sector Erase).


Esetleg ha megmutatod a kódot, akkor talán többet tudunk segíteni.

ne kímélj

Flash-nál szoktak olyat csinálni, hogy egyszerre egy meghatározott blokknyi adatot ír, nem bájtonként, mint az eeprom. Ebből adódik a flash alapú adattárolók jelentős írási sebessége az eepromhoz képest. Még nem néztem bele az adatlapba, de lehet, hogy a te memóriád is arra vár, hogy elküldd neki az egy blokknyi adatot, és csak azután rögzíti, amit kapott.

Végzek, de hatástalan, marad a tartalom. Ha Willemmel kitörlöm (úgy megy a törlés), de a PIC -el akkor sem tudom írni.

Abban biztos vagyok hogy az időzítések rendben vannak, 100ns egy utasítás ciklus, vezetékek rövidebbek mint 3cm, szkóppal (bár nem tárolós) nézve a PIC is tudja kellő sebességgel rángatni a lábait.

De abban is biztos vagyok, hogy nem értem a FLASH memória kezelését, és különbségeit egy EEPROM -hoz képest.

Ha egy byte-ot írok csak, (értsd: elkezdek egy írást, ugye a 4.táblázat szerint: 555 címre: AA ; 2AA címre: 55 ; 555 címre A0 ; és az írni kívánt címre : az oda való adat.) és itt abbahagyom az írást, majd kis idő elteltével olvasva, vissza kéne kapnom a beírt adatot?
Vagy egy egész szektoron végig kéne így mennem, és csak a végén rögzül az adat?

Érdekelne, hogy milyen elvi folyamatot használtok a soros porti adatok megszakításos vételénél(részletezve, de nem kóddal)! Én kétfélét is(egy jót, meg egy jobbat. ), de igazából lehet, hogy van még más elképzelés is!
Jó lenne kristályosítani a dolgot!
Ha valaki partner, akkor leírom a módszereket...

Az írás előtt elvégzel egy Sector Erase-t(vagy Chip Erase)?

Egyébként ez olyan bonyolult kérdés, hogy nagyon nagy szerencsédnek kell lenni, hogy mi megtaláljuk a hibát. Egy ilyen progit szisztematikusan kell felépíteni, és nagyon jól jön egy tárolós szkóp, vagy egy logikai analizátor. Ha nincs más én azt szoktam ,hogy leviszem az átviteli sebességet 1KHz tartományba, és felveszem a PC hangkártyájával, majd a SounFoge-val megjelenítem és akkor ki szokott derülni, hogy nem jól időzítek, vagy valami kimarad. Ez baromi időigényes és idegölő munka, ezért készülj fel rá nagy lelki nyugalommal!

"The reset command may be written between the sequence
cycles in a program command sequence
before programming begins."

Jól értem hogy programozás előtt küldjek egy reset parancsot?

Itt az adatlap:
http://www.amd.com/us-en/assets/content ... _00_c4.pdf

A 9. ábra szerint írtam a programrészletet, a fölötte lévő táblázatban szereplő idők is teljesítva vannak. A 4. táblázat szerint elküldöm az ott megadott címekre a parancsokat.

A kódvédelem nem szivathat? A Willem-ben a kódvédelemhez csak a Device fülön a "Temporary Sector Unprotect" pipa tartozik?

Köszi hogy foglalkozol a kérdéssel!

A fenti programrész csak egyszer fut le, én indítom kívüről tehát a tápfesz. megjelenésétől is elég távol van időben. Azóta többször kerestem az adatlapban a nekem szóló részt, de elég szegényes az angol tudásom. Valamit az alapoknál rosszul csinálok, vagy nem értek valamit, de még mindig nem megy.

Ez így tutira nem jó!
Az írás vagy ezerszer lassabb mint az olvasás,egy byte olvasása korszerű flash-ból nanoszekundumokig,(már régi epromból is volt 70nanós!) egy byte programozása inkább miliszekundumokig tart!
Az egy dolog,hogy azt a chip maga időzíti,nem kell már kötött idejű meg ismételt PGM impulzus mint a régi epromnak,de attól még elájulhat az egész folyamat,ha folyton újabb írást indítanak parancsok beírkálásval még mielőtt az előző végetért volna.

Minden eszköznek meg van adva az adatlapjában maximális sebessége, ill. a vezérlő vonalakhoz tartozó időzítések! Ezt neked kell kiböngészni, és megoldani a programban a megfelelő várakozásokat. Lehet, hogy megy 2,5MHz-el is az eeprom adatforgalma(?), de hogy a feléledése és a írás időtartama az sokkal hosszabb idő, az biztos. Tehát adatlapot elő és megkeresni, hogy hol kell várakozni! Tutira benne van!

off:
Mert még hol máshol?[/quote]
OFF:
Gondoltam ez elég amatőr kérdés, úgyhogy itt:
"Amatőr" kérdések
Ha gondolod törölheted is, ne legyen két helyen. Köszi!

ON:
Az adatlap ír valami olyasmit hogy figyelnem kéne pár bitet DQ0- DQ7 közül, mert bebillennek ha a programozás/törlés fázis elért valameddig, de kb. ennyit értek belőle. És ez elég kevés.

Az olvasás megy tökéletesen, hibátlanul, PLCC tokok a nyákon, a leghosszabb vezeték sincs 3cm, szerintem nem ilyesmi baj lesz. Inkább a flash -ra kéne várnom írás közben, csak nem tudom mikor, mire, mennyit?
Ja látom a végén Te is ezt írtad..

Első blikre azt mondanám, hogy 10MHz-es tempóval nem fog menni a vezérlő vonalak aktiválása, valami időzítést be kell iktass. Ez lehet, hogy az égetés elkészülésére való várakozásra is vonatkozik, bár nem bújtam annyira bele a programodba...

off:
Mert még hol máshol?

Sziasztok!

Akkor megpróbálom itt is..
Új, bolti AM29F010B -90 memóriát nyüstölök, PIC-el szeretném írni, olvasni.
Willem-el megy az írás olvasás is tökéletesen, de PIC-el csak olvasni tudom. Olvasgatom az adatlapját, csak épp nem sokat értek belőle..
Így próbálom írni, hátha talál valaki benne hibát: 18F6680 10Mhz 4xPLL


Előre is köszi a segítséget!

Nem hinném, hogy a 16 és a 32 bites kontrollerek a 8 bites fejlesztésének és főleg eladásának rovására mennének. Inkább arról van szó, hogy a konkurencia is rendelkezik 32 bites kontrollerekkel, és a Microchip ebből a kalácsból is szeretne egy szeletet. Pl. most is van egy néhány "Future Product" a 16F és a 18F sorozatban is.

Teljes mértékben kizárt dolognak tartom, hogy a PIC16/PIC18 családok gyártását belátható időn belül leállítsák. A Microchip 8 bites kontrollerekből sokkal többet ad el, mint a nagyobbakból és ez szerintem így is marad. (gondolom)

Az idő halad,a technika halad.
Pic 16C84-nél,4Mhz órajelnél,2K ROM-nál is válthattak volna valami tökmásra.
Nem sajnálnád utólag,így,hogy tudod hova fejlesztették tovább,ami "kimaradt" volna?
4-5év és a legtutibb 18Fxxx-re is úgy fogunk nézni,mint most a 16c84-re..érted..
Ha egy fejlesztési vonalnak vége,ez hónapokban mérhető,amíg kezd elavulni.
Én csak abban reménykedek,észretérnek előbb utóbb,és kihozzák legkésőbb akkor a 19FXXX vagy 20Fxxx családot,32bites képességekkel,80-100Mhz órajellel,több mint 100k ram-al,rom-al,de a hagyományos architektúrára építve.
Közben megint az lesz,az atmel jó sok kezdő és hobbi felhasználót elcsábít,ahogy egyszer 96-97körül már ez volt a helyzet..

Akkor lenne igazad, ha nem gyártanák tovább a trabantot és a belőlük kifejlesztett tuningolt gépsárkányokat. De igen, csak mellette elkezdtek gyártani kamionokat is.
Egyébként a személyeskedés dologban igazad van, elnézést kérek!

A vitával semmi gond,a személyeskedés nem hiányzik.
Úgylátszik a microchip megint arra kacsintgat,hogy "professzionalista" chipgyártó legyen,a low-end feladatok helyett a legalább közepes teljesítményigényű feladatokat szolgálja ki,az alsó vonal fejlesztését pedig befagyasztja ott ahol most tart.
Ezzel egyidőben egy tollvonással eldobja a kezdetektől bevált architektúrát,amit pedig sikeresen lehetne tovább bővíteni,ahogy lehetett eddig is,minden gond nélkül.
Kár volna érte,de nem nagyon látszik más forgatókönyv jelenleg,mint ez.

Kicsit olyan a helyzet,mint amikor egy cég elkezd trabantot gyártani,majd megtartva a kezelőszerveket és az eredeti konstukció minden puritánságát,eljut a turbós motorokig,komoly teljesítményekig,peres gumikig,sok extráig.
Hirtelen itt félbehagyja,és tök idegen licensz alapján óriási kamionokat kezd gyártani.
Ami nagyon jó,lehet kamionnal is járni végülis,csak nem valószínű,hogy mezei sofőrünk megtanul pótkocsist vezetni,inkább keres másik gyártót,ha kelletlenül is.

Na ezt sem gondoltam volna, hogy egy hír ilyen vitát tud elindítani

Nem tőled éreztem, és csak egy érzés csupán.
Biztosan rossz beidegződés...


Én már csak ilyen egyszerűnek látom a világot!


Korrekt! 24F-et is csak a TFT-m miatt vettem...

Ismét érdekes következtetést vontál le. Nem tudom, honnan vetted azt, hogy fáj valakinek, hogy a Microchip komoly procit dob piacra, vagy hogy kifogásunk lenne az új maggal kapcsolatban? Annyit jegyeztünk meg, hogy nem könnyű áttérni szerintünk, amit Te vitatsz. Majd idővel kiderül. Egyébként én nagyon is szeretem a PIC-eket és örülök az új PIC32-nek is. Áruk is jó, beszerzésük is könnyű lesz, égetőm is van. Igaz, a PIC18 és C18 páros tökéletesen megfelel a szokványos bonyolultságú feladataimhoz, így a jövőben is főként ezeket fogom használni. De majd igyekszem megtanulni az újabb cuccokat is, néha jól jön...

Néha olvasgatok más adatlapokat is kiváncsiságból, hogy lássam, mások hogy lássam más procik megoldásait is, de a PIC-ek tetszenek a legjobban nekem.

NickE
Szerintem itt nem kéne ilyen mélyre ásni. Felhasználási szempontból majdnem lényegtelen, hogy milyen "atomokból", és hogy épül fel a mag. A paraméterek egyértelműek, használni, és kihasználni kell csak tudni. Ahogy írod az F24-esek is új alapokra épültek, még is simát át lehet rájuk állni. Így van és lesz ez ezekkel is. Nem látok túl nagy kihívást.
Engem ez a hasonlítgatás tud inkább kiakasztani, mikor ehhez meg ahhoz, meg ettől-attól loptak, meg ilyenek. Fáj valakinek, hogy végre egy komoly proci látott napvilágot a Microchiptől? Nem tetszik a nexus, ahogy erről szó esik.

Egyébként valóban durva, hogy gyakorlatilag egy új nyelvet toltak elénk, de így voltam ezzel a C-nél is, pedig akkor PIC-et nem is váltottam! Ez a CALL helyett jal, meg RETURN helyett jr $ra kicsit fura, de hát ez van.

Én is belefolyok a vitába, kivételesen MotoHackernek igazat adva. Erre tényleg kíváncsi lennék, hogy miből vontad le azt a következtetést, hogy "... az adatlapból semmi olyan nem jön fel, ami az előző PIC-ekhez képest gondot okozna..."?

Persze ez dicséretes, hogy ilyen könnyen veszed az akadályt, de itt tényleg nem arról van szó, hogy PIC16-ról PIC18-ra váltunk. Szerintem is olyan, mintha teljesen új procit tanulnánk, márcsak azért is, mert ez teljesen új proci.
Persze lehet úgy is gondolkozni, hogy oh, hát itt is van mov, meg ott is, de ez komolytalan. Az a kijelentés is kicsit durva, hogy ez is egy RISC proci. Az évtizedekkel ezelőtt volt, hogy voltak RISC és CISC procik. Ma már minden gyártó kombinálja a kettőt RISC felé tolódva. (vannak kivételek, de legalább 90%-ban igaz a fenti állítás, különösen a gyakorlatban előforduló procik esetén) A mai 8051 alapú procik/kontrollerek is RISC-es megvalósítású procik, bármennyire CISC multúak. Egyébként meg ez inkább chiptervezési szempontból érdekes (meg sebesség miatt), gyakorlatilag a felhasználónak tökmindegy, hogyan oldották meg az prociban pl. a szorzást.

Az ARM -ről pedig annyit, hogy ugyebár Potyo ezt arra hozta fel, hogy mintahogy sok más gyártó, (Philips(NXP), ST, Samsung, Atmel, Texas, Motorola(Freescale) és még sokan ARM magot vesznek, most ugyanúgy a Microchip is vett egy magot a MIPS-től, ami egy másik szintén piacvezető cucc. Annyiban jogos a párhuzam is, hogy a nagy cégek figyelik egymást és ellopják a jó ötleteket egymástól. Ez igaz erre a két gyártóra is, de ettől függetlenül még jelentős difik is vannak a kettő között. Viszont a klasszikus Microchip architektúrától jelentősen eltérnek. Mondjuk az más kérdés, hogy a PIC24 is jelentősen eltér a PIC16/18 vonaltól. Ezen nem kell csodálkozni, fejlődik a világ, de azt mondani, hogy ez is RISC az is RISC, tehát egyformák kicsit vicces.
Sok problémát teljesen másképp kell megközelíteni a 2 procival történő megoldás esetén. Olyan kicsit, mint a DOS-os struktúrált és a Windowsos OOP programozás. Bár vannak akik Windows alatt is DOS-osan akarnak programozni. Nem egyszerű az egyik szemléletről a másikra áttérni.

Amit az egyiken if-then-else -ek százaival oldunk meg azt a másikon try-except-finally -val. És mondjuk itt jön ki az, hogy nem csak, sőt nem elsősorban a MIPS számít. És most egyet emeltem ki a 100 apró vagy nagyobb különbség közül, ami miatt más a két proci. Ilyan apróságokon múlik az, hogy a 6-800 MHz-en futó Motorola processzor miért végez el nagyságrenddel gyorsabban bizony műveleteket, mint a 2GHz feletti Intel. Ha megnézed, egy ARM vagy MIPS adatlap többet ír exceptionokról, trap-ekről. vektorokról, stack kezelésről, ..., vagy ami még nagyon fontos, a ciklusokról-ahol (sok kis ugrás és rövid utasításblokk van és ezt ugyebár sokszor végre kell hajtani, ezért cikulus), feltételesen de ugrás nélkül végrehajtott utasításokról, mint MIPS-ről. Azért, mert ezek fontosabbak. Csak nem akarok regényt írni, meg egyelőre még nem programoztam én (se) MIPS alapú procit, de azért van némi rálátásom a témára. De vannak segítségek, az MPLAB már ismert, az ICD2 tudja őket égetni, valószínűleg a PICkit2 is fogja tudni. Szóval van mit tanulni.

Ahhoz képest, hogy a korábbi kérdéseidből az derült számomra ki, hogy nem ismered kellőképpen a PIC-eket, most elég magabiztosan jelented ki, hogy semmi köze az elődeihez! Hogy ezt mi a frászból szűröd le nem tudom, de legyen neked! Nekem az adatlapból semmi olyan nem jön fel, ami az előző PIC-ekhez képest gondot okozna, valamint nem látok semmi olyan dolgot, amitől ezek ARM, vagy bármi más maghoz hasonlítanának! Talán nem szabad olyan utasításokat használni(névben!!), amit már mások is használnak? Ez még mindig RISC, semmi változás, csak több utasítás(124) és 32 biten. Na és? Örülök neki, mert egy utasítás csoporton belül rengeteg verzió van, ami csak könnyíti a prgogramozást, és hatékonyabban tud fordítani a C fordító is! De hogy ettől hogyan lesz rögtön ARM? Az ARM is 1,5szer órajel MIPS-es?. Na de hagyjuk...

Na majd este leülök és tervezek egy olyan magot, hogy a Microchip, Atmel, Texas, Motorola de még az Intel is tőlem fogja venni a magot. Mindenki NickE magot akar majd integrálni. Csak előtte elolvasom még a Silicon-level design című könyvet. LOL

Nemtudom,de legalábbis úgy fogalmaztál.
Mindenesetre leszögezhetjük:a PIC32-nek a PIC megszokott architektúrájához köze nincsen,ez inkább egy ARM proci szerűség,a durvábbik fajtából.
PIC-nek hívják,azonos fejleszőeszközbe integrálták a fejlesztőkörnyezetet,de itt a kapcsolata az eddigi PIC mikrokontrollerekkel véget is ér.

Mert szerinted én úgy alkottam véleményt, hogy ezt nem tettem meg?

Ha elolvasod a kapcsolódó datasheet-eket,akkor nem hinni,hanem tudni fogod,mekkora az "eltérés".

Nem hiszem, hogy akkora eltérés lehet, hogy az bármilyen gondot okozzon. Bármilyen CPU is legyen benne, valami módon működik, és ez nem lehet túl bonyolult! A fejlesztői környezet is ismerős marad. Én nem aggódom, csak kérdés, hogy mire lesz elég az a 80MIPS. Szerintem az FPGA-kat meg se tudja ugatni, az teljesen más világ! Az a 80MIPS még 20MHz-es IO műveletre sem elég, ha valamit közben még csinálni is kéne! Szóval FPGA kiváltó soha nem lesz, még egy 500MIPS-es sem(na jó az talán esetleg már jó lenne valamire!)!
Az F32 nagyon sok alkalmazásra jó lesz, de nem hardveres logikai 20MHz-es vezérlésre lett kitalálva szerintem.

Sajnos Megtaláltam egy assembly példát,azóta kapszkodom a székbe,nagyon az ARM procik kiismerhetetlenül kegyetlen világára emlékeztet..
Talán az ára ami miatt próbálkozni érdemes,meg mégis ismerős eszközökkel lehet fejleszteni,de így is nagy ugrásnak tűnik a sötétségbe.

Nekem se teljesen világos még, hogy mi, hogyan, miért ezekkel a chipekkel, de ha valami biztos, az az, hogy lehet asm-ben hergelni.

Az architektúrával (meg a többivel se sokat) annyira nem foglalkoztam, de úgy nézem, nem Microchip fejlesztés, hanem licenszelik a MIPS architektúrát (hasonlóan, mint ahogy az ARM-et mások), és azt bővítették.

Néztem,hogy már magát a chipet is kapni lehet,de kissé homályos ez még nekem...most a régi architektúrát elvetette,bővítette a microchip,vagy hogy is van ez?
Mindenütt a C compillert emlegeti,ezt assemblyben nem is lehet hergelni?

Szép,szép a 80Mips,nade ez vajon használható kötött időzítéssel is,tehát ha van egy ciklusom,tudhatom milyen gyorsan jutok el X utasításig?
Pedig,de jó lenne,ha IO sebességben is tudna 10-20Mhz-eket,sok olyasmit meg lehetne oldani vele,ami eddig csak CPLD-vel vagy FPGA-val ment..


Oké,a parallaxnak vannak gyors chipjei (SX,propeller) de mindegyik tolószékes,az SX egy PIC16C54 (!) klón, a propeller meg az 512word CPU memória miatt felejtős.

Megérkeztek az USB-s PIC32-k: Link

Vajon MotoHacker hozzászólása hová tűnt

Köszönöm a válaszotokat erre tippeltem én is!

Sziasztok!

Van egy kapcsolás, amiben 16F84-es PIC van de én csak 16F84A 04/P-set kaptam! Az a kérdésem hogy beleégethető-e az eredeti kód változtatás nélkül a 16F84A 04/P-be?

Ha végiggondolom végülis lehetséges így is.
Úgy használom a trafót,mint egy áramváltó,a fogyasztóval sorban,akkor "ellop" pár V-ot a fogyasztótól,a körben folyik olyan 250mA..
1W-ot simán el lehet lopni az izzó 60W-jából észrevehető fényerőcsökkenés nélkül.
Ami nagyon sok,még akár egy relés kapcsolásnak is elegendő lenne.

Hát, ha húzol be nullát, úgy könnyű. Nekem hogy húzzak be vezetéket, falat kellene vésnem... Mondjuk szerencsére három vezeték megy a kapcsolóhoz és a lámpához is, csak az elosztódobozban kell átkötni, és némi elektronikát elhelyezni a kapcsoló mögött és a lámpa mögött.

Ez is olyan,amit könnyű építeni,írtam hogy relé,stabilizátor,a nullát meg behúztam hozzá.
Pont ez volt az eredeti kapcsolóval a bajom..
már bocs,de szerintem ostoba megoldás a fogyasztó áramköréből lopni a tápot,mert ehhez mindig hasítani kell a fázist.
A kapcsolás maga nem nagy szó,de kell bele egy buzinagy fojtótekercs,ami akárhogy tekered meg,sisteregni,sípolni fog.
Ezért kezdtem széttúrni az eredeti kapcsolót,próbáltam rájönni,hogyan lehetne megszüntetni azt a fejfájdító hangot ami belőle jött.