Ebben lehet igazság, de könyörgöm: ha már mindenképpen 877 kell, mert mondjuk valaminek az utánépítése a cél , és a firmware nem hozzáférhető forrásban, akkor miért 877-20, és miért nem 877A?

PIC16F877-20/P 1020 Ft
PIC16F877A-I/P 870 Ft

Lehet tevedek de ugy nezem a 887 felulrol kompatibilis a 877-tel, es egyenlore nem talaltam semmi olyasmit amitol ne mukodne egy 877-es HEX a 887-ben. Erdekes tanulmany lenne, hogy valoban lehetseges-e, ill van-e olyan eset mikor ez igy nem mukodhet?

Hmm talaltam valamit, ECCPAS <-> CMCON valamint PSTRCON <-> CVRCON fedik egymast, tehat pl 877-es komparatort hasznal akkor mar nem lesz jo... akkor ez megsem 100%-ig kompatibilis, hat ez van...

Hali
Ha jol tevedek hianyzik a PSP
Vili

Teljesen egyetértek az elöttem szólókkal!
Ha engem kérdeztek én már évek óta 18F-et veszek csak, ha több láb szükséges és több memó!
Kivétel a 16F627A, mert az minden kisebb projectre megfelel és nagyon olcsó.

Nekem csak az a bajom a 18F sorozattal, hogy nincs belőle 8 lábú (valami a 12F683 helyett). Apró feladatokra, a 12F683 nagyon hasznos kis kontroller.

Tényleg jó lenne, de nincs. Ilyenkor természetesen a célnak legmegfelelőbbet kell választani. De ha 18, vagy több láb kell valahova, akkor nálam az 18F-el kezdődik. :kalap:

Akkor en erre mit monjdak, ilyen kicsi mar tenyleg nincs meg 14 bitesbol sem

A csati az a normal 0.1" -es tuskesor, csak hogy legyen valami elkepzeles ez mekkora...

Nem rossz! Mi ez?

Ez a mutyurom, a buszkesegem Egy RC modellekhez hasznalhato digitalis szuro + failsafe. PPM radio altal eloallitott PWM jelet szuri meg, raadasul ket csatornat egyszerre - mindezt egy 10F202-essel. Maradt meg 6 vagy 7 programszo, szoval meg lehetne valamit beletenni

Á, már emlékszem, szóval így néz ki! Nem semmi! A vevő és a szabályzó áramkör közé kell tenni és kiszűri a zavarjeleket?

OFF

Igy van, ill ha nagyon nem lehet mar mit kezdeni a jellel, akkor kenyszerusegbol alaphelyzetbe hozza a szabalyzokat - pl leallitja a motort, kormanyt egyenesbe vagy eppen kanyarba allitja, ill repulonel a vezerlo feluleteket allitja be arra amire a modellezo ugy gondolja a legkisebb kar erheti a gepet. Persze ha a jel helyreall akkor ujra vezerelhetove valik a gep, a cel, hogy minel kisebb legyen az okozott kar, ill. elkerulhetoek legyenek balesetek, mint amilyen volt Magyarorszagon egy europa bajnoksagon. Ott is radiozavar miatt zuhant a nezoterre egy repulogep modell es sajnos egy hazaspar halalat okozta.

ON

Maga az aramkor amugy szinte semmiseg, ill azota amiota ez a kep keszult mar modositottam kicsit rajta ami azt hiszem jot tett neki. A lenyeg amugy a firmware. Elmeletileg ez a baseline MCU alkalmatlan lenne erre a feladatra, marmint hogy ket csatorna digitalis szurese, tulajdonkeppen minden lehetoseget ki kellett hasznalni amit ez a 10F202 egyaltalan tud. Viszont be akartam bizonyitani hogy ez lehetseges, es azt hiszem ez sikerult is. Valoszinuleg majd a kovetkezo valtozatnal mar feljebb kell lepjek, de hogy ez 683, vagy valami 18F akar az meg nem korvonalazodott. Meg a 785 is felmerult a HV valtozat miatt.

Én egy Tamiya szöcskébe építettem inteligens motorvezérlőt, amibe eleve belekerült a rádiójelek digitális logikai szűrése. Sajnos a távirányítóm annyira gagyi(gyári alap), hogy ami nincs azt nem lehet feljavítani! De azt tudja, amit említettél, hogy leállítja a motort, ha nincs értelmezhető jel. Gondolom Te is a periódusidőt és a feltételezhető jelidőket vizsgálod, és az alapján kalkulálsz?

Jelenleg egyébként milyen (ha publikus) PIC-es témát fejlesztesz?

