Author Topic: PIC18F2550 USB  (Read 5517 times)

0 Members and 1 Guest are viewing this topic.

Offline void_errorTopic starter

  • Frequent Contributor
  • **
  • Posts: 673
  • Country: ro
  • I can transistor...
PIC18F2550 USB
« on: December 25, 2014, 12:44:21 pm »
Here's the deal:

I've been working on a bench power supply project and I ended up with the decision of adding USB connectivity. Nothing has been implemented or tested so far on the digital side of things, it's just a bunch of ideas and I have a few questions for you who have been mocking around with USB on a PIC18F2550 (or any 8-bit PIC with USB).

Will the USB connection mess with my interrupt based code? There won't be much sent through the USB just a few numbers and the PSU will be controlled through it's UI, so I'm not planning to use the USB connection to control the PSU, just data logging. Will I be better off using two micros, one for the PSU control and one for the USB connectivity?

All the peripherals (display, buttons, ADCs, DACs) are using the SPI bus, display and buttons via I/O expanders, ADC & DAC will be isolated using a specialized chip as the PSU is floating while USB is mains earth references.

The reason I'm not using an FTDI or similar chip is because of this tutorial I found while digging on the internet.
Trust me, I'm NOT an engineer.
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: PIC18F2550 USB
« Reply #1 on: December 25, 2014, 04:56:57 pm »
The lower layers of USB in PIC18F are hardware implemented and there is little interference with the rest of the code. The USB transactions as such (all but isochronous) have no timing constrains - uC can service those IRQs at any time and there are no buffer overruns or underruns, no matter how slow the uC is. The USB hardware governs all the communication.
As for locating the isolation - I think that is a reasonable place for dividing the PSU. An USB device on one side, then SPI optical isolation and then SPI-based ADCs/DACs.
 

Offline johnmx

  • Frequent Contributor
  • **
  • Posts: 277
  • Country: pt
Re: PIC18F2550 USB
« Reply #2 on: December 25, 2014, 06:20:52 pm »
The USB transactions as such (all but isochronous) have no timing constrains - uC can service those IRQs at any time and there are no buffer overruns or underruns, no matter how slow the uC is. 
Not completely true. Many years ago I found that the USB routines should be called once per around 10 ms or you could get communication issues. This is also recommended by Microchip.
Sometimes I can pause a running program in debug mode and continue normally, but most of the time the communication freezes without recovering.

The USB interrupt tasks are very fast. Usually this creates no problem. If you decide to use the stack in polling mode, don't block the CPU for too long.
Best regards,
johnmx
 

Offline fcb

  • Super Contributor
  • ***
  • Posts: 2117
  • Country: gb
  • Test instrument designer/G1YWC
    • Electron Plus
Re: PIC18F2550 USB
« Reply #3 on: December 25, 2014, 06:54:04 pm »
I've built a few products like this.

I tend to use an FTDI USB IC (FT230X) and isolate via either opto-couplers or my favourite digital coupler (TI ISO7521).
https://electron.plus Power Analysers, VI Signature Testers, Voltage References, Picoammeters, Curve Tracers.
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: PIC18F2550 USB
« Reply #4 on: December 25, 2014, 09:14:30 pm »
The USB transactions as such (all but isochronous) have no timing constrains(..)
Not completely true. (..) 10 ms or you could get communication issues.
Perhaps what you describe is the case with the setup packets where the device is idle, not configured yet and has to respond within some reasonable bounded timings before a USB host gives up. There are some USB timeout limits (1s or so) before a pop-up message appears "Cannot recognize your USB device" after pluging a USB device. After device is configured all the communication is driven by PIC hardware and the PIC firmware does not service any transactions or IRQs but the ones that govern the user data exchange. These transactions do not have any timing limits.

As for debugging - I understand that OP is asking about PIC USB load in running application, not about USB timeouts while debugging a PIC (with a debugging dongle).
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: PIC18F2550 USB
« Reply #5 on: December 25, 2014, 10:35:59 pm »
OP, how do you plan to interface with the device from the computer side, using serial port? HID? Other?

Serial port has the advantage that you can use standard terminal emulators and it is more cross OS friendly. With FTDI your power supply will be able to talk with Windows, Mac OSX and Linux without having to install any driver.

Will the PIC stack achieve the same?
 

Offline void_errorTopic starter

  • Frequent Contributor
  • **
  • Posts: 673
  • Country: ro
  • I can transistor...
Re: PIC18F2550 USB
« Reply #6 on: December 26, 2014, 05:11:23 am »
OP, how do you plan to interface with the device from the computer side, using serial port? HID? Other?

