De complete code ineens omzetten geeft te veel problemen.
Daarom ga ik ook eerst met de macro's aan de slag.
En het plan is om later de macro's staps gewijs te verwijderen.
Was je nog verder gekomen met de Delphi kant ?
De laatste versie staat nog steeds een aantal posts verder naar boven. Tenminste het interface gedeelte naar de dll. Hoe je het verder in gaat vullen met de commando's laat ik helemaal aan jou over.
Wat ik momenteel al gerealiseerd heb is het schrijven naar de PIC EEPROM (1 byte schrijven per control message) en ook het uitlezen van de eeprom (8 bytes per control message). Bij het schrijven geef ik dan aan dat ik een EEPROM read write actie wil doen (in de request), ik geef het eeprom adres mee (in de index), en natuurlijk de waarde die ik er in wil zetten (in de value).
Lezen op dezelfde manier, alleen dan worden er 8 bytes vanaf het opgegeven adres teruggestuurd.
editje: read moest natuurlijk write zijn
Misschien dat ik nog wel eens wat met die interrupt commando's wil doen, das nog wel geinig voor bijvoorbeeld realtime data uitlezen. Bulk data is verder niet zo interessant gezien de kleine hoeveelheid data die je meestal overstuurd.
Voorlopig houd ik het eerst bij wat ik momenteel heb. Dat is in principe al meer dan voldoende 
Waarvoor dient dit stukje precies ?
banksel BD0IBC
clrf BD0IBC, BANKED ; set byte count to 0
movlw 0xC8
movwf BD0IST, BANKED ; send packet as DATA1, set UOWN bit
[Bericht gewijzigd door MMSoft op ]
Die registers zijn de endpoint buffer control registers. Via deze registers is het mogelijk om met de geintegreerde USB engine van de PIC te communiceren (de usb engine is eigenlijk een apart onderdeel binnen de microcontroller). Kijk maar eens in de datasheet onder het hoofdstuk 17.4, hierin wordt alles uitgelegd.
Waar het op neer komt, iedere endpoint heeft 8 registers toegewezen, 4 voor de inkomende endpoint en 4 voor de uitgaande endpoint. Zo'n groepje van 4 bytes heet een 'buffer descriptor'. Er kunnen maximaal 64 van deze descriptors gedefinieert worden. Ze staan altijd gemapped in het geheugen vanaf adres 0x400. Als je de USB module overigens niet activeert, kun je dit geheugen als normaal werkgeheugen gebruiken, maar wanneer USB aan staat worden het 'automagisch' special function registers
De 4 registers zien er altijd als volgt uit:
BDnSTAT : Status register
BDnCNT : Byte Count Register
BDnADRL : Adress (low) van endpoint buffer
BDnADRH : Adress (high) van endpoint buffer
waarbij 'n' het endpoint nummer aangeeft
De assembly firmware heeft de buffers jammer genoeg iets ander benoemd (voor de verwarring), voorbeeldje voor inkomende endpoint 0:
BD0STAT = BD0IST
BD0CNT = BD0IBC
BD0ADRL = BD0OAL
BD0ADRH = BD0OAH
Wat je feitelijk met deze registers kan doen is de interne USB engine vertellen waar je inkomende en uitgaande data naar toe geschreven moet worden (mbv de pointer BDnADRH:BDnADRL) en hoeveel bytes dat er getransporteerd moeten worden (mbv BDnCNT). Met BDnSTAT heb je nog wat extra controle mogelijkheden, maar als je dat allemaal wilt weten verwijs ik je naar de datasheet 
Bedankt voor de uitleg !
Toch nog een vraagje.
banksel BD0IBC
Wat doet Banksel hier nu ?
Dit is toch bank select, maar waar wijst deze nu precies naar ?
Naar de bank waarin het register 'BD0IBC' staat of hoe moet ik dat zien...
Jep, daardoor wordt de bank geactiveerd waarin BD0IBC staat. Hierna kun je dan het register aanspreken met de toevoeging -BANKED.
Banking is overigens niet nodig voor alle normale Special Function registers en een aantal user registers (geloof 0x00 - 0x7F). Deze kun je direct aanspreken met de toevoeging -ACCESS. ACCESS mag je overigens ook gewoon weglaten, dit is namelijk de default van de assembler.
Ik ben nu (pas) zover dat ik meerdere uitgangen kan aansturen door middel van Request, Value en Index.
Echter wel zonder gebruik te maken van de macro's.
De Led op B0 gaat direct branden (dat is/was ook al bij de orginele code), ik vindt echter niet waar deze aangestuurd wordt !
SHOW_ENUM_STATUS is uitschakeld !
Edit:
Ook al een beetje bezig met gegevens uitlezen:
retval := usb_control_msg(usbDev, USB_ENDPOINT_IN OR USB_TYPE_VENDOR OR USB_RECIP_DEVICE,
Command, Param1, Param2, buffer, 8, 100);
Welke waarde moet 'USB_ENDPOINT_IN' hebben ?
[Bericht gewijzigd door MMSoft op ]
De Led op B0 gaat direct branden (dat is/was ook al bij de orginele code), ik vindt echter niet waar deze aangestuurd wordt !
SHOW_ENUM_STATUS is uitschakeld !
Opgelost, PortB was ongedefineerd (CLRF PortB, was de oplossing)
Goed om te horen dat de problemen zijn opgelost.
Op 24 juni 2006 17:14:50 schreef MMSoft:
Edit:
Ook al een beetje bezig met gegevens uitlezen:retval := usb_control_msg(usbDev, USB_ENDPOINT_IN OR USB_TYPE_VENDOR OR USB_RECIP_DEVICE,
Command, Param1, Param2, buffer, 8, 100);Welke waarde moet 'USB_ENDPOINT_IN' hebben ?
USB_ENDPOINT_IN staat gedefinieerd in de laatste versie van de DLL interface, die ik een stukje verder naar boven gepost heb.
Daar staat:
USB_ENDPOINT_IN = $80;
Dan zou het ontvangen moeten lukken.
Het ontvangen lukt nu ook !
Ik krijg 8 byte's binnen, zou het mogelijk zijn om slechts 1 byte binnen te halen (er zijn niet altijd meerdere byte's nodig) ?
In Delphi in de 'usb_control_message', de parameter size van 8 wijzigen in 1 werkt niet.
usb_control_msg(usbDev, requesttype, request, value, index, buffer, size, timeout);
Kijk naar de return value van de usb_control_msg. Deze returned < 0 als er een error was (fout in USB device, of disconnected) of als >= 0 het aantal bytes dat er verzonden / ontvangen is.
Het binnenhalen van 1 byte moet je dus wel regelen in je firmware, daar zet je het byte count register op 1. Vervolgens controleer je dit in delphi met behulp van de returnvalue.
Dat werkt nu ook !
Nu wil ik wat code in de PIC gaan plaatsen.
Code die continu bezig is met vanalles.
Waar zou deze het beste geplaatst kunnen worden, zodat de USB connectie niet wordt verstoord ?
Het verstoren van de USB connectie kan je voorkomen door de USB afhandeling geheel via interrupts te laten verlopen. Ik heb er zelf al over zitten nadenken, maar heb er nog geen tijd voor gehad om dit te doen.
Als je kijkt naar de routine 'ServiceUSB', die constant vanuit je mainloop wordt aangeroepen, dan zie je dat daar niks anders in gebeurd dan pollen van de interrupt flags. Het enige dat je dus hoeft te doen is de betreffende interrupts te enablen en deze op te vangen in de Interrupt Service Routine (ISR). Daar voer je dan de code uit die in 'ServiceUSB' staat.
Met interrupts hoef je je geen zorgen meer te maken om de USB communicatie, deze draait dan lekker onafhankelijk van de mainloop. Daar mag je dan netzoveel pauzes en rommel ingooien wat je maar wilt. De communicatie tussen je mainloop en USB vereist dan wel wat extra werk. (zie het als 2 aparte threads in delphi, communicatie tussen beide zul je moeten syncroniseren op de een of andere manier).
Je kunt overigens best wel wat rommel in je mainloop plempen hoor, maar alst veel langer duurt dan 1msec, dan wordt het oppassen, windows kan dan denken dat de device disconnected is oid.
Als er iets gelezen of gestuurd wordt, dan stuurt Delphi
een control_message naar de PIC.
Dus de PC bepaald wanneer er gekeken/gestuurd wordt.
Zou het mogelijk zijn om de PIC een signaal naar de PC (Delphi) te laten sturen, en dat het PC programma daarop reageerd ?
(Dus zonder dat Delphi continu control_message's hoeft te sturen als er op bijvoorbeeld 1 ingang van de PIC wordt gewacht)
Nee, dat is het grote probleem van USB, alle acties worden vanaf de PC opgestart. De zogenaamde interrupt transfers zijn ook niet wat ze lijken, dit houdt gewoon in dat de device precies 1x per milliseconde (minimum frame tijd) wordt gepolled op nieuwe data. Denk bijvoorbeeld aan een muis, die periodiek gerefreshed wordt.
Je kunt dus alleen met behulp van pollen (handmatig, of automatisch via interrupt transfers) communiceren van microcontroller naar PC.
Lees ook dit verhaal eens, in het bijzonder de interrupt transfers.
Ik ben weer een klein stukje verder.
Kan nu een Pot.Meter die aangesloten is op A0 uitlezen.
KillerB the Supreme, ben jij nog met dit project bezig ?
Ik ben er nog steeds mee bezig, maar het USB gedeelte is wel af voor dit project. Communicatie werkt beide kanten op. De controlmessages geven meer dan genoeg bandbreedte voor de meeste microcontroller projecten, dus hier laat ik het even bij. (complete eeprom uitlezen, 256 bytes, doe ik nu in 0.25 seconde)
Voor een vervolg project zal ik nog eens kijken hoe ik de usb routines via interrupt kan laten verlopen, dat maakt de main routine wat minder kritisch. Handig voor als je veel delays hebt enzo.
Ik ben nu zover dat ik nieuwe Firmware heb voor de K8055 (USB Experiment interface board) van Velleman.
Op dit Boardje is de weerstand R35 verwijderd, en het kristal van 6 Mhz vervangen door 20 Mhz.
-8 Uitgangen aansturen
-5 Ingangen inlezen
-2 Pot.meters inlezen (zowel '8 Bits: 0...255' en ook '10 Bits: 0...1023')
-2 PWM uitgangen.
Edit:
www.mmsoft.nl.nu
Onderaan 'PIC - USB Project K8055.zip'
[Bericht gewijzigd door MMSoft op ]
Op 18 juni 2006 15:43:24 schreef KillerB the Supreme:
Ik vind het ook raar dat het niet werkt met die zips van lycos.Maar goed, ik heb hem via de mail binnen, en hij lijkt prima te werken. Ik kan er in ieder geval naar connecten vanuit delphi.
Ik denk overigens dat ik de macro's er gewoon in laat zitten, is wel zo makkelijk. Dingen die ik zelf toevoeg zullen overigens zonder macro's zijn.Ik heb ook een nieuwe versie van de DLL interface voor delphi online gezet. Niet alles van de originele dll is vertaald, maar alles wat je nodig hebt voor delphi staat er in principe in. Ik heb er nu overigens een aparte unit van gemaakt. Routines als OpenDevice enzo komen ergens anders in te staan, bijvoorbeeld in je hoofdunit, of een eigen unit speciaal voor usb routines. Ik heb het laatste gedaan, wel zo overzichtelijk. Laat me even weten of je er problemen mee hebt
Ik probeer deze interface te douwnloaden maar de link werkt niet!
Heb je hier iets aan:
www.mmsoft.nl.nu
Kies: Elektronica (PIC Microprocessors)
Zie: Eigen firmware t.b.v. K8055 (incl. PC programma)
[Bericht gewijzigd door MMSoft op ]
Ziet er mooi uit. Heb hem al bij mijn favorites gezet.
Maar ik ben op zoek naar de DLL interface voor Delphi.
Ik zou graag zelf een applicatie in delphi maken met de usb.
Ik ben een jaar geleden gestart met de 18F2555
http://pe.ece.olin.edu/ece/projects.html
heb verschillende test gedaan met HID en PIC maar door omstandigheden gestopt.
gebruikte delphi met JDI USB component maar ben alles verloren geraakt.
Heb toen ICD2 (RdSs232) gebouwd ben nu zinnes om ICD2 USB te bouwen
http://www.icd2clone.com/wiki/Main_Page
Ben op zoek gegaan naar JDI component maar kan het niet terug vinden op het net.
Ben toen op dit forum terecht gekomen bij de DLL interface
[Bericht gewijzigd door are op ]