Igen, hat mas modszer ezen a szinten nem nagyon kinalkozik. Sajnos a radion belul a shift regiszter elott meg lenne ra mod, hogy magasabb szintu szures legyen elerheto, dehat ahhoz radiot is kellene epiteni De igy is amugy eleg jo eredmenyeket lehet elerni mint ahogy nyilvan tapasztalhattad is. Amival par honapot eljatszottam, hogy en kifejezetten repulre terveztem, igy a szuronek maskepp kell viselkednie mint egy autohoz valonak: azaz lehetoleg mindent elkovetni, hogy a repulo meg egeszen zajos kornyezetben is vezerelheto maradjon. Jo sokat vacakoltam vele, radio zavarokat szimulaltam es kozben nezegettem kulonbozo algoritmusokkal es parameterekkel hogy viselkedik. Aztan vettem vagy 5 fele kulonbozo termeket - amik ugye autokhoz vannak tervezve, de repulohoz valot nem kapni... Szoval azokkal ossze merve is jobban viselkedik, es egyetlen darab volt ami hasonloan jol mukodott - de az csak egy csatornas volt szembern ezzel Tobb csatornasat nem is talaltam amugy.

Mostanaban amugy elegge aludt minden PIC-es temam, de hat a "szokasos" modellezos temak vannak leginkabb szemem elott - motor vezerlo, fordulatszam mero, esetleg tolto aramkorok. Azonkivul USB eszkozok nagyon foglalkoztatnak.

Es Te milyen PIC-es temaban vagy bele merulve mostansag? Multkori hozzaszolasodbol itelve valami USB eszkozt faragsz? Masok projectjei is erdelnenek

Per pillanat egy USB_SD/MMC_RS485-ös panelt faragok a házvezérlőm összekötésére a PC-vel. A célja adatgyűjtés, PC-ről vezérlés, és adatok feltöltése, megjelenítése, kommunikáció a központi panellel RS485-ön keresztül(pl. ébresztő adatok, fűtésprogram, parancsok küldése stb.). Aztán most tervezek egy TCP/IP-s panelt, amin keresztül távolról is el lehetne érni a rendszert.

Most egész jól állok, mert sikerült végre együtt is működésre bírni az USB-t és az SD kártyát, miközben az RS485 kommunikáció se fagyott szét. Ezzel elég sokat szívtam. Elsősorban a microchip-es USB firmware miatt. Nagyon nehéz volt úgy átalakítani, hogy megszakításból legyen pollingolva és ne zavarják be egymás RAM területeit a kezelő részek.
Egy 2550-esben létre tudtam hozni 512+64+64+256+egyéb RAM változók számára független RAM területet. Igaz ez úgy sikerült, hogy az usb7-es lapot is elcsórtam az USB-től.
Azt olvastam, hogy a 4-est nem szabad nagyon zargatni, de a többit elővigyázatosan lehet. Mivel nem HID-es a kommunikáció, csak CDC(nekem elég bőven), ezért valószínű, hogy az 5-ös és 6-os usb lap sem használt, de erre még nem volt szükségem eddig, viszont a 7-eshez nem nyúl a CDC firmware(legalább is eddig ezt tapasztaltam).
Aztán van egy elég kemény tervem, amibe eddig beletörött a bicskám, de nem adom fel! Ez egy 12"-os TFT panel illesztése a vezérlőhöz. Ehhez egy 24HJ256, egy CPLD és némi 100MHz-es SRAM van a fiókba készen. 40MHz-es átviteli frekit kéne megoldani a SRAM-ból a TFT meghajtó panelre. Nem lennék szomorú, ha sikerülne!

Hu hat sokkal konkretabb projected van akkor mint nekem :wink: Amugy neha az az erzesem, hogy a MC USB megoldasai nem a legjobbak, es ahhoz, hogy sajat firmware-t faragj elegge rogos utakat kell bejarni. Nem is olyan regen Szilvaval farigcsaltunk USB-s konyvtarat assemblyben, hat mar nem is emlekszem hany ejszakat vegig dolgoztunk mire mukodni kezdett, es hozza vagy 3-4 doksit olvasgattunk, es a csepegtetett informaciokat ossze rakosgatva (meg persze sokat kiserletezgetve) jott ki az eredmeny. A MC-s CDC nekem az istenert sem akart beindulni Vista alatt Szilvanal az XP alatt ment ugy tudom. Bogarasztam egy ideig mi lehet a baj de aztan feladtam. Az erdekes az, hogy bar egyik MC-s pelda sem mukodott sem az egerentyu sem mas, a PicKit2 is ugyanezt a frameworkot hasznalja es azzal nincs gond.

