Jump to content

Recommended Posts

Have anyone write code/lib to use USB Serial port on PIC18F4550? I mean that a virtual RS232 COM port is created.

Edited by sdujolo

Share this post


Link to post
Share on other sites
Have anyone write code/lib to use USB Serial port on PIC18F4550? I mean that a virtual RS232 COM port is created.

 

Bumping this question, I am also VERY interested in a virtual RS232 USB lib for the BoostC. I am also using the 18f4550.

Share this post


Link to post
Share on other sites

Hi,

 

The next pic that I would be migrating to will be the pic18f4550. I'm look to have have a USB port. Also, having the ability to add USB keyboard and other devices.

Using laptop without serial serial port for programming.

 

All the best,

 

 

Eric RO

Share this post


Link to post
Share on other sites

A possible USB library is much needed by me as well – Please!

 

I have also decided to opt for the 18F4550 for my next projects. I one stage I thought it would be possible to connect a Bluetooth dongle onto the USB port of a PIC and go wireless, but alas it requires host code and this seems to be very complex and nearly impossible to develop.

 

Converting from RS232 to USB seemed easy, that is if you are reading all the Microchip Application Notes and some of the Microchip C18 compiler information. Basic serial communications seems to be bedded down by the C18 libraries.

 

If we break the task a hand up into smaller functional pieces, then we require no PC side software and only firmware for the PIC. The PC side is no problem as RS232 communications are emulated by the PC side software on the USB port. On the PIC side new firmware is unfortunately required to handle the data streams.

 

I have found the following information during my research:

 

The BoostC USB example code on the examples page.

 

Leon Heller’s Prototyping PCB

 

Major work done on USB by Brad Minch's

 

Lots of posts on the Microchip Forum

 

Description of the USB Bootloader!

 

White Paper by Prof Renzo Davali

Edited by RSABear

Share this post


Link to post
Share on other sites

I'll put in a vote for some help with USB. I'd like to switch over to the 18F4550 and add USB, but it looks like a big project that I don't have the time for.

Share this post


Link to post
Share on other sites

Ok - so I am reading the sample USB files and the USB Firmware Specification - "Device Class Definition for Human Interface Devices (HID)". Robert Lang donated the BoostC sample code (building on the code of other developers). He has done major work here, ever more comprehensive than what I am trying to achieve. Slowly and part time, I will work on the project, bit by bit in and out of the USB port I will make it work.

Edited by RSABear

Share this post


Link to post
Share on other sites

USB support is key. It is too much for me to write myself, especially if it is too much for the Boostc folks to write. RS232 will go away. I do not want to have to switch to the Microchip compiler, but if that is what I have to do to support USB I will. Note too that on the forum you cannot search for usb or serial bus. ( words are too short ) This should be fixed too.

Share this post


Link to post
Share on other sites

I agree fully. It is a mammoth task. I have downloaded all the PICDEM FS USB documentation, software, C-18 etc... Busy constructing my own circuit to clone the hardware of the PICDEM. The firmware compiles however, reading all the documentation and finding information is slow task. At least it will be a staring point to port the Microchip app to BoostC. There are the normal C challanges. However, I would like to understand the USB CDC specification and functions better before I start. Lastly, I am not sure about all the license implications and stuff, most of the code was released public domain, but some portions seem to go as far as patent rights?

 

At least if I don't get the software ported to BoostC. I would have learnt a lot.

Edited by RSABear

Share this post


Link to post
Share on other sites

There seems to be a lot of interest in USB implementation with PICs, so I thought some expert out there may help shed some light. Being put off by the apparent difficulty of implementing USB on a PIC that supports it I decided to try a different approach. It seemed like a good idea to 'offload' all the USB stuff onto a dedicated sub-system and use a (non-USB) PIC with which I am familiar - 16F87X. So I chose to use a DLP Design module that uses an FTDI chip for USB and comes with Win32 drivers, either for DLL's or (my choice) Virtual Com Ports. This module has a 16F877A which I intended to use for the main program.

