Ehhez meg egy kis kiegeszites, hogy a frameworkok hasznalata sem mindig trivialis. Az USB mukodesen kivul meg a frameworkot is meg kell ismerni, igy a betanulasi fazis igy is eleg meredek lehet. Teny, hogy ezutan mar a fejlesztes eroteljesen felgyorsulhat.

Valoszinuleg konyebb egy meglevo peldat eloszedni, es ha tudjuk mi az amit piszkalni kell benne azt a par dolgot megmodositjuk es "becsukott szemmel" leforditjuk + imadkozunk hogy mukodjon is. Pl ha van egy eger USB eszkoz forrasunk akkor lehet egyszerubb azt megmodositani, hogy milyen poziciokat es billentyu allapotokat kuldunk el mintsem megerteni a teljes USB es HID mukodeset valamit az adott framework hogy mindezt hogyan implementalja.

Az AVR kis hazánkban hátránnyal indul az USB szempontjából (is). Kerestem USB-s hardverrel ellátott példányt pl. Atmega8U2 de Mo-on gyakorlatilag beszerezhetetlenek.

Így maradna a szoftveres megoldás, de egyrészt az nem egészen támogatja a szabványt, másrészt eléggé leterheli a procit, így komolyabb dolgokra nem alkalmas.
Mennyire jöhet elő egy alkalmazásban ez a szabványossági probléma, tekintve, hogy USB-s programozókat is készítenek ilyen megoldással, és azért nem lehet hallani, hogy milyen szar, mert nem működik mindegyik gépen.

Ezek szerint PIC-eknél korrekt megoldás létezik. Csak az a kár, hogy a neten fellelhető dokumentációk közül az AVR-esek nekem valahogy jobban dokumentáltaknak tűnnek. Ott több megoldást is találni a PC oldali programozásra, míg PIC esetén csupán a Microchip által kiadottal találkoztam. Bár ez azt is jelentheti, hogy olyan tökéletes, hogy mindenki azt használja. Vagy a PICes közösség egyszerűen nem tárja a nyilvánosság elé a fejlesztéseit.

Én nem szeretek olyasmivel építeni, ami a szabványt nem teljesíti. A legváratlanabb pillanatban jöhet elő a probléma...

Ezzel én is így vagyok. Ahol ott van az apróbetűben, hogy pl. ilyen-olyan linuxoknál szedd le a kernel forrását, patcheld meg és fordíts új modult az USB kezeléshez, hogy működjön CDC módban a bulk transfer, ott azért már erősen elgondolkozom, hogy szabad-e ilyennel foglalkozni. De a Vista, és lehet, hogy a Win7 esetén is előfordulhatnak nyűgök, ahog olvastam a neten, ezért van "Vista-ready" driver is a AVR-es CDC-hez, szóval nem csak linuxnál probléma.

Nem véltlenül van jópár ilyen programozónak HID módja is, ami teljesen szabványos, viszont mivel teljesen saját kommunikációt valósít meg, de azt meg a kezelőprogramoknak is ismernie kell. Ilyenkor el lehet gondolkodni, hogy "melyik ujjamat harapjam meg".

Meg nem foglalkoztam AVR/USB megoldasokkal, azonban az teny, hogy a PIC reszerol jonehany dolog eleg homalyos volt mikor eloszor USB-ztem -- sokmindent innen-onnan-mashonnan kellett ossze bogaraszni, gyakorlatilag 4-5 dokumentacio szinte egyideju olvasgatasa volt a celravezeto, no meg sok probalkozas, kiserletezgetes.

Azota amugy a Microchip elegge komolyan foglalkozik a kerdessel es a honlapjukon is van kulon szekcio ami csak ezzel a temaval foglalatoskodik -- nyilvan nem magyarul, de ha valaki tud angolul (vagy kinaiul) akkor mar joval konnyebb helyzete lehet, mint amilyen nekem volt pl.



Ele tarja, csakhogy altalaban ezek a fejleszto eszkozok nem ingyenesek. Rengeteg framework kezdemenyezes is van, altalaban az ingyenesek nem tokeletesek, de ajandek lonak... A Microchip honlapjan egy taiwani srac (Xiaofan) szokta ossze szedni az USB-vel kapcsolatos infokat, erdemes rakeresni es bongeszni a linkeket...

Jól értem, hogy az AVR szoftveres USB megoldások közül csak a CDC eszközosztály esetén van szabványossági probléma, a HID esetén nincs?
"...viszont mivel teljesen saját kommunikációt valósít meg, de azt meg a kezelőprogramoknak is ismernie kell."
Kezelőprogramot mindenképp írni kell PC-re, legfeljebb a virtual COM port kezelésének előnyeit kell elfelejteni. Viszont van dll, amit lehet a programba importálni és drivert sem kell telepíteni. Jól okoskodom?

Igen, kb. ez a helyzet, persze léteznek még más eszközosztályok is, de azokkal én nem is foglalkoztam még. Gondolom, hogy pl. egy audio- vagy videoeszköz sem igazán kivitelezhető a low-speed kapcsolaton, de valószínűleg ez nem is lenne cél.