Na mindegy, neha az az erzesem sokszor egyszerubb egy FT-s USB-Serial konvertert berakni mint vacakolgatni az MC-s megoldasaival, bar ha kommercionalis celok vannak akkor minden gyartasban megsporolt filler szamit. Es hat ha sikerulne vegre formaba ontenunk ezt az assemblys USB frameworkot akkor szerintem egeszen leegyszerusitheto egy-egy ilyen project vele :wink:

Ami a TFT-t illeti, engem is erdekelne ilyesmi, eddig ket kukazasom van, egyik egy hordozhato DVD jatszo, a masik egy IBM Levono laptop LCD-je. Na ez utobbi siznte remenytelen hacsak le nem szedem az alaplapjarol valahogy a meghajtast :wink: A DVD jatekos LCD-je, haaat, az is ketseges megeri-e a faradsagot, de hat egy 7"-os szelesvasznu LCD-t csak nem hajitanek a kukaba - hisz epp onnan kaptam ki hihi

Teljesen egyetértek! Én is sok segítséget kaptam Szilvától, potyotól és tőled is, de eddig még nem sikerült saját rutint írnom.


Egyszerűbb, de lassabb és igazából az nem USB. De igaz, hogy néha az is elegendő.

Sajnos a képek valahogy nem jelennek meg nálam, és a teljes utat sem látni. Próbáld meg inkább belinkelni!

A TFT nekem egy oliveti lepiből van. Megvan hozzá a leírás, amit -talán itt- megtalálsz a tieidhez is, vagy közel hasonlót. A csati kiosztások sokszor igen hasonlóak, sőt egyformák. Amik nem azokon jól látszik az eltérés.
A téma -itt lett- kitárgyalva, elég jól ért hozzá a srác(már ha nem nő ).
Én nyitottam egy topicot a terminálon az ügyben, ott is sokat segített MotoHacker, esetleg ott folytathatnánk is a dolgot, mert itt ez egy kicsit off, mégy ha PIC is van benne...

Hu, azok a 'kepek' vigyorok voltak, en csupan kettospotty-vonalka-zarojeleket irtam, de lehet D betut is nehol, es ilyen butacskan jelent meg : - ) (space-ekkel elvalasztva talan jo lesz)

Igen, szoval USB miatt nagyon sokan szidjak a Microchip-et, mas mikrokontrollerekben egyszerubb a SIE-t kezelni. Mostanaban kezdik ezt azt hiszem felismerni es talan jobb tamogatast adni az USB-s eszkozeikhez.

Akkor megprobalok a terminalra ramenni mert erdekelne - eleg erdekes lenne pl egy scope-ot vagy egy jatek konzolt csinalni : - ) (ismet space-ekkel...)

off a : ) "-" nélkül ez lesz ...

on:
Épp most futottam bele egy hibába, amit nem kezelnek le, vagy lehet, hgoy csak én vagyok az értettlen, mert sehogy nem értem hogy is történhet meg a következő dolog:



Nos, ahogy most van a rutin, úgy nem azokat a karaktereket küldi el az USB-n, amiket a rutin elején deklaráltam, hanem mindenféle mást. Ezt úgy tudom elképzelni, hogy a rutinra futáskor deklarálódnak a RAM cellák és feltöltődnek. Aztám mikor az USB CDC hívásával kitér a program, akkor csak egy címet kap, ami a hívó rutinban él a hívás pillanatában.
Azt nem értem, hogy miért tudja felülírni bármi a havó rutinban deklarált belső változót, mikor még nem ért véget a rutin futása, csak egy mélyebben fekvő rutint hívok meg belőle?
Szerintem ilyenkor védenie kéne a hívó rutinban deklarált RAM terülteteket, nem?

Ti értitek mi a baj, vagy mit rontok el?

Egyébként a másik két kikommentezett sor jól működik. Az egyiknél át töltöm egy globális tömbbe a kérdéses belső tömbök tartalmát, mielőtt elküldeném.
A másik sorban pedig programmemória területen letárolt karaktereket küldök el.

Végül csak annyit, hogy a program két parancsot detektál amit a PC-ről kap USB-n keresztül és erre válaszol. Természetesen ez csak egy teszt rész, amit ki fogok egészíteni a megfelelő kezelő rutinokkal...

Van Pickit2-d, szakítsd meg a program futását valahol a mUSBUSARTTxRam() függvényben, és nézd meg a memóriaterületet, hogy az van-e benne, aminek lennie kell.

Szerintem a (byte *) felesleges, a byte úgy emlékszem (unsigned char)-nak van definiálva az usb framework-ben.

