Voor mijn afstudeerproject moet ik een IO interface gaan ontwikkelen met een daarbij behorend programma. Het programma is al voor een gedeelte gedaan. Dit is in Visual basic 6.0 geschreven. De opbouw van interface is ook voor het grootste gedeelte klaar. Alleen de communicatie moet nog. In het verleden heb ik dit al een keer gedaan door middel van RS232. Maar omdat er zeer snel en veel communicatie moet zijn zou ik dit liever met USB willen doen.
Is dit mogelijk om een Atmega32 met een pc te laten communiceren via usb en levert dit eventueel problemen op op de pc. heb namelijk al op verschillende plekken zien staan dat er dan een driver ontworpen moet worden ontworpen en dat het lastig te programmeren is in vb6. Hier heb ik dus geen verstand van (driver). Is dit mogelijk en/of moelijk?
Thanx en de groeten!
Erik
Tsja... Wat is 'veel' en wat is 'snel'? Als je RS232 een beetje fatsoenlijk implementeert kan het 115200bps, ofwel iets van 10k/sec aan (gok er even op dat die AVR dat ook haalt). Voor wat I/O lijkt mij dat ruim voldoende. Of een winshit PC dat bijsloft weet ik niet. Onder Linux of DOS is het geen punt.
Dat gaat opschieten... USB converteren naar iets wat op de UART aangesloten kan worden... Kun je net zo goed direct RS232 nemen...
shortcircuit, het is wel een nette pagina, maar idd usb naar UART geeft weinig verschil. Maar misschien staan er nog leuke dingen in.
golden member, De bedoeling is dat de interface ook datalogging gaat verrichten van analoge signalen. verder heeft hij de normale in en output functies en komt er nog een counter op. Het nadeel is dat deze allemaal tegelijk meoeten kunnen lopen. Ben bang dat ze elkaar in de weg gaan lopen.
usb pinnen op io brengen naar microprocessor en zelf een protocol schrijven in microprocessor.
heb hier nog een goed boek over usb via amazon aangeschaft waar het volledige protocol wordt uitgelegd
zelf protocol schrijven?
Lijkt me leuk, maar ben bang dat dat niks gaat worden. heb ik de kennis, ervaring en tijd niet voor ben ik bang. Wel jammer.
Welk boek is dat? Misschien ff kijken, het is wel een uitdaging 
!
Zeg maar gewoon Marco hoor 'Golden member' betekent alleen maar dat ik wat gedoneerd heb voor de kosten van deze site. Moet je ook eens proberen!
Voorlopig zie ik nog geen enkel probleem. Tenzij je natuurlijk real-time high speed I/O wilt gaan doen, maar daar ga ik niet vanuit omdat je onder winshit bezig bent. Even uit de losse pols: 10kb/sec (makkelijk rekenen). Elke AD conversie levert vast een word op. Identifier byte erbij. Checksum oid. erbij. 4 bytes/conversie. 2560 conversies per sec (als je de volledige bandbreedte hiervoor wilt gebruiken). Dan nog wat normale input, maar dat kan op commando. Kost dus weinig bandbreedte. Output is de andere kant op, dus dat telt ook niet mee. Hoogstens nog een ACK byte of zo. Kortom: wat wil je precies...
Voordeel is ook nog dat die UART hardwarematig is, als je het met USB wilt doen en alles zelf moet programmeren verwacht ik eerder snelheidsproblemen aan je AVR kant.
Haha, sorry marco, keek ff snel wat je naam is, en keek dus verkeerd.
Maar nu jij die berekening zo maakt lijkt het mij dus logisch dat ik gewoon RS232 moet gebruiken. Wat bedoel je eigenlijk met die realtime IO? Snap de uitdrukking real time niet zo, sorry.
Maar de input is inderdaad op commando. Dus dat is geen probleem. Counter eigenlijk ook. Het gaat dus inderdaad op de datalogging. Ik denk dat als ik 100 signalen binnenkrijg op de pc is het al snel genoeg. Dus ik ben bang dat ik voor niks aan USB gedacht heb.
En trouwens, heb hier nog niet zo veel ervaring in al zou ik dat wel moeten hebben, sorry, maar bedankt voor je hulp!
De definitie van 'real-time' is doorgaans zoiets als 'binnen een vast gedefinieerde tijd'. Dat gaat op een mutli-tasking (kuch) systeem (alweer kuch) als winshit dus never nooit niet lukken (om maar eens wat krom taalgebruik te plegen).
Met alle respect voor je ervaring / kennis niveau... Je gaat er nog wel even klus aan krijgen om het leuk draaiend op die AVR te krijgen. Ik weet niet in welke taal je dit wil gaan doen, maar denk heel erg goed na over je protocol en de structuur van je software. Het zal 'zwaar' interrupt-driven zijn. Da's niet moeilijk als je het foefje eenmaal door hebt. Een rotgeintje van Atmel: Bij een interrupt wordt je flags register niet op de stack gezet. Als je in je ISR daar dus wat in verandert (en dat doe je al snel), kan dat de meest verrassende gevolgen hebben. Goed opletten dus! (mocht je het in C willen doen... misschien lost de compiler dat voor je op, geen idee).
Oh okay. Nee dat kan in winshit om met jouw termen te blijven praten inderdaad niet. De taal die ik ga gebruiken is C (op de uc tenminste, op de pc vb6). Tijdens mijn opleiding heb ik ook al een keer een IO interface ontworpen dus heb al wat ervaring. Daar is toen ook een temperatuur sensor aangehangen. De communicatie lukte wel maar de waardes die binnen kwamen waren niet echt betrouwbaar (waarschijnlijk rekenfout) en deze kwamen per 0.1 sec binnen. hier zijn toen inderdaad veel problemen op getreden bij het protocol, maar is uiteindelijk wel gelukt.
Nu wil ik de snelheid dus ophogen, maar misschien zijn ze met deze snelheid ook wel tevreden, al zal ik zelf dat niet zijn!
Ik ga d'r nog ff over nadenken. Bedankt voor je hulp en tijd!
Captnoord
mov eax, 0x666
Ik wil jullie jongens niet in de fingers snijden door dit te zeggen, maar ATMEL heeft ooit de code gekocht van ene rus (genaamd igor) die USB 1.1 had draaien op een AT2313 overgeklockt op 12Mhz. Nu kan je er van uitgaan dat die code ook werkt op de ATTINY2313 die standaard op 20Mhz als max heeft dus dan hoef je dus niet over te klokken.
http://www.cesko.host.sk
hmmm stond dus ook op die andere site
http://unpythonic.net/avr/usb deze dus.
Veel programeer plesier gewenst.
De eerste link doet niets (op dit moment), de 2de levert een programmer op. Leuk en aardig, maar als je al moet gaan overclocken op een 10MHz uC, alles in software zit, is het dus best 'zware' software. Blijft er weinig tijd over voor andere dingen. Zou je nog enige transferrate halen? Dus alhoewel functioneel het wel zal werken, betwijfel ik of het per saldo op een 20MHz uC 'sneller' zal zijn. Wie probeert het? 
Als je toch nog naar USB wil gaan, kijk dan eens naar de IC's van FTDI.
http://www.ftdichip.com
Dan moet je zelf niets van het USB-protocol kennen...
DIP-Modules kan je zo in hun webshop bestellen:
bv. DLP-USB245M
Roland van Leusden
It's the rule that you live by and die for It's the one thing you can't deny Even though you don't know what the price is. It is justified.
Blijft er weinig tijd over voor andere dingen. Zou je nog enige transferrate halen? Dus alhoewel functioneel het wel zal werken, betwijfel ik of het per saldo op een 20MHz uC 'sneller' zal zijn.
* receiving of infrared code (time diagram of received code) (it is transmitted to serial line in real time too) (receiving of infrared code makes microprocessor without PC - zero usage of PC CPU)
* control of 8-bit input-output data gate (every bit can be independently input or output, there can be independently controlled pull-up resistors on input pins)
reading and writing of internal 128 byte EEPROM (storing of data after no power state - for users is accessible all memory)
* transmitting or receiving char via serial line
(now only one non buffered char - but by firmware change is possible to make internal buffer (for injury of infra buffer) : like FTDI chips)
* change of baudrate of serial line in range cca 4800Baud to 700 000Baud (after power on is 57600baud)
("Classical" baudrates are: 4800, 9600,19200,38400,57600. Device DLL automatically detects invalid baudrates.)
Snel genoeg dus om naast USB nog wat extra dingen te doen.
De makkelijke manier is met een FDTI chip. Zowel in de AVR als op de PC doe je net alsof je tegen een serieel device kletst alleen zit er een USB<->Serial converter tussen.
Ik gebruik dit in mijn logic analyser en daar gebruik ik een baudrate van 500k met de VCP driver van FDTI zonder problemen. Ik heb ook 1Megabit geprobeerd, maar dat gaat niet altijd goed, blijkbaar houdt de PC dat niet vol. Dan moet je zelf tegen de DLL's van FTDI aankletsen en zou je tot 3Mbit kunnen gaan.
Ik weet trouwens niet of je op een AVR zulke hoge baudrates kan selecteren, met een PIC was dat geen probleem en ik denk dat dat bij een AVR ook wel in te stellen is.