Good cheap uC with low-jitter USB HID capability? - Page 1
Forum section: electronics / beginners

author: lpc32
author_rank: Frequent Contributor
timestamp: May 01, 2014, 08:18:55 pm
content: What are some good cheap uCs for implementing a low-jitter USB HID device? I don't need a very fast processor, but low jitter is important (if that's an issue at all).Would USB 2 High Speed help in assuring better worst case jitter?On uCs with an integrated USB controller, how do you use it in practice? Minimally just connecting the chip directly to a USB connector?

author: electr_peter
author_rank: Unknown
timestamp: May 01, 2014, 08:29:51 pm
content: Can you give a bit more detail about your application? Why the jitter is important for you?I am not sure if this is more accurate representation of your question: "which µC can maintain reliable USB 2.0 connectivity with internal oscillator only (without external crystal)?"

author: lpc32
author_rank: Frequent Contributor
timestamp: May 01, 2014, 08:36:57 pm
content: I want to send sensor data to PC, with report latency consistent to < 1ms. I don't know how consistent Windows would be, but at least I can remove variability from the device side.Jitter wouldn't matter if I could somehow synchronize the PC and device clocks, but I don't see how I can do that.

author: electr_peter
author_rank: Unknown
timestamp: May 01, 2014, 09:03:45 pm
content: Jitter doesn't matter at all for low latency applications (as long as communication works).For <1ms latency USB as a protocol is not suited well (if we are talking about random data burst, not continuous transmission). This is mainly to due to USB protocol specifics (not real time by any means).I can't tell exactly what kind of latency you could expect, but I doubt that <1ms is doable. You could try to do that and test performance - you should mainly work to setup both µC and PC sides to communicate as fast as possible. Windows, for example, hardly allows "direct metal" access to USB or USB serial ports - these have internal time outs, buffers to fill in, coffee breaks, etc. that you cannot control with <1ms.I would suggest to do everything critical in µC (maybe add some RAM for temporal storage) then send all data for PC - this way you can control latency in critical areas.

author: lpc32
author_rank: Frequent Contributor
timestamp: May 01, 2014, 09:10:17 pm
content: Latency doesn't matter as much. It's consistency I'm after: I need the relative timing to be as consistent as possible so that I can timestamp the data.But what USB-capable controllers are a good choice, also in terms of hardware simplicity?

author: electr_peter
author_rank: Unknown
timestamp: May 01, 2014, 09:37:09 pm
content: Quote from: lpc32 on May 01, 2014, 09:10:17 pmIf you like to have consistent delivery of data, you should match send data size with buffer size of receiving end (PC). It depends on your data size and reconfigurability of PC. See the links, they explain importance of matching data size to buffer size (you may need to send "fake" 0 data just to fill in the buffer).http://www.datatranslation.com/phpkb/question.php?ID=627http://www.digi.com/support/kbase/kbaseresultdetl?id=3418In terms of devices, I would suggest to look at Maxim MAX232 or FTDI line of serial to USB converters. Very simple to use and configure (there are fake ones on eBay, beware).If you have USB controller build in µC, it should suffice.Other option would be to timestamp data at µC side and add timing info to data stream.

author: elgonzo
author_rank: Unknown
timestamp: May 01, 2014, 09:48:48 pm
content: If you need to timestamp your data with millisecond accuracy or better, do it on the MCU side and send the data together with the time-stamps through USB.Depending on your application scenario the MCU choice depends on more factors than just having USB support in hardware.One such factor certainly is driver support, where FTDI is rather good.But you might also need to consider possible license restrictions when using 3rd-party USB libraries (even if they are from the MCU manufacturer) and how they would apply to your case. As an example, look at DangerousPrototypes' BusPirate version 4 which is stuck in hell and probably will never be finished properly. As Ian Lesnet from DangerousPrototypes fame recently stated: "I'm frankly sick to death of dealing with USB on PICs." Reason behind this is to a great deal Microchips unfriendly licensing terms regarding their PIC USB libraries, which sort of forced the PIC community to spend lots of efforts in developing their own USB libs with varying success...