Serial port has the advantage that you can use standard terminal emulators and it is more cross OS friendly. With FTDI your power supply will be able to talk with Windows, Mac OSX and Linux without having to install any driver.
It's going to interface as an HID device, like in the tutorial I linked. I'm going to experiment with it in the next few days after I slap together a small development board.

The USB transactions as such (all but isochronous) have no timing constrains(..)
Not completely true. (..) 10 ms or you could get communication issues.
Perhaps what you describe is the case with the setup packets where the device is idle, not configured yet and has to respond within some reasonable bounded timings before a USB host gives up. There are some USB timeout limits (1s or so) before a pop-up message appears "Cannot recognize your USB device" after pluging a USB device. After device is configured all the communication is driven by PIC hardware and the PIC firmware does not service any transactions or IRQs but the ones that govern the user data exchange. These transactions do not have any timing limits.

As for debugging - I understand that OP is asking about PIC USB load in running application, not about USB timeouts while debugging a PIC (with a debugging dongle).
No debugging, just sending data back to the PC for logging purposes.

Will constantly 'spamming' data back to the PC via the USB connection often enough be a workaround the timeouts? Since the PSU code will be sync'd to timer0 interrupts I suppose could send the data in the ISR then go about communicating with the SPI peripherals.
I'm planning to do this using a software-based timer to divide timer0 like this (not in this particular order):
  • Read one ADC channel at a time (will be using an ADS1241)
  • Refresh the display (128x64 graphical LCD connected via a MCP23S17 I/O expander)
  • Read buttons (via a MCP23S08 or MCP12S17 using its interrupt feature to detect/store whether a button has been pushed)
  • Write to the DAC (MCP4922)

With the DAC being far less accurate than the ADC there will also be some calibration routines with every write to DAC, the ADC will have two channels connected to the DAC outputs. Two more will be used to read the PSU output voltage/current, one for the input voltage, one for the pre-regulator voltage and two more for two temperature sensors.
Trust me, I'm NOT an engineer.
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: PIC18F2550 USB
« Reply #7 on: December 26, 2014, 07:35:25 am »
No debugging, just sending data back to the PC for logging purposes.

Having a serial interface (e.g. FTDI) with plain text is more straight forward for this application and will support all three OS's with no special drivers.
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: PIC18F2550 USB
« Reply #8 on: December 26, 2014, 10:26:45 am »

No debugging, just sending data back to the PC for logging purposes.

Will constantly 'spamming' data back to the PC via the USB connection often enough be a workaround the timeouts?
There are no USB timeouts w.r.t. those data transfers. You can send one byte per week or 1MB/s if you like, no "spamming" required.
As for debugging - I do not remember if PIC18F freezez USB transceiver when entering halt state (during debugging). IIRC it does freeze USART while debugging. If it does the same with USB - prepare for PITA.
 

Offline hamdi.tn

  • Frequent Contributor
  • **
  • Posts: 623
  • Country: tn
Re: PIC18F2550 USB
« Reply #9 on: December 27, 2014, 02:47:14 pm »
i used a HID application once with PIC18F4550 ( same thing as PIC18F2550) not hard task to do , you can use the HID example given by Microchip in their library and  start from there, you will have a basic source code for the firmware and the PC software as well, and i don't think it will interfere with controlling your power supply. When i used it , the project was a meter counter , it can work by itself no need for usb connectivity and like your case the usb was only for debugging. had no problem at all.   ;)

 

Offline JTR

  • Regular Contributor
  • *
  • Posts: 107
  • Country: au
Re: PIC18F2550 USB
« Reply #10 on: December 28, 2014, 08:14:27 am »
Sorry for short reply, on crap tablet in back of Chiang Mai. USB ALWAYS has timing constraints. A setup packet or USB reset can arrive ANYTIME and it must be serviced within a specified time. See specs for details.

In any case you ISR probably won't be too long to cause spec to be violated. 
 

Offline theatrus

  • Frequent Contributor
  • **
  • Posts: 352
  • Country: us
Re: PIC18F2550 USB
« Reply #11 on: January 13, 2015, 05:42:10 pm »
No debugging, just sending data back to the PC for logging purposes.

Having a serial interface (e.g. FTDI) with plain text is more straight forward for this application and will support all three OS's with no special drivers.

This actually requires drivers (specifically, the FTDI ones).

A USB HID application is driver free on all systems, and having an automatically packetized data flow is immensely useful.
Software by day, hardware by night; blueAcro.com
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf