USB data pins driven directly by Zynq pins - Page 1
Forum section: electronics / general

author: RoGeorge
author_rank: Super Contributor
timestamp: February 23, 2021, 02:17:26 pm
content: I need a very cheap board with Linux, uSD, LAN, USB and a few I/O pins exposed. Not fancy or fast. For small home automation/sensing around the house. One option will be the EBAZ4205 used boards from former miners, for about $10-15. They have a Zynq7010 and plenty of I/O exposed, but no USB port onboard.All USB schematics I've looked up for other Zynq boards seem to use an extra USB transceiver chip, transceiver connected to the Zynq with many parallel I/Os, not just the two D+/D- USB data pins.Is there a way to connect D+/D- pins from the USB straight to FPGA I/O pins? If not, is there any other $10-20 board (not necessarily FPGA) that can run Linux and has uSD, USB, LAN and a few I/O pins?

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 02:35:16 pm
content: Quote from: RoGeorge on February 23, 2021, 02:17:26 pmNo.Quote from: RoGeorge on February 23, 2021, 02:17:26 pmDump the Linux and use any MCU board. It will probably be cheaper too.

author: tszaboo
author_rank: Super Contributor
timestamp: February 23, 2021, 02:47:02 pm
content: Quote from: RoGeorge on February 23, 2021, 02:17:26 pmProbably. Maybe you can port the V-USB drivers to an FPGA or cobble something together from opencores.But I would only do this, if the project goal is to connect USB directly to an FPGA. That's not what you want to do.This sounds to me like a project, where you buy a raspberry pi 4.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 23, 2021, 03:19:26 pm
content: Quote from: RoGeorge on February 23, 2021, 02:17:26 pmTo implement a USB host I suppose? USB 2.0 HS (High speed) without a proper PHY, I highly doubt you can achieve that. For USB FS only, that may be doable. I think some have managed to do it. Now good luck implementing the USB core for USB host support. An alternative would be to use an external USB PHY as you saw. But I don't know much about the Zynq. Does it have an integrated USB controller (without PHY)? Or would you have to implement that in HDL? Or are there ready-to-use IPs for that?Of course as said above, using an MCU instead would be much easier and make more sense.

author: RoGeorge
author_rank: Super Contributor
timestamp: February 23, 2021, 03:35:37 pm
content: Quote from: asmi on February 23, 2021, 02:35:16 pmThe OS request was for fast development, flexibility, available software, long term availability, remote admin, etc. That is why Linux might make more sense than an RTOS or bare metal C.Quote from: NANDBlog on February 23, 2021, 02:47:02 pmIndeed, writing a USB IP would be interesting. However, it will be very time consuming and a sidestep from the final goal. The plan is to cobble some automation around the house/garden/livestock/field crop and so on, on the countryside. An array of Raspberry Pi 4 will be too expensive and probably too power hungry. Maybe some Pi Zero W or alike, will consider that.Another option would be to come up with some cheap USB adapter that adds a few I/Os to an Android phone. Second hand Android mobile phones can be bought locally very cheap, sometimes available even for free.Google shows me tens to hundreds $ adapters.Are there any known solutions for USB to I/O cheap adapters for Android?

author: RoGeorge
author_rank: Super Contributor
timestamp: February 23, 2021, 03:36:52 pm
content: Quote from: blueskull on February 23, 2021, 03:25:24 pmGreat, thank you!

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 03:37:16 pm
content: Quote from: SiliconWizard on February 23, 2021, 03:19:26 pmZynq does have two USB UHCI's for USB 2.0, but they require external ULPI PHY. They are cheap (about $1 per chip for qty 1), but ULPI runs at 60 MHz, so some care is required to ensure signal integrity.As for "manual" implementation - there is a certain "type" of people who shove Linux everywhere they can, and it's not the type which would go about implementing USB physical signaling from scratch.

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 03:43:55 pm
content: Quote from: RoGeorge on February 23, 2021, 03:35:37 pmThat is a lot of words to say "I'm too lazy to do it right, so I will compensate my laziness with excess HW".Linux is almost always an overkill in embedded world, except for some odd cases.

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 23, 2021, 03:58:33 pm
content: Quote from: asmi on February 23, 2021, 03:37:16 pmWell. Indeed.

