View previous topic :: View next topic |
Author |
Message |
noman yousaf
Joined: 07 Jan 2016 Posts: 17 Location: pakistan
|
USB bar code scanner interface with PIC18F2550 |
Posted: Wed May 25, 2016 10:01 pm |
|
|
hi all
i want to get data from USB bar code scanner on 16X2 LCD via PIC18F2550.
Need hints to write code.
Can someone help me? |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Thu May 26, 2016 1:12 am |
|
|
Forget it.......
Honestly, this means you are going to have to get USB OTG working (to give USB _host_ mode). CCS does not offer a OTG stack, and while Microchip does offer one, I have tried it, and it is very unreliable. It is also very bulky. Where a slave on a PIC occupies perhaps 25% of the ROM (a typical USB PIC), a master implementation, nearly fills the ROM (on a similar sized PIC), and of course can only be used on the relatively few PIC's that support OTG.....
You have to understand that USB has a 'master'/'slave' design. It is designed to make slave devices be relatively easy to build, but the master is vastly more complex. The hardware for the master is also different. The standard PIC drivers are all for being a USB slave. Problem is that your bar code scanner is a slave device, so to drive this off the PIC, requires you to build a USB master.
Honestly much easier to let another device handle being the host. The easiest is possibly the FTDI Vinculum. This is available as complete modules offering a USB connector, and SPI/serial interface to another microcontroller. Either of these interfaces can be driven by the PIC.
A module like:
<http://www.mouser.co.uk/ProductDetail/FTDI/V2DIP1-32/?qs=%2fha2pyFaduh4q%2fxSutHuKkACzckDTwAR0U2kS1iZLHU%3d>
Offers the whole USB master already built. This can then be driven off the PIC using SPI (honestly the quickest interface).
Building a PIC USB OTG system, you have several _weeks_ of development ahead, and will still probably have problems. Use a module like this, and once you have mastered the commands to the device, 80% of the work has already been done. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Thu May 26, 2016 5:13 am |
|
|
Mr T is 100% right !! I started a project like yours 3-4 years ago. Still have the Vinculums collecting dust. USB is extremely complicated and you need a MINIMUM of 4 months to see progress. While getting a PIC to SEND to USB is 'easy'(say to a PC), I just buy $2 TTL<>USB modules instead of using a PIC that has USB 'inside'(like the 4550s collecting dust here as well....).
As Mt T points out, buy a 'USB device to PIC' module then the rest is easy...well, easier.
Things were a LOT simpler ,easier and faster to implement with good old 'RS-232' !!
Jay |
|
|
noman yousaf
Joined: 07 Jan 2016 Posts: 17 Location: pakistan
|
|
Posted: Thu May 26, 2016 9:59 pm |
|
|
thanks all to guide me.
need more guideline.
can i use arduino usb host shield for my purpose?
if yes then can i use shield directly to any PIC MCU or should use arduino it self with? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9225 Location: Greensville,Ontario
|
|
Posted: Fri May 27, 2016 5:02 am |
|
|
Yes you could use the 'shield' as your USB device TO PIC interface. It's probably easier than buying the chip and other parts and making a PCB. I have NOT looked at what code is required( driver) to operate the device but it is possible. Converting "A" C into CCS C is not that difficult .
It'd be interesting to know if someone makes an Ardunio shileds compatible PIC based 'motherboard',something with a 28 or 40 pin DIP socket.
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Sat May 28, 2016 1:37 am |
|
|
It's a lot more work to use the Arduino shield than the FTDI Vinculum.
First, you'd need to ensure you are talking about the V2 shield. The original shield is now retired.
Then you'd have to translate the Arduino library to drive the MAX3421E into CCS.
Then the MAX3421, is a 3.3v device, so you'd need to be using a 3.3v PIC, or have level translators on the SPI interface.
The FTDI is a much smarter device. On the Maxim, the PIC is still going to have to handle the host stack. On he FTDI, this is done 'for you' by the controller. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Sat May 28, 2016 11:36 am |
|
|
There is also a big question that has not been asked, of whether there is any data published about how to talk to the device on the PC?.
Does it appear as a CDC device?.
Do you know what commands it accepts, and what data it returns?.
If both the answers to this are 'yes', then the actual software is relatively easy. The VDAP2 firmware for the Vinculum can handle this, and you could use this just using the UART interface.
If no data is available, then the job becomes enormously harder. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Sun May 29, 2016 1:50 am |
|
|
Just done some searching, and the 'standard' way most of these devices work, is they appear as an HID keyboard, and effectively 'type' the values they see directly into the PC on which they are connected.
As such, the whole thing becomes relatively easy.
1) Connect device to Vinculum controller.
2) Ensure Vinculum has latest correct firmware.
Go here:
<http://www.ftdichip.com/Firmware/Precompiled.htm>
and get the ROM for:
"UART to USB HID Class Device Sample Application ROM"
3) Jumper the Vinculum to operate in UART mode.
4) Short together the RTS/DTS pins so that handshaking is not used.
5) Connect the Vinculum UART pins to the PIC UART.
6) Use interrupt driven serial on the PIC.
Vinculum defaults to 9600bps 8N1.
The default VNC2 setup in this mode, allows a connected HID device data to be forwarded to the UART port.
Remember though these are the _raw_ keyboard commands. So you will see 'key down', and 'key up' messages for each key, which you will have to decode into ASCII. Fortunately, there has been code posted here (may be in the code library) to drive a PS/2 keyboard, and this uses the same message format.
<https://www.ccsinfo.com/forum/viewtopic.php?t=27544>
A little tweaking, should allow this to be used. You need to substitute the standard UART commands for the I/O commands, and just use the translation components. |
|
|
|