Igen, bar engem szemely szerint jobban izgat az, hogy a chip is megjelent amint ez a demo board alapszik: MCP2200. Ha minden igaz, olcsobb lesz, mint az FTDI chipek (Farnell majdnem fele arat mutat).

Nem csak a demo boardra gondoltam én sem. Chipcad 400-430Ft áron írja a chipet.

Ja, latom mar 970Ft-t ir a legolcsobb FTDI-re... Azt hiszem jol jartunk ezzel az uj chippel, bar varjuk ki a veget, mennyire megbizhato, driverek kulonbozo op rendszereken stb...

Én már várnék egy olyan chip-et, aminél nem a sebesség a korlát(az FTDI-nek van: FT2232H és a FT4232H). A 12Mb/s elég karcsú. Egy dsPIC-et már nem szolgál ki. Egyébként nem rossz, csak nem jobb, mint egy 2550...

Hellóztok!
Nekem olyan problémám lenne,hogy megépítettem itt az oldalon található PIC-es frekvencia mérőt, és az lenne vele a bajom,hogy amikor bekapcsolom,a kijelző nem ir ki semmi mást mint fekete kockákat. A bemenő jel tökéletesen uniformizálva van, a tápfeszültségek megvannak. Mi lehet vajon a probléma?
Jah és a nyák is az ami a cikkben szerepel.

Üdv Erik!

Sőt, még olyan sincs, mert a lábkiosztása alapján ez csak egy maszkprogramozott PIC18F14K50, amibe gyárilag belepakolták a USB CDC firmware-t, amit megfejeltek egy HID EP-vel is, amin keresztül konfigurálni (illetve a szabadon maradt lábakat matatni) lehet.

Arra mindenesetre jó, hogy nem kell a felprogramozásával bajlódni...Bővebben: Link

Egy hülye ötlet: az MCP2200 doksijában azt írják, adnak egy dll-t a generic I/O lábak tetszőleges vezérléséhez, ehhez a 2.3 pontban az interface hívások is fel vannak vázolva. Ha ez ennyire jól dokumentált, akkor lehetne akár egy bitbillegtető programozó progit is írni a PC-re, olyasmit, mint az eddig soros vagy párhuzamos portokon kommunikálók, csak most az USB HID eszközön keresztül billegtetnék ezt a pár lábat. Így lehetne egy USB-s felületű, de nem felprogramozandó PIC-et tartalmazó programozónk...

Sziasztok!

Itt a megoldás a tyúk - tojás problémára. Az USB felületű (pic) programozók tartalmaznak egy kontrollert is, amit fel kellene programozni a használatba vétel előtt. Az MCP2200 segítségével - a bit billegetés lehetne az aktuális kontroller programozása - fel lehetne programozni őket.... Biztosabban működne, mint a párhuzamos vagy a soros portra készült programozók.

Ezzel ugyanaz a probléma, mint az USB-RS-232 átalakítókkal: elúszik az időzítés. Kiküldesz egy parancsot, hogy az RC7 álljon 1-be, s majd 1 ms múlva mehet a következő parancs, hogy menjen vissza 0-ba?

Ennél szerintem éltrevalóbb volna, ha valaki a Texas Instruments TUSB3410 USB-UART át alakítójára írna programot. Az ugyanis gyárilag tartalmaz egy olyan bootloadert, ami akár az USB porton keresztül is le tudja tölteni a firmware-t (a 16 kbájtos RAM-ba!). Csak ott kezdődik a bibi, hogy az egy másik világ, egy 8052-es MCU ketyeg benne...

Nekem is eszembe jutott, nem tartana semeddig vezérelni, van rá megoldásom, de pont abba a problémába ütköztem, amit icserny mester említett! Pedig milyen jónak tűnő ötletnek nézett ki!

És mi a baj ezzel a késleltetéssel ? Lassú lenne a felprogramozás ?

Nagyon lassú.

A 8052 alapvetően nem gond, a diplomamunkám abból írtam

Ezt az időzítéseset azért csak ki kellene próbálni, hogy vajon mennyi az annyi. Amikor az AVR programozómat építettem, akkor volt egy hasonló megoldással gyakorlati tapasztalatom. A programozón FT232 csinálja az USB illesztést, maga a programozó firmware egy ATtiny2313-ban fut, és szabályos soros kommunikációval lehet vele beszélgetni. Ám az AVR-t is fel kellett programozni valahogy az első programozóhoz, és azt úgy tettem meg, hogy az FT232 megfelelő RS232-es lábait digitális jelszinten összekötöttem az AVR programozó lábaival, majd PonyProg-ot használva beleprogramoztam a firmware-t. A normál esetben maximum 10mp-ig tartó programozás negyed óra-húsz perc alatt zajlott le, de hibátlan lett!

Ebből kiindulva lehet, hogy ugyan lassú, de működő megoldás születhetne az MC2200-ból is, sőt, én megkockáztatom azt, hogy ha nem a soros portot kezelő interface-en keresztül billegtetünk bitet, hanem a direkt erre kitalált dll-en keresztül, akkor jóval gyorsabb is lesz a dolog. Azt is valószínűnek tartom, hogy az időzítésekben leginkább a minimumok a kritikusak, de ennek persze utána kellene nézni.

Ha lesz egy kis időm, mindenképpen be fogok szerezni egy ilyen cuccocskát, bár ahogy néztem, csak SMD-ben létezik. Hej, de jó lenne, ha DIP tokosban is kihoznák...

