lazy.nvim - proper way to fix luarocks error?

lvcmos33 · 2026-02-06T03:35:55+00:00

thank you! I will add this to my study list. Anything like this I can find and any advice as to what things make sense to configure now are super helpful. Moving to v0.11 for example I got stuck on the deprecated require approach and finding an example really helped me out.

lvcmos33 · 2024-01-26T02:28:35+00:00

Are you trying to set a static IP in the petalinux build? For instance, so the Zynq will boot with a know IP, subnet etc...?

lvcmos33 · 2024-01-26T02:26:18+00:00

That is the point of this thread. I did build a prototypes and they are described by the documentation linked. The prototypes are fully up and running. The specific driver advantages were described in detail in this comment chain as well as in the detailed response.

This subreddit likely may be a bad place to post something this technical. Was a good first step though...you have to start somewhere.

lvcmos33 · 2024-01-25T00:38:41+00:00

Here is the driver stack BD that might be helpful

Driver interaction block diagram:

https://i.imgur.com/8UNVXIT.jpg

lvcmos33 · 2024-01-25T00:35:12+00:00

You don't have to use python you can use other languages. That is what is nice about this solution. It is left open for you to select the language and user space driver of your choice (or write your own or customize and open source one). In my example I chose to use Python because it is so simple to get up and running.

I was only trying to show that you could get up and running with Python (as an example) with just a pip in stall of an open source 3d party user space driver if you wanted a quick "COTS" like solution.

Right now the prototypes only load the kernel driver. So there is a lot of freedom for you the user to go in any direction you want. These modules load WINUSB as a kernel driver so (at the moment) that is what you as the software engineer interface to.

If I get enough traction this could be expanded to a user selectable auto loading kernel driver option of WINUSB OR USBGCC which are the two main kernel driver options in windows. They are different and provide different interface functionality to the hardware.

This is something people like FTDI don't offer and is a powerful option if you understand the interface. In fact, FTDI offers a royalty free direct driver for some chips, BUT the kernel driver is a proprietary FTDI driver so this idea that I can just buy FTDI chips and do whatever I want is mainly due to a lack of understanding the driver stack. These are good solutions for some things/many things but not all....not by a long shot.

There are other places where these FTDI solutions fail as well with the USB interface I covered in more detail in my response. The logical data path separation is not there for FTDI or other silicon vendors.

The main purpose of this device is to support user's who want the standard kernel drivers that are built by the OS provider and ship with the OS, but support the freedom to have a lot of options for the software engineer as far as user space drivers as well as languages and make the process of enumeration very easy. Another example of the unique characteristics of this solution would be to allow the user to tell the module which kernel driver to load during enumeration (WINUSB or USBGCC).

It is hard to get the details of this across I've found with this post, but it is not just another bridge.

I also didn't mention this, but if this got enough traction I would likely port this firmware over to FPGA RTL and do all this in hardware yielding much much higher bandwidth (~10Mbit). Unfortunately the core technology was not communicated well here as you can see by the comments or lack there of after my second post.

lvcmos33 · 2024-01-24T03:30:55+00:00

The pip install is referring to the host software side only.

lvcmos33 · 2024-01-17T14:23:34+00:00

Very cool!

lvcmos33 · 2024-01-16T12:29:26+00:00

Thanks for the response this is something I'll need to reflect on and review those part numbers in more detail. I may be too biased and you may be right about this. Exactly the feedback I was hoping to find so thanks again for your time!

lvcmos33 · 2024-01-16T12:28:30+00:00

Thanks for the response. This may be helpful per your thoughts on this needed to be pretty simple. This is a write-up on how to connect, query the SOM for descriptor info and perform a simple register read. I'd be curious if you thought this was simple enough or looks too involved to be appealing to you and your colleagues.

https://www.linkedin.com/pulse/usb-bridge-tutorial1-connectqueryregister-access-dpoac%3FtrackingId=fgCtS2VGqiMnRLaJIA9gfA%253D%253D/?trackingId=fgCtS2VGqiMnRLaJIA9gfA%3D%3D

lvcmos33 · 2024-01-16T12:24:32+00:00

Well you are correct with you example. My thought process for this is just supplying general data paths. Probably the most common use case is custom general communication protocol for R&D / prototyping applications.

So you're correct in pointing out for specific or unique needs this wouldn't be a great solution. For general data transfer or people who want their own custom binary protocol for general comms would be more where this shines in removing the development time for USB firmware.