A HID kezelésére nyilván vannak beépített függvények minden környezetben, de adatkommunikációra mégis az egyik legjobban bevált dolog a soros port. Egy soros portos eszköz fejlesztési fázisában sokszor elég teszteléshez egy soros porti terminálprogram, míg a HID eszközzel az API hívásokon keresztül történő kommunikációnál muszáj valamit írni már a PC oldalon is a teszteléshez. Kicsit talán macerásabb, de ha egyszer az ember végigzongorázta már, akkor biztosan használható olyan jól, mint a soros port.

Demo programok léteznek a HID osztályhoz is, így kb. úgy lehetne használni, mint a terminál emulátort a soros port esetében.

Számtalan megoldás létezik, akár olyanok is, mint az FTDI chip-ek, amelyek saját firmware-rel elátott mikrovezérlőt tartalmaznak, s soros vagy párhuzamos illesztőfelületet nyújtanak.

A Texas Instruments TUSB3410 USB-s mikrovezérlője pedig tartalmaz egy beépített bootloadert, így önprogramozó módon tölthető bele a firmware.

A MAXIM MAX3420E USB illesztője pedig SPI interfészen keresztül kommunikál a mikrovezérlővel.

Nem szükségszerű tehát, hogy maga a PIC vagy az AVR csatlakozzon közvetlenül az USB-re.

„Mi van a hardveres megvalósításokkal?”
Toto nem a külső hardveres megoldásokra gondolt, hanem a kontrolleres belső megoldásokra, mint PIC18F4550 vagy ATMEGA64U

Igen, picinek igaza van, első sorban a két fajta kontroller szempontjából vetettem fel a kérdést.
És persze neked is igazad van (mint a viccben ) célhardverrel általában egyszerűbb, és főleg gyorsabb kommunikációt lehet megvalósítani.

Másik kérdés, hogy pl. az FT232 árából kitelik két-három AVR és másfél PIC. Persze egyedi konstrukciónál nem lényeg, sorozatgyártásnál viszont annál inkább.

Köszönöm a hozzászólásokat, sikerült megvilágítanotok a témában a sötét foltokat.

Ez így nagyon félrevezető megállapítás, mivel sem az olcsó AVR sem az olcsó PIC nem helyettesíti egyenértékűen. Az alkatrészár tehát csak egy szempont a sok közül. További szempontok lehetnek a műszaki paraméterek (pl. USB szabvány betartása, átviteli sebesség), a szoftverellátottság (16/32/64 bites Windows, Linux, MAC OS driverek) és a többi...

Igen, sajnos az az igazság, személyes tapasztalat, hogy kisebb USB-s AVR procik beszerzése kérdéses. És nem is nagyon van USB-s AVR DIP tokban, amire a bütykölők várnak.
Igazából az ATmega8U2 simán beszerezhető alkatrész, csak a magyarországi kiskerek nincsenek belőle feltárazva. De ez soha nem volt hátrány.
Igazság az, hogy rengeteg processzora van még az Atmelnek, ami magyarországon még sosem hallott, nem hogy nem raktározott.

Mellesleg kontra a nincs kis AVR USB-vel... Nem tudom. Nekem még sosem kellett 8K-s prociba USB. Ha valahova USB kell, ott vélhetően mást is kell csinálni. Noh meg míg a Microchip ad arra, hogy egy procit DIP tokban gyártson, addig az Atmelnek nem éri meg. Ha én arról az oldalról nézem, én sem gyártanék.
Egy TQFP tok, könnyűszerrel beforrasztható. TQFP-ben mindegyik kapható már.
Gyártásban, fejlesztésben a DIP tok halott. Az max a játékra próbapanelen jó. Azért meg én nem biztos nem gyártanék DIP tokot. Évi 20-30 darabért, mert vannak olyanok akik előbb összeszenvedik próbapanelon, mint hogy inkább elkészítenék a nyákot és abban próbálnának. Merthogy ritka az az áramköri fejlesztés (nálam) amit egyáltalán próbapanelen ki lehet próbálni.

Én is szomorkodom viszont, hogy egy FT232 árából, több proci is lazán kijönne. De hát a kompatibilitást meg kell fizetni! És itt van inkább a hangsúly.

Nekem nem borsódzik a hátam a szoftveres USB-ről. Működik, egyre jobban, szép számmal születnek driverek. De ahova biztos USB kapcsolat kell, oda FT232 a nyerő, nem is merek mást betervezni.

Itt most inkább visszakérdeznék. Létezik elterjedt FTDI alternatíva? Mert nézegettem ezt a MAX meg TUSB IC-ket, de az aztán tényleg beszerezhetetlen.
Van a Cypress-nek is. Arról tud valaki tapasztalattal szolgálni?

TUSB3410 a RET-nél kapható. Van CP2101/2102 is, de az QFN tokozású.

QFN nem gond, reflowal lenne forrasztva. De 900Ft sok.