The problem I have now discovered, mainly as a result of my ignorance of USB, is that it seems impossible to re-connect to a USB host correctly once it has been disconnected, but with the PIC still running its program. Hence (at last!) my question; can anyone tell me if my deduction is correct - that once a USB device has been connected to a host and enumeration has taken place, disconnection and then re-connection and consequent re-enumeration requires that any program (running in the PIC) requires a reset/restart?

I am wondering if a PIC with USB would allow this problem to be circumvented, although it seems inherent in the USB protocol - that is once a USB connection is made it must be maintained and if lost or removed enforces a complete restart.

Apologies for a long post, but I am hoping to avoid wasting any more time and money before pursuing an alternative route.

Share this post


Link to post
Share on other sites

A reset should not be required, but a lot of USB hosts will power down when the last device disconnects. This is not too common on desktops but is typical for laptops.

 

If your device is not self powered then when the host powers down the port your PIC will loose power too.

Edited by cac001

Share this post


Link to post
Share on other sites

I agree, but I have complete control over power selection. The module I am using has a FET controlled by a signal from the FTDI USB chip that is intended to cut power to the external electronics when the USB is in suspend mode. This is what first made me aware that the intention with USB devices is that they are powered down when disconnected from the port. Although you say this should not be necessary, my experience is that enumeration will not take place unless the peripheral is powered down and re-powered on enumeration - thus defeating the object of my design!! I've tried using the PIC to reset the USB interface, hoping this would force a re-enumeration, but the system just 'hangs'.

My expectation that all the details of the USB protocol could be ignored by using a dedicated sub-system have proven to be false; no doubt my time now could be better spent swatting up on the very thing I hoped to avoid - arrrrgh!

Share this post


Link to post
Share on other sites
is that it seems impossible to re-connect to a USB host correctly once it has been disconnected

 

If you are using a virtual com port, make sure that the port is closed before disconnecting your device. You may

be enumerating as a different com port if the previous port is still open. Also, if you connect to a different USB port

it may enumerate as a different com port.

 

 

my experience is that enumeration will not take place unless the peripheral is powered down and re-powered on

 

the host can reset your device at anytime. It does not have to be disconnected and reconnected to enumerate, although

that will obviously force a reset. In fact, anytime you plug a USB device into a Windows machine it will enumerate twice.

Share this post


Link to post
Share on other sites

Many thanks for your suggestions, but after a lot of puzzling I've discovered the 'fault' lies in the source code supplied with the module. I simply used the USB portion and added my own extras. Briefly, the program as given expects that enumeration will only take once and the device will remain connected for the duration. At startup there is a section that is used to purge the FTDI FIFO; re-connecting will not do this, and a false read occurs, returning a garbage value. Fortunately, the read seems to be from a floating bus, and returns a value of 255. Since my program only ever expects buffer size values (the returned value) no greater than 16 I simply reject anything greater and problem solved.

 

Regards,

 

MikeW

Share this post


Link to post
Share on other sites

The FIFO lines may be pulled high when not enumerated giving you 255. Check FTDI documentation for config setting to pull lines low when the

FTDI chip is in reset.

 

I've discovered the 'fault' lies in the source code supplied with the module. I simply used the USB portion and added my own extras.

There isnt really anything on your PIC that is USB related. The FTDI is taking care of all things USB. Every time you disconnect and reconnect

your module the FTDI chip is busy talking to the host whether your PIC knows it or not.

 

 

Since my program only ever expects buffer size values (the returned value) no greater than 16 I simply reject anything greater and problem solved.

If future projects make this approach less than ideal consider monitoring the unused 5V from the USB port for connection status (assuming your

module is self powered). Only read FIFO when connected and ignore all else. It looks like your module has jumpers to carry the USB 5V to your PIC I/O.

Share this post


Link to post
Share on other sites
Have anyone write code/lib to use USB Serial port on PIC18F4550? I mean that a virtual RS232 COM port is created.

 

