A C nekem sem tetszett, és ma sem tartozik a kedvenceim közé, de elkerülhetetlen, mivel a gyár ezt favorizálja és nincs asm fejlesztés USB-s 18F-ekre.
A bootloadert én nem használom, mert azt is útálom, ezért átalakítottam a linkert és PICKit2-vel programozom az USB-s firmwaret.
Ha csak egy kijelző meghajtása a cél, akkor lehet hogy igazad van, de tudod milyen az élet! De jó lenne még ez is meg az is, meg egy időzítés kéne, meg egy hőmérés - ha már van kijelző - , meg....
Nekem eddig mindig kevés volt a sima átalakító, és ha már PIC is bekerül, és eddig soha nem vettem észre, hogy a CDC lassítana, valamint hogy gondot okozna a kommunikációban a "butasága", így az FD ott porosodik és várja mire lesz jó. Biztosan fel fogom használni egyszer, mert jó...

hihihihi, nem! én ezt ÁLTALÁBAN mondtam, mivel általában beszéltünk az önálló FT csip előnyeíről, hátrányairól. Az én kis projektem esetében csak azt kéne tudnom, hogy a 2455-ömre mégis melyik boot loader kell feltölteni, illetve (mivel a C nem tetszik nekem) milyen gyári asm routinok vannak és azokat hogyan tudnám használni. Egyébként itt a feltételes módon (tudnám) van a hangsúly, mivel nagyon úgy érzem, hogy ágyúval a verébre lövés esete a (jó nagy) 18f2455 + kvarc + mittudoménmikellmég egy kijelzőt meghajtani. A vitatott üzembiztonságról már nem is beszélve. El fogom én vezérelni azt a kijelzőt egy <200Ft-os csippel is. (ahogy azt megoldottam lptről, usb->lptről és soros portról is)

Ugye nem arra célzol, hogy egy LCD az ilyen bonyolult időzítést kívánó eszköz lenne?

Én mostanában szinte mindenhová FTDI chipeket használok. Sokkal stabilabban működik vele a kommunikáció, mint a CDC-s Microchip féle stackkel+driverrel.
Abban egyet kell értsek NickE-vel, hogy a fejlesztési időt nagymértékben csökkenthetjük az alkalmazásával, továbbá sokkal erőforrásigényesebb a CDC (USB alapú) a kommunikáció. Vannak olyan területek, ahol ez nem megengedhető.

Én a Microchip helyében az új USB OTG perifériákat úgy hoztam volna létre, hogy egy konfig bit segítségével átkapcsolhatóvá váljon USB->RS232/SPI üzemmódra, és hagyományos RS232 vagy SPI regisztereken keresztül menne a kommunikáció (a kommunikáció vezérlését pedig egy külön, de a tokba integrált egység végezné (~FTDI+PIC egy tokban)). Így az összetett USB kommunikáció irányítása nem a kontrollert terhelné.

Egyébként az FTDI fejleszt ezerrel, mert jönnek az USB 2.0 High Speed üzemmódot támogató konvertereik is.
http://www.soselectronic.hu/?str=661

Én a Minch féle firmware közül a custom specific devicet használtam. A CDC előnye, hogy valamelyest egyszerűbb, de a hátránya az, hogy pont az USB lényege hiányzik belőle. Most így fejből pontosan nehéz már visszaemlékeznem, de ugyebár van control, interrupt, bulk és isochronous átvitel. Ha kevés adat meg át, akkor lehet a control átvitelt is használni, én meg lehet oldani, hogy a descriptorok megfelelő kitöltése után a PIC automatikusan más-más lekezelő függvényre ugorjon. Tehát nem kell protokolt gyártani, amiben lesznek parancs, adat és végül hibadetektáló rész, hanem csak egyszerűen a descriptorokban adod meg, hogy adat megy át, vagy parancs, így automatikusan az átküldött üzenetet lekezelő rutinra ugrik a PIC. Hibadetektálással sem kell foglalkozni, mert az az USB hardveresen megcsinálja. Még számtalan előnye van az USB-nek, ami csak akkor látszik, ha nem CDC-t használunk, viszont szerintem nagyon nehéz a programozás...

Elolvastam a Jan Axelson féle könyvet, az USB in Nutshellt, az USB specificiationt, a Microchipes doksikat, +még a PC oldali driverprogramozáshoz is a Sprut féle leírást. Ez összesen több, mint 2000 oldal. És a végén nagyjából sejtettem a Minch féle firmware és Microchipes topic segítségével, hogy mégis hogy működik az USB, de tökéletesen nem volt minden világos. (sőt, azóta elég sokat sikerült felejtenem is)

Az FTDI hátránya ugyan ismét az, hogy az USB specifikus dolgokat elfedi, de sokkal egyszerűbbé teszi a fejlesztést. És ha az ember nem csak hobbi/tanulás végett kódol, akkor fontos szemponttá válik a fejlesztési idő hossza. Na ebben az FTDI szerintem verhetetlen. Nagyon egyszerűvé teszi az USB-s kommunikációt.