author: lpc32
author_rank: Frequent Contributor
timestamp: May 01, 2014, 10:05:51 pm
content: Thanks for the links, Peter, I'll have a look.I need the timestamps to be PC-relative, not device-relative, that's the problem. MAX232/FTDI would be CDC, I suppose, so no latency guarantees, unlike HID's Interrupt transfers. HID is also driverless, which is a plus. And I want the USB controller and processor to be the same chip.My thinking is, if USB2 High Speed Interrupt transfers are nominally guaranteed to 125us, that's the most likely way to get low jitter. But I'll go with USB1's 1ms if that means a much cheaper uC, or something that's easier to work with, mostly hardware-wise, but also software.

author: elgonzo
author_rank: Unknown
timestamp: May 01, 2014, 10:16:44 pm
content: Quote from: lpc32 on May 01, 2014, 10:05:51 pmWhat is the problem? When you initialize your USB device for operation let the PC send a time information (essentially from the PC's clock) to the MCU, and the MCU adjust its clock or sets up a timer with the time -- voila, now both the MCU and the PC have the same time base. It seems to be possible to do control transfers to such a HID device in a comparatively(!) easy way with the help of libraries such as libUSB.This is way, you will also avoid any kind of variations occurring during time taking on PC, which will very likely happen unless you use a real-time OS.If you worry about the few microseconds (or perhaps rather milliseconds) difference between the clocks of the PC and the MCU (because of the time it takes to send the time info through USB and to setup the MCU clock), well, don't worry. Your PC clock is most likely anything but accurate in relation to any official time reference anyway, so a few milliseconds more divergence does not really matter...

author: janoc
author_rank: Super Contributor
timestamp: May 01, 2014, 10:36:41 pm
content: Quote from: lpc32 on May 01, 2014, 10:05:51 pmEhm, CDC is also interrupt transfer. USB interrupt transfer has nothing to do with interrupts in the MCU sense. It just means that the USB host polls your device periodically and services the requests one by one.The other types are bulk (set up transfer once and send a large amount of data over several data requests) and isochronous (set up once and then timing has to be followed - used for e.g. streaming audio).Looking at the description of your application, I would say you need the isochronous transfer. But that is not possible to do without custom driver.Quote from: lpc32 on May 01, 2014, 10:05:51 pmWhat matters more is the total roundtrip time. If you are using interrupt transfers, then each has to be set up first. That gives you some ~10ms end-to-end latency at best, regardless of whether you are doing USB 1 or USB 2.0 - the time is going to be completely dominated by the transfer setup overhead. E.g. in Windows the task scheduler runs every 10ms, so your driver likely won't be scheduled to set up an interrupt transfer every 1ms ...

author: janoc
author_rank: Super Contributor
timestamp: May 01, 2014, 10:53:59 pm
content: Have a look here, these two pages describe what is what in USB:http://www.usbmadesimple.co.uk/http://www.beyondlogic.org/usbnutshell/usb1.shtmlThat is for USB 1.x, USB 2.0 is quite a bit more complex and unless you need the extra bandwidth (transferring LOTS of data), don't bother. Chips that can handle that are a few and far between and the board design starts to be nontrivial (the signal integrity at 480Mbps is quite a big deal). If you only need to send few bytes of data with a predictable latency, then full speed USB 1.x and isochronous transfer will do the job just fine.

author: Galaxyrise
author_rank: Frequent Contributor
timestamp: May 01, 2014, 11:03:08 pm
content: Quote from: lpc32 on May 01, 2014, 10:05:51 pmAdd a one-time computation when the PC receives the first event, computing the mapping input time x to PC time y. You're not going to get a better source of relative timings than the MCU, so you should preserve that information. Depending on your setup, the PC can handle the device rebooting by recomputing the offset if MCU time ever goes backwards.

author: lpc32
author_rank: Frequent Contributor
timestamp: May 02, 2014, 12:08:14 am
content: elgonzo: The issue is indeed the few ms due to the transfer. If jitter is low (admittedly, particularly from the Windows side) I might be able to account for the roundtrip and sync the clocks more or less: a few pings, throwing out high outliers, maybe minding both the average and minimum. Ultimately the timestamping I needisthe PC time. I don't care about world time.janoc: CDC data is Bulk and possibly Isochronous. Or do you mean the control endpoint(s)? Iso is allowed to drop data, and I think is more likely to add jitter due to buffering (assuming it just needs to guarantee a semi-local data rate rather than max latency per transfer). I don't need to transfer data most of the time, but when I do it's just a few bytes and the latency needs to be as consistent as possible. HID is both Interrupt and driverless in Windows, so seems the most suitable. (Though I think continuous but minimal data should work just as well, as mice are HID?)Galaxyrise: Ideally I need to sync the clocks to <1ms, so the USB jitter starts to dominate.But anyway, this is all software. I need advice with hardware!Any recommended chips? Cheap, easy package, as much of USB/HID handled by hardware rather than software (if that's gonna be useful), minimal auxiliary components, enough memory, high frequency/resolution timer, easy to work with/good docs/tools, and if possible USB2 High Speed.