author: filssavi
author_rank: Frequent Contributor
timestamp: February 23, 2021, 04:16:51 pm
content: Quote from: asmi on February 23, 2021, 03:43:55 pmIf we followed that logic in my opinion anything other than a fully custom (that means no standard cell rubbish, only full custom layout) means you are too lazy to do it right, as such a solution will always have the most performing and power efficient solution, with the least amount of transistor, anything else is overkillSame with software anything else other than directly writing binary with an hex editor is lazy software development, an assembler is for pussiesAnd so om

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 04:22:53 pm
content: Quote from: filssavi on February 23, 2021, 04:16:51 pmhttps://en.wikipedia.org/wiki/Straw_manHere in FPGA world we work on a lower level than assembly - we use gates and flip-flops directly.Let me guess - you use Python for your embedded system, right?

author: RoGeorge
author_rank: Super Contributor
timestamp: February 23, 2021, 05:44:30 pm
content: Quote from: asmi on February 23, 2021, 03:43:55 pmYou steampunk, me cyberpunk!Steampunk:Cyberpunk:SCADA with some cheap DIY source of custom PLCs would be a good start, therefore Linux is a realistic request.https://www.google.com/images?q=SCADA

author: filssavi
author_rank: Frequent Contributor
timestamp: February 23, 2021, 06:19:33 pm
content: Quote from: asmi on February 23, 2021, 04:22:53 pmYou are almost right, I use JavaScript, python, system verilog and solder (ok that is maybe not programming)And I am a huge fan of using the right tool for the job, as Dave can no doubt attest, USB is a huge pain in the neck to get right, and powerful processors are ridiculously cheap, why anyone in its right mind would want to go through the pain of implementing a functional usb stack (that includes both sides firmware and pc driver）for multiple OSes maybe, when you can just use the Linux one that has been written by much better programmers than us, tested to death (compared to rolling your own) on milion of devices, and guaranteed to be maintained for much, much longer that your own version?Don’t assume that just because someone likes and can use high level tools such as Linux or python that means he does not know what an FPGA is, or even how a transistor works (and I am talking drift-diffusion, dopant concentration and the like)

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 06:34:21 pm
content: Quote from: filssavi on February 23, 2021, 06:19:33 pmQuote from: filssavi on February 23, 2021, 06:19:33 pmThere is so much wrong in this sentence, I don't even know where to begin...- What multiple OSes are you talking about?- I don't need a million devices, I only need to test on my own.- I disagree that Linux has been written by much better programmers than me. You, maybe(since you said it yourself)- I don't need somebody else's maintenance of OS because it's written by me.- You said powerful CPUs are cheap? How cheap they are for environment? What about power consumption? Thermal issues? But since you use script languages, you are unlikely to even think about these issues...Quote from: filssavi on February 23, 2021, 06:19:33 pmWell there is a strong correlation. Script kiddies typically don't really know what's really going on behind the code they are running, and in many cases it's not even their own code, but stolen from the likes of SO and tinkered with until it kind of does what is required.Maybe you are the exception to this, but again - accepting such waste makes me question that too.

author: filssavi
author_rank: Frequent Contributor
timestamp: February 23, 2021, 06:52:29 pm
content: Quote from: asmi on February 23, 2021, 06:34:21 pmFirst of all DONT EDIT MY QUOTES TO PROVE YOUR ARGUMENT quote the full context1) There are three major OSes Windows, MAC os and Linux, anybody serious enough will need a driver for all three, but even if you just target windows, unless you are doing something excedingly standard for which the generic microsoft drivers work well enough you will need to get your driver signed by microsoft to even load properly (ok you can turn on driver signing, but apart from being a big security risk is very painfull to do)2) Even if you need to do only a one off, you can test it to death, only to discovert 5 year down the line that the motherboard of your new laptop, due to a firmware bug, that all normal OSes work around for you, your device does not communicate anymore, and you have to spend a bunch of time re-familiarizing with your code (now tell me that you remember perfectly how all the code you have ever written works...)3) If you think you are a better programmer than the ones that work full time on the core of an OS kernel (be it microsoft, linux or even apple/BSD) you have a severe case of dunning kruger4) fair enough if that is your definition of fun5) I don't even know where to begin with this...The truth is that once your board needs to be used by even a small group of collegue (lets say 5/10) on their own personal systems (desktops, laptops) with different OSes,technical skill levels and in a work environement (so the thing has to be rock solid, not janky as hell) using a proper standard compliant implementation is the only way

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 07:07:38 pm
content: Quote from: filssavi on February 23, 2021, 06:52:29 pmOh, so you are talking about implementing USB device? In this case I just use FTDI chip and call it a day. What kind of "stack" do you need for that? Even feeble stm32f0 can do that ffs. I was talking about host side of USB.Quote from: filssavi on February 23, 2021, 06:52:29 pmAgain, more talk about USB devices. This is not relevant. And you don't need any OS for that for sure.Quote from: filssavi on February 23, 2021, 06:52:29 pmDo not make yourself an idol. I developed drivers for Linux and Windows in my career so I guess that makes me about as good as these guysQuote from: filssavi on February 23, 2021, 06:52:29 pmYeah, exactly. Let's use 10 W RasPI instead of 1 uW MCU because...Linux!Quote from: filssavi on February 23, 2021, 06:52:29 pmAgain, you are too fixated on USB client systems. I rarely do any of those, and in those cases I did require some comms with PC, I used COTS devices like FTDI FT230X, and so driver is not my problem.Besides, why do you even want Linux for client USB system? I can at least understand an argument for USB host support, but device? Like I said, stm32f0 can do that without any OS whatsoever, as do any of COTS USB interface chips (and latter will handle all driver issues too).