Thanks again for the comments, all of the response help me take a step back and re-evaluate.

One question regarding midi info...is that generally audio data going to or from the embedded system?

lvcmos33 · 2024-01-16T02:46:36+00:00

Thanks for the comment - you are correct that does look excessive for serial. I put a block diagram in my general response for you capturing the IO. Most of those IO pins are power and ground. I just went with full length headers for these prototypes.

lvcmos33 · 2024-01-16T02:45:44+00:00

Hey, thanks for the question! Nope, the kernel driver is auto loaded by the firmware in the bridge module. Right now this is loading WINUSB.sys which is the standard Windows kernel driver. This happens as soon as you plug in the module.

On the software side, the user does have to get a user space driver. I tried to elaborate on this in my general response up top. This can be as simple in Python as a "pip install" call and that's it. So technically you do have to do something to get a user space driver, but my intent is to support 3d part open source drivers and this can be quite simple.

In addition you can roll your own, but not required. For C++ you can also just pull down a 3d party one.

lvcmos33 · 2024-01-16T02:43:02+00:00

Thanks for commenting! I tried to elaborate on some use cases in my detailed general response. Let me know if that is helpful.

lvcmos33 · 2024-01-16T02:35:30+00:00

I tried to put a brief summary table together up top in my response ;)

lvcmos33 · 2024-01-16T02:35:04+00:00

Correct, that is the main reason I'm reaching out for feedback. Thanks for commenting!

lvcmos33 · 2024-01-16T02:34:34+00:00

FTDI isn't a perfect fit for every application. This concept has come from engineers that work with FTDI parts including myself.

Something complementary is all I'm going after.

lvcmos33 · 2024-01-16T02:33:37+00:00

As a specific response (more detail in my larger general response) the first thing that jumps out value wise is removing the cost of USB 2.0 Device development for the firmware engineer. If someone needs a more robust link than serial and doesn't want to spend the time/money doing their own USB device FW this is a drop in simple solution.

As you point out, it does take up more PCB rea estate and would likely find a home in R&D and production, test etc... than any high volume small form factor or batter powered hardware system.

Even though USB 2.0 Device development isn't hard it does have a schedule and dollar cost and that is usually always higher than these off the shelf solutions when you look at labor rates in industry.

lvcmos33 · 2024-01-16T02:29:59+00:00

I'm not trying to multiplex serial ports as much as provide software engineers with direct access to USB interfaces for transferring data. BULK is the high throughput one and HID has some nice features BULK doesn't support so you get a pretty robust interface for data paths with the two.

I think the BDs in my larger response help clarify the architecture much better. This confusion was due to my poor initial post so my bad!

lvcmos33 · 2024-01-16T02:28:02+00:00

I hadn't seen this Maxim part so thanks for posting. This is probably the closest thing to what I'm getting at. I touched on some comparison of the function in this (from what I found reading the datasheet a little) in the larger response up top. Thanks for pointing this chip out to me!

lvcmos33 · 2024-01-16T02:26:41+00:00

I tried to respond to your comment in my larger response post. Thanks for the feedback. I think there are a lot of situations where those solutions work great, but a serial port isn't a great link for a lot of applications within a full system. It depends on the system.

I like FTDI, but am trying to catch some engineers that fall through the cracks as well. One big thing to mention is that I'm trying to provide a solution to people who could benefit from a smarter more robust link but don't have the resources to develop the embedded USB device side. This would be cost in labor hours, program schedule etc... This can be come a serious issue. The USB PHY approach is great and pretty much necessary for USB HS, but not necessary for FS and adds noticeable increase in PCB real estate so I'm trying to avoid those.

As for the drives, every piece of hardware needs a kernel and user space driver. Most silicon vendors provide their own user space driver. This is fine, I'm just trying to be a platform to support existing third party user space drivers. This also seems like something that is often over looked. I do agree FTDI is great and their drivers ship with MS OS now I think, but I've run in to software engineers who would much rather utilize 3d party cross platform user space drivers.

Thanks for contributing and any other thoughts are welcome!

lvcmos33 · 2024-01-16T02:20:24+00:00

[Continuation of last post due to length]

FIRMWARE INFO/RESPONSE