author: janoc
author_rank: Super Contributor
timestamp: May 02, 2014, 07:02:38 pm
content: Quote from: lpc32 on May 02, 2014, 12:08:14 amQuote from: lpc32 on May 02, 2014, 12:08:14 amYou are mixing everything together. All transfers are going to be buffered on the OS side, but the isochronous transfer is your best bet if you want to limit the jitter and have a defined deadlines when to deliver the data to/from the device (otherwise things like audio streams would have dropouts).Quote from: lpc32 on May 02, 2014, 12:08:14 amBut mice are certainly not working on ~1ms latency/jitter limit.Quote from: lpc32 on May 02, 2014, 12:08:14 amI doubt you will find a general purpose chip that does HID in hardware. Most microcontrollers have general purpose USB transceivers and is up to you to write firmware that does what you want - e.g. implements HID or CDC or whatever.The USB2 issue - you are insisting on USB2 - no idea why - it is a complete waste for your application as your latencies will be completely dominated by the transfer setup times. With HID you are limited to interrupt transfers (bulk and iso are not allowed for HID). So each transfer must wait until your host sends a control transfer and then starts a data transfer. That will make you fully dependent on the OS latencies (the control transfers are application/driver-initiated). In addition, you may demand the 125uspolling frequencyfrom the host, but there is no guarantee you will get it:http://www.embeddedsys.com/subpages/resources/images/documents/InterruptsAndUSB.pdfAnd no matter what USB host controller does, that is still only latency to the host's buffer. Afterwards you are at the mercy of the OS when it decides to actually give time to your driver.I strongly suggest you rethink your design, because you are attempting to do something that may not be possible with the tools you want to use.

author: mariush
author_rank: Super Contributor
timestamp: May 02, 2014, 07:31:02 pm
content: Here's an idea... make your project output a stereo sound, 48Khz 16 bit stereo... you'd be able to safely pack 8-10 bits and some crc info in that 16 bit sample, and have redundancy in each of those 48000 samples a second. Use second channel for redundancy or for signalling that new data packet comes etc etc, use your brains.Write some simple software that records line in input... if you need to synchronize, maybe use send a "ping" through usb (or maybe serial to mcu for less latency) to your microcontroller and your mcu sends back an "aknowledge" through the audio cable, and when it comes your software knows the time it takes for signal to go to mcu, be processed and how much time it takes for the soundcard to get you the sound.Seehttp://hackaday.com/2011/07/10/sound-card-microcontrollerpc-communication/

author: amyk
author_rank: Super Contributor
timestamp: May 03, 2014, 12:41:14 am
content: Simplest solution would be to put a PCI/PCIe parallel port card in the PC.

author: Rerouter
author_rank: Super Contributor
timestamp: May 03, 2014, 02:16:39 am
content: Another flip on it, why not time-stamp on the local device and use a good crystal, if your running it for stupidly long periods of time them have the computer send back a current time packet every hour and your assured that it wont matter how unreliable the communication method is, it will get there and have a correct time stamp,

