• AVR Freaks

Helpful ReplyHot!Force Feedback Tutorial: PIC18F4550

Page: < 1234 Showing page 4 of 4
Author
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/09/27 12:04:53 (permalink)
0
Coman
There is one think i'd like to ask from you, gpaolo.
Once you finish the firmware for the 16 bit processor, could you post here a complete version of it ?
( at least up to the point where forceedit will see it as a ffb device ).
 
Per i posteri, signore. Per coloro che in futuro, cercheranno una soluzione.
 
ps: i'm glad mister vtrx is still following the topic :)




I didn't get the notification of new replies!!
Of course I can post the 16bit version of your project once I get it working, no problem at all!
 
Just a curiosity, are you italian? Because I have noticed the comments in Italian… I'm Italian too, in case you wonder :)
 
So, I kept trying. I can't really understand what I am missing. I have installed Wireshark, I have used even at work, I just haven't thought about it for the USB.
 
When I plug the board I have:
GET DESCRIPTOR Request DEVICE
GET DESCRIPTION Response DEVICE
then twice configuration, then
SET CONFIGURATION Request
SET CONFIGURATION Response
SET_IDLE Request
SET_IDLE Response
 
This, in my understanding, it is the normal setup procedure for the USB device. 
Then I see:
GET DESCRIPTOR Request HID Report
GET DESCRIPTOR Response HID Report
 
In the last packet, I have the huge descriptor as defined in the code. 
First doubt: I understand where you said that there will be one report (ID:01) which contains the data from the joystick, from device to host, and then there should be another report (ID?) from the host to the device with the information of the FFB part. 
If I look at the packet, in the Main Item (Collection) I have the REPORT ID = 0x01, which contains everything, but I don't have any other report ID defined in the packet.
On the other hand, if I look in the definition of the report in usb_descriptor.c, I do see indeed only one report with ID 1:
 
