USB interface without a microcontroller

[jtruc34]

I'd like to make a USB joystick. I'm not sure yet what measuring technique I will use, but I'm hesitating between inductive sensing, capacitive sensing or a hall effect sensor. But in any case, I'll just need to send one analog measure for each axis over USB.

But what I want to focus on in this question is this very last part. I want to learn a bit more about USB interface and I would like to know if you think that it would be feasible without a microcontroller. I'm pretty sure that making it from scratch with discrete components will be far to complicated, but maybe there is a middle ground between extremely low level and extremely high level like an arduino.

Maybe there is an IC that act like a low level interface, that maybe handles all the timings and clock but that still needs you to specify every bit that you have to send (not necessarily exactly like what I describe, but just so you have an idea of what I'm talking about). Any idea?

Thank you

[ledtester]

A USB HID (human interface device) such as a joystick needs to send its position data back to the host computer in packets with a specific format. It also needs to respond to certain messages which are part of the general USB protocol.

That is, there is a bunch of complex protocol logic that is doable with a microcontroller and almosr impossible to do without one.

That said, one option is to get a commercial USB joystick and replace its analog sensors with your own. It's likely that most joysticks use resistive potentiometers and just read a voltage to determine position. If you can adapt your sensors to do the same thing it might just work.

[wraper]

I want to learn a bit more about USB interface and I would like to know if you think that it would be feasible without a microcontroller.

Not really for joystick. Even if you get something that will do USB interface thing for you, there will be microcontroller inside anyway. This asks for 8 bitter with USB interface like silabs EFM8UB10F16G or PIC16F1455. Both have USB joystick/HID code examples so you could work from there. Of course there are also ARM based projects like this: https://github.com/vostrenkov/EazyJoy

[wraper]

This might be the easiest. No need to write your own code. https://github.com/FreeJoy-Team/FreeJoy

[ataradov]

If you want to specify bits, then there are USB PHY controllers, like USB3300, for example. But you can't really control them from an MCU without ULPI interface. You would need an FPGA at least, since you need to provide bytes as they go over the bus in real time.

I'm not aware of any ICs that would let you specify the payload ahead of time over SPI or something like this. This can be implemented using an MCU with a USB controller, but it sort of defeats the purpose.

And there are projects of software-only USB LS implementations, like V-USB.

And MCUs in general are pretty low level if you don't use vendor stack, so starting with an MCU with a USB controller is not a bad move to learn about USB.

[S. Petrukhin]

Obviously, USB connectivity is not implemented by triggers/counters or other logic elements in a reasonable size.
But it seems to me that a person is not interested in implementations inside, but in the presence of chips that have already implemented the protocol. Such as, for example, CH340G. There's probably a small microcontroller inside, but it's a hardware solution for the user.

[wraper]

Such as, for example, CH340G. There's probably a small microcontroller inside, but it's a hardware solution for the user.

But it does not do what OP needs.

[Doctorandus_P]

I want to learn a bit more about USB interface and ...
 Any idea?

V-USB is is a good way to learn about the internals of how to use USB, as it's all in software and you don't have to think about or bother yourself with hardware implementations and special register bits. I'ts also quite well written.

It was also a quite amazing project in a time that microcontrollers wit built-in USB interface were rare, and it's still possible to use it these days of course, but for real life applications a microcontroller with built in hardware USB would be a much more logical choice. A "problem" with USB is that it is polled every milli second, which means that if you implement it in software, you have to chop the rest of the program in pieces that need less than a milli second to complete. Not very difficult for a simple interface such as a HID device, but a bit old fashioned these days none the less.

Doing USB without a microcontroller would be a weird situation. The protocol is simply to complex for a simple implementation. It's not like a UART for example which can be done with a shift register and some extra's.

For the rest I agree with the other posts. Skip "arduino" and dive into one of the many example projects for a uC with hardware USB that you fancy.

I also highly recommend to use Sigrok with one of those cheap CY7C68013A Logic Analyser hardware clones.
It is fast enough to capture low-speed USB (1.5Mbps), and with the software decoders you learn a lot of about the internals of USB, such as different packages, device recognition and initialisation, Headers of packets, bit stuffing, checksums and loads of other details.

[pigrew]

I'd really suggest using a microcontroller that already supports USB, but there do exist some USB interface IC with ADC or serial ports with can be paired with an ADC. The disadvantage with these "no-MCU solutions" is that you would need custom software running on the computer to submit the ADC read requests. This means that the joystick will not work with default USB HID drivers.

One solution would be the MCP2221 (not recommended for new designs) that itself contains an ADC.

You could also use a USB CDC<->UART converter (e.g. FT230X) with a UART ADC like ADS122U04IPW.

Again, none of these are a "good" design. Myself, I'd use something like a STM32F051 but the programming for that is non-trivial.

[wraper]

It was also a quite amazing project in a time that microcontrollers wit built-in USB interface were rare, and it's still possible to use it these days of course, but for real life applications a microcontroller with built in hardware USB would be a much more logical choice. A "problem" with USB is that it is polled every milli second, which means that if you implement it in software, you have to chop the rest of the program in pieces that need less than a milli second to complete. Not very difficult for a simple interface such as a HID device, but a bit old fashioned these days none the less.

First of all VUSB uses interrupts, so you code can run longer. Secondly, it's a low speed USB polled at 125Hz.

[S. Petrukhin]

Such as, for example, CH340G. There's probably a small microcontroller inside, but it's a hardware solution for the user.

But it does not do what OP needs.

I gave an example of a hardware solution. There is probably a similar ADC. I don't know, I wasn't interested. For a USB stick, it is quite enough - you can send the position without using the MCU.

[wraper]

Such as, for example, CH340G. There's probably a small microcontroller inside, but it's a hardware solution for the user.

But it does not do what OP needs.

I gave an example of a hardware solution. There is probably a similar ADC. I don't know, I wasn't interested. For a USB stick, it is quite enough - you can send the position without using the MCU.

No it is not, unless you want to write your own driver which will translate virtual com port into virtual HID device. Or if this will be used for your own application only. And you will still need the MCU anyway to send the data via UART instead of USB directly.

[jtruc34]

I realise I have never thanked you for your replies. Sorry! In hindsight, doing the USB part outside the uC is maybe useful for learning but actually quite boring. I have already messed with other simpler protocols, and while I could read the 200 pages USB specification, there are other things I would fancy learning first.

To get back to the original project, I don't think the actual uC is critical for that task, and I might use the first one I have on hand that satisfies the basic requirements.

What do you think about the sensing method? One big problem I found with commercial joysticks for flight simulation is the lack of resolution around the neutral position, and that the sensors (whatever is used) tend to wear out pretty quickly and become awfully laggy/noisy or just get a dead zone around the middle.

So, what do you think of the three methods I suggested: inductive (the moving joystick would move an iron core inside a coil), capacitive (it would move some metal plates, or I could just use a variable capacitor commercially available) or hall effect (I would put a magnet on the moving part and measure the magnetic field). Someone mentionned potentiometers, but I think they are the cause of wear and play on commercial joysticks.

The general problem is that a joystick for simulation have to be quite sensitive (I don't know if you've already flied a real plane, but on some small ones, just 5mm of movement on a 50cm yoke stick can already have an big impact, and that's just about 0.5°). I have too options: either the sensor is sensitive enough, and everything's fine, or I have to put some mechanical amplifications, and now I have to make an accurate, wear-free and play-free mechanical amplifier, which doesn't seem much easier without taking too much space.

What are your thoughts?

[ataradov]

Magnetic angle sensor ICs are reliable and wear resistant. They typically have < 1 degree resolution over the whole 360 degree range. With mechanical scaling it should be possible to get a really good resolution.

Look at ICs like AK7451 or MLX90365. One is digital with a serial interface the other one analog/PWM. There are others.

Those things are ver y reliable, their primary use is industrial and automotive. The disadvantage - they are not cheap and require special magnets to work.

I would not do custom inductive/capacitive sensing unless you are really into debugging flaky analog circuits.

[jtruc34]

Thank you for your answer. Why use a fully integrated sensor if I'm gonna need a uC anyway? Why not just use a hall effect sensor that just outputs a simple analog signal that goes into the ADC? Is it because of the limited resolution of the ADC or is there any other reason?

[ataradov]

Yes, you will need a separate processor. The issue with raw hall effect sensor is that it will be on you to do the DSP and filtering. Their output is noisy. This may require much faster processor than needed for a simple reading of the values and transferring them over USB. It is doable, but again it depends if you are into a lot of R&D to potentially save a few dollars.

You can certainly try with a simple hall effect sensor, it might work in your case.

[jtruc34]

Thank you. I will try (some day (I really need to focus on less projects if I want to finish just one)).

[ataradov]

I just looked it up and the price for fully integrated ICs is not that different compared to a simple hall sensor with analog linear output. For a hobby low volume project it is absolutely not worth it to reinvent the wheel.

Just sorting by price and skipping complete junk you can get this https://www.digikey.com/en/products/detail/ams/AS5600-ASOM/4914332 for just $3 in single quantities. Linear output sensor is at least $1. And the IC includes 4 sensors precisely located and provides nice digitized output over I2C.

[amyk]

FPGA or medium-size CPLD might be enough to implement a "hard wired" USB device, if you're really interested in doing it that way. But MCUs have gotten so cheap that trying to effectively make an ASIC is not cost-effective unless you are looking at a volume greater than millions or tens of millions of parts. (I believe the infamous FT232 USB-UARTs are hardwired; but all the clones are just mask-ROM MCUs.)

[jtruc34]

Well, I've been thinking about it a little, and I've come to the conclusion that my input is only going to cover +/-10°, which is only one eighteenth of the sensor scale, which would by a massive drop of resolution, wasting more than four bits. Even if the ADC has 12 bits, I'm back to less than 8-bits, which is definitely too low to my taste.

I could give some mechanical amplification, but not that much. Using gears, it would take to much space and would be to hard to avoid any play, and using a compliant mechanism is impossible/not practical to output 360°. I don't think an angle sensor is the right way to do it on its own.

Do you have any other idea?

[ataradov]

You are asking for an impossible or extremely expensive thing. There are no miracles, you have no option, but to do mechanical amplification. The quality of it depends on your manufacturing capability.

The most accurate sensors would be similar to the stuff used in digital calipers/dial indicators. This stuff - https://hackaday.io/project/511-digital-dial-indicator-cnc-surface-probe/log/814-the-digital-dial-indicator-and-how-to-read-from-it

But it would require custom boards and larger microcontroller to control a lot of I/O. And a lot of experiments to make it all work.

You can try to reuse the caliper board itself, but it would be bulky and mechanically challenging. And their update reate may be way too slow for this application.

But what I'm trying to say here is that there is no perfect and cheap off the shelf solution. Whatever you do will need a lot of R&D.

[jtruc34]

I understand I might be limited by what's possible at this price or R&D resource. But what I'm wondering is whether there is a way of optimising where I measure the magnetic field. If I place the magnet in the correct place, I could make the 10° movement completely swap the field from north to south. I could then use the full scale of the sensor, but then an angle sensor might not be the most adequate.

You said I could try a raw hall effect sensor, but that I might get noise problem. Isn't there a middle ground, that has all signal processing and AD conversion integrated but that doesn't output an angle?

From a quick look at the datasheet, I don't see immediately why this part wouldn't fit: https://www.digikey.com/en/products/detail/memsic-inc/MMC5603NJ/10452796

It's got a ridiculous 20-bit (which sounds definitely too high seeing the 0.1%FS repeatability) and up to 1kHz reading rate. I don't necesseraly need the 3 axes, but it's the cheapest I2C chip available. It's also not hall effect but resistive, but I don't really care, I guess.

As you have slipped the fact that my goals are too high, and that you're probably a ton more experienced than I am, I might have to think that I'm too optmistic, so, why is my solution not a solution?

[ataradov]

Angle sensor requires exact placement of the magnet and only rotation of the magnetic field. But I think there are linear sensors like this as well. The issue here is that the magnet still needs to move in a plane parallel to the IC. So, if you attach it to the other end of the stick, it will sweep a radius. And I have no idea how that will affect operation. Again, this is something you can find out by purchasing a bunch of different ICs and prototyping that. It is possible that some calibration is all you need. But it is also possible that sensor will go nuts and output incoherent data.  I don't think it is possible to come up with a good design for this without experiments on real hardware.

That IC might work, but the only way to know is to get it and see if it really works.

One more factor with all magnetic sensors is the quality and accuracy of the magnet itself. "Official" magnets for those rotary sensors are quite expensive. And I don't know if there is a real reason for this or just to charge more and random magnets would work too.  They are definitely magnetized  in a different plane than regular magnets you find everywhere, so this is something to keep in mind.

[jtruc34]

I do have the luxury to do some experiments, and I will, but I might as well clear the obvious mistakes and take profit from others' experience beforehand. That might also decrease the number of order I'll do and save me some money.

The thing is, I don't really care about the absolute accuracy of the measurement, I just want some number that's 0 in the centre and about FS when I bottom out the yoke. So, I don't really need to know if the sensor gives distance, angle, or just magnetic flux density. I'll post a drawing  of what I'm thinking about tomorrow or later this night if I can't sleep.

Thank you very much for your help again.

[ataradov]

I understand what you need. But I don't have a good 100% solution.

The sensor you have linked is really designed to sense Earth's magnetic field for navigation purposes. It will sense the external magnet's field, of course, but since it is not an official use case for the IC, it will be up to you to figure out if it works for that application. You would need quite a weak magnet. Typical Ne magnet would permanently damage that IC if brought close enough. So even here you would have to experiment.

And the calibration may also be an issue, since measurement would be affected by the Earth's magnetic field. The other sensors are explicitly designed to cancel out that field, this one is designed to measure it.