author: lpc32
author_rank: Frequent Contributor
timestamp: May 03, 2014, 10:15:00 pm
content: janoc: Regardless of USB class or transfer type I need to settle on a chip first before I could experiment. (BTW, some mice/drivers do have a 1ms polling rate.)mariush: I considered line-in, but I don't think I can expect low jitter from audio recording.amyk: I need it to work on any random computer, so no real serial/parallel ports.Rerouter: Jitter is still the issue.Anyway, no one has recommended chips so I'll go with some more specific questions...I'm new to this. Should I completely rule out anything without a big community? Does that mean only PIC and AVR, or should I consider also ST, TI, Freescale, Silicon Labs, etc.?Some MCUs don't need an external crystal for USB and apparently re-adjust based on USB communication from the host. Any big reasons to still prefer an external crystal? If part minimization is a factor, are there any reasons to look at chips that do need a crystal?If I need to store dynamics settings, should I still consider chips with no EEPROM and just flash? (Some advertise 512-byte flash block size, which is workable enough.) Do all chips allow writing to the flash in-system?Is 8-bit vs 16-bit a big deal?Do chips of the same family with more instructions offer a big advantage?

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2014, 10:24:16 pm
content: Quote from: lpc32 on May 03, 2014, 10:15:00 pmYou are confusing the polling rate that you can request from the host with actual latency you will get. That are two very different things.If you take the interrupt transfer (e.g. HID), your device gets polled first time - it signals the host that it wants to do transfer. However,whenyou are going to actually get the incoming control transfer from the host setting up the actual data transfer containing the HID report, you don't know -that does not happenright away (e.g. the next polling period)That is completely dependent on the situation on the OS, how it handles interrupts from the USB host controller, load, task scheduling, etc. Common latencies there are on the order of 10ms or so. The faster polling rate does not help you anything. That's why these "gaming mice" with super fast polling are mostly a gimmick - beyond certain polling rate the host will not be able to service the device as fast as it is asking and the extra interrupts only increase system load.See why the 125us limit of USB 2.0 is a red herring here? The overhead of the interrupt transfers needed for something like HID is going to blow your latencies out the water. USB 2.0 is good if you need to transfer a LOT of data fast, but that isn't your case.Let's take the isochronous transfer instead - in that case you haveonly onecontrol transfer setting it up and afterwards you are streaming data to the host at a defined speed, no matter what else is going on on the bus. Your transfer even gets priority over stuff like bulk or interrupt transfers, because isochronous mode guarantees constant latency. However, to use this, you cannot insist on HID, you will need to write your own driver and firmware.Re chips: small USB2.0 micros are rare, I think only some Cypress PSoCs have USB 2 transcievers. USB 2.0 is way too fast and needs way too much memory to service on the small chips (another reason to stick to USB 1.1). You would have to step up to some bigger ARM SoC and similar, but then we are talking devices on the level of a BeagleBoard or something that could power a smartphone.If you stick to USB 1.1, then you can get the 12MBps full speed transciever in many micros - I have good experience with the STM32F1 & STM32F3xx line, also the LPC17xx from NXP is decent.PIC was also mentioned, while it does work, the tooling and the libraries from Microchip leave a lot to be desired - it is not very easy to make work, even if you know what you are doing. Moreover, their libraries were not compiling with their new compilers, only the old C18 oneIn addition, the smallest USB-enabled chips like 18F14k50 have a weird memory layout with only very tiny slice of the address space accessible to the USB hardware - makes for an "interesting" debugging and development, where you have to count every byte of your HID report in order to make sure it still fits in there.Some of Atmel's ATmega and XMega chips also have USB hardware, but I don't have experience with those, I have only used the V-USB bitbanged low speed USB on Atmels.

author: free_electron
author_rank: Super Contributor
timestamp: May 05, 2014, 10:46:07 pm
content: Janoc got it rightIN SHORT : High speed usb (480 mbit/s) is good to open a pipe and blast a huge amount of data in one operation. repeatedly opening and closing the pipe to send a few bytes takes way too much overhead. and you can't leave the pipe open.now , Low speed usb (1.5mbit/s) or full speed usb (12 megabit) per second is limited to a packet every 1 millisecond you can't go faster than that hardware wise. miss the slot and you have to wait.USB is a time multiplexed bus. every 1 milliseconds a packet can be transmitted. miss the begin by 1 microsecond and you wait another 1 milliseconds.so what you are attempting is simply not possible