ROM struct{BYTE report[HID_RPT01_SIZE];}hid_rpt01={{

 0x05,0x01, // Usage Page Generic Desktop
 0x09,0x04, // Usage Joystick
 0xA1,0x01, // Collection Application
    0x85,0x01, // Report ID 1
...

 
Starting from that point, I see only URB_INTERRUPT IN packets, which I understand contains the data from the joystick. I have tried to monitor if there is any request when I open ForceTest but there is no difference in the traffic.
 
It seems to me that there is something missing in the initialisation. It looks like the PC doesn't know that there are other reports available, or that the device has the capability to receive one.
What do you think?
 
 
 
 
 
#61
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/09/27 12:11:02 (permalink)
0
vtrx
You may have tried too many times and Windows is not updating the device in its list of drivers.
Change the PID, change a number and Windows will reinstall the driver


I did try, when I was trying the other VID/PID to see if that was the problem. It was indeed detected as a new device and reinstalled, but no change...
#62
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/09/27 13:15:32 (permalink)
0
Ok digging into the descriptor packet, I see the other report ID as "Main item (collection)". 
I have tried to set a breakpoint in USER_GET_REPORT_HANDLER and USER_SET_REPORT_HANDLER.
Is USER_GET_REPORT_HANDLER, it enters into case 0x22 (REPORT ID PID_POOL_REPORT) during initialisation, but it never enters into case 0x11 at any point. Even more odd, it never enters into USER_SET_REPORT_HANDLER function at any moment.
 
So it seems that this part that you have described:
 
I think the sequence is : pc sends SET_REPORT, so we handle it with this :
 USBEP0Receive((BYTE*)&pid_report[0], SetupPkt.wLength, USBSetEffect);
when the microcontroller receives the data, it will call USBSetEffect() function. That function initializes the effects ( writes some values in the data structures ), then prepares PID_BLOCK_LOAD_REPORT[] vector with the success/failure of creating an effect.

 
is never triggered...
 
 
#63
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/09/27 15:13:14 (permalink)
0
--- edit ----
I found the answer. This is due to the difference between standard requests and class specific requests, it's still not clear to me how the code distinguish between one case or the other, but anyway, the libraries are done in this way, there isn't anything custom here. 
 
Anyway, after another evening of struggle, my conclusion for today is: the PC never sends the request to write to the end point. I can see endpoint 0x81 IN and 0x01 OUT configured, but ultimately the PC only sends URB_INTERRUPT IN to endpoint 0x81.
I don't know if it is of any importance, but all messages that I see on wireshark are from protocol USB *except* for the SET_IDLE and GET DESCRIPTOR HID Report which are from USBHID protocol. 
I have found on another thread a program to send requests to the USB to write Report or Feature, but nothing happens on the microcontroller and I don't see any different packet either. 
I'm getting more and more convinced that it is a driver issue, that is not allowing the transmission towards the device. Why? No idea. 
 
Here below the original post...
 
---------------
 
ok things are getting less and less clear, which might be a clear indication that it's time to stop for today. I try with one last question.
In usb_ch9.h there are the definition of the bRequest codes, according to USB protocol:
 
#define USB_REQUEST_GET_STATUS 0 // Standard Device Request - GET STATUS
#define USB_REQUEST_CLEAR_FEATURE 1 // Standard Device Request - CLEAR FEATURE
#define USB_REQUEST_SET_FEATURE 3 // Standard Device Request - SET FEATURE
#define USB_REQUEST_SET_ADDRESS 5 // Standard Device Request - SET ADDRESS
#define USB_REQUEST_GET_DESCRIPTOR 6 // Standard Device Request - GET DESCRIPTOR
#define USB_REQUEST_SET_DESCRIPTOR 7 // Standard Device Request - SET DESCRIPTOR
#define USB_REQUEST_GET_CONFIGURATION 8 // Standard Device Request - GET CONFIGURATION
#define USB_REQUEST_SET_CONFIGURATION 9 // Standard Device Request - SET CONFIGURATION
#define USB_REQUEST_GET_INTERFACE 10 // Standard Device Request - GET INTERFACE
#define USB_REQUEST_SET_INTERFACE 11 // Standard Device Request - SET INTERFACE
#define USB_REQUEST_SYNCH_FRAME 12 // Standard Device Request - SYNCH FRAME
 
 
These codes match what I find in chapter 9 of usb protocol and they are stored in the SetupPkt.bRequest field.
 
From the usb_function_hid, I see in the USBCheckHIDRequest function the following code:
 
if(SetupPkt.bRequest == USB_REQUEST_GET_DESCRIPTOR)
    {
        switch(SetupPkt.bDescriptorType)
        {
            case DSC_HID: //HID Descriptor
                if(USBActiveConfiguration == 1)
                {
                    USBEP0SendROMPtr(
                        (ROM BYTE*)&configDescriptor1 + 18, //18 is a magic number. It is the offset from start of the configuration descriptor to the start of the HID descriptor.
                        sizeof(USB_HID_DSC)+3,
                        USB_EP0_INCLUDE_ZERO);
                }
                break;
            case DSC_RPT: //Report Descriptor
                if(USBActiveConfiguration == 1)
                {
                    USBEP0SendROMPtr(
                        (ROM BYTE*)&hid_rpt01,
                        sizeof(hid_rpt01), //See usbcfg.h
                        USB_EP0_INCLUDE_ZERO);
                }
                break;
            case DSC_PHY: //Physical Descriptor
    //Note: The below placeholder code is commented out. HID Physical Descriptors are optional and are not used
    //in many types of HID applications. If an application does not have a physical descriptor,
    //then the device should return STALL in response to this request (stack will do this automatically
    //if no-one claims ownership of the control transfer).
    //If an application does implement a physical descriptor, then make sure to declare
    //hid_phy01 (rom structure containing the descriptor data), and hid_phy01 (the size of the descriptors in bytes),
    //and then uncomment the below code.
                //if(USBActiveConfiguration == 1)
                //{
                // USBEP0SendROMPtr((ROM BYTE*)&hid_phy01, sizeof(hid_phy01), USB_EP0_INCLUDE_ZERO);
                //}
                break;
        }//end switch(SetupPkt.bDescriptorType)
    }//end if(SetupPkt.bRequest == GET_DSC)

 
So the function performs a check on the bRequest code if(SetupPkt.bRequest == USB_REQUEST_GET_DESCRIPTOR) and, in that case, it sends the descriptor requested.
 
Then the function goes on:
 
    switch(SetupPkt.bRequest)
    {
        case GET_REPORT:
            #if defined DEFINE_GET_REPORT_HANDLER
                USER_GET_REPORT_HANDLER();
            #endif
            break;
        case SET_REPORT:
           // #if defined DEFINE_SET_REPORT_HANDLER
    
                        
                USER_SET_REPORT_HANDLER();
            //#endif
            break;
        case GET_IDLE:
            USBEP0SendRAMPtr(
                (BYTE*)&idle_rate,
                1,
                USB_EP0_INCLUDE_ZERO);
            break;
        case SET_IDLE:
            USBEP0Transmit(USB_EP0_NO_DATA);
            idle_rate = SetupPkt.W_Value.byte.HB;
            break;
        case GET_PROTOCOL:
            USBEP0SendRAMPtr(
                (BYTE*)&active_protocol,
                1,
                USB_EP0_NO_OPTIONS);
            break;
        case SET_PROTOCOL:
            USBEP0Transmit(USB_EP0_NO_DATA);
            active_protocol = SetupPkt.W_Value.byte.LB;
            break;
    }//end switch(SetupPkt.bRequest)

 
Here, again, there is a check on SetupPkt.bRequest with the switch, but the cases follow this other definition:
 
/* Class-Specific Requests */
#define GET_REPORT 0x01
#define GET_IDLE 0x02
#define GET_PROTOCOL 0x03
#define SET_REPORT 0x09
#define SET_IDLE 0x0A
#define SET_PROTOCOL 0x0B

 
I cannot find any indication of where these are coming from, but they don't match any of the content defined for the bRequest in the USB ch. 9. 
 
Now, here I'm puzzled. 
First, these two checks are executed one after the other, so the same operation can be potentially repeated.
Second, the definitions used for the bRequest are different!
 
What is the meaning of all this?
 
 
 
 
 
post edited by gpaolo - 2020/09/27 16:49:36
#64
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/09/28 14:14:43 (permalink)
0
Update of my daily struggle. 
Quick version: it's not working.
 
Longer version: there is absolutely no way to get this damn thing working.
But I think the issue is on the initialisation part.
So, since I can't put breakpoints without getting the USB disconnected, I have added some LED blinking for the report descriptor request, then for the get report and for the set report.
As expected, the set report is never triggered -not a big surprise, there is no OUT event on the USB.
Just to be sure, I have tried the board on two more computer, one with Windows 10 and one with Windows 7. Same result, device not recognised as FFB joystick and FFB setting not sent. ForceTest doesn't recognise it either.
So, I have tried two more PID/VID, one from the SideWinder FFB and one from a Logitech FFB thing. I was expecting some driver search at least for the Logitech, but nothing. 
So I have checked the device status and I found an odd event:
Device was not migrated due to partial or ambiguous match
I could hardly find anything useful on the web, mostly pointless copy-paste messages on Microsoft forum, but my guessing is that there is something not really matching between what the PC thinks that is connected and what the PC sees connected.
First idea I have, that huge descriptor. No? 
Well, I am trying to see if I can find a copy somewhere, up to now I have found only very different stuff, so I can't really compare them.
As usual, if anyone has any clue, it will be really appreciated. Oddly, most threads seem to be 10 years old, all talking about XP...
#65
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/01 01:46:34 (permalink)
0
I have not given up, I'm still convinced that it is a problem of recognition of the device and driver not loaded properly.
So I have moved to another descriptor, I found the dump of the SideWinder descriptor ( https://code.google.com/a...winderFFPDetails.wiki) and I am trying that one.
Still no luck with the FFB part, but I found an interesting problem.
Your code is based on 8 bits structures, as well as the USB packets. But when I move to a 16 bit micro, things get messy. I would have expected that the libraries would have taken care of that, but… evidently they don't.
So, here is the situation. In the new descriptor, the joystick_input has a different structure:
 
typedef union _JOYSTICK
{
    struct
    {
  struct
        {
         BYTE RID;
        }REPORT_ID;
        struct
        {
         unsigned int X;
         unsigned int Y;
         BYTE Z;
         BYTE Rz;
     } analog_stick;
        struct
        {
            BYTE hat_switch:4;
            BYTE :4;//filler
        } hat_switch;
     struct
        {
            BYTE square:1;
            BYTE x:1;
            BYTE o:1;
            BYTE triangle:1;
            BYTE L1:1;
            BYTE R1:1;
            BYTE L2:1;
            BYTE R2:1;//
        } buttons;
        struct
        {
         unsigned int dummy1;
         unsigned int dummy2;
     } dummy;

    } members;
   BYTE val[13];
}JOYSTICK_UNION;
As you can see, it is 13 bytes long.
First, I was getting the USBD_STATUS_BABBLE_DETECTED error, meaning that my device was sending more data than expected. Debugging, I discovered that the command
USBOutHandle = HIDTxPacket(HID_EP, (BYTE*)&joystick_input, sizeof(joystick_input));
was sending 14 bytes instead of 13, because sizeof(joystick_input) was returning 14.
Manually forced to 13, and it started working, but still, information from JoyTester was messy. So I checked more deeply and found the issue.
 
[see attachment in next post, as usual the forum doesn't let me add images…] 

If you look at the data, you see that, despite having 13 elements for the VAL part of the variable, the information is shifted by one byte. This is because, even if the first element is defined as a 8 bit variable, the memory works in blocks of 16 bytes and the information on the X axis starts at location 0x13B6 instead of 0x13B5. In this way, the function sends out one extra byte of zeroes and misses the last byte, shifting all the content of the packet.
Any idea how to deal with this?
 
#66
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/01 01:49:48 (permalink)
0
 
nope, nothing works today. I can't even edit my message now.
You can get the image here: https://www.dropbox.com/s/39nkn1bh6sku978/data.jpg?dl=0
#67
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/01 11:13:08 (permalink)
0
Ok, I reply to myself, at least this part is working and I have got the force feedback descriptor working for the joystick part. Response to my previous question is: use directive __attribute__((packed)) in the structure, and there will be no gaps between bytes.
So here is the correct definition of the joystick structure then (for 16 bit micros):
 
 
typedef union _JOYSTICK
{
    struct __attribute__((packed))
    {
  struct
        {
         BYTE RID;
        } REPORT_ID;
        struct
        {
         unsigned int X;
         unsigned int Y;
         BYTE Z;
         BYTE Rz;
     } analog_stick;
        struct
        {
            BYTE hat_switch:4;
            BYTE :4;//filler
        } hat_switch;
     struct
        {
            BYTE square:1;
            BYTE x:1;
            BYTE o:1;
            BYTE triangle:1;
            BYTE L1:1;
            BYTE R1:1;
            BYTE L2:1;
            BYTE R2:1;//
        } buttons;
        struct
        {
         unsigned int dummy1;
         unsigned int dummy2;
     } dummy;

    } members;
   BYTE val[13];
}JOYSTICK_UNION;

 
still nothing good on the FFB side… sad: sad
 
#68
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/01 11:48:05 (permalink)
+1 (1)
I've done it! I have done it!
It is recognised as FFB now! I had to find a suitable VID/PID, I knew it was a problem on the PC...
 
This:
#define MY_VID 0x03eb
#define MY_PID 0x2046
 
from this project
https://code.google.com/archive/p/adapt-ffb-joy/downloads
 
works! 
Ok, new work now, see if I receive the commands properly. Ahhh finally a step forward mr green: mr green
#69
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/02 01:19:31 (permalink)
+1 (1)
Well, I'm more or less talking to myself here, but I was wondering...
With those VID/PID, the joystick is recognised as FFB device with both the original descriptor and the SideWinder descriptor (which is actually quite interesting, because I can basically define what I want keeping the device recognised; I have tried to change the range of the joystick in the original descriptor from 0-1024 to 0-2^16 and it works perfectly).
But those VID/PID apparently have nothing to do with the SideWinder, and I haven't changed anything else (I think…).
On the other side, it was not a problem of the single PC, as I have tried the board on two more computer with Win10 and Win7 with the same result.
 
So, the decriptor is not telling the PC what the device is. VID/PID are obviously not the main issue here. So… what is exactly? What was causing the PC to not load completely the right driver?
#70
Coman
Senior Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2016/11/06 14:56:29
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/04 08:02:05 (permalink)
+1 (1)
VendorID/ProductID is used by the operating system when searching for drivers.
Once a driver is associated with a VID/PID, for each device that reports that VID/PID, the OS will load that driver, no matter what the device descriptor says.
 
( i got a new  pic kit 3 programmer, and this week the new chips should also arrive, so i'll go trough the initialization part again, and make some notes on the sequence ( how reports are sent and in what order ), but it will take some time.
 
From what i understand :
[device] -> | attach | -> [pc]
(the usb firmware from microchip handles this part)
[pc] -> | get reports | -> [device]
[device] -> | sends reports | -> [pc]
… (device descriptor) (configuration descriptor) (strings)… (report descriptor) (the report descriptor is sent last)
-----------------------------END OF HID------------------------------
if i remember corectly:
at this stage, windows looks for a device driver,it doesn't find a custom one ( based on VID/PID ), so it should load
the default joystick HID driver for that device. ( it will not tell you it's a ffb device, just that it's a HID input device )
-----------------------------START OF PID------------------------------
when a program wants to know if an input device handles PID ( not the one defined in usb hid book… )
it will call DirectX functions for initializing force feedback.
DirectX will scan all joystick devices and search for this :    0x05,0x0F, // Usage Page Physical Interface
( i don't exactly know all the details ).
It rebuilds all the information in the report descriptor, and then it starts to querry the device for it's capabilities.
----------------------------------------------------------------------------------------------------
It does it by :
a)Issuing a setup packet, in wich SetupPkt.bRequest = bRequest  is a SET_REPORT
followed by
b) Issuing a setup packet, in wich SetupPkt.bRequest = bRequest  is a GET_REPORT
    (if the set report request expects data back )
c)Issuing the next setup packet, in wich SetupPkt.bRequest = bRequest  is a SET_REPORT
   (if the set report request a) did not expect data back )
 
extern volatile CTRL_TRF_SETUP SetupPkt ( defined in usb_ch9.h)
----------------------------------------------------------------------------------------------------
a)
the firmware should call USER_SET_REPORT_HANDLER() from usb_function_hid.c.
this is what the microcontroller should do ( call order for functions and switches on the micro ):
[pc] -> | setup packet->set report | -> [device]
[device] ->
1.USBCheckHIDRequest()->
2.switch(SetupPkt.bRequest)->
3.case SET_REPORT ->
4.USER_SET_REPORT_HANDLER()->
5.switch(SetupPkt.W_Value.byte.LB)->
6.case 0x10:// REPORT ID 0x10 | Create New Effect Report ->
7. switch(SetupPkt.W_Value.byte.HB) // REPORT TYPE->
8. case 0x03:// FEATURE, the host wants ME to send the data->
9.USBEP0Receive((BYTE*)&pid_report[0], SetupPkt.wLength, USBSetEffect); ( and you receive the packet)
10.USBSetEffect() // is called automatically when USBEP0Receive has finished.
10. API_READ_EP1_DATA() // pooling with this function in main.c
11. API_USER_SERVICE_EP1_RECEIVED_DATA()// pooling with this function in main.c
 
now here it's important
you MUST read this packet, do all the computations etc, and be ready to respond to the get report that will follow.
there is no time indication as how fast that next get report will come.
and you must keep track of the setreport-get report cases.
 
you might receive 2 set reports in a row, then 2 get reports in a row, and you must respond accordingly.
 
that is why in the main.c i call these 2 functions each cycle ( pooling )
API_READ_EP1_DATA() // this function reads incoming data where the set-get report happens (endpoint1)
API_USER_SERVICE_EP1_RECEIVED_DATA() // this function looks what kind of request the pc has sent
 case 0x03://Usage Set Effect Report
// Usage Set Condition Report, etc, those numbers are the report ID's defined in the descriptor.
and prepares the data to be sent back.
 
-----------------------------------------------------------------------------------------------------------------------------
 
 
 
b)
the firmware should call USER_GET_REPORT_HANDLER() from usb_function_hid.c. ( if the previous set report request  expects data back )
this is what the microcontroller should do ( call order for functions and switches on the micro ):
[pc] -> | setup packet->get report | -> [device]
-------------------------------------------------------
[device] ->
1.USBCheckHIDRequest()->
2.switch(SetupPkt.bRequest)->
3.case GET_REPORT ->
4.USER_GET_REPORT_HANDLER()->
5.switch(SetupPkt.W_Value.byte.LB)->
6.case 0x11:// REPORT ID  PID_BLOCK_LOAD_STATUS ->
-------------------------------------------------------------------
 0x05,0x0F, // Usage Page Physical Interface
 0x09,0x89, // Usage PID Block Load Status
 0xA1,0x02, // Collection Datalink
    0x85,0x11, // Report ID 17  ( as defined in the descriptor, if you have different id in the descriptor it will send that )
