USB GamePad with PIC18F4550

[Jerson]

This is how I have managed USB. Maybe you're missing the tx buf empty check.

[manusoftar]

[Jerson]

[Jerson]

If you do need to use delays, I suggest you write non-blocking type delays so that the USB is serviced in the background @ approx 1mS

[manusoftar]

Anyway, the issue is that I wasn't setting the max packet size properly. Apparently I was sending more info than the driver expected... Now I need to figure out why the heck my multiplexer is not doing what it should. I should receive a resistor kit tomorrow as I didn't have a 370 ohm resistor (needed for the LM317 to obtain an output of 3.3v).

[Ttelmah]

You talk about 'your multiplexer'. Are you referring to the PIC's own A/D
multiplexer?.
If so, a series of key things.
This is a simple FET switch, allowing you to select which analog input
connects to the ADC's internal capacitor.
The PIC ADC is a successive approximation design done on this capacitor.
So sequence always has to be:
Select channel.
Let capacitor charge to the input voltage. This is Tacq, and depends on
the internal capacitances, the internal resistances, and the external
resistances. The ADC recommends that the analog source used has a
maximum impedance of 2500R (for your PIC), and then the Tacq is 6.4uSec.
This is the minimum time needed for the capacitor to charge withing 1/2
bit of the real voltage.
Then when you perform a reading, this capacitor is disconnected from the
source, and the reading is done on the voltage stored in the capacitor.
So a 'sample and hold' system. Since this capacitor has internal leakages
this is why when running at lower clock rates, you should not select an
ADC clock that gives a Tad much longer than the required minimum.

Now on your chip the ADC has the ability to use an automatic Tacq.
Selecting this is a very good idea.
Tad is specified to be 0.7uSec minimum.
Also be aware that the chip will not meet it's ADC specification for
CPU clock rates above 40MHz. The fastest/best CPU clock rate with USB
and the ADC, is to run the CPU at 32MHz.
So with this, using /32 for the Fosc divisor, gives 1uSec for Tad, and then
setting Tacq to 8Tad, gives 8uSec acquisition time, and then 11uSec to
perform the conversion.
You should not use the RC clock. On 90% of PIC's this will give very
poor performance for clock rates above 1MHz.
Then realise that for any form of accuracy, you really must use an external
Vref. USB introduces a lot of nose on the supply rail of the PIC,and
the 'best' you are likely to get using the supply as Vref is possibly 5%.

With some careful thought, the PIC ADC can perform very well indeed.
But it does require careful design. Good Vref, Good smoothing round the
PIC itself (your earlier comment about having to change to 0.1uF
from 22pF for the supply smoothing is worrying here). The supply should
have 0.1uF adjacent to each pair of supply pins, and probably 100uF
somewhere nearby. Then really good grounding (ground plane). And
careful design of the circuitry itself.

[temtronic]

It 'sounds' like he's connecting ALL the switches and pots to the ADC ?
We really need a 'list of connections', what switches /pots go to which pins of the PIC
Old guy like me gets confused easily these days,so I like to SEE stuff .
did learn something new... the PB on the top of a joystick is called the 'hat button' !!

[manusoftar]

No guys, when I say multiplexer I'm talking about an actual external multiplexer, a CD4051, which now is working as expected. The things I changed were that now I am calling the usb_put_packed() method with a pointer to my data structure and also I did a couple of modifications on my header file to set the proper maximum size of my report.

Here is an image of my current circuit design (it's still WIP, needs a couple more multiplexers and some other stuff).

HERE

[Ttelmah]

I have to say 'why'?. Given you have so many unused pins on the PIC, that
seems to be a tremendous waste of time and work....

[temtronic]

had a look at the schematic....

those 8 switches could be connected to the PORTD pins.
eliminates the 4051 mux
faster to poll/read
simpler code
less code space
faster 'buttons to USB transfer

still have LOTS of leftover pins even if you dedicate the programming pins.

[manusoftar]

Guys, unless I did my math wrong, which can happen, I don't have enough pins for all the buttons and stuff I want to use.

- A hat switch with 8 positions (meaning 8 pins)
- 17 buttons (meaning another 17 pins)
- A two axis analog stick (meaning another 2 pins on ADC mode)

If you keep in mind I already used two pins (D+ and D-) for the USB connection, plus leaving MCLR not connected as it is the "reset" pin to restart the execution of the PIC.

I really think I don't have 27 free pins to connect all that, and also there could be a chance to use either rs232 or an lcd for debug purposes. If I use an lcd I would probably use an additional input pin with a jumper to tell the PIC if I want it to try to initialize the lcd driver. Because if I don't have an lcd physically connected, the lcd_init() method would actually stop the whole execution...

[newguy]

The LCD code hangs the processor because the default LCD driver has a while() loop which tests for (from memory) D7 to either go low or go high - this is the LCD's way of letting the host processor know it's busy.

You can alter the LCD code so that it does not ever read from the LCD and will instead drive it in a timed blocking mode (i.e. instead of waiting for the D7 busy indication, it simply waits for a fixed time before proceeding). This alteration will allow you to keep your LCD code but won't lock up the processor.

[temtronic]

'hat' switch may only have 5 pins, common and N.S,E,W or U,D,L,R
Have you the part already, if not ,need pinout...

Also rethink the 'array of switches'.

A standard keypad of 4x4 matrix, only needs 8 PIC pins for 16 switches. 2 PIC 8 bit ports can easily decode 64 'keys' or 'push buttons' or 'switches'.

PC KBDs decode up to 192 switches with same technology..
CCS supplies a keypad driver (4x3 and 4x4) can be modified for more.

[temtronic]

re: LCD

pretty sure you change a variable that controls 'R/W' of the LCD,pin 5 of the LCD module ?

Most think of ONLY writing TO the LCD, but you can READ the data on the screen ! As the RAM area is larger than the screen size(# of positions), it was a 'fun' place to store some data years ago with tiny PICs.

[manusoftar]