De Te az MCP2200-t próbáltad a saját dll-ével, vagy egy FT232-n pl. az RTS/CTS bitezést a soros porti függvényhívásokkal? Mert én azt gondolom, hogy nem mindegy!

Ha lenne energiád rá, lehet, hogy egy gyakorlati próbát megérne a dolog, beletenni valamelyik égetőprogramodba a kezelést.

Szia!

Ezt a programozót általában egyszer használná fel az ember, az igazi programozójában használt kontroller beprogramozására - itt a programozási idő nem lényeges.
A régi égetőm (párhuzamos portos, bufferelt, külső táppal), Pentium I laptoppal, Dos alatt futó Turbo Pascal programmal is csak a port írási műveletek közötti idő kivárással volt gondom. (Az ISA buszos párhuzamos portoknál az írás / olvasás művelet idejét hadrver időzítéssel kb. 1us-on tartották, a műveletek közötti idő pedig a processzortól függött - a kivárásra egy másik portra vonatkozó műveletet használtam fel.) A 18F2550 -t is beprogramozta hibátlanul. Lépésenként végrehajtva a pascal programot sikeresen programoztam 16C84-et. A PicKit2 kb. 20-szor gyorsabb nála...

Az újabb pic kontrollerek programozási lapján is csak a Vpp és Vdd kikapcsolása közötti időre van minimum megadva (100ns) (ill. felfutási időkre, de az nem a függ a kommunikáció sebességétől). A programozást tetszőlegesen lassan lehet végezni...

Igen, alapvetően én is ezt gondolom, de még talán akkor is van létjogosultsága, ha JDM helyett építi meg valaki, aki csak időnként fel akar egy-egy PIC-et mondjuk neten talált projektek alapján felprogramozni.

Teljesen mindegy melyik eszközről van szó, mert két egymás után következő állapotot csak két egymás után következő csomagban lehet elküldeni, ami 500Hz kapcsolási frekvenciájú órajelet eredményezne, ami, ahogy írtad nagyon lassú. Annyit nem ér az egész. Sajnos kommunikáció nélkül nem lehet USB-s égetőt építeni. Működni működne, csak nem győzné kivárni az ember.

Egy kérdésem lenne. A 16F887 esetében a Calibration szót (címe: 0x2009) ASM-ban és C-ben hogy lehetne megadni? Találkoztatok már ennek az állításával égető programokban? (Sajnos nincs ilyen PIC-em, de kéne az infó...)

Nem láttam még ilyen, de ezen a fórumon így írják:

Üdv mindenkinek!
C30-as fordítót használok a kérdésem az lenne hogy hogyan lehet legegyszerűbben létrehozni egy olyan változót amelynek értéke 0-127 lehet? enum-ban felsorólni?.....elég csúnya úgy.

Én is ilyesmivel próbálkoztam, csak typedef-fel definiáltam a struktúrát:


Ami nem tetszik:
1. Nem lehet a =12 formában írni, muszáj a.m-nek hívni.
2. A b.m=150;-re nem ad hibajelzést, csak warningot (warning: large integer implicitly truncated to unsigned type).

Valaki homályosítson fel, légyszi: a fenti deklarációban a struct utáni név (jelen esetben mysplit) tulajdonképpen mire szolgál/mire használható?

Válaszolok magamnak: nem muszáj halmozni a neveket, tankönyv szerint így is lehet írni:



Bővebben: Link

A peldadban a bit7 a typedef-hez tartozo nev, mig a mysplit a struktura neve. Tehat:


a es b ugyanaz tulajdonkepp. Van olyan fordito ahol a struktura nevet pl el lehet hagyni (nevtelen strukturak), ill. C++ eseteben a struct onmagaban is mar tulajdonkepp egy typedef, tehat akkor az a resz hagyhato el.

UI: Ja, kozben megtalaltad

Köszönöm a segítséget!!

Én is próbáltam így de hibát ír a linker:

Az említett fórumon mintha kézzel állítgatnák a HEX állományt, vagy valamit félreértettem?
Leszedem a 8.50 MPLAB-ot, lehet, hogy a linkerem régi...

A 8.50 MPLAB-al ugyanaz a linker települ(4.35) Szóval ez nem megoldás. Elég fura lenne, ha csak a hex állomány módosításával lehetne ilyet létrehozni. Azt nem is látom még, hogy az égetők foglalkoznak-e egyáltalán ezzel a területtel!?

szerk:
Módosítottam egy hex-et és a PK2 programja nem tudja értelmezni a 2009-es címet, azt írja, hosszabb a fájl, mint kéne. Most már csak az a kérdés, hogy ez a terület egyáltalán módosítható? Úgy látom kénytelen leszek venni egy ilyen PIC-et, mert nem jutok a -al WPB_F16_F18előrébb...

TMR3-al szeretnék megszakítást generálni. Miért nem sikerül? :no:


Ja, PIC18F2423.

Úgy tűnik, hogy ez a terület nem változtatható, törölni nem lehet, az írásáról sem említenek semmit. Annyit említ az adatlap, hogy az írás után le kell ellenőrizni ezt is, és akkor tekinthető késznek a folyamat. Ha esetleg más infótok van erről ,szívesen venném! Köszi!

Ebből nem derül ki. RCON.IPEN hogy van beállítva? Hogy kezeled le a megszakítást? Honnan tudod, hogy nem fut rá a megszakításra a program?