author: filssavi
author_rank: Frequent Contributor
timestamp: February 23, 2021, 07:39:37 pm
content: You are a bit too fixated on your own needs IMOIf you need anything more than a simple serial you are screwedEven if you don’t need any host side stuff (which I’m the real world you always do) usb device can still be a major PITAIf you need to transfer any significant amount of data which is not too uncommon with an FPGA based system both the FTDI and the UART on the other side will run out of steam and you will have to fall back onto regular usb protocolDo you need usb PD in order to avoid having a separate supply, again you need to deal with The USB protocol, and as Dave documented in the uSupply saga the code from vendors is usually janky as hell and only works with their test setupDo you want to make your device look like a USB drive, for ease of use (let’s say drag and drop the firmware file to program instead of using software) bingo you need to deal with the raw USBP.S not all kernel drivers are created equal the tiny Temperature sensor is as much of a driver as the whole graphics subsystems....

author: SiliconWizard
author_rank: Super Contributor
timestamp: February 23, 2021, 07:48:25 pm
content: asmi may be a bit extreme here, but still, I don't know what you're on about exactly.For implementing robust USB host functionality able to support a very large range of USB devices/classes, I agree that using an OS like Linux makes sense. If that's your use case, and want a board that can handle third-party USB devices of various classes, then I'd agree.Now for implementing USB *device* functionality, I can't see how Linux or a similar kind of OS could ever help.And you're taking examples like USB PD. Does Linux have USB PD support from the device side? How would Linux help here?

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 07:59:02 pm
content: Quote from: filssavi on February 23, 2021, 07:39:37 pmThere are FT60x devices which give about 2.5 Gbps of real-world bandwidth over USB 3.0, while requiring zero effort on a driver side, and a simple client using public API.So, no, you don't.Quote from: filssavi on February 23, 2021, 07:39:37 pmUSB PD has zero relations to USB protocol, it even uses different wires. You obviously don't know what are you talking about here.Quote from: filssavi on February 23, 2021, 07:39:37 pmImplementing USB device is not very hard in FPGA if you have ULPI PHY and ever bothered to read USB device class spec. The host side is much more complex.And I am at loss as to how Linux with help you with device side of USB.Quote from: filssavi on February 23, 2021, 07:39:37 pmWhat makes you think it was a temperature sensor?

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 08:06:40 pm
content: Quote from: SiliconWizard on February 23, 2021, 07:48:25 pmWhat's so extreme? Choosing to use slow-by-design script languages and compensating this slowness by using massively overkill CPU? Sorry, but I have no respect for script kiddies.Just so we're clear here, I'm not against high level integration, heck, I use Vivado's IPI all the time. What I am against is gross inefficiency-by-design. That's not engineering.

