Je code draait dan niet meer, dus de led zal niet meer aan of uit gaan. Maare waarom wil je eigenlijk het kristal eruit halen? Laat deze er gewoon inzitten ;)

Nee, ik bedoel dat de LED niet meer knipperd (terwijl het kristal aanwezig is).
LED A0 kan ik wel aan/uit schakelen.

De kristal had ik alleen even verwijderd om te kijken wat voor invloed dit had op Speedtest :)

[Bericht gewijzigd door MMSoft op ]

Oh die knipperende led, dan moet je even naar de opbouw van de main routine kijken.

De knipperende led gebeurd pas als de device door de software is geconfigureerd. Configuratie (zie ook 'set_config.exe' van de voorbeelprogrammas) kun je er heen sturen met de volgende opdracht:


  const
    USB_TYPE_STANDARD = $00;
    USB_REQ_SET_CONFIGURATION =	$09;

  usb_control_msg(udev, USB_TYPE_STANDARD OR USB_RECIP_DEVICE, USB_REQ_SET_CONFIGURATION, 1, 0, buffer, 0, 100);

Met Delphi werkt het (nog) niet.
Set_config.exe werkt wel.
LED A0 gaat aan, en LED A1 knipperd dan.

(Het is zelf mogelijk terwijl Delphi verbonden is met de Device, om met Set_config.exe de LED te laten knipperen.
Dus 2 programma's gelijktijdig toegrijpen op 1 Device).

Ik ben nu bezig om 'SHOW_ENUM_STATUS' uit te schakelen.
Daarvoor heb ik voor elke regel die hier mee te maken heeft
een puntkoma ';' geplaatst.
Compileren gaat goed, alleen als ik de PIC prog, dat krijg ik een fout melding tijdens het Veriferen:
Error in Program Memory

Haal ik de puntkoma's weg, dan is het goed....

[Bericht gewijzigd door MMSoft op ]

Hmmm ik zal er straks even naar kijken waarom die setconfig niet werkt, ik heb het net even snel uit de set_config.exe gekopieerd en vertaald.

Die show_enum_status mag je in principe allemaal weghalen hoor. Dat je programmer daar een fout op geeft is heel raar, aangezien het gewoon code is wat tussen deze directives staat. Er zijn geen rare foutmeldingen bij het assemblen?

Met welke programmer werk jij als ik vragen mag? Ik heb hier momenteel een zelfgemaakte ICD2 kloon, dat werkt echt prima, direct vanuit MPLAB programmeren en debuggen.

Ik gebruik: MPLAB IDE v7.31

Ik de ASM file even mailen ...

Edit:
Set_Config is gelukt:


procedure TForm1.Button6Click(Sender: TObject);
//set_config
Var
  buffer : array[0..7] of Char;
begin
  If assigned(usbDev) then
   usb_control_msg(usbDev, USB_TYPE_STANDARD OR USB_RECIP_DEVICE, USB_REQ_SET_CONFIGURATION, 1, 0, buffer, 0, 100);
end;

[Bericht gewijzigd door MMSoft op ]

Ik heb je ASM file getest, deze werkt prima, zolang ik in de configbits het volgende aangeef:

config BORV = 21

Maar dat had te maken met de MPLAB versie geloof ik. Ik werk met v7.20

Programmeren gaat ook goed en met delphi kan ik de device ook prima vinden. Als ik de config uit delphi doe, dan werkt het prima, dan gaat de led knipperen. Let er op dat je in de assembly code nog wel de TRISB goed zet! Door het weghalen van de show_enum_status haal je ook de TRISB weg. Deze moet je even opzoeken in de code.

Oh ja, de eerste parameter van usb_control_msg moet geen udev zijn, maar usbDev. Maar dat had je vast al wel in de gaten.

edit

Dat had je inderdaad dus al gezien ;)

Ik heb je ASM file getest, deze werkt prima, zolang ik in de configbits het volgende aangeef:

config BORV = 21

Maar dat had te maken met de MPLAB versie geloof ik. Ik werk met v7.20

Inderdaad bij v7.31 kan je max. 3 opgeven (dacht ik).

Let er op dat je in de assembly code nog wel de TRISB goed zet! Door het weghalen van de show_enum_status haal je ook de TRISB weg. Deze moet je even opzoeken in de code.

TRISB was inderdaad het probleem, nu werkt het !

[Bericht gewijzigd door MMSoft op ]

Ik denk eraan om er nog een paar uitgangen bij te progen.

Lijkt je dat verstandig, of heb je nog grote wijzigingen in gedachten ?