Kérdés az illető eszköz mennyire pontos "időzítést" igényel.

Evvel: www.motohacker.fw.hu/USBint.JPG
simán meghajthatóak a karakteres kijelzők, mivel az FT2232 a soros és párhuzamos üzemmódjai mellett mikroproceszort is tud emulálni.

Mondjuk nyákra szerelni valóban elég meredek, itt is látszik, hogy kellett egy darab huzal, mert a tok alatti "via" szakadt lett a kis vonalvastagság miatt.

nekem is az a véleményem, ha egy másik, önálló időzítést igénylő eszközt is akarunk vezérelni, akkor az egy uC-s dolog már behalt vagy olyan extra bonyolult programozást igényel, ami gyakorlatilag lehetetlen. És árban sem járunk jobban, ha veszünk egy >1000Ft-os PIC-t, mint 800Ft-os FT csip + 150Ft-os kiegészítő uC esetén.

Van benne valami. Egyébként osztom a véleményed a CDC kérdésben is. Az hogy mennyi idő megy el? Én nem nagyon tapasztaltam lassulást, pedig van még egy kommunikációs csatorna a 2550-en(RS485 115baud-al), valamint egy SD kártya is. Igaz még nincs teljesen kész az SD része, de már néhány IO funkció működik. Nem vettem észre, hogy lassú lenne a PIC ehhez.
Te mire gondoltál, mikor ezt említetted?

Én is használom ezeket a chipeket. Egyébként a 0,5 mm lábtávolság ellenére nehezebb forrasztani, mint a többi hasonló lábtávolságút, mert szélesek a lábai. Ha adapter kell, akkor az UM kezdetűeket érdemes nézegetni, mert azokon rajta van minden egyébb cucc, ami az IC-hez kell. A sima SMD-DIP átalakítók azért felejtősek, mert van néhány mazdag, amit nagyon tanácsos rövidre venni, ez nem fog sikerülni átalakítóval. De ha low-cost megoldás kell, akkor be kell forrasztani.

Egyébként annyiban nem értek egyet Wattal, hogy én is használtam 1db projecthez USB-s PIC-et, de ha nem a com-os firmware kell, akkor szenvedés az egész. Több, mint egy hónapom elment USB tanulással úgy, hogy szerintem nem vagyok nagyon homály PIC-ekhez. A PC oldalt meg ne is említsük, ha az ember ki szeretné használni az USB előnyeit. plusz az USB firmware elég sok munkát ad a PIC-nek. Ehhez a chippel a PIC-nek csak akkor van dolga, ha épp kommunikáció folyik és PC oldalon pedig olyan drivek vannak hozzá, amivel gyerekjáték USB kapcsolatot létesíteni.

Egyetértek, semmi gondot nem jelent a panel gyártása és beforrasztása. TQFP 100lábú is megoldható vasalással. Nekem is van otthon néhány ilyen chip, de még nem használtam fel őket, mert egyedül buták. Ha kellett USB, akkor kellett PIC is mellé eddig, így inkább egyben oldottam meg(18F2550, 4550). De egyszer lehet, hogy bekerül valahová, talán egy PIC nélküli PIC égetőbe, csak ezzel az a baj, hogy mióta van PICKit2 klón, azóta nincs értelme fejleszteni égetőt... Elnézést ha nagyon off voltam!

Szerintem a SSOP probléma nélkül forrasztható házilag (pl.), felesleges ilyen adapterekkel játszani, egyből mehet be a céláramkörbe. Szerintem.
Ha mégis belevágtok, a forrasztást vállalhatom, igaz jó messze vagyok

Fenti chipeket - gondolom - nem kell bemutatni, http://www.ftdichip.com/FTProducts.htm, ha mégis: sörös port felületet (COMx-et) adnak a Windowsban, USB-n kapcsolódnak a géphez és TTL szintű kimenetet adnak saját áramköreinknek. Mondhatni ideálisak hobby célra (áramkört illeszteni USB-re), leszámítva azt, hogy sem az SSOP, sem a QFN csatlakozás nem könnyű eset, DIP-ben pedig nem árulják. A gyártó cég siet kedvünkben járni, és - önmaga számára cseppet sem előnytelenül - a (z egyébként sem olcsó) csip árának 8x-ért adja azt próbapanelra szerelve. Alternatíva még, hogy külön veszünk SSOP/QFN próbapanelt - aminek az ára annyi, mint a csip maga -, majd valahogy ráimádkozzuk a csipet.

Úgy gondolom, hogy itt a fórumon lenne igény 9db vagy 16db (esetleg 25db) FT232R/245R IC-re próbapanelra szerelten, ne külön-külön készítsünk panelt, hanem egyet közösen, szeleteljük és forrasszuk rá az IC-ket, így 5.000Ft/DB helyett önköltségi áron csináljuk meg magunknak!

Akit érdekel, az írja meg hány db FT232R és mennyi FT245R-re tart igényt!!!