USB and usb_task()?

[hmmpic]

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.

[Ttelmah]

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]

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]

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]

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]

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]

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