We are starting to look into this chip for several applications and once we start we would be happy to work with and share experiences getting the code up and running on BoostC.

 

For the moment, we are working on four projects that use an FTDI chip for serial USB, but we do communication on the PC side using the D2XX dll so that we can have the user select the device by name rather than by com port. Out PC software is written in .NET (a mix of C# and VB).

 

Jacob Christ

www.pontech.com

Share this post


Link to post
Share on other sites

I must confess that I've found the FTDI documentation less than helpful. After a lot of experimenting with some startup code, taking the C source supplied with the DLP module as example I discovered a way of getting the FT245 chip to resume reliably (this was before the other problem, and before I decided to re-program the FT245 EEPROM) Asking FTDI for advice on if the approach I had taken was OK their response was - 'we haven't put that information in the documentation because we don't think that method should be necessary'.

The documentation, at least that I've found, leaves out a lot of detail; I had expected that forcing a reset of the FT245 would be a solution to re-enumeration; but there is no detail of the reset timing, nor the reset state, and I could not get reproducible results when used. I didn't bother FTDI Chip again, as I get the impression they are only interested in commercial users, which I am not.

Share this post


Link to post
Share on other sites

I have been struggling to make the Microchip MCHPFSUSB working as a starting point. Using my hardware setup, I could get the bootloader working by using the Microchip hex file, but after programming the demo MCHPUSB.hex file PIC would not run or enumerate on the USB bus. Hours reading and searching the internet I managed to isolate the problem to dyslexia :rolleyes: – I ordered the PIC18F4450 instead of the PIC18F4550, as the PIC18F4450 does not have eeprom the code config settings are not saved by the bootloader, preventing the PIC to startup, or starting-up with default configuration settings.

 

I should have my PIC18F4550’s soon and I'm determined to use USB for my next projects.

Share this post


Link to post
Share on other sites

I have received my PIC18F4550's. I have recompiled the Microchip MCHPFSUSB Demo & CDC with C18 and it is working as described in the documentation.

 

While searching for information on the 18F4450 problem, I noted that Hi-Tech has a port of the MCHPFSUSB CDC posted on their website as well. I have not ported many applications - but can see a few challanges here.

 

I suggest a new thread in the "BoostC porting source code" forum to address the matter.

Edited by RSABear

Share this post


Link to post
Share on other sites

I'm about to start on a project that will require USB support as well. All I need to be able to do is set up as a CDC device so I can access the PIC through a USB serial connection. I looked at Microchips Application Note AN936 and it seems like it ought to be simple, but it doesn't look like it will be without switching to CC18. I'd rather stick with BoostC, since I have it and like it. Is anyone having any luck with USB CDC and BoostC?

 

Keith

Share this post


Link to post
Share on other sites
I'd rather stick with BoostC, since I have it and like it. Is anyone having any luck with USB CDC and BoostC?

 

USB CDC is the way to go.

 

Porting the Microchip C18 code to BoostC is not an easy task, I have been studying the code part time and can’t commit time as I am pretty tied-up at work with on a project. One would ultimately try and retain the code developed by Microchip in the CDC systems directory and not modify this code except for the typedefs.h file and adding specific definitions for the BoostC compiler. The porting problem appears to be largely focused around the differences between the way data structures, unions and especially bit data is handled by the different compilers as well as the placing the code in segments by the linker. I do not have the detailed in-depth know how on C to easily port the code – thus progress is very slow and painful.

Share this post


Link to post
Share on other sites

Maxim have just released a USB host/ controler chip, the Max3421E.

I dont know anything about it, I received details today from a mailshot off Maxim.

It may be a solution to some of your USB problems, (then again it may not)

Share this post


Link to post
Share on other sites
It may be a solution to some of your USB problems, (then again it may not)

 

I prefer to have the USB CDC in the firmware of the PIC. The problem is that my project (Energy Consumption Meter) is currently in the PIC18F4550 by means of Microchip C18 (and it works). The problem is to get it from C18 to BoostC in such a way that it still works...

Share this post


Link to post
Share on other sites

Hi,

 

A long time ago Geoffrey Hopkins did an amazing job of porting the CDC code to Sourceboost and I helped in packaging it up. Unfortunately when we contacted Microchip they said we weren't allowed to publish the code....which is a real shame. You're allowed to modify the code and use it yourself or in your own products, but not publish any modified code apparently.

 

Having said that the main problem was trying to simulate bit field structures in Sourceboost, to this day I still cannot figure out how Geoff did it, but it wasn't pretty. It also meant some version dependant code, as an example I've been unable to use Sourceboost compilers beyond version 6.60, and we're now at version 6.86!

 

In order to do a reasonable port of the CDC code and all the other USB code (such as their newly released host stack) we'll need bit fields in structures. Structure bit fields are all over the Microchip C18 code.

 

Currently according to the forum this is a low priority on Dave/Pavels list of things to do......can you guys bump it up the priority list please??

 

Once this has been done, we should be able to do a simple port and publish a conversion guide or diff file which would circumvent the Microchip licence limitations. Perhaps a bit of lobbying by Sourceboost users direct to Microchip and they'll lift the restriction. Alternatively although the Microchip CDC code looks complex, it is actually simple in operation, however does need someone more familiar with USB protocols than me to re-write it in Sourceboost, rather than a port.

 

Phil

Share this post


Link to post
Share on other sites
A long time ago Geoffrey Hopkins did an amazing job of porting the CDC code to Sourceboost and I helped in packaging it up

 

Unfortunately when we contacted Microchip they said we weren't allowed to publish the code....which is a real shame.

 

Thanks for the great piece of information – I so much needed some good news today.

 

Please help us Geoff...

 

I think we should play by the rules - Microchip's rules, it is the correct thing to do.

 

Microchip should be asked the following question - What is the main objective of their sales channel, to sell processors or protect code?

 

If the answer is to increase sales then we have a means of getting more USB PICs sold. Engineers and developers will have a USB library on BoostC to deploy on these processors.

 

I suggest we go the route of their 18F Microprocessor Product Support Staff to assists us to turn the decision into our (SourceBoost) favor. What sort of pull does Hi-Tech have with Microchip to publish a port of the Microchip demo code? (or else Microchip does not know this)

 

More 18F sales = USB CDC Firmware in public domain

 

I assume it is clear that there is a demand for USB in the PIC C programming community? Have a look at the views on this thread.

 

Does anybody have strong contacts in Microchip to help us to help them sell more 18F processors?

 

Once we have the above in place, we can light a candle on both ends for Pavel & Dave…

Share this post


Link to post
Share on other sites

I'm not sure if this has already been mentioned (the thread is quite long), but a complete USB CDC and HID implementation is available in the PicPack library (clean room USB implementation using SourceBoost). Complete source, examples etc.

 

It's under active development, in fact, within a few days we should have it working with the fantastic 18f14k50 chip, meaning you can do your own USB serial port with a completely customisable PIC chip for less cost than a SiLabs or FDDI chip.

 

We'll have some hardware supporting all this available shortly. Suggestions, problems, ideas, bug (fixes), please let us know.

 

See www.embeddedadventures.com

 

kind regards,

Ian.

iharris [at] embeddedadventures.com

Share this post


Link to post
Share on other sites
Have anyone write code/lib to use USB Serial port on PIC18F4550? I mean that a virtual RS232 COM port is created.

 

Hi,

Have u not tried the picpack lib(pic_serial.c)? I tried it with 2550 & it works.

Its such a waste of time trying to make a virtual serial port from ur usb device.

USB is used for hi speed communication & u can make HID class device thro' which

u can transfer data at a rate of 40-50 characters per millisecond.

Sending variables from pic to PC is so easy using the HIDMAKER tools from tracesystem.

try this out...

http://tracesystemsinc.com/all-usb-product...ucts-alias.html

 

Regards

Raghunathan.P

Edit : Sorry Harris I did'nt realise this was a very old thread.

Edited by ra68gi

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×