author: janoc
author_rank: Super Contributor
timestamp: May 05, 2014, 10:46:28 pm
content: Quote from: lpc32 on May 03, 2014, 10:15:00 pmUm, ARM chips like from ST, NXP and similar have probably orders of magnitude larger "community" behind than anything AVR (especially because AVRs don't have USB except for a few odd chips).Quote from: lpc32 on May 03, 2014, 10:15:00 pmIf you want to keep jitter to a minimum, you must have a crystal, period. The need for precise timing and not using a crystal oscillator is just silly. Moreover, the crystal-less operation usually works with large limitations - e.g. only for low speed USB. There are some PICs that do clock recovery from USB 2.0, but I have no experience with those (also see about PICs below)Quote from: lpc32 on May 03, 2014, 10:15:00 pmTypically you don't want to write into flash too often - the flash has limited number of writes, with some chips even as low as 1000 writes. Also not all chips allow self-programming (writing into program flash), even though those are getting rare. Either get a chip with a built-in EEPROM or add an I2C/SPI external one - it costs peanuts.Quote from: lpc32 on May 03, 2014, 10:15:00 pmFor USB 1.1, the difference between hacking something up on a slow 8bit CPU which and a beefy 32bit ARM can be whether you application will work or will not work at all (e.g. because the CPU is too slow to send the data over USB fast enough).For USB 2.0 there are only some Microchip PICs that support this on 8bit/16bit, but I wouldn't feel comfortable using an 8bit/16bit PIC for a low latency USB 2.0 device. Those chips simply don't have the power nor RAM to handle much traffic at those speeds.Quote from: lpc32 on May 03, 2014, 10:15:00 pmThat depends pretty much on your compiler (whether it can take advantage of the extra instructions, for ex.), which chip are we talking about, etc. It is not possible to answer in general.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: May 05, 2014, 11:43:41 pm
content: Quote from: lpc32 on May 01, 2014, 08:18:55 pmCypress makes some very pretty USB µC (ARM) + Analog + CPLD programmable all-in-one chips: EZ-USB and PSoC 5 have built-in USB, and the PSoC 4 dev kits (the dev kit is $4, the chips are $1) although not themselves USB devices, can connect via USB through a bridge chip (that isn't a HID device):http://www.cypress.com/?rID=92146If you haven't seen them already, I'd say check out their PSoC and EZ-USB intro videos, just in case.

author: lpc32
author_rank: Frequent Contributor
timestamp: May 05, 2014, 11:55:23 pm
content: I realize actual latency won't be that good, but my hope is that jitter would have lower bounds. If <=1ms polling rates are there, I hope there's some drive in software/hardware to try to implement it in practice.The USB specs define Interrupt as "limited latency transfer", "may have response time bounds that the USB must support", and "guaranteed maximum service period". Iso is "sensitive to delivery delays" and has "guaranteed bandwidth and bounded latency". I have not tested this, can't yet, but my hunch is that Iso transfers would act more like average bitrate than constant bitrate, as the implied usage is audio/video and other streaming. Jitter won't matter much, it would mainly need no buffer underruns and latency that isn't horrible. But this is all a future issue.Yeah, I see cheap USB 480Mb MCUs are non-existent. There are some at around $5 from ST, Atmel, etc., but I'll skip that for the time being. And yes, I've read complaints about Microchip's software, so these are out.Would you consider the ST/NXP/Freescale ARM ecosystem/community/whatever to be equally newcomer-friendly as AVR? I'm leaning toward Atmel, maybe ATmega32u4, but going with ARM might have long-term advantages.Re extended instruction sets, assembly is acceptable too (where needed). I just wonder how common it is, with the more basic chips, to run into situations where you have to start doing things tediously with multiple instructions, or ending up getting much larger binary code, or much slower code even for simple things (no hardware mul?).BTW, another advantage would be programming (flash) and debugging interfaces that don't require more hardware.

author: lpc32
author_rank: Frequent Contributor
timestamp: May 05, 2014, 11:58:08 pm
content: George, thanks, I'll have a look. Too bad it's not the PSoC5 board for $4. But I bet anyway shipping is $40.

author: miguelvp
author_rank: Super Contributor
timestamp: May 06, 2014, 07:45:00 am
content: Quote from: lpc32 on May 05, 2014, 11:58:08 pmThe pioneer board not only has the PSoC 4 but also comes with the PSoC5LP that can be used as well:http://www.element14.com/community/thread/23736/l/100-projects-in-100-dayshttp://www.element14.com/community/thread/25084/l/psoc-4-pioneer-kit-community-project036-what-i-can-use-the-psoc-5lp-toobut the kit is $25 unlike the PSoC 42xx/41xx prototyping kits for $4 or $1 for the chip. I bought my pioneer from newark since they drove the effort for all that sample code (no HID samples I'm afraid)

author: rs20
author_rank: Super Contributor
timestamp: May 06, 2014, 08:11:33 am
content: Quote from: lpc32 on May 02, 2014, 12:08:14 amHoping for a PC clock to remain consistent to within 1ms is just nuts. Your operating system will check its time against the OS and adjust the clock tick amount, making the clock drift all over the place. The room will warm up and lose 1ms every second. PC clocks are all about being accurate to the second over years, not at all about being accurate to 1ms every second. Your MCU will be far better at the latter. What are you actually try to achieve here? What's the purpose of the project?The only reason you should be so much more interested in your PC's time than your MCU's time is if you want to drive something with that same PC clock. If so, what is it? You should probably be considering moving this other thing away from PC clock control. If not, what on earth are you trying to do??In any case, if your MCU timestamps every event according to its own excellent timer (and I'm sure most MCUs are quite excellent in this respect), and sends that back to the host, the PC can then add its own crappy timestamp to the message (whether it be crappy due to the inherent crappiness of a PC clockor because the timestamp is late due to a high latency/high jitter-link). It's a straightforward job to combine the short-term accuracy of the MCU with the absolute long-term correctness of the PC, as mentioned by earlier posters in the thread. (In short, fit a linear regression between the two, if you want help on this, do ask and we'll help you out.) Think about it, if an MCU sends two messages that itknowsare 1 second apart, but the PCthinksthe messages are 1.2 seconds apart, youknowyou have 0.2 seconds of jitter right there, and you can so easily just subtract it.