-------------------------------------------------------------------
7.switch(SetupPkt.W_Value.byte.HB) // REPORT TYPE ->
8.case 0x03:// FEATURE, the host wants ME to send the data ->
-------------------------------------------------------------------
you prepare the report here
( because it came on ep0, not ep1, so it's not handled by API_USER_SERVICE_EP1_RECEIVED_DATA() )
  pid_report[0]=PID_BLOCK_LOAD_REPORT[0]; // PID BLOCK LOAD REPORT ID
   pid_report[1]=PID_BLOCK_LOAD_REPORT[1]; // EFFECT INDEX
   pid_report[2]=PID_BLOCK_LOAD_REPORT[2]; // SUCCESS/FAIL STATUS
   pid_report[3]=PID_BLOCK_LOAD_REPORT[3]; // AVAILABLE RAM
and you send it back
-------------------------------------------------------------------
9.USBEP0SendRAMPtr((BYTE*)&pid_report[0], 4, USB_EP0_NO_OPTIONS); -> [pc]
 
 
what i don't remember now is the exact order of requests the pc does...
 
once i get the new microcontrollers i'll extract them and post them here.
#71
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/04 14:08:37 (permalink)
0
What you say makes perfect sense… but it doesn't correspond to what happened.
In my case, I have just changed the PID/VID and the device went from being recognised as a HID device = plain joystick to a HID device = FFB joystick. I didn't change anything else in the last attempt...
But I will restart working on it soon, I had to take a break. I need to sleep once in a while mr green: mr green
#72
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/08 11:57:29 (permalink)
+1 (1)
Nope. Forget it. My mess :D
post edited by gpaolo - 2020/10/08 13:23:56
#73
gpaolo
Starting Member
  • Total Posts : 81
  • Reward points : 0
  • Joined: 2011/02/22 15:43:15
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/08 13:53:03 (permalink)
+1 (1)
wow. It works. I reach the point where I start the timers when I enable the effects (only the Grooves are not replying properly).
Now the work should be, based on the effect commanded and on the configuration, to implement it. 
Give me some time to cleanup the code and I will post the working version on the dsPIC33F!
#74
Coman
Senior Member
  • Total Posts : 44
  • Reward points : 0
  • Joined: 2016/11/06 14:56:29
  • Location: 0
  • Status: offline
Re: Force Feedback Tutorial: PIC18F4550 2020/10/12 04:43:44 (permalink)
0
Good job Paolo!
Meanwhile my components arrived and i am starting to rebuild the joystick circuit.
I've hit a small problem yesterday and i need to investigate it further.
I had programmed the chip, plugged in usb, recognized.
I started forceedit, and the chip disconnected from usb and now it seems that the external oscillator is not working any more. strange...
 
 
Solved :  the simple act of soldering it on a matrix test board added so much capacitance to disable the oscillating circuit of the pic.
Moved the quartz crystal directly on the pins.
post edited by Coman - 2020/10/14 13:55:53
#75
Page: < 1234 Showing page 4 of 4
Jump to:
© 2020 APG vNext Commercial Version 4.5