PIC18F2550 USB - Page 1
Forum section: electronics / general

author: void_error
author_rank: Frequent Contributor
timestamp: December 25, 2014, 12:44:21 pm
content: 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 ofthis tutorialI found while digging on the internet.

author: Brutte
author_rank: Frequent Contributor
timestamp: December 25, 2014, 04:56:57 pm
content: 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.

author: johnmx
author_rank: Frequent Contributor
timestamp: December 25, 2014, 06:20:52 pm
content: Quote from: Brutte on December 25, 2014, 04:56:57 pmNot 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.

author: fcb
author_rank: Super Contributor
timestamp: December 25, 2014, 06:54:04 pm
content: 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).

author: Brutte
author_rank: Frequent Contributor
timestamp: December 25, 2014, 09:14:30 pm
content: Quote from: johnmx on December 25, 2014, 06:20:52 pmPerhaps 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).

author: zapta
author_rank: Super Contributor
timestamp: December 25, 2014, 10:35:59 pm
content: 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?

author: void_error
author_rank: Frequent Contributor
timestamp: December 26, 2014, 05:11:23 am
content: Quote from: zapta on December 25, 2014, 10:35:59 pmIt'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.Quote from: Brutte on December 25, 2014, 09:14:30 pmNo 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.

author: zapta
author_rank: Super Contributor
timestamp: December 26, 2014, 07:35:25 am
content: Quote from: void_error on December 26, 2014, 05:11:23 amHaving 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: December 26, 2014, 10:26:45 am
content: Quote from: void_error on December 26, 2014, 05:11:23 amThere 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.

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: December 27, 2014, 02:47:14 pm
content: 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.

author: JTR
author_rank: Regular Contributor
timestamp: December 28, 2014, 08:14:27 am
content: 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.

author: theatrus
author_rank: Frequent Contributor
timestamp: January 13, 2015, 05:42:10 pm
content: Quote from: zapta on December 26, 2014, 07:35:25 amThis 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.