author: andersm
author_rank: Super Contributor
timestamp: May 06, 2014, 08:36:07 am
content: Quote from: lpc32 on May 05, 2014, 11:55:23 pmLow jitter is extremely important for USB audio, and your operating system will have entire subsystems dedicated to providing steady, low-latency audio.As others have stated, the interrupt transfer polling rate is best-effort, and the device descriptor only provides a lower bound. Additionally, the OS will not poll a device unless there is an outstanding data request, and guaranteeing a steady rate of requests can be difficult. If your USB thread ever gets suspended, you can easily lose 10+ milliseconds.I'd recommend just getting a cheap board like an ST Discovery and start prototyping with that. Once you have something working, you'll know more about what's actually involved and what to look for.

author: miguelvp
author_rank: Super Contributor
timestamp: May 06, 2014, 08:38:43 am
content: Quote from: rs20 on May 06, 2014, 08:11:33 amQueryPerformanceFrequency and QueryPerformanceCounter should give you a good sync time base on the PC. Still your second might not be "one" second but it will sync nicely to your MCU. In order to do a good one second it will take some signal processing between your PC frequency and the RTC of the PC to get rid of the aliasing between both frequencies.The problem on the RTC is that it's sampled by the OS so even if the RTC is accurate the sampling from the OS will alias it making the seconds jump all over the place.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: May 06, 2014, 10:56:30 am
content: Quote from: lpc32 on May 05, 2014, 11:58:08 pmShipping to Spain was $15, where are you based?

author: SandunDhammika
author_rank: Newbie
timestamp: May 06, 2014, 11:07:14 am
content: Quote from: miguelvp on May 06, 2014, 08:38:43 amIn the case of linux the operating system does uses RTC on it's boot. After the kernel initialized it no longer use RTC.The kernel uses it's timer interrupt to update operating system kernel software clock.Software clock is not either accurate as RTC.But I think if wanted one could hook RTC interrupts , kernel support you to write a hook.>>http://www.mjmwired.net/kernel/Documentation/rtc.txt

author: rs20
author_rank: Super Contributor
timestamp: May 06, 2014, 12:51:52 pm
content: Quote from: miguelvp on May 06, 2014, 08:38:43 amAll irrelevant when the computer's receipt of the event in question is affected by latency and "latency jitter". What I'm saying here (admittedly not as clearly as I could) is that the OP is solving the wrong problem. Once you've said "I need ~ 1ms timing accuracy on a non-real-time PC", you've already taken a wrong turn, even if there are ways to complicatedly and hackily achieve this. But every rule has its exceptions, which is why I'm encouraging the OP to describe the actual overarching goal of this project.

author: amyk
author_rank: Super Contributor
timestamp: May 06, 2014, 01:32:46 pm
content: Quote from: lpc32 on May 03, 2014, 10:15:00 pmIt's interesting that 10-15 years ago, this would be considered absurd.(I still havetwo eachof parallel and serial ports on my main machine, and it's only a few years old.)