Op 11 juni 2006 15:14:21 schreef MMSoft:
Ik denk eraan om er nog een paar uitgangen bij te progen.

Lijkt je dat verstandig, of heb je nog grote wijzigingen in gedachten ?

Je mag ze er bij proggen hoor, ik zal alleen de overige DLL commando's er nog bij zetten, en dan alles in een aparte unit plaatsen.

Ok, dan ga ik daar mee bezig.....

ha, ik heb de doorvoersnelheid inmiddels met een factor 5 kunnen verhogen. Dit is nog wel steeds op het niveau van control commando's, niet op bulk data oid.
Je moet maar eens kijken naar de usb_control_msg, je kunt daar namelijk naast de requesttype ook een 16bits request en value meesturen :)

overzichtje:


function usb_control_msg (dev : Pusb_dev_handle; requesttype, request, value, index : integer; 
  bytes : Pchar; size, timeout : integer): integer; stdcall; external 'libusb0.dll';

Voor requesttype hadden we voorheen 'SET_RA0' of iets dergelijks. Nu kun je dit heel mooi aanpakken door bijvoorbeeld te zeggen:
requesttype = CONTROL_LED
en dan request = LED1, LED2, LED3 (bedenk zelf maar iets)
en value = ON of OFF (misschien wel 50% PWM oid, tis maar wat je er zelf van wil maken)

Echt super, op deze manier kun je zelf al commando's en parameters meesturen. De doorvoersnelheid is in principe 5 keer hoger, aangezien requesttype = 8bit, request en value = 16bits.
Als je wilt weten hoe je de parameters kunt opvangen in assembly code, kijk dan even bij de Vendorrequests, je ziet daar al staan:


USB_buffer_data+bRequest   --> Dit is de requesttype (8bits)

Daar komt dan nog bij:


USB_buffer_data+wValue      --> Dit is de request (lower 8 bits)
USB_buffer_data+wValueHigh  --> Dit is de request (upper 8 bits)
USB_buffer_data+wIndex      --> Dit is de value (lower 8 bits)
USB_buffer_data+wIndexHigh  --> Dit is de value (upper 8 bits)

Probeer het eens uit zou ik zeggen :)

Ik heb het 3 keer gelezen, maar ik begrijp het nog niet helemaal...

Wat moet ik wijzigen in Delphi, en wat in de PIC ?
Graag één klein voorbeeldje voor de LED op A0 bijvoorbeeld.

Edit:
Het kwartje begint te vallen :)
Toch is een voorbeeldje welkom...

[Bericht gewijzigd door MMSoft op ]

OK, voor de PIC zijde:



#define	CONTROL_LED			0x00

#define LED1				0x00
#define LED2				0x01
#define LED3				0x02

#define LED_ON				0x00
#define LED_OFF				0x01


  MOVF USB_buffer_data+bRequest, W, BANKED
  select
    case CONTROL_LED                          ;Als requesttype = CONTROL_LED
      MOVF USB_buffer_data+wValue, W, BANKED
      select
        case LED1                             ;Als request = LED1
          MOVF USB_buffer_data+wIndex, W, BANKED
          select 
            case LED_ON                       ;Als value = LED_ON
              BSF PORTB, 0
              break
            case LED_OFF
              BCF PORTB, 0
              break
            ends
          break
        case LED2
          MOVF USB_buffer_data+wIndex, W, BANKED
          select 
            case LED_ON
              BSF PORTB, 1
              break
            case LED_OFF
              BCF PORTB, 1
              break
            ends
          break					
        case LED3
          MOVF USB_buffer_data+wIndex, W, BANKED
          select 
            case LED_ON
              BSF PORTB, 2
              break
            case LED_OFF
              BCF PORTB, 2
              break
            ends
          break
        ends				
      break
    case ...
      (andere commando afhandelingen hiero)
    break	
  ends

Ik vind het allemaal nog wat omslachtig met die assembly macro's maar het idee is er denk ik.

En zoiets voor de PC zijde:


procedure TForm1.Button8Click(Sender: TObject);
var
  buffer : array[0..7] of Char;
  requesttype: Integer;
  request: Integer;
  value: Integer;

begin
//usb_control_msg(dev,requesttype,request,value,index,bytes,size,timeout)
//
//USB_buffer_data+bRequest    --> Dit is de requesttype (8bits)
//
//USB_buffer_data+wValue      --> Dit is de request (lower 8 bits)
//USB_buffer_data+wValueHigh  --> Dit is de request (upper 8 bits)
//
//USB_buffer_data+wIndex      --> Dit is de value (lower 8 bits)
//USB_buffer_data+wIndexHigh  --> Dit is de value (upper 8 bits)

