There does appear to be an issue with the Windows 10 serial driver (also see MSDN). The workaround that we use is sending at most 63 bytes (in one packet) per USB frame. This results in 1 packet per transfer and 1 transfer per frame. Usually microcontrollers have some sort of SOF interrupt or callback that can be utilized to implement this.
USB / USB OTG doesn't give you much of an option here – the device never powers the host, so you can't charge your tablet while it's the host to an OTG device – at least as long as the tablet behaves standards-compliant (and I'd argue doing that here would be a very good idea, because drawing power from a device sounds like a very bad idea if the device ...
Are there standard error codes or are the error codes manufacturing / instrument specific?
Having worked with SCPI for over 20 years, I have never seen such a thing. Maybe "0" for "No Error" is widespread enough to be considered a standard.
Even if there were, most likely only Keysight and National Instruments would follow the standard.
The USB connector on the Nucleo board goes to a separate ST-LINK programming MCU (F103) which provides the ST-LINK and serial port functions over USB.
The F103 connects to the target F401 via UART. The F401 does have an USB interface, but it is not wired to any USB connector on the board, so you cannot use direct USB connectivity with the F401.
So basically, ...
Yes, to create Hardware independent and easy to reuse application, it will be good to utilise UART peripheral of MCU and USB-UART interface adapter(CP210X based are good ones).
That way even if you change hardware in future, you software application will stay same as almost all MCUs provide UART peripheral.
Technically there's no such thing as "UART over USB".
What does happen is sending comparable data, sometimes with a custom USB scheme (most USB-interfaced UART chips), sometimes with the more standard CDC/ACM meant as a serial-port replacement for things like mobile data modems, but also sometimes used by MCU's with an on-board USB engine.
From a ...
These colors are non-standard. Welcome to the bad news.
Black and white are clearly ticker than blue and red, your first bet would be white and black to be power. You can use a voltmeter to distinguish between +/- . If the power brick is plugged to the wall and everything "floats", the voltage between black and white should be around 5V. The white ...
The White and Blue are not D+/D- wires. They are likely CC1 and CC2 wires. Try to solder them as such to your breakout connectors if you want the charger to operate in standard functionality.
If you want the charger to just output the default +5V, try to pull down one (or both) blue/white wires with 5.1k resistors to ground. Type-C ports/chargers enable ...
How is USB C able in practice to be so polyvalent?
It was designed that way. And because it has multiple wires/channels that can be reconfigured as needed.
Do all the converters communicate with the port using a single protocol like HID to register their type and bring up the appropriate driver and message format? How is it implemented roughly?
I wouldn't ...
The constructed circuit is correct!
After repositioning the bypass Capacitors to a closer distance, problems with the recognition in Simplicity Studio and general of the chip have disappeared.
My Capacitors wouldn't work with a trace length greater than 3 cm. (Doc.CP2102N Data Sheet: 2.1 - Figure)
Additionally I couldn't get the chip working when ...
For the first errors you appear to have the pins flipped so the active end is not out. Therefore they are not connected even though they look (almost) like they are.
Using a metric grid for the schematic sounds like a way to have a bad day. You appear top have a display grid that's not aligned with your snap grid, for whatever reason.
I would try removing the oscillator and mount it to a different part of the board with some wires. It may affect the oscillators performance but it should help you prove if the oscillator is the issue.
By the way, why do batteries even puff up?
Lithium-polymer batteries 'puff up' when some of the electrolyte decomposes into gas. This can be caused by over-voltage, over-discharge, high temperature (ambient or self-heating at high current), poorly formulated electrolyte or mechanical damage.
Combination of high temperature and high voltage exacerbates ...
None of the USB specifications involve directly charging the battery, rather they supply power to a battery charge supervising circuit inside the device.
Damaging a battery by overcharging, overdischarging, charging after overdischarging, etc, is the fault of the charge supervisory circuit or a defect in the battery itself, not the external power supply.
Unfortunately, I don't think you're going to be able to. Your USB-C power adapter probably uses the USB Power Delivery standard, which requires the use of USB-C. Your fast-charge compatible wireless charger can't use USB PD, since it isn't using USB-C, so it probably is using Qualcomm QC, which is incompatible with USB PD.
[I'm the OP, answering my own question]
I just found this old question of mine which I had long forgotten. Finally I ended up switching microcontroller for one requiring only 3.3V, and I had only one small chip left requiring 5V. Moreover, as pointed out by thisjt, using a diode on the USB power rail was probably not a good idea. So, in case someone finds ...
You have powered the AVR with 5V from USB so it uses 5V IO voltage. USB data pins are 3.3V signals and your schematics have nothing to limit the voltage except the 68R seris resistors to limit the current to 25mA so unplug the device before it damages your PC.
If the USB port of PC is not yet damaged, there are other reasons as well. The fuse bits must be ...
My assumption is that LUFA library helps to add software support to AVR which Don't have this kind of capability.
From the LUFA documentation, first sentence:
LUFA is an open-source USB library for the USB-enabled AVR microcontrollers,
So, this is only working on the chips that have USB hardware. Having some hardware doesn't mean you can ...
It would be interesting to know if my hunch is correct or is it really
possible to do USB completely in hardware and how?
It's possible, but the FPGA would need differential transceivers that support 480MHz for USB 2.0, and I suppose that a clock running at 240MHz or more. Because this is difficult for many FPGA's most designs use UMTI which parallelizes ...
Good shielding simply means good shield continuity. The PC board usually doesn't even figure in any of it - for shield continuity, you should mentally replace the board with an insulator. For purpose of analysis, replace the board with a piece of bare FR4, no copper, just holes and epoxy used to fasten the connectors. The shielding between all shielded ...
USB2 speed-defining pull-up is a function of a device itself (which should be on the right-side of your schematics). Type-C by itself does not care about USB communication, it is an independent connector specification. The two 5.1k pull-downs on your schematics do define the device function, it is sufficient.
If you want to get high speed operation then you will need to use controlled impedance tracking. These are 'ordinary' in the sense that they are still signal interfaces. They are not ordinary in the sense that they are more constrained than other routing.
Full speed (12 Mb) can use less rigorous layout.
USB 2 does not imply that high speed signalling (480 Mb)...
It depends on many factors, like what chip are you connecting to, and how long is the distance from connector to chip, and whether you want it to work reliably, or have to pass the compliance testing.
The resitors depend completely on the chip if it requires resistors or not. Some do, some don't.
The USB interface is a differential signal, so it requires a ...
so there are surge protecting devices for 5V and USB - just a quick pick from a supplier I know: https://www.bourns.com/docs/product-datasheets/cd143a-sr05lc.pdf?sfvrsn=3be0efe9_6
But this is the very last resort and the smaller the devices are, the less energy over time they can absorb.
Don't know which country you are from, but here in Germany there are so ...
I would like the host system's Linux to use PPP to connect to the internet via the module and to be able to send/receive SMS at the same time.
So, the usual: AT commands for both
So, I will need at least 2 USB virtual ports for these two capabilities.
no, why should you?
Modems have (and have had since AT commands became a thing) something called "...