author: electr_peter
author_rank: Unknown
timestamp: May 06, 2014, 07:32:19 pm
content: lpc32, please provide more information of what are you planning to do. This way it could be easier to provide adequate solution. As others mentioned, USB protocol and PC timing are not low latency or accurate to your provided request (<1ms).I wanted to also mention that USB 1.1 and USB 2.0 are half-duplex ONLY (USB 3.0 has provision for full duplex mode, but USB 3.0 implementation is way too complex for MCU). USB protocol allows to send big data stream in one direction (host->device or device->host), but bidirectional communication is limited in comparison with full duplex systems. This could really ruin your day if you want good timing and good data rate.Another point. I would suggest to use term "latency" as "time from initialisation of transmit to first received bit". Latency has minimal bound for USB, but no clear maximum bound. Term "jitter" - "randomness/uncertainty of clock".Some writing above is confusing due to terminology used.

author: tszaboo
author_rank: Super Contributor
timestamp: May 06, 2014, 07:44:09 pm
content: NXP's LPC13xx MCUs have USB HID, but take into account that with HID, you can transfer 64 byte every 1 ms, nothing more. For the PC side I recommend the so called hidapi library, which is for C.

author: janoc
author_rank: Super Contributor
timestamp: May 07, 2014, 09:05:48 am
content: Quote from: NANDBlog on May 06, 2014, 07:44:09 pmThose micros have a general purpose USB transciever, not "USB HID". Yes, you can implement HID with it by writing custom firmware, but it is not something that comes "built-in". Just a clarification for the sake of the original poster.

author: SandunDhammika
author_rank: Newbie
timestamp: May 07, 2014, 10:01:05 am
content: Quote from: amyk on May 06, 2014, 01:32:46 pmMy PC is not more than 6 months old [since I fry my laptop], but it does have both ports. But it's not the point.Serial or parallel ports are connected with the LPC bus which is designed for low bandwidth devices and limited around 6MBps.So latencies are there on it too.And form the intel LPC specification docs.http://www.intel.com/design/chipsets/industry/25128901.pdfQuoteThere are some embedded x86 boards which have some FPGA space to implement your own LPC device. Since OP describes somewhat about a portable computer which does only have USB. Don't know the extract value of the LPC bus latency but I think USB have low latency than LPC.

author: tszaboo
author_rank: Super Contributor
timestamp: May 07, 2014, 11:45:25 am
content: Quote from: janoc on May 07, 2014, 09:05:48 amThat is not entirely true. Most of the code is built into the code is in the ROM of the device, you just have to call the functions there, and of course set some registers. It is as hard as downloading the example, opening it, and it works. AN10904 from them explains how it is done. I had it working in less than a week, and most of the time of this was trying to make it work as a keyboard (which was impossible btw).You cannot expect any MCU to use USB without code, and this is as easy as it gets.

author: janoc
author_rank: Super Contributor
timestamp: May 09, 2014, 01:45:32 pm
content: Quote from: NANDBlog on May 07, 2014, 11:45:25 amNXP actually ships part of their peripheral library in siliconThis I didn't know - usually this type of code is in a library that you link to, not something built-in within the device. Interesting approach ...However, my comment was more targeted at dispelling the notion that the micro somehow does HID without custom firmware, as you have pointed out as well - e.g. something like the FTDI chips do for UART/CDC where you just hook up your device and "it works".

author: lpc32
author_rank: Frequent Contributor
timestamp: May 09, 2014, 09:56:48 pm
content: miguel: PSoC looks potentially interesting, but I won't go with one for this. Interesting, but I don't understand what it does really, analog-wise. The few things I looked at, trying to get an overview of what it is, were all marketing. Kinda sad.rs20: Yes, I need to correlate the timing with the PC, which orchestrates other aspects in the overall process. In theory it can all be done externally to the PC, but it would be more expensive, and especially more complex than would be wise for me to attempt at this stage. Another option, maybe, could be some Linux after tweaking it to prioritize USB.andersm: That's more or less the idea; start prototyping, and worst case just learn some about what's involved.George: Not in Europe. But I didn't check the shipping in practice, maybe it is $15.amyk: I bet in many cases you can still find at least headers for serial or parallel, but not on laptops. But even on serial or parallel I'm not sure what latency or jitter you can expect nowadays. The bus they're on is probably also radically different between computers, depending on the CPU or chipset. Most likely a 386 running DOS would be a better platform.peter: Worst case I will have gained some knowledge in embedded. Yeah, I generally mean that by "latency" or "jitter". Half duplex is not a problem.Sandun: 4µs sounds great.LPC134x's ROM code for HID is interesting. Though I suppose if you go anyway with faster 32-bit MCUs there's no need for dedicated hardware. What I had in mind initially was real hardware that enables good HID performance on cheap/modest MCUs, but by the looks of it it's not necessary even there.Anyway, thanks for the suggestions everyone!