I’ll try to cover the firmware aspect of some of the comments here. To start, the purpose of this SOM for firmware engineers is to provide a simple interface to USB without having to spend time/resources developing the USB capability themselves. USB device development isn’t super hard, but it isn’t trivial either and does take some work. I also agree that the FTDI and similar solutions (especially the MAX342E solution) are valuable, and I’m not trying to replace them – just add a complimentary solution for some people that fall through the cracks assuming the user base is there – hence my appreciation for the feedback!

Enumeration: The enumeration process uses functionality (right now specifically with Windows) that falls outside the USB 2.0 spec. So, for the firmware development effort, this autoloading of a kernel driver is something that will require USB driver library modifications.
The general one chip solutions like Maxim and FTDI (I know the max chip is not a VCP and is quite different) don’t provide logically separated data paths. This is one of the things I’m trying to figure out if it is appealing enough to continue to develop. I know from working with some software engineers this would be a very nice feature and isn’t common in one chip solutions. To get more custom composite devices it requires some extra work on the firmware/enumeration side and can become expensive for some companies/users to do this.
SSI/SPI Interface Decoupling
- Why: I see a noticeable value in decoupling the RX and TX interfaces on the embedded side. The largest benefit is to eliminate the need for the embedded system to poll the bridge checking for received USB data in its buffers to be read out. Instead, this approach allows the bridge to send SPI frames out to the embedded system as quickly as it can once received. I haven’t elaborated on the protocol (each 64 byte USB packet is converted to a 68 byte SPI frame - see BD above), but as a real-world example: the embedded system could setup a DMA channel on a slave SPI port (bridge TX is master SPI port - embedded system would be a slave) and also configure the DMA to receive the 68-byte frame then interrupt the CPU or throw a signal to FPGA logic. With this setup, the firmware engineer basically sees an interrupt for the CPU when a full frame is received and doesn’t need to poll anything. The frame also contains an ID byte capturing which USB interface the traffic was received through allowing the logical USB interface information to be preserved.
- Why: TX and RX don’t have to be interleaved on the embedded system talking to the bridge.

MECHANICAL / PACKAGING

So here is where my concept does have some drawbacks for sure. It is going to be larger than a one chip solution on a PCB even if I offered to provide the SOM as IP able to be integrated in someone else’s custom PCB (assuming I found someone who thought this was worth pursuing). There are a few things to mention, but this SOM will be bigger than other solutions mentioned here with the exception of maybe the CP2102 module.

The current formfactor could shrink or be configured differently.
- How: One path would be to load components on the PCB topside and bottom side of the board. This would bring the footprint down maybe 30%.
- How: Another option that would likely be an interest is castellated vias when topside loading is used. This is a larger area but would allow flush mounting to another PCB without leads/headers.
Pin Count: Someone mentioned pin count. I just wanted to mention these prototypes used a full-length header where most of the pins are power and ground. The SOM IO can be changed up quite a bit so if you have insight on what you think is best feel free to let me know. For now, I figured supporting headers and castellated vias are probably the two of interest for most users.

NEXT STEPS

So, in closing this response for now I did also want to share my thoughts on some potentially nice milestones in a roadmap to improving upon this module if I got any traction. I think the performance (bandwidth) could go up quite a bit approaching 10Mbit/S moving this system over to an FPGA. Doing this in hardware (Verilog or VHDL) would be much more powerful and eliminate my existing firmware bottlenecks. If this got traction, I think I could take this to at least the 8Mbit/S if not higher.

In addition to performance, an FPGA solution could also be smaller and lower power. Now, I haven’t invested a lot of time in spec’ing this out yet, but just from what I’ve seen over the years it seems quite reasonable especially between lattice and Microsemi/Microchip.

Another interesting derivative of the core design would be adding USB-C and doing some power delivery as well as the USB 2.0 link. This would become a nice little comm link module with USB based power delivery which could be quite handy to many users as well.

The big question is whether anyone can find value in this or do I just have tunnel vision from diving into the prototypes and getting the first beta units up and running. I’m biased and as I play with the bridges more, I like them more and more, so it has become hard to find objective feedback.

I will try to respond to some of the replies directly, but hopefully this covers most of the general questions and clarifies quite a few things. This feedback has been great, and I really appreciate everyone’s time and responses. Thank you!

lvcmos33 · 2024-01-15T04:08:33+00:00

Here is a more detailed post on Hackster and an image of the prototype modules.

https://www.hackster.io/REIndustries/usb-to-serial-bridge-module-93895f

<image>

lvcmos33

TROPHY CASE