View previous topic :: View next topic |
Author |
Message |
tiagojampietro
Joined: 15 Mar 2012 Posts: 3
|
USB Pic18f4550 problem!! |
Posted: Wed May 30, 2012 8:11 am |
|
|
I'm having some problems with USB on PIC18F4550:
- My pc does not recognize the device, how to fix this?
- Someone could send me a code that works?
- How do I send strings to the pic of the pc via USB?
Please help me, I have little time to design and need it to run my soccer robots!
I thank in advance! :confused: :shock: |
|
|
ezflyr
Joined: 25 Oct 2010 Posts: 1019 Location: Tewksbury, MA
|
|
Posted: Wed May 30, 2012 9:50 am |
|
|
Hi,
Your post reminds me of one of my favorite saying here at the office: "A lack of planning on your part does not constitute an emergency on my part"....
Everything you need can be found in the \Examples directory after you've installed the compiler. Specifically, look at 'ex_usb_serial2.c'. I went from zero knowledge about USB with CCS 'C' to a fully working project in just a couple of hours using that example code. It's not hard!
John |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9218 Location: Greensville,Ontario
|
|
Posted: Wed May 30, 2012 10:19 am |
|
|
John's right. It's ALL in the examples that CCS kindly supplies.
Took me a bit longer as I'm used to REAL serial ports..but the code runs fine on XPP-sp2.
Jay |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Wed May 30, 2012 2:30 pm |
|
|
What is the allure of the 18f4550???
While CCS has provided the means to operate
the USB capability of the chip,
I have never considered using it for a product.
IMHO, there is more program memory bang for the buck and FAR less code complexity involved in using the 18f4520 with an FTDI FT232 external Serial to USB converter. Most of all FTDI maintains a very excellent HOST support driver suite for VCOM on the computer you want to be connect to.
I am baffled that this part has any fans at all, given how much overhead is required to get USB connectivity - and by the issues involved in making it work with other than a limited range of host OS. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9218 Location: Greensville,Ontario
|
|
Posted: Thu May 31, 2012 5:21 am |
|
|
media hype ! BTDT , I have a drawer full of 4550s collecting dust and learned that the FTDI modules are the way to go...
supposed to get smarter the older we get....hahaha...I've just seen the specs for a $50 PC and will use it for R&D of my new PIC based solar controllers.
sigh..it never ends... |
|
|
dan king
Joined: 22 Sep 2003 Posts: 119
|
|
Posted: Thu May 31, 2012 5:59 am |
|
|
hmm, I've had no problems with the USB drivers for the PIC using XP, 7, or Linux.
I think some of the popularity with that series is that various boards have been developed for people that don't have the time or resources available to spin their own board.
Personally, I use the 18f2553 (4550 variant) all the time and have never had an issue with the USB I/F and never ran out of ROM space aside from an SD to USB project. I like the parts and the fact that the boards are small, reasonably priced (24.95 from sparkfun), and provide a USB I/F with no effort make it a nice solution for me. |
|
|
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Sat Jun 16, 2012 9:11 am |
|
|
I've never had an issue with the microchip built in usb support. IMHO it has advantages over a more pedestrian approach of PIC via rs232 to an external
chip to move it to usb and then have the PC create a virtual com port and receive via rs232. I have used the Microchip bulk transfer PC drivers and can take in bulk 512 byte buffer transfers from the PIC to the PC app. The lazarus PC app calls the Microchip dll and it allows several pic usb devices to connect to it at the same time by building a table of attached devices using the same vid pid and differentiating by a PC poll of unique serial numbers embedded in the pic code. Building the table and getting handles for each attached pic is very very fast and each attached device has its handle opened and its serial number polled and then closed as the table is built. A selected PIC device can then be chosen and opened or closed using the table. The PC app connects with several devices and acts as a master and manages all data transfers. I'm not saying this is the better way to go but managing all those virtual com ports seems unattractive. It is true built in usb chews up code in a pic but the chips supporting usb often have lots of code space. An issue rs232 presents is that without flow control it is asynchronous ( they squawk when they choose). It is more difficult to prove data can't be missed. |
|
|
|