author: rs20
author_rank: Super Contributor
timestamp: May 11, 2014, 10:54:44 pm
content: Quote from: lpc32 on May 09, 2014, 09:56:48 pmHow are you orchestrating these other aspects? Are they being driven over USB as well? You don't necessarily need your logic to be external to the PC, but if you have a single device performing both dumb input and dumb output on a consistent time-base, all your worries go away. Obviously I'm suggesting this without knowing the specific protocols going on here.Alternatively, I'll re-iterate again that not worrying about USB latency "jitter", timestamping on the MCU, and blending with PC clock timestamps in PC software will be more accurate, more reliable, easier, and more platform-independent than trying to assemble a low "jitter" USB chain from MCU to PC. A PC just isn't a real-time device.

author: tszaboo
author_rank: Super Contributor
timestamp: May 12, 2014, 03:11:02 pm
content: Quote from: janoc on May 09, 2014, 01:45:32 pmI suppose it is because the size of the Flash is small, and with the libraries you wouldn't have any space left. If you don't need USB than you wouldn't chose this part anyway. So It kinda makes sense, and there is less things to break... Makes debugging harder, but debugging USB is kinda impossible anyway (connection dies on the breakpoint, device gets dropped). Also, it comes with a ROM mass storage bootloader (which is awesome), the code for the USB would be there anyway.I liked the approach, I hope others will use this.I think you can make mass storage, CDC and HID with it, but not HID keyboard or mouse, at least I found that impossible.

author: janoc
author_rank: Super Contributor
timestamp: May 12, 2014, 11:18:14 pm
content: Quote from: NANDBlog on May 12, 2014, 03:11:02 pmSomehow doubt that, there are devices with up to 64kB of FLASH in the LPC13xx line. The minimum is 8kB, but that is only one device, most have at least 32kB. I have a full USB CDC device with a lot of other things running in about 20kB of FLASH on an STM32 with ChibiOS/RT, without any built-in drivers, so I think the same should be possible on the NXP chips as well.I suppose it is more for convenience and to save FLASH, they probably assume that that product is going to be used for USB peripherals, so the driver can be as well included.Quote from: NANDBlog on May 12, 2014, 03:11:02 pmUrgh ... Don't get me started on that ... I have learned this the hard way on a PIC.It is a pity that there isn't any affordable USB analyzer, I was looking at the OpenVizsla, but it seems that those guys have just disappeared with their Kickstarter money ...Quote from: NANDBlog on May 12, 2014, 03:11:02 pmThat's bizarre that you can make HID, but not a HID keyboard/mouse? Why would that be? It is just a matter of a different HID descriptor, which has to be specified by the developer anyway.

author: lpc32
author_rank: Frequent Contributor
timestamp: May 14, 2014, 12:26:31 am
content: rs20: No, the other PC aspects don't involve USB. I'll know more after I start playing with it.

author: ve7xen
author_rank: Super Contributor
timestamp: May 14, 2014, 01:28:59 am
content: If you just tell people what the practical problem you're solving is, you'll get much better advice. Being vague and dancing around the questions you're asked does not help anyone help you. Your specified problem seems to be one of your own making ( and doesn't make a whole lot of sense to start with, given rudimentary knowledge of USB ), that would be better solved by a better design, not a specific part. We can't help you fix that if you won't tell us what problem you're actually solving.

author: lpc32
author_rank: Frequent Contributor
timestamp: May 14, 2014, 02:11:49 am
content: I was just looking for MCU suggestions and opinion. I got some info and pointers, so mission accomplished. The global goal is something I'd like to tackle myself. If it can't be done, it will require a more complex design, but this is not something I feel comfortable approaching at this stage.