author: filssavi
author_rank: Frequent Contributor
timestamp: February 23, 2021, 08:45:47 pm
content: Quote from: asmi on February 23, 2021, 08:06:40 pmYou have no idea of what I do, why do you keep assuming, all my real time functions for my applications are implemented in logic in the FPGA, and it the control loops can be run at eccessive frequencies, multiple hundreds of kilohertz in the area optimized configuration, many megahertz otherwise, however I have still to find an application that needs that kind of frequency (and yes I need the FPGA, what I need to do can't be easily done on a microcontroller)I use python as the back end to the internal web application I use to control the whole system from any host PC, or should I use C for that, maybe even assembly, because lower level is better?Why did I chose a web app and not the usual crappy WPF application? this gives me easy cross platform capability, since I use both windows and linux as my primary OSes with zero upfront effortIt handles purely HMI functions, where the bottleneck is the human reflexes anyway why would I go through the pain of doing bare metal development on the zynq cores for that, reimplementing my own network stack, or high speed usb transfer protocol (I need bandwidth)? just because manly men use bare metal only?you seem to have a very narrow definition of embedded system.Now do you need Linux to implement USB device, of course not, however in geenral using an RTOS in that case would be a no brainer.In case of the OPs problem, whose platform is a repurposed recycled ZYNQ board I still think that the best course of action to connect it to the PC, is to put linux on the processor (even on a single one of the two cores if the other is needed to do bare metal for some reason) and use ehernet to connect it to the pc (point to point link, if intenet connection is not needed), If the OP is not particularily attached to USB for some reason.This way there is no need to solder wires, no need to implement usb device in logic, no software support, no nothing, it just works the power consumption of the chip, assuming no crazy logic is running in the FPGA will be in the order of few watts lets say 2 to 5, and apart from changing platform will not go down much lower than that as the cores use 1.5 watt (checked in vivado 2020.2 power advisor)This could be a great platform to learn FPGA development (implement your own I2C and SPI peripherals) and FPGA SoC workflows (connect the peripherals to the core either through bus or some other memory mapped interface)Now I could also give the standard forum response of, nevermind what you want to do since only I know the true way, thus throw away the ideas, completely change platform, buy an MCU, or better design your own PCB as only script kiddies buy ready made stuff and have and have fun doing your project as I want you to

author: tszaboo
author_rank: Super Contributor
timestamp: February 23, 2021, 10:18:08 pm
content: Quote from: asmi on February 23, 2021, 08:06:40 pmActually, it is engineering. You are making a trade-of of power consumption and speed, for ease of coding and maintainability of the software.So you can focus on the project, where it actually matters, instead of reinventing the wheel for the thousandth time.Dont worry, I was like you years ago. But then I grew up, and realized that the hardest part of engineering is to make the right compromises.

author: asmi
author_rank: Super Contributor
timestamp: February 23, 2021, 10:51:22 pm
content: Quote from: NANDBlog on February 23, 2021, 10:18:08 pm"Maintanability" of scripts is usually pretty bad. There goes a famous joke of "write-only" scripts, which were very common not too long ago. For some reason, most of scripts I ran across, tend to be a very loosely structured mess of very large functions all in the same source file. Maybe it's because of iterative approach, when each pass only adds a little bit of code, and so the fact that functions as whole have become unmanageable, it often lost as focus is on getting changes to work. And so over time these scripts grow to become a huge patchwork of barely working mess, which breaks if you look at it the slightly wrong way.Quote from: NANDBlog on February 23, 2021, 10:18:08 pmNobody is talking about reinventing wheels over here. We're talking about picking the right tool for the job, and not using a single hammer for everything from nails to screws.Quote from: NANDBlog on February 23, 2021, 10:18:08 pmSave that patronizing for your kids pleaseI don't need any of that.Do you think it's a coincidence that vast majority of those script kiddies resort to scripts simply because they don't know any other way? I've seen all-too-many of those in my career already, co-ops love it. Since I was tasked to teach them real engineering, I had to break some bad news to them about those RasPI scripts. The good news is some of those coops were willing to come back to me for another term, and yet some more of those later came to work there. So I guess that means they found my teaching useful enough for their careers.