Good cheap uC with low-jitter USB HID capability?

[rs20]

Galaxyrise: Ideally I need to sync the clocks to <1ms, so the USB jitter starts to dominate.

Hoping 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 clock or 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 it knows are 1 second apart, but the PC thinks the messages are 1.2 seconds apart, you know you have 0.2 seconds of jitter right there, and you can so easily just subtract it.

[andersm]

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.

Low 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.

[miguelvp]

Galaxyrise: Ideally I need to sync the clocks to <1ms, so the USB jitter starts to dominate.

Hoping 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 clock or 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 it knows are 1 second apart, but the PC thinks the messages are 1.2 seconds apart, you know you have 0.2 seconds of jitter right there, and you can so easily just subtract it.

QueryPerformanceFrequency 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.

[GeorgeOfTheJungle]

George, thanks, I'll have a look. Too bad it's not the PSoC5 board for $4. But I bet anyway shipping is $40.

Shipping to Spain was $15, where are you based?

[SandunDhammika]

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.

In 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

[rs20]

QueryPerformanceFrequency 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.

All 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.

[amyk]

amyk: I need it to work on any random computer, so no real serial/parallel ports.

It's interesting that 10-15 years ago, this would be considered absurd.

(I still have two each of parallel and serial ports on my main machine, and it's only a few years old.)

[electr_peter]

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.

[tszaboo]

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.

[janoc]

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.

Those 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.

[SandunDhammika]

amyk: I need it to work on any random computer, so no real serial/parallel ports.

It's interesting that 10-15 years ago, this would be considered absurd.

(I still have two each of parallel and serial ports on my main machine, and it's only a few years old.)

My 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.pdf

From a latency standpoint, the performance may not exactly fit. For example, if all ports are active,
the maximum latency could be much greater than 4 microseconds for the Parallel port.

There 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.

[tszaboo]

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.

Those 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.

That 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.

[janoc]

Those 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.

That 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.

NXP actually ships part of their peripheral library in silicon This 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".

[lpc32]

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!

[rs20]

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.

How 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.

[tszaboo]

Those 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.

That 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.

NXP actually ships part of their peripheral library in silicon This 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".

I 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.

[janoc]

I suppose it is because the size of the Flash is small, and with the libraries you wouldn't have any space left.

Somehow 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.

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).

Urgh ... 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 ...

I think you can make mass storage, CDC and HID with it, but not HID keyboard or mouse, at least I found that impossible.

That'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. 

[lpc32]

rs20: No, the other PC aspects don't involve USB. I'll know more after I start playing with it.

[ve7xen]

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.

[lpc32]

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.