CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

USB and usb_task()?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
hmmpic



Joined: 09 Mar 2010
Posts: 314
Location: Denmark

View user's profile Send private message

USB and usb_task()?
PostPosted: Wed Nov 28, 2012 2:03 pm     Reply with quote

Hi

I wonder if there are a minimum call time for usb_task();

A real big old program there use RS232 and FTDI. There is 4 interrupt running, and 1 timer are used. Now we want to change it to use a PIC with embedded USB. Hardware will be redesigned, and in the end much lower cost price.

What I don't like is the call to the function usb_task(); Furthermore all the driver there will be loaded for to get the USB ready to run?

Is there a nicer/smarter way to have the USB working? Maybe a library from 3party or Microchip?

I am confused, it is so simple to use RS232 and all other hardware layer in the PIC, but the USB is real complicated.

*
Another thing what about the new 16F1455 chip, real cheap low pin count but low rom&ram... How to handle this in CCS with all the loaded USB files?
Will run out of rom&ram before I have started to enter my own code.
*

Help and suggestion please. Rolling Eyes
Ttelmah



Joined: 11 Mar 2010
Posts: 19540

View user's profile Send private message

PostPosted: Wed Nov 28, 2012 3:03 pm     Reply with quote

There is only a 'critical' short time for USB task, if you are running the USB polled, rather than interrupt driven.
The critical thing when running interrupt driven, is that you must not significantly delay calling the USB interrupt. You don't want any significant code sections with interrupts disabled, and your other interrupt handlers should all follow the mantra of returning quickly. However, do this, and you can handle multiple things very easily. I have a 46J50, handling 2 serials (interrupt driven transmit and receive), I2C slave, timer tick interrupt, USB, and a CCP interrupt, without problems.
Remember you want to use usb_init_cs, rather than usb_init, if you want your other functions to work before the USB is connected.

Best Wishes
temtronic



Joined: 01 Jul 2010
Posts: 9243
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Nov 28, 2012 5:33 pm     Reply with quote

For what it's worth..
Maybe 2 years ago I played with the PIC18F4550 (has USB hardware inside) but 1/3 of the code space got used by the USB drivers...admittedly newer PICs are out might be better. There is a huge learning curve (bugs, timing, layout, etc)
...but...
for just $3 I can buy TTL<>USB modules that litterally just wireup and GO! No PIC drivers to contend with, no code issues, just plug the USB cable in and it's 'up and running'. Simple serial data communications...
I know ,you'll say '$3' !!..arrgh, there goes the profit.
..but..
please consider the R&D time and effort to get your product 'up and running'. You could easily spend months($$$) working out the USB bugs so that $3 module will be looking real good in getting your product out the door.

options..just think about options
hth
jay
rwskinner



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Mon Dec 03, 2012 7:43 am     Reply with quote

Ttelmah,
Do you have any more details on this regarding the interrupt usb? I have a 26J50 as well using one HW serial for GPS, one HW serial for CCS Modbus, and trying to get USB to work properly but it hasn't been very reliable as in the timing isn't tight enough and it doesn't always want to enumerate properly in polling mode.

Richard

Ttelmah wrote:
The critical thing when running interrupt driven, is that you must not significantly delay calling the USB interrupt. You don't want any significant code sections with interrupts disabled, and your other interrupt handlers should all follow the mantra of returning quickly. However, do this, and you can handle multiple things very easily. I have a 46J50, handling 2 serials (interrupt driven transmit and receive), I2C slave, timer tick interrupt, USB, and a CCP interrupt, without problems.
Remember you want to use usb_init_cs, rather than usb_init, if you want your other functions to work before the USB is connected.

Best Wishes
Ttelmah



Joined: 11 Mar 2010
Posts: 19540

View user's profile Send private message

PostPosted: Mon Dec 03, 2012 8:05 am     Reply with quote

The old mantra. Keep the interrupt handlers quick. Guesses would be doing more than just reading the character in the GPS handler. Also look for warnings about interrupts being disabled to prevent re-entrancy. Annoyingly there is one from the CCS USB code itself, but if you study the code for this, the 'external' version that will cause the delay, is only a few uSec long and called in the USB setup, so shouldn't cause a problem. But if you have any others, work out, 'why', and 'can they be stopped' (either means duplicating code, or moving code out of the interrupt).

Best Wishes
rwskinner



Joined: 08 Dec 2006
Posts: 125
Location: Texas

View user's profile Send private message

PostPosted: Mon Dec 03, 2012 4:27 pm     Reply with quote

My GPS serial int just grabs a char and puts it in a buffer and exits. I'm really concerned about the state machine in the CCS modbus driver RTU Slave.

I also see warnings not to use usb_task() in an interrupt.

Richard
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Dec 04, 2012 2:24 am     Reply with quote

Both USB and Modbus are time critical. They both require firmware drivers that respond within quite limited time frames. They probably don't work too well together. To get them to work happily side by side on the same PIC may well required extensive changes to both "drivers". It may not be possible, or at least practical in a reasonable timescale at reasonable development cost, to make them work 100% satisfactorily on the PIC: maybe just too much time criticality going on. As you say: "it hasn't been very reliable as in the timing isn't tight enough".

Fully interrupt driven code is the way to go - no polling, but the timing, especially of the delays and waits required by Modbus, is going to be hard to acheive.

RF Developer
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group