Nekem az a tippem, hogy az MsgB1[] és az MsgB2[] valamiért a programmemóriába kerülnek, és amikor átküldöd a pointert a mUSBUSARTTxRam() függvénybe, akkor az meg úgy veszi, mintha a ram területre mutatna (a pointer az csak egy egyszerű unsigned szám, a fogadó és a küldő rutin is ugyanarra a területre kell, hogy "értse").

Van mikor részleteiben kiírja a szöveget. Biztos, hogy RAM-ba kerül, látszik a Watch ablakban is.

A byte*-al kapcsolatban ezt úgy hagytam, ahogy az exaple-ban volt, de majd próbálom elhagyni...

Most ertem haza, igy meg nem volt idom megnezni, hogy mi van, de nem lehet, hogy a stack merete kicsi ehhez? Mondjuk statikus szoveget nem illik stacken tarolni, de nem tudom az MC18 hogy kezeli le ezt. Probald meg elobb kisebb szoveggel, pl 3 karakter - es ugye nem felejtetted el, hogy minden c text utan van lezaro nulla ('\0' vagy 0x00 ha ugy tetszik), tehat az 4 helyet fog lefoglalni neked.

Masik, hogy nem szerencses igy szamot beirni buffer hossznak (pl a 17) hanem ha MsgBx1[] = "..."; akkor pl lehet sizeof(MsgBx1) operatort hasznalni hisz fordulaskor kiderul a tomb merete - igy ha kesobb valtoztatsz a tombodon nem kell a szamokat keresgelni es akkor ha egyet is kihagytal nezni most miert nem jo Sizeof() amugy a lezaro nullat is bele szamolja, tehat ezt nyilvan le kell vonnod ha nem kell atkuldeni.

Sziasztok!
Szóval megvettem a pickit2 express debuggert és a 877-et!Lenne pár kérdésem!(ha nem baj)
Az égetőt értelem szerűen rádugom a laposra,majd a másik felén lévő kimenetre rádugom az általam készítendő nyákot ami tartalmazza a picet az oszcillátort és az ötlábú tüskesort(a csatlakoztathatóság miatt).(nyilván a pic megfelelő lábait vezetem ki)no de mondjuk milyen sorrendben?Valaki elmagyarázná nekem hogy mit tegyek hogy elkezdhessem a munkát?

köszi!!

A pickit2 manualjában le van írva a lábkiosztása! (meg minden egyéb fontosabb dolog ami az áramkörön belüli programozáshoz tudni kell)

PICkit2 Users Guide, 1. fejezet, 1.5.4 bekezdes, 1-2 abra... 877-esed labkiosztasat pedig a 877-es adatlapjarol tudod kinezni.

Remélem nem idegesítelek titeket nagyon a kérdésekkel(bár tudom hogy igen)sajnos el kell kezdeni valahol.Nos az oszcillátor méretét csak az befolyásolja hogy a picnek mennyi a max?Tehát ha 20Mhz a picnek és én egy HS oszcillátort rakok mellé ami ugye szintén 20 akkor azzal nem cseszek el semmit?

Rendben, nem kell szöveget tárolni stack-ban, de ha nem szöveg lenn benne, akkor is elrontaná?(persze!)
Bevallom nagyon nem szeretem a C-t e miatt. ASM-ban mindig tudtam milyen memóriát mire használok, most meg keresgélek mint a világtalan a vakablakban!

Nem cseszel el semmit. Azt azért érdemes megnézni, szintén az adott PIC adatlapjában, hogy tápfeszültség függvényében hogyan alakul a maximálisan használható sebesség.

5V-on biztos fogja tudni a 20MHz-et a 877A vagy a 877-20 (még mindig nem értem, miért ragaszkodtál a legdrágább, ám mégis legelavultabb típushoz...), de 3.3V-on már lehet, hogy van rá sebességkorlátozás.

(De az adatlap minden ilyen kérdésre választ ad!)

Köszi!

Mentségemre legyen mondva már van egy 887-em is!!

887 gondolom a debug expressel jott Szepen pihentesd azt a 877-est azt javasolnam, es egyenlore hanyagold a kulso kvartzokat, igy is eleg tanulnivalo akad. Abban a 887-esben van egy 8 megas belso ora, mundjuk ez 4 megas uzemmodban indul de miert is kell neked hirtelen akkora sebesseg? Ha jol ertem ezek az elso szarnyprobalkozasaid, arra boven eleg ez - nezd meg azt a mutyurt amirol tegnap esett szo, az is 4 megan ketyeg es kivalo

Sok sikert a probalgatasokhoz!