Mihez képest?
Én pl. ~4000 Ft-ért kaptam egy USB-RS232 átalakítót a boltban, ami csak egy szintillesztővel több, ráadásul a csatlakozó is olyan, hogy közvetlenül nem tudom rádugni a demókártya RS232 kimenetére, kell közé egy toldókábel is. Mégis megvettem, sőt, örültem is neki.

Melleslleg a hardveres USB-s megoldások közül most szerintem a PIC18F14K50 a legolcsóbb. SSOP tokozásban, nagytételben nettó 350 Ft (bruttó 438 Ft).

Ugyanakkor azt az RS232-t tudod hasznalni az osszes projectedhez. Bbar ugye azokhoz meg kellene egy MAX232 vagy valami hasonlo illeszto... amit amugy szinten el lehet kesziteni kis modulban es definialni neki egy pin headeres csatlakozot amit az ember mar tud mindegyik projectjehez hasznalni. Nyilvan egy sorozatgyartasnal mar megint maskepp kell gondolkodni...

Haha, ezt a povray-el keszitett panelt talaltam
Bővebben: Link

Hello!
PIC-ben járatlan, AVR-ben és ARM-ben (LPC2106 és 2366) többéves tapasztalattal rendelkező emberkeként kérdezném, hogy melyik PIC-kel érdemes elindulni? Valami ATmega32-höz hasonló kellene, ami DIP40-es tokú, egyszerű felprogramozni, használható rajta egyszerre I2C, SPI és UART is (ahogy néztem, a 18F4550-ben az I2C-s lábakat az SPI is használja, vagyis ez számomra finoman fogalmazva sem vonzó), és valami olcsóbb csomagküldőn is megrendelhető (pl TME, nem a dupla felárú FDH)

Azt nem tudom melyik pic kellene neked
De azt tudom honnan érdemes megvenni !
http://www.chipcad.hu/

Van egy házi tákolmány AT90USB-s panelom (hát a vezérlő csillagászati árú volt - 5500 HUF TME-n keresztül), nem is vagyok tőle elragadtatva. Az tény, hogy van az ATmel FLIP-je, de azzal már nem lehet a FUSE biteket állítani, így a szerencsétlen vezérlő továbbra is 2 MHz-en ketyeg a beépített DIV8 funkciónak hála (hogy az atmel is elmegy a sóhivatalba...), míg hát a pony még hírből sem ismeri a szériát, így hát haladni sem lehet vele. Pedig kéne, mert kész hozzá a dj pult, találtam hozzá MIDI implementációt, de az órajel osztása miatt semmi sem megy rendesen, szóval én az atmel usb-itől tartózkodnék. Új programozó kéne hozzá, JTAG-re meg egyelőre nem akarok pénzt adni

Avrdude v.>=5.6 supportolja az AT90USB* kontrollerleket. Egy STK200 meg 5 db ellenállás+ csatik. Egy LPT portos gép meg azért még nem annyira beszerezhetetlen.

Na ez életet ment. LPT kábelt használom már lassan 2 éve programozásra, sajna ennél elakdtam. De eztet kipróbálom. Köszi szépen. Mellesleg arról tudtok valamit, hogy PCI-> LPT - COM átalakítóval működik a letöltés ponyval vagy egyébbel?

Azok szoktak működni, mert szinte teljesen egyenértékűek az alaplapi portokkal, csak be lehessen a címüket állítani az égetőprogramban.

SPI es I2C-t ugyanaz a modul valositja meg, ezert vannak ugyanazon a labon... Ha neked mindkettore szukseged van, akkor egy olyan tipust kellene kinezned, amelyikben 2 SPI ill 2 I2C van, es akkor Te mondod meg neki ket db I2C, 2 db SPI avagy egy SPI es egy I2C kell neked... (en csak J sorozatbol talaltam ilyeneket, amelyek 3.3V-osak, raadasul TQFP-s tokozasu).

Gyanitom, hogy amennyiben 4550-essel szeretned megoldani akkor valamelyik kommunikaciot szoftveresen kell megoldanod -- nem egy nagy ordongosseg as sem szerintem.

Ha nem feltétel az 5V-os táp, megfelel a 3,3V is, akkor a 18F45J10 szerintem jó lenne neked. Ez DIP tokban (is) lakik, chipcad-nél nettó 530Ft. Ebben két MSSP modul van, tehát lehet független I2C és SPI-t használni (amúgy én sem értem a logikát, hogy microchipnél miért van egyben az I2C és az SPI)

Köszi szépen, valszeg ez lesz a nyerő.

Megfontolandó, hogy az adatlapja szerint ennek nagyon kicsi az újraprogramozhatósági száma (endurance). Kísérletezéshez, debuggoláshoz nem ajánlom.

Ez jogos eszrevetel, ezt a tipust nem hobby celokra fejlesztettek ki.

Ezt nemis figyeltem. Bár szerintem a néhányszáz lehetőség elég egy olyan embernek, aki már nem kezdő a kontrollerek terén. Ha meg tönkremegy, végülis nem egy nagy összeg venni másikat.