requesttype := 0;  // = 'CONTROL_LED'
request :=  1;     // = 'LED1'
value := 100;      // = 100%

  If assigned(usbDev) then
    usb_control_msg(usbDev, requesttype, request, value, 0, buffer, 0, 100);

end;

Je snapt het al aardig. In principe kun je de value zo doen als jij dat wil, maar je moet het wel aan beide kanten gelijk houden, dus ook in de assembly code. In het voorbeeld dat ik gaf zou je dan 0 of 1 moeten sturen ipv 100. (LED_ON = 0, LED_OFF = 1). Maar het is helemaal wat je er zelf van wilt maken hoor, het is jouw feestje :D

Als ik dit stuur:
requesttype := 0; //CONTROL_LED
request := 1; //LED2
value := 0; //ON

Dan moet de LED op PORTB, 1 toch aan gaan ?
(die blijft uit)

Jep dan zou die aan moeten gaan. Ik heb de code verder niet getest ofzo. Ik heb gewoon wat achter elkaar geklopt aan code. Die assembly macro's zijn ook nogal nieuw voor mij dus ik weet ook niet zeker of dat helemaal goed is. Het gaat een beetje om de grote lijnen. Probeer anders eens te debuggen, kijk op welk punt de code komt. Dit kun je misschien het beste doen door wat andere ledjes aan te zetten op strategische punten in de code.

Die assembly macro's zijn inderdaad wel wennen !

Ik ben intussen ook aan het zoeken naar een mogelijkheid
om gegevens uit te lezen.
Bijvoorbeeld een register inhoud naar de PC sturen.
Heb je hier al een mogelijkheid voor gezien ?

Dat is inderdaad ook de volgende stap voor mij, maar ik heb er nog niet echt iets voor gezien. Ik denk dat het via een IN-Token moet gebeuren.

Tenminste, zoals ik nu denk dat het ongeveer zou moeten:

- verstuur een usb_control_msg naar de microcontroller, met een commando waarin je aangeeft wat je wil ontvangen
- De microcontroller plaatst de gewenste data in de uitgaande buffer (van endpoint 0)
- De PC verstuurd een IN-Token waarbij de gebufferde data teruggestuurd wordt naar de PC.

Nu nog uitvogelen hoe dat zou moeten. Ik denk dat ik even naar die andere Lab firmwares ga kijken. Meen dat in Lab4 iets stond over terugsturen. Zie ook: http://pe.ece.olin.edu/ece/projects.html

He ik zie overigens dat ik een fout heb gemaakt in de bovenstaande voorbeelden.
Requesttype is namelijk iets anders. Je moet gebruiken:
request, value en index in de delphi code, dit komt dan overeen met USB_buffer_data+bRequest, USB_buffer_data+wValue en USB_buffer_data+wIndex. Is opzich ook logischer natuurlijk ;)

Vandaar dat het niet werkten :)

Ik was er al een beetje mee bezig geweest, maar het wou niet...

Tijdens het doorgronden van de PIC code kom ik enkele dingen tegen die ik niet ken.


bank0		udata                    ;?
COUNTER_L	res		1        ;res 1 ?
STARTUP		code		0x0000   ;code  ?

Wie kan hier wat uitleg over geven ?

Edit:
Ook probeer ik de macro's te vervangen door normale ASM code:


			forlf USB_loop_index, 1, USB_packet_length

            ;(START OF A FORLF-NEXT LOOP)
            ;forlf		macro		index,begl,endf
			;movlw		begl
			;movwf		index,BANKED
            ;_for#v(_forcount)
			;movf		index,W,BANKED
			;subwf		endf,W,BANKED
			;btfss		STATUS,C,ACCESS
			;goto		_next#v(_forcount)
			;variable	_forstack#v(_forstackptr) = _forcount
            ;_forstackptr ++
            ;_forcount ++
			;endm

Hoe pak ik dit aan bij 'forlf' ?

[Bericht gewijzigd door MMSoft op ]

bank0 udata -> Geeft aan dat er variabelen dedeclareerd gaan worden, deze kunnen geplaatst worden in bank 0
COUNTER_L res 1 -> Reserveer 1 byte voor counter_L. Ass: COUNTER_L equ x
STARTUP code 0x0000 -> Geeft een code blok aan, startend op fysiek adres 0. Ass: org 0x0000

Die macros ben ik ook niet echt in thuis, ik laat ze maar eerst voor wat het is...

Bedankt voor de uitleg.

STARTUP code 0x0000 -> Geeft een code blok aan, startend op fysiek adres 0. Ass: org 0x0000

Met code bedoel je instrukties (Programma memory) ?