PIC24FJ64GB002 Keyboard

[vtrx]

Is there any example of a USB keyboard with PIC24FJ64GB002 using CCS?

[Ttelmah]

If you mean the PIC acting as a USB keyboard, the ex_usb_keyboard
with the compiler does this. You would need to just setup the usb_common
for your chip. This will depend on what oscillator you are using, and
and other specific changes you need for your project.

If you mean using the chip's usb in OTG mode to talk to a USB keyboard,
then this is not something that people have really got into with CCS. I
experimented with USB OTG, and actually decided it was more hassle than
it was worth. For a single device like this it can probably be got to be
reliable, but for anything involving multiple devices, the code become
unacceptably large, and with every PIC stack I tried, fairly unreliable....

[temtronic]

I decided a long,long time ago the 'U' in USB does not mean 'Universal' rather USELESS. Whatever 'layer' you look at...hardware,firmware, software... USB requires you to spend weeks reading 1000s of pages of 'tech' then praying to the USB gods that maybe, just maybe, your code might ,kinda work..sometimes.
Interfacing a PS2 keyboard is basic PIC101... complete code,BOTH ways, easily stored in a lowly PIC16C84 with room to spare.... BTDT..made a LOT of PS2 KBD to real RS232 modules decades ago.
The problem with USB is it isn't easy, it needs a LOT of overhead for even sending just 1 byte and it's NOT interrupt driven.. 'They' keep making it 'better' at the expense of needing faster computers, more memory and HUGE amounts of code.
yes, I'm a dinosaur...just like PCs that had real RS232 comports with 25 pins. The older I get, the more I like 'old school' stuff that's easy to use and reliable.

Jay

[jeremiah]

I personally feel like USB was designed so you could take a single cheap dedicated microcontroller to interface with it and manage it. They weren't necessarily targeting chips like the PIC at the time when the original design was created. I think a lot of problems tend to occur when people want to mix USB functionality with other functionality on the PIC. You really want the micro fully dedicated to the USB to make it reliable and if you need something other than USB, then use separate micros that can talk to each other as needed. Or optionally, just buy a pre-made USB chip or board for your application if development costs/schedule are a concern.

[Ttelmah]

Actually one of the key design criteria of USB, was that the main
complexity should be in the master device. Allowed the peripheral cost
to be low.
The USB slave PIC implementation runs fine, and can be reliable.
It is bulkier than something like serial, but otherwise gives few problems.
With the master though, you are faced with having to implement that
complexity....

So the big question comes back to what I first asked, of whether he
wants the PIC to be a USB keyboard device, or whether he wants the
PIC to talk to a USB keyboard?.

If the former, 'easy', if the latter, I'd say the easy way is to use a
Vinculum. To try to do it with PIC code will be very hard.

[PCM programmer]

[Ttelmah]

Yes, just copied some files off a hard drive here, and was managing over
400MB/sec (it's a fast RAID array, and running USB3). The idea of handling
traffic like this on older interfaces is 'scary'....

[temtronic]

Why do I still say it, cause it's still true...today
I'd like to know much overhead does USB require to a simple send/receive , say 20 bits of data, consisting of a 4 bit adrs, receive 8 bits of alarm data and send 8 bits of control data. I do that as a simple serial stream with 2 start bits.22 bits at 24 baud...while it's slow it works and is very efficient.

One reason why USB 'works', is that as memory got real cheap and CPUs got faster, programmers go to be sloppy and cut 'bloatware' so the end user really didn't see what was happening 'behind the scene'. Then special USB 'engine' chips came along, like in the USB<>TTL modules for a buck.
Like I said, I'm a dinosaur, taught that every bit of every byte matters and if you learn ASM, you can make a PIc , or any micro , do stuff...fast.. AND efficiently.

[Ttelmah]

90% of the 'overhead' is in the hardware of the peripheral, and the
hardware/software of the PC. The actual code size on the PIC is quite small.

Just built a basic USB CDC example to send a string every second to the
USB 'serial'' emulation on a 18F4550. Including initialisation code,
delay, printf, etc., uses just 12% ROM. A 'serial' version still uses 2% ROM.
So the USB here is costing just 10% of the ROM space in this chip.

[temtronic]

Thanks for the info Mr. T. ! 10% is less than I'd thought, though still a big chunk of codespace. Course with PICs having 64KB or more, ,it's a 'drop in the bucket'....
Was given a PC to look at, no video( on board) and noticed NO printer port.Sigh...now I really feel old. Maybe I'll re-read my Circuit Cellar Inks, starting at Vol 1, number 1. 'what's inside the box still counts'.....

[Ttelmah]

You sum up why I've gone USB.

My last ten computers at least, have not had any interfaces except USB
or thunderbolt.
I have got one with SCSI still, used to drive some old drives that I retain
for compatibility.

[vtrx]

...USB HOST
Imagine how good it would be to implement a keyboard in this project.

https://drive.google.com/open?id=1rwBuLBFHTWy8p7OLYqKYGUiRRhcm5eKR

[Ttelmah]

So, just use a Vinculum.
Key problem is that though the peripherals share a lot between
different PIC's, each is slightly different, and you then have a huge
range of different clock rates etc.. So you can have USB code working perfectly on one chip and then it has to be tweaked on the next chip.
The slave hardware has been sorted over several years now, and
except for a few oddities when you want to do more complex things
like DMA, works fine. The OTG hardware though still seems to have
issues. The Vinculum, because it has been used so much more, now has
it's issues well sorted, and makes a USB master easy to implement.
A device like:
<https://www.digikey.com/catalog/en/partgroup/vdrive3-vinculum-ii-application-modules/42111?mpart=VDRIVE3&vendor=768>
Gives you a simple serial connection to USB. The standard firmware
in this is for drive interfacing, but firmware is available for other things
like talking to a keyboard.